S95 Porting Thread - page 97 - DryOS Development - CHDK Forum

S95 Porting Thread

  • 1015 Replies
  • 251631 Views
*

Offline msl

  • *****
  • 1274
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: S95 Porting Thread
« Reply #960 on: 10 / November / 2011, 13:07:53 »
Advertisements
Note on another older camera, clicking display several times (while not in CHDK) would turn of the display. Not so on my S95. So I'm guess a press "display" would not work either.

Any ideas? Thanks.

Cameras without optical viewfinder can't turn off the display. But you can control the LCD backlight. Use set_backlight. Important, read also the notes: http://chdk.wikia.com/wiki/Script_commands#set_backlight.28.29

msl 
CHDK-DE:  CHDK-DE links

Re: S95 Porting Thread
« Reply #961 on: 10 / November / 2011, 16:29:36 »
Cameras without optical viewfinder can't turn off the display. But you can control the LCD backlight. Use set_backlight. Important, read also the notes: http://chdk.wikia.com/wiki/Script_commands#set_backlight.28.29
msl
Wow, this is very helpful, although I'm a bit disappointed I can't keep the screen completely off. I was barking up the wrong tree trying to search for "display off" or "lcd off". I'm surprised this isn't better documented since it seems like most of Canon's new models are going for a larger LCD with no viewfinder.

What still is confusing me is that when CHDK is off, and I go into MENU->Set Short Cut Button, I can set the button to "Display Off". Is this just turning the back light off? When I fire a picture off in this mode, the screen comes back on. So it does that it is hardwired into the camera to turn on the back-light after a picture is taken (regardless of whether you have image review on).

Using set_backlight, here is the stripped down version of final code use to test the optimal setting for keeping the backlight off:
Code: [Select]
@title Interval backlight off test
@param s Backlight off after shot (10th Seconds)
@default s 4
@param e Interval (Seconds)
@default e 5
n=0
t=(e*10)*100
:interval
n=n+1
print "Shot", n
shoot
sleep s*100
set_backlight 0
sleep t-(s*100)
goto "interval"
I made the interval after each shot a variable (s), so I could test shortest duration possible. In my limited testing it seemed like 4 (as in 4/10ths of a second) was the lowest setting I could get away with. Anything lower than that ignored "set_backlight 0" because the shot had not completed (in fact on the first shot 4/10th of a second is to slow and it doesn't shut the screen off, but it is fine after that). Anything longer than that kept the back_light on for longer than necessary.



*

Offline fe50

  • ******
  • 3131
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: S95 Porting Thread
« Reply #962 on: 11 / November / 2011, 03:56:37 »
@denver.steiner

You can disable the camera's sensor, electronics & LCD with the Canon sleep function assigned to the PRINT key, also in a script...
With one of the Canon functions registered to the PRINT/Shortcut button, use a short / long button press to use the CHDK or the Canon function...

* http://chdk.setepontos.com/index.php?topic=6982.msg75056#msg75056
* http://chdk.setepontos.com/index.php?topic=5306.msg51443#msg51443
* http://chdk.setepontos.com/index.php?topic=6829.msg72927#msg72927

...don't forget: MD (motion detection) is not possible with shutdown sensor ;)

Jpeg badpixel removal
« Reply #963 on: 10 / December / 2011, 21:59:55 »
I've been trying to enable badpixel removal on jpegs for the S95 and it seems not to be supported by the current S95 CHDK port.
On this thread http://chdk.setepontos.com/index.php?topic=7239.0 I mentioned what I tried and the suggestion from waterwingz is

Quote
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.

Is anyone here able to check this easily, and my obvious followup question would be, would it be easy to change to support badpixel processing of jpegs?


Re: S95 Porting Thread
« Reply #964 on: 10 / December / 2011, 22:03:04 »
capt_seq_hook_raw shows up in capt_seq.c on line 581 :
http://trac.assembla.com/chdk/browser/trunk/platform/s95/sub/100e/capt_seq.c

Its being called if you have RAW files being stored.  However, its being called from a much different place in the code than several other cameras ( S90,  G10 were the ones I looked at).  Whether that's right or not will take some serious debugging.

pickler :  which firmware version are you using ?
« Last Edit: 10 / December / 2011, 22:27:29 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3291
    • Photos
Re: S95 Porting Thread
« Reply #965 on: 11 / December / 2011, 04:26:04 »
I've been trying to enable badpixel removal on jpegs for the S95 and it seems not to be supported by the current S95 CHDK port.
On this thread http://chdk.setepontos.com/index.php?topic=7239.0 I mentioned what I tried and the suggestion from waterwingz is

Quote
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.

Is anyone here able to check this easily, and my obvious followup question would be, would it be easy to change to support badpixel processing of jpegs?

The code is similar to the G12 which works ok (the cameras are very similar firmware wise).
I changed the G12 to match the S95 for calling capt_seq_hook_raw_here and the bad pixel still worked - I created a dummy 4x4 bad pixel file and modified the bad pixel code to change the 'bad' pixels to a bright value rather than average them out.

The co-ordinates of the bad pixels in the badpixel.txt file are relative to the RAW image top left corner.
The JPEG is cropped from inside the RAW frame so you need to make sure the co-ordinates are correct.
Try adding 72 to the X value and 24 to the Y value.

Phil.
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)

