SX170 porting - page 15 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20 ... 27   Go Down

SX170 porting

  • 266 Replies
  • 86617 Views
*

Offline Garden

  • **
  • 60
Re: SX170 porting
« Reply #140 on: 18 / September / 2014, 09:08:05 »
Advertisements
Sorry I think IDA did not disassemble it correctly.
ROM:FF810B64                 DCB 0x1E
ROM:FF810B65                 DCB 0xFF

Actually is the code of the same instruction BX LR.
Thanks.
 Any other idea on the raw image problem?
« Last Edit: 18 / September / 2014, 10:56:39 by Garden »
Logged
*

Offline Garden

  • **
  • 60
Re: SX170 porting
« Reply #141 on: 18 / September / 2014, 13:01:28 »
I think the raw image garbage problem is somehow related to this:
Quote from: srsa_4c on 22 / October / 2012, 00:40:28
Quote from: srsa_4c on 14 / October / 2012, 17:54:31
Cameras with DryOS >= r50 have a more complicated filewritetask. This means that a protocol change and a change of the hooking method will be needed to successfully retrieve those files.
In changeset 2226 I have checked in support code for this. It hasn't been tested on a DryOS r50 camera yet, so it may contain some errors.
Remote capture protocol:
I had to add (back) param3 as "position" value in PTP_CHDK_RemoteCaptureGetData. R50 and newer cameras will need it.

Some background info about the behaviour of new cameras:
The jpeg data is either completely present in memory when filewritetask is notified (similarly as in older cameras), or appears like this:
- first filewritetask invocation: file is opened, seek is performed to skip over the (future) exif data, first chunk of jpeg written, file left open
- second, third invocation: additional chunks (one per invocation) are written sequentially, file left open
- last invocation: seek to position 0, exif written, file closed
According to my observations, exif is placed into the same buffer as the second jpeg chunk. There is some delay between the availability of the big jpeg chunks, my code tries to wait when needed.

I have created a new #define in camera.h, with the name CAM_EXTENDED_FILEWRITETASK. As indicated by my comment, this could be substituted by a (not yet created) CAM_DRYOS_2_3_R50 define.

I'm considering to change the filewrite hook function to only require the pointer to the start of the task's data block as argument, and use #define'd offsets to the values of interest.

edit:
The r50 code is not working as expected, needs to be fixed. However, the camera-specific part is OK.
edit2:
After analyzing the code (and the debug data provided by nafraf) I concluded that there must be some multitasking issue between the ptp and filewrite tasks. If that's the case, changeset 2243 should fix it.

I am not using PTP but I would guess the problem seems similar.
it is just a guess.

Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: SX170 porting
« Reply #142 on: 18 / September / 2014, 13:06:24 »
Quote from: Garden on 18 / September / 2014, 09:08:05
Sorry I think IDA did not disassemble it correctly.
ROM:FF810B64                 DCB 0x1E
ROM:FF810B65                 DCB 0xFF
Press 'c' on a 4-byte-aligned address ;)
Quote
Any other idea on the raw image problem?
Not really. The raw hooks (capt_seq_hook_raw_here in capt_seq.c) seem to be at the correct place. Perhaps some lower level Canon code has changed.
Note that there is only one fixed place in RAM for the RAW buffer (see the sx170is lib.c hook_raw_image_addr() and the sigfinder's output in stubs_entry.S). The camera's memory is shared, it's possible that parts of the RAW buffer get sometimes re-used for other kinds of image processing.
How often do you get corrupted RAWs when shooting for a while?
Upload a corrupted RAW (not DNG) file somewhere, maybe the cause of corruption can be identified.
Logged
*

Offline Garden

  • **
  • 60
Re: SX170 porting
« Reply #143 on: 18 / September / 2014, 15:00:25 »
Quote from: srsa_4c on 18 / September / 2014, 13:06:24
Quote from: Garden on 18 / September / 2014, 09:08:05
Sorry I think IDA did not disassemble it correctly.
ROM:FF810B64                 DCB 0x1E
ROM:FF810B65                 DCB 0xFF
Press 'c' on a 4-byte-aligned address ;)
Quote
Any other idea on the raw image problem?
Not really. The raw hooks (capt_seq_hook_raw_here in capt_seq.c) seem to be at the correct place. Perhaps some lower level Canon code has changed.
Note that there is only one fixed place in RAM for the RAW buffer (see the sx170is lib.c hook_raw_image_addr() and the sigfinder's output in stubs_entry.S). The camera's memory is shared, it's possible that parts of the RAW buffer get sometimes re-used for other kinds of image processing.
How often do you get corrupted RAWs when shooting for a while?
Upload a corrupted RAW (not DNG) file somewhere, maybe the cause of corruption can be identified.

After some tests I found out that the problem occurs  only when DNG is turned on and both images (DNG and JPEG) are affected. I am sending the JPEG image just for the sake of understand.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: SX170 porting
« Reply #144 on: 18 / September / 2014, 18:53:20 »
Quote from: Garden on 18 / September / 2014, 15:00:25
After some tests I found out that the problem occurs  only when DNG is turned on and both images (DNG and JPEG) are affected. I am sending the JPEG image just for the sake of understand.
Disable 'RAW buffer cached' in the RAW menu and test DNG again. reyalp might be interested in this...
Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: SX170 porting
« Reply #145 on: 18 / September / 2014, 18:57:17 »
Quote from: srsa_4c on 18 / September / 2014, 18:53:20
Quote from: Garden on 18 / September / 2014, 15:00:25
After some tests I found out that the problem occurs  only when DNG is turned on and both images (DNG and JPEG) are affected. I am sending the JPEG image just for the sake of understand.
Disable 'RAW buffer cached' in the RAW menu and test DNG again. reyalp might be interested in this...
Might also be interesting to see the resulting RAW image (although it might take some work to decode it).
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: SX170 porting
« Reply #146 on: 18 / September / 2014, 23:41:07 »
Does turning off the Canon date/time stamp on the image make any difference?

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

Offline Garden

  • **
  • 60
Re: SX170 porting
« Reply #147 on: 19 / September / 2014, 07:50:21 »
Quote from: srsa_4c on 18 / September / 2014, 18:53:20
Quote from: Garden on 18 / September / 2014, 15:00:25
After some tests I found out that the problem occurs  only when DNG is turned on and both images (DNG and JPEG) are affected. I am sending the JPEG image just for the sake of understand.
Disable 'RAW buffer cached' in the RAW menu and test DNG again. reyalp might be interested in this...

It does not work either. The same problem with buffer cached disable.
Logged
*

Offline Garden

  • **
  • 60
Re: SX170 porting
« Reply #148 on: 19 / September / 2014, 08:03:50 »
Quote from: philmoz on 18 / September / 2014, 23:41:07
Does turning off the Canon date/time stamp on the image make any difference?

Phil.

Turning off date/time stamp does not change anything.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: SX170 porting
« Reply #149 on: 19 / September / 2014, 08:15:25 »
Can you upload a DNG & JPG file to a file share site and post links here.

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)
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20 ... 27   Go Up
« previous next »
 

Related Topics