badpixel.lua dissection

MidnightLightning

4

« on: 05 / March / 2010, 09:47:07 »

Advertisements

As I'm trying to solve my own problem with getting a badpixel.bin file for my SD450, I'm dissecting the badpixel.lua that came by default in the 1.00c download for this camera, and have a few questions on it.

Here's the main "get_bad_count" function, with my comments added:

Code: (lua) [Select]

function get_bad_count()
 a=get_raw()		-- Save current "RAW enabled?" setting
 set_raw(255)		-- Turn on RAW capture
 set_tv96_direct(96)	-- same as "set_tv 1"; sets the shutter speed to 1/8"
 shoot()		-- Take a picture
 b=get_raw()		-- Current "RAW enabled?" setting; should still be 255?
 set_raw(a) 		-- Set "RAW enabled?" setting back to the original
 return b		-- Return 255?
end

Firstly, since there's a known issue with the SD450 models not liking the "shoot()" command, and the suggested change is 'click "shoot_full"', why is the default script included with the download for this model including that command? I had my camera hang on the script execution until I changed that line.

Then the script executed, and from further down the script, I see that it pulls a file from "A/CHDK/bad_tmp.bin" to save in "A/CHDK/badpixel.bin". But in that "get_bad_count" function, I don't see anywhere that actually saves a bad_tmp.bin file. Is that file automatically created when a RAW image is saved?

Additionally, what is the purpose of the "b" variable in this function? It seems to always grab the current setting of the "RAW capture enabled?" setting (which is 255, from a few lines above), and return that. And that seems to be the case, since my camera is reporting that I have "255" bad pixels, each time I run the script, which is an echo of the return of the function, which is 'b'. Now, I'm gleaning that from the fact that the UBASIC documentation indicates "set_raw" and "get_raw" deal with the enabled/disabled state of capturing RAW images in addition to JPEGs; I could find no reference to a LUA function of the same name, and whether or not it does something different. It would seem to me that the value for "b" needs to be fetched from some function that grabs the number of dead pixels the camera's native firmware thinks there are, but is "get_raw" the proper function for that?

« Last Edit: 05 / March / 2010, 09:49:45 by MidnightLightning »

Logged

ewavr

1057
A710IS

Re: badpixel.lua dissection

« Reply #1 on: 05 / March / 2010, 12:50:23 »

My comments:

Code: (lua) [Select]

function get_bad_count()
 a=get_raw()		-- Save current RAW setting
 set_raw(255)		-- Turn on special "bad pixel mode"
 set_tv96_direct(96)	-- sets the shutter speed to 1/2"
 shoot()		-- Take a picture,  detection of bad pixels and create "A/CHDK/bad_tmp.bin" file (inside CHDK core)
 b=get_raw()		-- save bad pixel count to "b" variable
 set_raw(a) 		-- setting back RAW state to the original
 return b		-- Return bad pixel count
end

See core/raw.c file

Code: (c) [Select]

    // ! ! ! exclusively for special script which creates badpixel.bin ! ! !
    if (conf.save_raw==255) conf.save_raw=get_bad_count_and_write_file("A/CHDK/bad_tmp.bin");

Logged

MidnightLightning

4

Re: badpixel.lua dissection

« Reply #2 on: 06 / March / 2010, 10:41:53 »

Thanks ewavr! So, the code should be intercepting the '255' as a special value (instead of 0 or 1 for on and off?), and then replacing that 255 with the contents of the get_bad_count_and_write_file() function. But since my camera is always returning "255", which is the original 'special flag' value instead of a much higher number (one thread I came across said dead pixels should number in the thousands?), could that indicate that the source code is not compiled correctly for the version I downloaded? I grabbed the compiled package from http://mighty-hoernsche.de/bins/ixus55_sd450-100c-0.9.9-875-full.zip; is this a bug for that package? Maybe I'll try compiling from source and see if that works out better.

Logged

fudgey

1705
a570is

Re: badpixel.lua dissection

« Reply #3 on: 07 / March / 2010, 03:29:46 »

Yes, 255 is a third option to the set_raw script command, specially crafted to execute this bad pixel test in core/raw.c. So I suppose either there's a bug/incompatibility somewhere or your camera happens to report exactly 255 bad pixels in these particular conditions.

Logged