Does CHDK for the S95 support badpixel removal for jpeg files?My S95 has developed a stuck pixel that I'd like to map out. I'm running the recent version 0.9.9-1418

In CHDK I ran "RAW Parameters/Create badpixel.bin" to create the badpixel.bin fileIn Windows I then loaded this into "Badpixel Manager 1.1 for Windows" and used it to save a text file named "badpixel"I made sure that this file uses only LF characters as line terminatorsI copied this file back to the SD card in the same directory as badpixel.binI have "RAW Parameters/Bad pixel removal" set to "Averag."

This has no visible effect on my jpegs - at least the stuck pixel is still there.

I also tried generating a badpixel file from scratch that defined a 20x20 pixel region to be bad, just to see whether this had any effect on jpeg shooting, and it doesn't.Am I doing something wrong?

CHDK is not involved in the process of creating jpeg files on the camera in any way - that's all a function of the Digics processer and the connected DSP chip. So there is no way to manage bad pixels in the camera jpegs using CHDK.

I hope this will answer your question. I had already been confused with bad_pixel processing.

There are 3 bad pixel processes :

First, the Canon bad pixel removal process, integrated to your camera, to remove bad pixels known at the Canon plant. It is applied during jpeg process, without learning capability.

The second process, use a CHDK's user created file "badpixel.txt" (or "badpixel") in CHDK folder, to create a list of bad pixels at CHDK boot up. The structure of the text file, per line, is [ col , line ] (ex: "123,456"). ThisThe bad pixel's removal process will be execute just before CHDK raw and dng "check-to-save" (see raw.c)during CHDK raw process (and therefore CHDK dng process since raw process is preliminary).

The third process, use "badpixel.bin" in CHDK folder and is created by CHDK's raw/dng menu "create bad pixel bin", to remove bad pixels learned from black exposure. This bad pixel's removal process is executed only when DNG file is saved to SD card.

P.S.: To complete waterwingz's comms, from what I know, jpeg file is created from raw data space and therefore applying bad pixel removal processes to raw data space will remove bad pixels but the second process is executed only during raw process and the third process is executed only during dng process.

UPDATE: having now read through the code, it looks like this works if capt_seq_hook_raw_here is inserted in capt_seq.c prior to the camera creating the jpeg. If it gets inserted later in the sequence, RAW & DNG files will still get created but any bad pixel changes will get missed. So to repond to the original question, it might be a question of how capt_seq.c was implemented on the S95.

Thanks for the replies waterwingz and Lebeau. I'm guessing that I've probably done the correct thing and that the S95 isn't supporting this since the camera takes time after I take a shot to do its raw processing stuff, but there's no visible effect on the jpeg.For others reading this thread in future, show_bad.exe doesn't work with the newer .CR2 version files produced by the S95 (and presumably a bunch of other current model Canon cameras), so support for badpixel removal for jpegs on this or other newer cameras requires getting the badpixel file some other way. The technique I mentioned of using "Badpixel Manager 1.1 for Windows" to produce the required badpixel text file seems to work.@waterwingz, I can't check whether capt_seq_hook_raw_here is inserted somewhere in capt_seq.c because the S95 source code link is broken in the porting thread. I'll post a question over on the S95 porting thread in case someone over there is able to check.

@waterwingz, I can't check whether capt_seq_hook_raw_here is inserted somewhere in capt_seq.c because the S95 source code link is broken in the porting thread. I'll post a question over on the S95 porting thread in case someone over there is able to check.

UPDATE: having now read through the code, it looks like this works if capt_seq_hook_raw_here is inserted in capt_seq.c prior to the camera creating the jpeg. If it gets inserted later in the sequence, RAW & DNG files will still get created but any bad pixel changes will get missed. So to repond to the original question, it might be a question of how capt_seq.c was implemented on the S95.

I don't know for specific cameras, other than A650, but when I do DNG save, I have to execute "reverse_bytes_order2" to de-endianeese, else the saved jpeg is "endianeese".