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

CHDK PTP interface

  • 1240 Replies
  • 438263 Views
*

Offline jpq5588

  • *
  • 9
Re: CHDK PTP interface
« Reply #1080 on: 27 / May / 2014, 10:07:56 »
Advertisements
Quote from: reyalp on 16 / March / 2014, 21:47:41
Here's an a490 100f build for jpq5588


Thank you very much for that built, reyalp.
(I haven't seen it before... )

It is ok with A490 and rs, also in Chdk SuperFine mode and -dng mode.

Many thanks to srsa_4c who fixed the problem.


By the way, what is the command to apply .diff file to a local copy of a trunk ? (with chdk-shell win32 and gcc)
(I applied the patch by hand... :( )
« Last Edit: 27 / May / 2014, 10:57:47 by jpq5588 »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1081 on: 27 / May / 2014, 15:19:16 »
Quote from: jpq5588 on 27 / May / 2014, 10:07:56
By the way, what is the command to apply .diff file to a local copy of a trunk ? (with chdk-shell win32 and gcc)
I don't use that shell, but it has a "source tools" button. "patch" should be available from there.
Attached the 'completed'(= for all affected cams) patch for this problem - which is, as the last posts show, only a partial fix. The patch may not apply cleanly, as it's a bit dated.
« Last Edit: 27 / May / 2014, 15:30:25 by srsa_4c »
Logged
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: CHDK PTP interface
« Reply #1082 on: 16 / June / 2014, 08:53:39 »
Quote from: srsa_4c on 27 / May / 2014, 15:19:16
Quote from: jpq5588 on 27 / May / 2014, 10:07:56
By the way, what is the command to apply .diff file to a local copy of a trunk ? (with chdk-shell win32 and gcc)
I don't use that shell, but it has a "source tools" button. "patch" should be available from there.
Attached the 'completed'(= for all affected cams) patch for this problem - which is, as the last posts show, only a partial fix. The patch may not apply cleanly, as it's a bit dated.

Been playing with this on my G12.

What I've found so far:
- CAM_FILEWRITETASK_MULTIPASS is not needed on the G12, only one call to 'filewrite_main_hook' is made per file (regardless of mode)
- OFLAG_APPEND (not sure this is a good name) is always set in continuous mode, and never set in single shot
- 'fwt_close' is never called in continuous mode, this seems to be a major source of problems and lockups

Will update this post if I find more.

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 #1083 on: 16 / June / 2014, 14:51:21 »
Quote from: philmoz on 16 / June / 2014, 08:53:39
- CAM_FILEWRITETASK_MULTIPASS is not needed on the G12, only one call to 'filewrite_main_hook' is made per file (regardless of mode)
"multipass" is relatively hard to trigger on my a3200, a very detailed scene and/or superfine quality override is needed for it to happen.
Quote
- OFLAG_APPEND (not sure this is a good name) is always set in continuous mode, and never set in single shot
the name (which can be changed) is based on the variable's single mode behaviour, I only noticed the continuous mode ill-behaviour later
Quote
- 'fwt_close' is never called in continuous mode, this seems to be a major source of problems and lockups
There are like 3 different places in the Canon code to close the file, continuous mode uses a different one.
Thanks for the notes, btw.
Logged
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: CHDK PTP interface
« Reply #1084 on: 16 / June / 2014, 16:11:34 »
Quote from: srsa_4c on 16 / June / 2014, 14:51:21
Quote from: philmoz on 16 / June / 2014, 08:53:39
- CAM_FILEWRITETASK_MULTIPASS is not needed on the G12, only one call to 'filewrite_main_hook' is made per file (regardless of mode)
"multipass" is relatively hard to trigger on my a3200, a very detailed scene and/or superfine quality override is needed for it to happen.
Might also depend on camera resolution the G12 is only 10MP compared to the A3200 14MP.
Quote
Quote
- OFLAG_APPEND (not sure this is a good name) is always set in continuous mode, and never set in single shot
the name (which can be changed) is based on the variable's single mode behaviour, I only noticed the continuous mode ill-behaviour later
Quote
- 'fwt_close' is never called in continuous mode, this seems to be a major source of problems and lockups
There are like 3 different places in the Canon code to close the file, continuous mode uses a different one.
Thanks for the notes, btw.

Ok, missed one of the Close calls.

In limited testing today it seems to work ok - except after using chdkptp 'rs' or 'rsint' the camera crashes when switching to playback mode with 'unidentified image' displayed.

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 #1085 on: 16 / June / 2014, 18:09:46 »
Quote from: philmoz on 16 / June / 2014, 16:11:34
Might also depend on camera resolution the G12 is only 10MP compared to the A3200 14MP.
Could be, or some related Canon code can be different. My identification was based on the presence of '0x8000' in that part of the fwt code. I managed to make a multipass JPEG at the camera's 7MP setting - I'm using a fine black/white grid displayed on the monitor to torture the JPEG engine.
Quote
In limited testing today it seems to work ok - except after using chdkptp 'rs' or 'rsint' the camera crashes when switching to playback mode with 'unidentified image' displayed.
I have updated nafraf's table.
Logged
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: CHDK PTP interface
« Reply #1086 on: 16 / June / 2014, 20:56:12 »
Quote from: srsa_4c on 16 / June / 2014, 18:09:46
Quote from: philmoz on 16 / June / 2014, 16:11:34
Might also depend on camera resolution the G12 is only 10MP compared to the A3200 14MP.
Could be, or some related Canon code can be different. My identification was based on the presence of '0x8000' in that part of the fwt code. I managed to make a multipass JPEG at the camera's 7MP setting - I'm using a fine black/white grid displayed on the monitor to torture the JPEG engine.

Haven't reproduced it yet, will keep testing.

I think the OFLAG_APPEND bit (0x8000) may be more related to calling a different version of Close, than indicating that the file is being appended. Perhaps an optimised code path.

Have you tried checking the 'flags' parameter to 'open' to see if the O_APPEND flag is set or not? (Don't forget the value of O_APPEND differs between VxWorks and DryOS).

For a multi-pass image save, I would expect the final file update would not have O_APPEND set, since it would need to re-write the file header.

If you combine OFLAG_APPEND, 'flags' & O_APPEND, and a test of the very first chunk for a JPEG file header, then there might be enough information to determine if a multi-pass save is happening and detect the last segment.
This is all speculation at the moment, I'll do some more experiments and testing when I get a chance.

Phil.

Edit: back at a computer now, and looking at this in more detail. In this post http://chdk.setepontos.com/index.php?topic=4338.msg111230#msg111230 you show the fwt_data from a normal and multi-pass image save.

From these it looks like:
- oflags & 0x300 == 0x300 --> first or only invocation for file
- oflags & 0x308 == 0x008 --> appending to file (O_APPEND)
- oflags & 0x308 == 0x000 --> last invocation for file

So the problem is how to determine if this is a single or multi-pass file save - in this case examining the first chunk of memory for a JPEG header should work.

Phil.
« Last Edit: 17 / June / 2014, 05:23:53 by philmoz »
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 #1087 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).
However, if you don't ever get a multipass JPEG, your cam may not be affected by any of these issues. The playback mode crash is a separate thing, unrelated to our fwt code (reyalp mentioned somewhere that it's also happening when JPEGs are erased after shooting).
Logged
*

Offline philmoz

  • *****
  • 3445
    • Photos
Re: CHDK PTP interface
« Reply #1088 on: 17 / June / 2014, 16:02:18 »
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).
However, if you don't ever get a multipass JPEG, your cam may not be affected by any of these issues. The playback mode crash is a separate thing, unrelated to our fwt code (reyalp mentioned somewhere that it's also happening when JPEGs are erased after shooting).

Why would the logic not work for continuous mode as well as single-shot?
Is there a different pattern for oflags (ignoring the 0x8000 bit)?

I would have thought continuous mode would work the same with regard to the actual file saving.

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

I'm unsure whether checking the first memory chunk for a JPEG header would be reliable, you mentioned in a previous post that it contains random data; but there is always a chance it could contain a JPEG header from a previous image.

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 #1089 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).
Logged
Pages: 1 ... 104 105 106 107 108 [109] 110 111 112 113 114 ... 125   Go Up
« previous next »
 

Related Topics