S95 Porting Thread

msl

1280
A720 IS, SX220 HS 1.01a

Re: S95 Porting Thread

« Reply #960 on: 10 / November / 2011, 13:07:53 »

Advertisements

Quote from: denver.steiner on 10 / November / 2011, 11:53:25

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

Logged

CHDK-DE: CHDK-DE links

denver.steiner

2

Re: S95 Porting Thread

« Reply #961 on: 10 / November / 2011, 16:29:36 »

Quote from: msl on 10 / November / 2011, 13:07:53

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.

Logged

fe50

3152
IXUS50 & 860, SX10 Star WARs-Star RAWs

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

Logged

-->FIRMWARE DUMPS<-- * Manual * Lua * me

pickler

7

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?

Logged

waterwingz

12140

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 »

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: S95 Porting Thread

« Reply #965 on: 11 / December / 2011, 04:26:04 »

Quote from: pickler 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?

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.

Logged

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)

pickler

7

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.

Logged

waterwingz

12140

Re: S95 Porting Thread

« Reply #967 on: 11 / December / 2011, 09:16:19 »

Quote from: philmoz on 11 / December / 2011, 04:26:04

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 ?

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: S95 Porting Thread

« Reply #968 on: 11 / December / 2011, 16:22:11 »

Quote from: pickler 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.

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.

Logged

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)

philmoz

3450

Re: S95 Porting Thread

« Reply #969 on: 11 / December / 2011, 16:25:03 »

Quote from: waterwingz on 11 / December / 2011, 09:16:19

Quote from: philmoz on 11 / December / 2011, 04:26:04
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.

Logged

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)