DNG and badpixel.bin questions - page 2 - General Help and Assistance on using CHDK stable releases - CHDK Forum supplierdeeply

DNG and badpixel.bin questions

  • 12 Replies
  • 4108 Views
*

Offline srsa_4c

  • ******
  • 4263
Re: DNG and badpixel.bin questions
« Reply #10 on: 22 / July / 2013, 12:55:03 »
Advertisements
and tools (compiled show_bad_b) were removed from servers.
There is a modified(?) version of the show_bad utilities in source form here: http://chdk.setepontos.com/index.php?topic=3459.0
I haven't tried to use them, so I don't know whether they work. They do not support your camera at the moment.

Edit: the functionality of that badpixel.lua script is now a built-in feature of CHDK ('create badpixel.bin' in the menu).
« Last Edit: 22 / July / 2013, 12:57:37 by srsa_4c »

*

Offline srsa_4c

  • ******
  • 4263
Re: DNG and badpixel.bin questions
« Reply #11 on: 08 / November / 2013, 06:15:21 »
Resurrected again.
The following has been bugging me some time now, so I decided to ask.

https://trac.assembla.com/chdk/browser/trunk/core/raw.c?rev=3168#L342

"point" uses ints as pixel coordinates. Is there any reason not to use shorts instead? That would reduce memory allocated to bad pixel information by 33%.
edit: I see this is only for the text based badpixel list, but the question still stands.

The other question is, why has DNG_VERT_RLE_BADPIXELS (and the code behind it) disappeared? The define is still there in some ports' platform_camera.h, and I was surprised to see that none of its related code exists.
edit2: it hasn't, it's done by default
« Last Edit: 08 / November / 2013, 06:34:17 by srsa_4c »

*

Offline reyalp

  • ******
  • 12690
Re: DNG and badpixel.bin questions
« Reply #12 on: 08 / November / 2013, 15:56:41 »
"point" uses ints as pixel coordinates. Is there any reason not to use shorts instead? That would reduce memory allocated to bad pixel information by 33%.
edit: I see this is only for the text based badpixel list, but the question still stands.
I don't think there is any reason not to, but the number of hot pixels unknown to the canon firmware is generally quite low.

The memory use could be reduced further by putting them in a single buffer instead of a linked list. A pass through the input file counting newlines would give you the max buffer size, and should have a negligible performance cost.
Don't forget what the H stands for.

 

Related Topics