Quote from: srsa_4c on 14 / October / 2012, 17:54:31Cameras 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 closedAccording 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.
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.
Sorry I think IDA did not disassemble it correctly.ROM:FF810B64 DCB 0x1EROM:FF810B65 DCB 0xFF
Any other idea on the raw image problem?
Quote from: Garden on 18 / September / 2014, 09:08:05Sorry I think IDA did not disassemble it correctly.ROM:FF810B64 DCB 0x1EROM:FF810B65 DCB 0xFFPress 'c' on a 4-byte-aligned address QuoteAny 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.
Quote from: Garden on 18 / September / 2014, 15:00:25After 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...
Does turning off the Canon date/time stamp on the image make any difference?Phil.
Started by alvm
Started by runnercho
Started by TMHKR
RAW Shooting and Processing
Started by dvip
General Discussion and Assistance