CHDK PTP interface - page 110 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 105 106 107 108 109 [110] 111 112 113 114 115 ... 125   Go Down

CHDK PTP interface

  • 1240 Replies
  • 434269 Views
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: CHDK PTP interface
« Reply #1090 on: 17 / June / 2014, 18:56:28 »
Advertisements
Quote from: srsa_4c on 17 / June / 2014, 18:33:29
Thanks for the idea, I'll see whether it can be used in practice.
Side note: The 'ff d8 ff e1' byte sequence appears more than once in JPEGs of some new models (ixus115: twice, sx280: 3 times).

Hopefully we would really only care about the contents at the very start of the first chunk being saved.

Probably need to check for more that just these four bytes.

0xFF 0xD8 = SOI marker (Start Of Image)
0xFF 0xE1 = APP1 marker (EXIF header)

Following these are the APP1 size, EXIF header, TIFF header, IFD0, etc.

It's possible there could be multiple APP1 segments in the file, for thumbnail images.
If one of these is generated and saved first, then we are probably screwed.

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 philmoz

  • *****
  • 3445
    • Photos
Re: CHDK PTP interface
« Reply #1091 on: 21 / June / 2014, 02:18:41 »
Quote from: srsa_4c on 15 / February / 2014, 20:31:52
I have to correct my earlier statement.
Quote
It looks like that
- filewritetask only writes jpeg files (!), native raw is written elsewhere
Native RAW files are also written by filewritetask. In RAW + JPEG case, native RAW is saved first - the code doesn't currently handle this, rs -jpg will simply retrieve the native RAW file and let the camera save the JPEG to the card.

Noticed this as well when testing the G12.

It seems we need two changes to support this:
- send a flag to chdkptp to tell it whether to expect 1 file (JPEG, or RAW) or 2 files (RAW+JPEG). Property 214 on the G12 & G1X could be used to determine this (RAW=0, JPEG=1, RAW+JPEG=2).
- send the filename from the fwt_data_stuct.name field, instead just sending the file number from target_file_num

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 srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1092 on: 26 / June / 2014, 18:46:07 »
Quote from: philmoz on 17 / June / 2014, 16:02:18
A single-pass save would have:
    - oflags & 0x300 == 0x300
    - a valid JPEG header in the first chunk of memory

A multi-pass file save would have:
    - oflags & 0x300 == 0x300 on the first invocation
    - an in-valid JPEG header in the first chunk of memory
    - oflags & 0x308 == 0x008 for each append to the file
    - oflags & 0x308 == 0 for the last invocation that re-writes the header
A small update on this: I have encountered a variation in which a multipass JPEG starts with a big chunk of the final JPEG (with its exif in place). Of course no flags help with the indication (oflags is 0x8301 for the 1st pass).
I wonder if we should assume multipass for all cases which can't be pre-determined and use either the timeout (while waiting for the next pass) and/or filename-check to deal with the situation gracefully...
« Last Edit: 26 / June / 2014, 18:55:08 by srsa_4c »
Logged
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: CHDK PTP interface
« Reply #1093 on: 26 / June / 2014, 19:02:42 »
Quote from: srsa_4c on 26 / June / 2014, 18:46:07
Quote from: philmoz on 17 / June / 2014, 16:02:18
A single-pass save would have:
    - oflags & 0x300 == 0x300
    - a valid JPEG header in the first chunk of memory

A multi-pass file save would have:
    - oflags & 0x300 == 0x300 on the first invocation
    - an in-valid JPEG header in the first chunk of memory
    - oflags & 0x308 == 0x008 for each append to the file
    - oflags & 0x308 == 0 for the last invocation that re-writes the header
A small update on this: I have encountered a variation in which a multipass JPEG starts with a big chunk of the final JPEG (with its exif in place). Of course no flags help with the indication (oflags is 0x8301 for the 1st pass).

Is it the correct EXIF for the image (correct segment length and filename)?

There's a chance the memory could contain the data from a previous save - which would make things somewhat difficult.

Another thought I had was maybe we could move the problem to the host computer instead of the camera.
The process might work something like this:
- host tells camera to send next filewrite invocation to PC, camera just sends all the data without trying to figure anything out (including oflags and filename)
- host uses oflags and filename to open/create/append and write data to file
- if this is a new file (oflags & 0x300 == 0x300), then examine file content to see if it is complete (EXIF header is correct and consistent), if complete then we are done
- if file is not complete, then request more filewrite invocations from the camera until we get the final one (oflags & 0x8 == 0)

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 srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1094 on: 27 / June / 2014, 18:26:00 »
Quote from: philmoz on 26 / June / 2014, 19:02:42
Is it the correct EXIF for the image (correct segment length and filename)?
The question is good. Some of the exif data seems final, but some of its parts are missing: the halfword after the first ff d8 ff e1 is zero, the thumbnail image is not there yet. The "file number" (as exiftool calls it) is there and is correct. Since this was the first photo taken in that session, it may not happen regularly (apparently, chunks of the JPEG are allocated separately).