Re: S95 Porting Thread
« Reply #966 on: 11 / December / 2011, 07:44:17 »
Thanks for your help on this.
@waterwingz, I'm using CHDK 0.9.9-1470 now on my S95 1.00e.
I just tried Phil's suggestion of adding 72 to the X value and 24 to the Y value and it didn't work for me, but I probably need to try more carefully when I have a bit more time. Sounds like it should work so I guess I'm doing something wrong at the moment. Phil, it sounds like you've done this with the G12. How did you generate the badpixel.txt file? After generating mine, I plotted all the coordinates in the badpixel file as a scatter plot and overlaid them on an image. Even before adding the 72,24 offset, some coordinates lie outside the x range of the image (a png I generated from a .cr2 with rawtherapee) so I assume this means my badpixel.txt file is wrong. Is the format of the badpixel.bin file described somewhere? - if so, I can write my own program to generate the badpixel.txt file directly from it.

Re: S95 Porting Thread
« Reply #967 on: 11 / December / 2011, 09:16:19 »
I created a dummy 4x4 bad pixel file and modified the bad pixel code to change the 'bad' pixels to a bright value rather than average them out.
The co-ordinates of the bad pixels in the badpixel.txt file are relative to the RAW image top left corner.
The JPEG is cropped from inside the RAW frame so you need to make sure the co-ordinates are correct.

@philmoz :   can you post the file here as an attachment ?  Sound like it would make a good test file for anyone doing a port as well as pickler in his efforts ?  Maybe even put it on the distro as badpixel_test.txt or something ?
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline philmoz

  • *****
  • 3291
    • Photos
Re: S95 Porting Thread
« Reply #968 on: 11 / December / 2011, 16:22:11 »
Thanks for your help on this.
@waterwingz, I'm using CHDK 0.9.9-1470 now on my S95 1.00e.
I just tried Phil's suggestion of adding 72 to the X value and 24 to the Y value and it didn't work for me, but I probably need to try more carefully when I have a bit more time. Sounds like it should work so I guess I'm doing something wrong at the moment. Phil, it sounds like you've done this with the G12. How did you generate the badpixel.txt file? After generating mine, I plotted all the coordinates in the badpixel file as a scatter plot and overlaid them on an image. Even before adding the 72,24 offset, some coordinates lie outside the x range of the image (a png I generated from a .cr2 with rawtherapee) so I assume this means my badpixel.txt file is wrong. Is the format of the badpixel.bin file described somewhere? - if so, I can write my own program to generate the badpixel.txt file directly from it.

There still seems to be some confusion over the various bad pixel files, so I'll try and clarify it.

badpixel.bin & the CHDK menu option to 'Create badpixel.bin'

This is only used by the CHDK code when saving a DNG format raw file. The file is a binary file containing a simple list of 16 bit integer values, each pair of values is the X,Y co-ordinate of a bad pixel in the raw image.
The 'Create badpixel.bin' option takes two photos and then scans the raw data looking for pixels with a value of 0 - these will be dead pixels in the sensor. It then writes these out to the file.

You don't need to do anything with this file, CHDK will automatically use it when creating a DNG file. The 'Bad pixel removal' option in CHDK does not affect this process.

If you aren't saving raw as DNG then this bad pixel file is not used - the assumption being that the RAW convertor will do the bad pixel correction.

Note this does not deal with stuck/hot pixels only dead ones.

You don't need to convert this file to generate badpixel or badpixel.txt.

badpixel & badpixel.txt

These are text files that you can manually create to fix stuck/hot pixels. Each line in the file should contain the X,Y address of a bad pixel. You probably only need one of these; but they are limited to 8K in size so if you have a lot of stuck pixels you could use both (or get a new camera).

You have to set the 'Bad pixel removal' option for CHDK code to fix these pixels.
Normally this code should be called before the camera generates the JPEG so it should fix the pixels in the JPEG image.

The co-ordinate values should be relative to the top left corner of the raw image. If you use a camera generated JPEG image to get the pixel co-ordinate you need to add an offset since the JPEG is cropped from the raw data. If you can convert a .CR2 raw file and your raw convertor shows the full sensor image data (including the dark edges) then you can get the correct co-ordinates directly.


All of the bad pixel files must be in the CHDK directory on the SD card.

Phil.
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

  • *****
  • 3291
    • Photos
Re: S95 Porting Thread
« Reply #969 on: 11 / December / 2011, 16:25:03 »
I created a dummy 4x4 bad pixel file and modified the bad pixel code to change the 'bad' pixels to a bright value rather than average them out.
The co-ordinates of the bad pixels in the badpixel.txt file are relative to the RAW image top left corner.
The JPEG is cropped from inside the RAW frame so you need to make sure the co-ordinates are correct.

@philmoz :   can you post the file here as an attachment ?  Sound like it would make a good test file for anyone doing a port as well as pickler in his efforts ?  Maybe even put it on the distro as badpixel_test.txt or something ?


It wouldn't be of any use. You can't really see effect of the bad pixel removal unless you have a stuck pixel (or you modify the source code to create stuck pixels instead of fixing them which is how I tested it).

Phil.
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)

 

Related Topics