SX30 IS porting thread

fe50

3152
IXUS50 & 860, SX10 Star WARs-Star RAWs

Re: SX30 IS porting thread

« Reply #50 on: 03 / December / 2010, 01:13:17 »

Advertisements

Quote from: Microfunguy on 02 / December / 2010, 18:20:17

IrfanView reported image size is half the correct value

Check the settings for RAW images, IMO IrfanView's default setting is to show RAW images with 1/2 size for better performance...

Logged

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

philmoz

3450

Re: SX30 IS porting thread

« Reply #51 on: 03 / December / 2010, 03:29:44 »

Any suggestions on how to calculate the CAM_COLORMATRIX1 array.
I've tried shooting a GretaMacBeth colorchecker card and loading the images into DNG4PS-2 calibration calculator; but it always complains that it can't get the min below 15%.

Regards,
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)

Microfunguy

4037

Re: SX30 IS porting thread

« Reply #52 on: 03 / December / 2010, 07:11:57 »

Quote from: philmoz on 03 / December / 2010, 03:29:44

Any suggestions on how to calculate the CAM_COLORMATRIX1 array.

Don't know if this helps :-

http://labs.adobe.com/wiki/index.php/DNG_Profiles:Editor

@FE50

Thanks, that was the problem.
A slightly obscure setting in 'Plugins' options.

Any other DNG qustions will be here http://chdk.setepontos.com/index.php?topic=5877.0

« Last Edit: 03 / December / 2010, 08:31:20 by Microfunguy »

Logged

whoever

280
IXUS950

Re: SX30 IS porting thread

« Reply #53 on: 03 / December / 2010, 12:11:33 »

Quote from: philmoz on 03 / December / 2010, 03:29:44

Any suggestions on how to calculate the CAM_COLORMATRIX1 array.
I've tried shooting a GretaMacBeth colorchecker card

A real Gretag Macbeth? Shot in daylight, at noon on a sunny day?

Dave Coffin's dcraw contains code to compute the color matrix in this case. (It is not compiled by default; look for COLORCHECK in dcraw.c) Better yet, ask Dave to compute it. In which case, he will also include it in the next release of dcraw (an added benefit), with the rest of the pack to follow.

Logged

philmoz

3450

Re: SX30 IS porting thread

« Reply #54 on: 04 / December / 2010, 00:29:38 »

Quote from: whoever on 03 / December / 2010, 12:11:33

A real Gretag Macbeth? Shot in daylight, at noon on a sunny day?

Dave Coffin's dcraw contains code to compute the color matrix in this case. (It is not compiled by default; look for COLORCHECK in dcraw.c) Better yet, ask Dave to compute it. In which case, he will also include it in the next release of dcraw (an added benefit), with the rest of the pack to follow.

Thanks for that, yes it was a real card shot under the right conditions. I just couldn't get DNG4PS-2 to calibrate it.
I compiled dcraw with the COLORCHECK enabled and that seems to have done the trick - at least I'm getting pretty reasonable DNG results. Probably could be better; but it will do for now.

Regards,
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)

reyalp

14117

Re: SX30 IS porting thread

« Reply #55 on: 04 / December / 2010, 03:19:21 »

Quote from: philmoz on 30 / November / 2010, 03:42:03

I'm saving as DNG and I noticed that the reverse_bytes_order function is really slow (and it's called twice). With 14MP to swap it takes a while. I looked at the code and noticed that the two lines:
Code: [Select]
mov r3, r4, lsr #8 // r3 = in >> 8 and r3, r3, r2 // r3 &= 0xFF00FFcould be replaced with:
Code: [Select]
and r3, r2, r4, lsr #8 // r3 = (in >> 8) & 0xFF00FF

I checked this in, it looks like it might save ~100ms on my d10. ~3.9s with new dng ~4 sec for old dng, ~3.1 for crw

Fragmentation or other card condition can have a much bigger effect, on my old never reformatted development card, dng varied between 4 and 5.7 seconds

Logged

Don't forget what the H stands for.

philmoz

3450

Re: SX30 IS porting thread

« Reply #56 on: 04 / December / 2010, 04:29:43 »

Quote from: reyalp on 04 / December / 2010, 03:19:21

I checked this in, it looks like it might save ~100ms on my d10. ~3.9s with new dng ~4 sec for old dng, ~3.1 for crw

Using the debug mode to show the raw save time I'm seeing 1.04 secs for CRW and between 1.97 and 2.18 seconds for DNG.
This is on a new 4GB Sandisk class 10 30MB/s card.

Update:
Did a more detailed analysis of the DNG save timing, and after optimizing get_raw_pixel, set_raw_pixel and the number of calls to get_raw_image_addr I have the following stats (avg case):
RAW data write time = 1040ms
ReverseBytes = 350ms (called twice)
Thumbnail gen, bad pixel patch & DNG header write = 180ms

Also I seem to get more consistent results if I use cached memory for everything except the raw data write, and force this to always use uncached memory.

Phil.

« Last Edit: 04 / December / 2010, 17:43:31 by philmoz »

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)

reyalp

14117

Re: SX30 IS porting thread

« Reply #57 on: 04 / December / 2010, 17:59:18 »

One small optimization you could do is not reverse or patch the top and bottom border pixels. The side borders would probably not be a win for reversebytes, since it would get a lot more complex. Badpixel generation should probably skip all the border pixels, this would save time and memory.

Interesting that write with uncached is different. What sort of differences are you seeing ? Doing it your way should be more correct in any case.

Logged

Don't forget what the H stands for.

philmoz

3450

Re: SX30 IS porting thread

« Reply #58 on: 04 / December / 2010, 18:36:03 »

Quote from: reyalp on 04 / December / 2010, 17:59:18

One small optimization you could do is not reverse or patch the top and bottom border pixels. The side borders would probably not be a win for reversebytes, since it would get a lot more complex. Badpixel generation should probably skip all the border pixels, this would save time and memory.

Interesting that write with uncached is different. What sort of differences are you seeing ? Doing it your way should be more correct in any case.

Good ideas, I'll give them a try and see what happens.

I was occasionally getting write times between 200 - 500 ms longer when passing the cached memory address to write. No idea why this would be case, it doesn't make sense to me; but forcing the uncached address seemed to have fixed it. Will need more testing to be absolutely certain.

Regards,
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: SX30 IS porting thread

« Reply #59 on: 04 / December / 2010, 21:14:15 »

Today's dumb question

I've implemented the jogdial task; and it stops the camera from responding to the dial when in ALT mode.

But the jogdial movements are buffered and the camera executes them when I leave ALT mode.

Not a major issue; but a bit annoying - any ideas what I've missed.

Regards,
Phil.

(BTW reducing reverse_bytes to the active area vertically shaved about 10ms off each call).

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)