Quote
There's a chance the memory could contain the data from a previous save - which would make things somewhat difficult.
Seems unavoidable (unless we erase some sensitive parts after transfer), but wouldn't happen very often.

Quote
Another thought I had was maybe we could move the problem to the host computer instead of the camera.
I don't know. So much trouble to support this camera generation.
On the a3200, only continuous mode has these problems, single mode is working well (with the current multipass code).

Your recent commit seems to suggest that none of your cameras is "multipass". If so, I don't have an idea how to detect which cameras have this problem (other than getting bugreports from users).
Logged
*

Offline reyalp

  • ******
  • 13882
Re: CHDK PTP interface
« Reply #1095 on: 19 / August / 2014, 16:52:42 »
Quote from: srsa_4c on 17 / June / 2014, 15:11:04
Quote from: philmoz on 16 / June / 2014, 20:56:12
So the problem is how to determine if this is a single or multi-pass file save
No, the problem is with continuous mode. My last patch is already able to deal with single shot mode (at least I believe so).
If this still holds, I'd be tempted to say use this code for 1.3 and disable remote capture in continuous mode. It turns out that most of the benefits of continuous mode can be achieved by holding half press and clicking full, so the need for continuous mode is less. Assuming this doesn't also trigger the bug... which I guess we need to test.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1096 on: 20 / August / 2014, 16:24:54 »
Quote from: reyalp on 19 / August / 2014, 16:52:42
Quote from: srsa_4c on 17 / June / 2014, 15:11:04
Quote from: philmoz on 16 / June / 2014, 20:56:12
So the problem is how to determine if this is a single or multi-pass file save
No, the problem is with continuous mode. My last patch is already able to deal with single shot mode (at least I believe so).
If this still holds, I'd be tempted to say use this code for 1.3 and disable remote capture in continuous mode. It turns out that most of the benefits of continuous mode can be achieved by holding half press and clicking full, so the need for continuous mode is less. Assuming this doesn't also trigger the bug... which I guess we need to test.
I have since made some changes to my experimental code (plus it's stuffed with debug lines), I'll try to determine which one works better.

My other problem is that not all cameras from the affected generations appear to have this issue (see Phil's posts).
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1097 on: 28 / August / 2014, 18:44:58 »
I have rediscovered ( :-[ ) that the patch attached to this post does appear to solve the problems on my a3200 when the camera is not in continuous mode. If this fix should be the official one then I should probably change some names in it (as suggested by philmoz).
We'll also have to determine somehow which cameras need the fix...
Quote from: reyalp on 19 / August / 2014, 16:52:42
It turns out that most of the benefits of continuous mode can be achieved by holding half press and clicking full, so the need for continuous mode is less. Assuming this doesn't also trigger the bug... which I guess we need to test.
Can you suggest a way to test this situation?
Logged
*

Offline reyalp

  • ******
  • 13882
Re: CHDK PTP interface
« Reply #1098 on: 30 / August / 2014, 23:23:05 »
Quote from: srsa_4c on 28 / August / 2014, 18:44:58
We'll also have to determine somehow which cameras need the fix...
We could just apply it to cameras known to suffer from the problem.

Quote
Quote from: reyalp on 19 / August / 2014, 16:52:42
It turns out that most of the benefits of continuous mode can be achieved by holding half press and clicking full, so the need for continuous mode is less. Assuming this doesn't also trigger the bug... which I guess we need to test.
Can you suggest a way to test this situation?
The new rs -quick=n option described here http://chdk.setepontos.com/index.php?topic=6231.msg116242#msg116242 should do it.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1099 on: 31 / August / 2014, 17:32:07 »
Quote from: reyalp on 30 / August / 2014, 23:23:05
The new rs -quick=n option described here http://chdk.setepontos.com/index.php?topic=6231.msg116242#msg116242 should do it.
Done, the camera does not show the continuous mode anomalies (as expected) when using that command.
Logged
Pages: 1 ... 105 106 107 108 109 [110] 111 112 113 114 115 ... 125   Go Up
« previous next »
 

Related Topics