SX30 IS porting thread - page 3 - General Discussion and Assistance - CHDK Forum

SX30 IS porting thread

  • 115 Replies
  • 57981 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: SX30 IS porting thread
« Reply #20 on: 30 / November / 2010, 05:57:01 »
Advertisements
unfortunately the spec goes on to state

You beat me by a matter of seconds, I have just read that !

I am writing an application right now to save separate header and narrow image strips.

A simple MSDOS bat file joins the raw and headers, I just need a utility to reverse the bytes.

David

My thought was to continue to write one file; but with the bytes not swapped. Then write a command line app that would fix up the DNG file(s) by swapping the bytes. Should not be too difficult.

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

  • *****
  • 3450
    • Photos
Re: SX30 IS porting thread
« Reply #21 on: 30 / November / 2010, 05:59:55 »
Interestingly I just found another address that seems to always contain the raw image data. The address is just over 32MB above the address found in the firmware


Is that the CHDK raw-cached option ?

If so, why use it, is it faster ?


David

No it's still an uncached address (if I understand how the cache bit works). It's just somewhere that always seems to contain the raw image data; whereas the address I found from the firmware only holds the data for every second shot (usually, sometimes it's every third or fourth). Still testing this new address; but fingers crossed it will give me what I need.

Address found in firmware = 0x4235F6B0
Address that seems to work = 0x443B4960

The CAM_UNCACHED_BIT is the same for the SX30 (0x40000000)

Regards,
Phil.
« Last Edit: 30 / November / 2010, 06:01:32 by philmoz »
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: SX30 IS porting thread
« Reply #22 on: 30 / November / 2010, 06:01:24 »
Should not be too difficult.

Good, that will save me reading a book about 'C' programming.

While you are doing that, I will have a cup of tea   :)


David

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: SX30 IS porting thread
« Reply #23 on: 30 / November / 2010, 07:26:47 »
Posted a comparison of RAW versus JPEG test shot at 24mm on DPReview:
http://forums.dpreview.com/forums/read.asp?forum=1010&message=37055669

Man this camera has some serious vignetting at the wide end :)

Regards,
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: SX30 IS porting thread
« Reply #24 on: 30 / November / 2010, 07:31:00 »
Man this camera has some serious vignetting at the wide end :)


Hmmm ....

I have just finished reading the DNG specification and there is the option of including data for post-processing correction of vignetting and distortion.

Presumably that data is also in the Canon firmware somewhere.


David

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: SX30 IS porting thread
« Reply #25 on: 30 / November / 2010, 16:36:26 »
Unfortunately the address I thought was consistent for the raw buffer isn't. The camera is using both addresses although they don't alternate - it seems to depend on how much time you take between shots.

Can't find anything in the firmware for this yet to detect which buffer is in use. For now I'm checking the first four byes of each buffer to see which one looks like a raw image - the one that is has 0x00, 0x08, 0x08, 0x80, at the start, otherwise it usually has 0xff,0xff,0xff,0xff.

Don't like this as it might not work 100%; but until I find some sort of flag to indicate which buffer is being used it will have to do.

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

  • ******
  • 14082
Re: SX30 IS porting thread
« Reply #26 on: 30 / November / 2010, 17:01:22 »
could be replaced with:
Code: [Select]
and r3, r2, r4, lsr #8 // r3 = (in >> 8) & 0xFF00FF

This is done 8 times in each loop, so there's a small saving this way (it still seems to work on my system).
Good catch, I spent a while trying to cut one more instruction out of that and missed that. :-[
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14082
Re: SX30 IS porting thread
« Reply #27 on: 30 / November / 2010, 17:11:07 »
My thought was to continue to write one file; but with the bytes not swapped. Then write a command line app that would fix up the DNG file(s) by swapping the bytes. Should not be too difficult.
This has been discussed previously.
http://chdk.setepontos.com/index.php?topic=4657.msg45265#msg45265
my preferred solution http://chdk.setepontos.com/index.php?topic=1390.msg53067#msg53067

I don't like the idea of saving non-valid DNGs, it would be better to prepend our own small, well documented header to it so DNG aware programs don't end up reading our broken DNGs. I still have mixed feelings about adding Yet Another Format, but if we are going to do it, we should do it right.

If you use cached raw buffer, the DNG saving time isn't so bad even on 14mp cams. I don't recall exactly what it was on sd990, but I don't remember it being too horrid.
Don't forget what the H stands for.


*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: SX30 IS porting thread
« Reply #28 on: 30 / November / 2010, 17:42:20 »
This has been discussed previously.
http://chdk.setepontos.com/index.php?topic=4657.msg45265#msg45265
my preferred solution http://chdk.setepontos.com/index.php?topic=1390.msg53067#msg53067

I don't like the idea of saving non-valid DNGs, it would be better to prepend our own small, well documented header to it so DNG aware programs don't end up reading our broken DNGs. I still have mixed feelings about adding Yet Another Format, but if we are going to do it, we should do it right.

If you use cached raw buffer, the DNG saving time isn't so bad even on 14mp cams. I don't recall exactly what it was on sd990, but I don't remember it being too horrid.

Agree 100%, another file format is a bad idea. I changed the calls to reverse_bytes_order to use the cached address and that helped a bit, will try setting the config option to force cached and see what happens. Currently DNG adds about 3 seconds to the shooting time - also need to try a faster SD card.

Out of curiosity why do you fix the bad pixels in CHDK rather than write the bad pixel list to the DNG file using the FixBadPixelsList Opcode (and let the raw processor fix them)?

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

  • ******
  • 14082
Re: SX30 IS porting thread
« Reply #29 on: 30 / November / 2010, 17:50:33 »
Out of curiosity why do you fix the bad pixels in CHDK rather than write the bad pixel list to the DNG file using the FixBadPixelsList Opcode (and let the raw processor fix them)?
AFAIK that was done because the opcode stuff isn't widely supported yet (or wasn't, at the time DNG was originally implemented). This is discussed in the original DNG thread: http://chdk.setepontos.com/index.php?topic=156.0

Timewise, bad pixel fixing isn't significant, but saving people the hassle of generating badpixel.bin would nice. It would also save some RAM

Don't forget what the H stands for.

 

Related Topics