SX30 IS porting thread

reyalp

14037

Re: SX30 IS porting thread

« Reply #10 on: 29 / November / 2010, 12:42:45 »

Advertisements

Vector 0x10 is an invalid memory access.

StartRedirectUART you can call somewhere else, like at spytask startup (need a wrapper if you call it from thumb code). You need to have uartr.req on the disk, and pass the arguments as described in the lua script.

Printf should should work. You do have to pass it a string, e.g.

Code: [Select]

const char *mystr="blah"; // this should be a global
...
ASM_SAFE( 
"LDR R0, =mystr\n"
"LDR R0, [R0]\n"
"BL _Printf\n"
)

Maybe this is more complicated than you want to get into for debugging. Getting back to your original problem, you may be able to find code that is similar other cameras if you trace the functions for messages 0 and 1 far enough. It's unlikely that canon has rewritten the whole thing. You might be able to just put the raw hook after at the end of 1, ISTR some cameras did this.

Logged

Don't forget what the H stands for.

Microfunguy

4037

Re: SX30 IS porting thread

« Reply #11 on: 29 / November / 2010, 13:30:59 »

Quote from: philmoz on 28 / November / 2010, 20:54:46

The code at message 0 and message 1 doesn't match the sx20 or s95 (which I've used as references so far), s95 is closer;

Waldo has not been able to get the capture task working on the S95 (or the jump to wait_until_remote_button_released().

Your work may help him.

David

Logged

philmoz

3450

Re: SX30 IS porting thread

« Reply #12 on: 29 / November / 2010, 16:08:59 »

Quote from: reyalp on 29 / November / 2010, 12:42:45

Maybe this is more complicated than you want to get into for debugging. Getting back to your original problem, you may be able to find code that is similar other cameras if you trace the functions for messages 0 and 1 far enough. It's unlikely that canon has rewritten the whole thing. You might be able to just put the raw hook after at the end of 1, ISTR some cameras did this.

I tried adding the raw hook at the end of message 1; but I just get a mostly white image. I did once get a recognisable section of the image at the bottom (approx 1/10th of the image height) with weird colours; but have not even been able to reproduce that much again. Hopefully that means that at least the buffer, size and dimension settings are correct.

I also tried calling the raw_savefile code when the 'alt' key is pressed to see if I could manually force it create a raw image after taking a normal image; but that didn't seem to work either.

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

14037

Re: SX30 IS porting thread

« Reply #13 on: 29 / November / 2010, 16:42:40 »

Quote from: philmoz on 29 / November / 2010, 16:08:59

I tried adding the raw hook at the end of message 1; but I just get a mostly white image. I did once get a recognisable section of the image at the bottom (approx 1/10th of the image height) with weird colours; but have not even been able to reproduce that much again. Hopefully that means that at least the buffer, size and dimension settings are correct.

I believe the raw buffer is destroyed in the develop process, so this isn't surprising.

Note that some cameras have multiple raw buffers, so you will sometimes get raw correct raw data and other times get garbage unless you get get the correct address at run time. SD990 is an example of this.

Generally, the first address is easily found with a string like CRAW BUF

Logged

Don't forget what the H stands for.

philmoz

3450

Re: SX30 IS porting thread

« Reply #14 on: 30 / November / 2010, 03:42:03 »

Quote from: reyalp on 29 / November / 2010, 16:42:40

Quote from: philmoz on 29 / November / 2010, 16:08:59
I tried adding the raw hook at the end of message 1; but I just get a mostly white image. I did once get a recognisable section of the image at the bottom (approx 1/10th of the image height) with weird colours; but have not even been able to reproduce that much again. Hopefully that means that at least the buffer, size and dimension settings are correct.
I believe the raw buffer is destroyed in the develop process, so this isn't surprising.

Note that some cameras have multiple raw buffers, so you will sometimes get raw correct raw data and other times get garbage unless you get get the correct address at run time. SD990 is an example of this.

Generally, the first address is easily found with a string like CRAW BUF

I've now found a place for the raw hook that gives me a raw file for every second shot taken, which would imply that there are two buffers. Now I just have to find the other one and how to determine which one is in use.

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 &= 0xFF00FF

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

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 #15 on: 30 / November / 2010, 04:55:00 »

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

Save the header and raw separately and write a utility that will batch-process a folder of files and reverse the bytes.

I am interested in that approach but don't know how to do it.

The DNG Specification says :-

"DNG readers are required to support either byte order, even for files from a particular camera model. Writers can write either byte order, whichever is easier and/or faster for the writer."

DNG also supports Opcode lists :-

"This allows complex processing to be moved off the camera hardware, which often has limited processing power, and into the DNG reader, which is often running on more powerful hardware.
This also allows processing steps to be specified, such as lens corrections, which ideally should be performed on the image data after it has been demosaiced, while still retaining the advantages of a raw mosaic data format."

Bad pixels can be fixed in post-processing by including a bad pixel fixing opcode in the OpcodeList1 tag.

David

« Last Edit: 30 / November / 2010, 05:44:34 by Microfunguy »

Logged

philmoz

3450

Re: SX30 IS porting thread

« Reply #16 on: 30 / November / 2010, 05:43:23 »

Quote from: Microfunguy on 30 / November / 2010, 04:55:00

Save the header and raw separately and write a utility that will batch-process a folder of files and reverse the bytes.

I am interested in that approach but don't know how to do it.

The DNG Specification says :-

"DNG readers are required to support either byte order, even for files from a particular camera model. Writers can write either byte order, whichever is easier and/or faster for the writer."

David

Hi David,

Wish that were the case; but unfortunately the spec goes on to state in the 'BitsPerSample' section:

Supported values are from 8 to 32 bits/sample. The depth must be the same for each sample if SamplesPerPixel is not equal to 1. If BitsPerSample is not equal to 8 or 16 or 32, then the bits must be packed into bytes using the TIFF default FillOrder of 1 (big-endian), even if the TIFF file itself uses little-endian byte order.

Since the SX30 is 12 bits per pixel for raw data we have to convert it to big-endian.

I might use your idea of just writing the DNG file with the bytes the wrong way round then use a batch utility to fix them later. For now the DNG writing in CHDK is handly because I can see immediately if the images are being dumped correctly.

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 #17 on: 30 / November / 2010, 05:48:46 »

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; but it never appears in the firmware anywhere that I can find.

I found it by writing a very large block of memory when saving the raw image then searching through the file looking for raw image data.

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 #18 on: 30 / November / 2010, 05:50:12 »

Quote from: philmoz on 30 / November / 2010, 05:43:23

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

Logged

Microfunguy

4037

Re: SX30 IS porting thread

« Reply #19 on: 30 / November / 2010, 05:51:50 »

Quote from: philmoz on 30 / November / 2010, 05:48:46

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, when is it used, is it faster ?

For the SX10 :-

#define CAM_UNCACHED_BIT 0x40000000

David

« Last Edit: 30 / November / 2010, 05:59:08 by Microfunguy »

Logged