Thanks for the explanation of the badpixel files Phil. I had assumed that the badpixel.bin contained both hot and stuck pixel information. So, I gather that the way I have to generate the badpixel.txt file is to take a photo, measure the xy-coords of the bad pixel, then manually calculate its sensor coordinates and create the entry in the badpixel.txt file. I've done this, but I must be getting the xy-coords wrong because the bad pixel is still there in my jpegs. Do you know of a RAW file converter that will give me an image of the full 3744x2784px sensor image? Perhaps I need to investigate dcraw? I used raw therapee to get a 3676x2752px png, but I have no idea what the offsets to 0,0 for this image are. I also took a 3648x2736px jpeg image and measured the coords, which I think are 1930,1346 (it's much harder to tell, even with sharpening set to a minimum, because of the jpeg processing), then I added the suggested 72, 24px offsets to these coords to get the coords for the badpixel.txt file.
QuoteI actually came here to report there is no reason to have to hold the on button to get to recording mode. I have the 100H firmware and I made this change in boot.c This is a design decision made early on - it is safer to start the camera in playback mode if the button is accidentally bumped or pressed while in a case.It is also better to have all cameras operate the same way for consistency rather than have some work one way and others differently.
I actually came here to report there is no reason to have to hold the on button to get to recording mode. I have the 100H firmware and I made this change in boot.c
Thanks for these Phil. They have already been helpful. I loaded your firmware but used my own badpixel file and took a photo. This produced my jpeg with its red hot/stuck pixel and another white (or red or blue) pixel at the coordinates specified in the badpixel file (I had an offset of about 18 in x and 8 in y). I iterated a few times, updating the coordinates, until I got them to coincide by choosing the location that causes the least change in the resulting file when used with your code. A change of 1 in any direction of the pixel coordinate produced a noticably worse image artifact. I then tried setting the coordinates to each of the coordinates in a 3x3 region centred at the location I determined using the standard CHDK firmware, but it hasn't had any visible effect on removing the bad pixel, so there's still something not right. I'll have to look into it more on the weekend I think. I'm thinking of setting a sort of crosshair pattern of white pixels using your firmware to check how much I might be off by, then perhaps going through more of a range of pixels. I might have to look into how the interpolation is done.
Is there any possibility with Canon S95 and CHDK rotate the image upside down?
Started by fvdk DryOS Development
Started by jonny360 CHDK Releases
Started by jnmaessen Feature Requests
Started by It Is What It Is Feature Requests
Started by kepler CHDK Releases