Adding new cameras, applying patches into trunk (with source code prepared) - page 127 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 122 123 124 125 126 [127] 128 129 130 131 132 ... 169   Go Down

Adding new cameras, applying patches into trunk (with source code prepared)

  • 1685 Replies
  • 845914 Views
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1260 on: 13 / November / 2013, 19:43:58 »
Advertisements
Quote from: srsa_4c on 13 / November / 2013, 11:10:27
Can somebody upload a real life badpixel.bin made on a CMOS camera (preferably after the fix)? I'd like to test something...
Sorry - not much help here.  Tried it on my only CMOS sensor camera (SX50 with BSI-CMOS sensor) both with and without the patch.  I get a zero bad pixel (and therefore zero file length badpixel.bin file) report from the camera either way. 

Note : camera has to be in P mode - creating badpixel.bin fails in AUTO mode.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1261 on: 14 / November / 2013, 03:00:52 »
Quote from: srsa_4c on 13 / November / 2013, 11:10:27
Patch to fix a regression in raw_init_badpixel_bin() - CHDK 1.2 and 1.3.
Code: [Select]
Index: modules/dng.c
===================================================================
--- modules/dng.c (revision 3220)
+++ modules/dng.c (working copy)
@@ -845,6 +845,7 @@
                     fwrite(c, 1, 4, f);
                 }
                 count = count + len;
+                y += len - 1;
             }
         }
     }
Can somebody upload a real life badpixel.bin made on a CMOS camera (preferably after the fix)? I'd like to test something...

Thanks, can't believe I missed that :)

Added in revision 3221 (trunk) and 3222 (release-1.2).

IXUS310 badpixel.bin files attached (after patch).

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline nocaC_230

  • *
  • 27
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1262 on: 14 / November / 2013, 03:05:36 »
Sorry for my late reply!

On SX230HS 1.00c no Error.

By
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1263 on: 14 / November / 2013, 11:22:11 »
@philmoz, @nocaC_230
Thanks for the files.

@nocaC_230
Don't forget to update your dng module ;) The issue knocked out the RLE compression of repeating bad pixels and made the camera report a higher badpixel count.

00000000  78 00 55 00
00000004  78 00 57 00
00000008  78 00 87 00
0000000C  78 00 FD 03
00000010  78 00 4F 06
00000014  78 00 20 67
00000018  78 00 21 47
0000001C  78 00 22 27
00000020  78 00 23 07
00000024  78 00 04 08
00000028  78 00 1C 29
0000002C  78 00 1D 09
00000030  79 00 AE 00
00000034  79 00 4D 01
00000038  79 00 E0 23
0000003C  79 00 E1 03
00000040  79 00 E3 03
00000044  79 00 E7 03
00000048  79 00 04 64
0000004C  79 00 05 44
00000050  79 00 06 24
00000054  79 00 07 04

Quote from: waterwingz on 13 / November / 2013, 19:43:58
Tried it on my only CMOS sensor camera (SX50 with BSI-CMOS sensor) both with and without the patch.  I get a zero bad pixel (and therefore zero file length badpixel.bin file) report from the camera either way.
Don't know how new cameras behave, it could be that bad pixels are now corrected before they reach the RAM...
Logged
*

Offline nocaC_230

  • *
  • 27
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1264 on: 14 / November / 2013, 16:29:29 »
@srsa_4c

Thanks for the tip.
Quote from: srsa_4c on 14 / November / 2013, 11:22:11
Don't forget to update your dng module ;) The issue knocked out the RLE compression of repeating bad pixels and made the camera report a higher badpixel count.
w new cameras behave, it could be that bad pixels are now corrected before they reach the RAM...

However, it is always displayed the same number of bad pixels.

It seems that
Quote
y + = len - 1;
has no effect on the number of bad pixels. At least not in my camera.

Bye
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1265 on: 14 / November / 2013, 16:42:39 »
Quote from: nocaC_230 on 14 / November / 2013, 16:29:29
@srsa_4c

It seems that
Quote
y + = len - 1;
has no effect on the number of bad pixels. At least not in my camera.
The above hexdump is from the start of your file. The red blocks are "wrong", only their first line (4 bytes) should be present in the file when you re-create the badpixel.bin with the fixed dng module.
Logged
*

Offline nocaC_230

  • *
  • 27
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1266 on: 14 / November / 2013, 17:16:07 »
@srsa_4c

With the old configuration data, it did not work. Now I have downloaded the latest dng.c and creates a new badpixel.bin.

This version seems to be better. But some red blocks are still found in the hex dump.

Bye

Attachment: New badpixel.bin
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1267 on: 26 / November / 2013, 11:57:28 »
Attached is a patch for finsig_dryos to include ARAM_HEAP_START and ARAM_HEAP_SIZE in stubs_entry.S. I have intentionally not checked it in myself, in case the output or the code is not optimal.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1268 on: 27 / November / 2013, 00:20:32 »
Quote from: srsa_4c on 26 / November / 2013, 11:57:28
Attached is a patch for finsig_dryos to include ARAM_HEAP_START and ARAM_HEAP_SIZE in stubs_entry.S. I have intentionally not checked it in myself, in case the output or the code is not optimal.

If these are written as 'DEF()' macros to stubs_entry.S then we should be able to remove the makefile related stuff for them. Might simplify usage.

Won't work as DEF macros - ARAM_HEAP_START is needed to set MEMISOSTART in the makefile.

Phil.
« Last Edit: 27 / November / 2013, 02:35:56 by philmoz »
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1269 on: 29 / November / 2013, 17:34:31 »
Quote from: srsa_4c on 26 / November / 2013, 11:57:28
Attached is a patch for finsig_dryos to include ARAM_HEAP_START and ARAM_HEAP_SIZE in stubs_entry.S. I have intentionally not checked it in myself, in case the output or the code is not optimal.

Added to trunk in revision 3252.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
Pages: 1 ... 122 123 124 125 126 [127] 128 129 130 131 132 ... 169   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal