CHDK PTP interface - page 104 - General Discussion and Assistance - CHDK Forum

CHDK PTP interface

  • 1227 Replies
  • 379901 Views
*

Offline blackhole

  • *****
  • 844
  • A590IS 101b
    • Planetary astrophotography
Re: CHDK PTP interface
« Reply #1030 on: 06 / July / 2013, 16:28:04 »
Advertisements
Quote
Requests for filewrite support on specific cameras are also welcome.
Can you please make a filewrite support for a590 101b, when you have free time.
-raw and -dng works great.

*

Offline reyalp

  • ******
  • 13438
Re: CHDK PTP interface
« Reply #1031 on: 06 / July / 2013, 18:05:43 »
edit:
Ugh, it gets more complicated:
shooting_is_flash returns:
shooting_get_prop_int(PROPCASE_IS_FLASH_READY), which is what the old ubasic code did.

shooting_flash_is_ready checks more stuff.
Checking PROPCASE_IS_FLASH_READY on a540 and D10, it appears to behave pretty much as expected. I would expect there's some situations where the additional checks in shooting_is_flash_ready() are required.

Also,  shooting_is_flash_ready() returns true if the flash is not selected, which is desirable if you are waiting to shoot.

If it were just additional checks, I'd be tempted to add a parameter to get_flash_ready (e.g. default uses current behavior, get_flash_ready(1) uses shooting_is_flash_ready(), but the difference in return logic makes that even uglier.

Since the current get_flash_ready just checks a propcase, removing it wouldn't be a big deal for Lua, whereas shooting_is_flash_ready cannot be replicated in lua.

searching the wiki (using google, I don't trust wiki search) with
site:http://chdk.wikia.com get_flash_ready
only returns reference pages, not actual scripts. Googling without site restriction also doesn't turn up a whole lot.

 :'(
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: CHDK PTP interface
« Reply #1032 on: 06 / July / 2013, 18:59:32 »
Ugh, it gets more complicated:
shooting_is_flash returns:
shooting_get_prop_int(PROPCASE_IS_FLASH_READY), which is what the old ubasic code did.

shooting_flash_is_ready checks more stuff.

The 'shoot' command uses 'shooting_is_flash_ready' which is how I found the problem.

Phil.
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 reyalp

  • ******
  • 13438
Re: CHDK PTP interface
« Reply #1033 on: 08 / July / 2013, 23:16:11 »
In changesets trunk 2944 and 2945, I've changed the way alt mode is handled when running PTP scripts.

Previously, it would just set kbd_blocked. This is required to allow sending key presses (e.g. click('set')) but it isn't full alt mode, and left the camera in a state where you need to press alt once to get canon firmware keys, or twice to get back to real alt mode.

I changed to use enter_alt() and, if the camera wasn't in alt when the script started, use exit_alt() when the script ends. Calling enter_alt() or exit_alt() from script overrides the saved state, so that when the script exits it will stay in whatever state the script set.

Aside form fixing the issue mentioned above, the main visible impact is that the alt indicator will flash when you run a script.
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 13438
Re: CHDK PTP interface
« Reply #1034 on: 21 / July / 2013, 22:20:43 »
Regarding this from the 1.2 release thread
Quote
* Make PTP not use 50% of available RAM for buffer if there's lots available.
I did some investigation. Conclusion is basically that download performance is better with larger buffer size, up to at least 1mb or so. I tested both downloading a DNG file (which does file IO in units of the "buffer size") and using GetMemory (which still sends in "buffer size" units, even though it doesn't do any actual buffering)

Attached patch is the code I used for testing.

To time, i used the following in chdkptp
Code: [Select]
set cli_xferstats=true
set cli_time=true
To adjust the (max) size of the buffer
Code: [Select]
=set_usb_buf_max(1024*1024)
note it will still be capped at 1/2 ram, so you need to check how much you have free. For 1mb or more, exmem is recommended...

to test download speed
Code: [Select]
d -nolua DCIM/100CANON/CRW_nnnn.DNG

to test rmem speed
Code: [Select]
!con:getmem(0x1900,1024*1024)

Some results on D10
DNG file (18,801,888 ),
32k buf = 4.8 sec
64k buf = 4.2 sec
128k buf = 3.8 sec
512k buf = 3.5 sec
1m buf = 3.4 sec

Above is all with camera in playback mode, record mode is notably slower (~6 sec with a 32k buffer). I've seen the same effect in other situations, so this isn't a surprise.

I tested uploads too, but the difference was much smaller, possibly due SD writes being significantly slower.

rmem
1m data, 1m buf = 0.032 sec
1m data, 64k buf = 0.059 sec

In the end, I decided not make any changes in the trunk for now. It would be nice to be able to control it, but doing something useful would be a bit complicated. For max performance, you might want to allow > 1/2 free mem, while if you had a complicated script or shooting running at the same time, you might want to limit it to less.

I did notice that remote capture is using send_ptp_data (which always writes in buffer_size chunks) rather than calling data->send_data like live view. I suspect it could be sped noticeably using the latter, unless it all has to fit in some internal buffer.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13438
Re: CHDK PTP interface
« Reply #1035 on: 21 / July / 2013, 23:30:55 »
I did notice that remote capture is using send_ptp_data (which always writes in buffer_size chunks) rather than calling data->send_data like live view. I suspect it could be sped noticeably using the latter, unless it all has to fit in some internal buffer.
I changed this to use data->send_data, which makes dng remoteshoopt about 200ms quicker on my D10.

I think the original reason for send_ptp_data using fixed data size was on the theory that it might have a limited size buffer somewhere, and not know what to do with larger values. However, given that D10 happily sends a ~18mb raw buffer in one go, I don't think this could be true. EXMEM_COM on D10 is 1mb. I assume this is the PTP data buffer since it is allocated when PTP is present.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4426
Re: CHDK PTP interface
« Reply #1036 on: 24 / July / 2013, 19:11:04 »
I think the original reason for send_ptp_data using fixed data size was on the theory that it might have a limited size buffer somewhere, and not know what to do with larger values.
:-[ Actually, I don't know why I used that call. It was there since my first implementation. I probably copy-pasted some lines, and hadn't noticed the possible adverse effects. So, thanks for fixing it.

*

Offline reyalp

  • ******
  • 13438
Re: CHDK PTP interface
« Reply #1037 on: 29 / July / 2013, 01:31:27 »
I've noticed chdkptp remoteshoot sometimes returning a corrupt dng header, with either -dng or -dnghdr. Rather than the 0x4949 byte order marker it has 0xcd68. A bit more of the header seems corrupt too, but much of it is normal

I'm not clear yet whether it is happening on the camera side or chdkptp side, although checking immediately after the data is received shows it is corrupted, so I think it's on the camera side.

It might be something in my chdkptp development code, but I thought I'd post in case anyone else sees it.

The current chdkptp code in SVN won't notice a corrupt header unless you are using sub-image dng (rs -s and/or -c options) so that may explain why I haven't noticed it before.

edit:
May have found the culprit, create_dng_header_for_ptp returned an uncached address, but did not clean. I changed it to a cached address in r2990.
« Last Edit: 29 / July / 2013, 02:00:24 by reyalp »
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 13438
Re: CHDK PTP interface
« Reply #1038 on: 08 / August / 2013, 02:16:19 »
remote shoot in continuous mode seems to fail frequently on a540.
The output cli_verbose output when it happens looks something like this:
Code: [Select]
get data 16
rc file IMG_7576.jpg 1
rc chunk get IMG_7576.jpg 1 0
rc chunk size:7680 offset:nil last:false
rc chunk get IMG_7576.jpg 1 1
rc chunk size:1536116 offset:nil last:true
time 8.6325 0.4710
get data 17
rc file IMG_7578.jpg 1
rc chunk get IMG_7578.jpg 1 0
rc chunk size:7680 offset:nil last:false
rc chunk get IMG_7578.jpg 1 1
rc chunk size:1533559 offset:nil last:true
time 9.4095 0.7770
get data 18
rc file IMG_7578.jpg 1
rc chunk get IMG_7578.jpg 1 0
rc chunk size:0 offset:nil last:true
ERROR: d:\chdk\chdkptp\lua\chdku.lua:1015: invalid offset
Each get data should be an image. Note that 16 is image #7576, 17 is #7578 (skipping one) then 18 is 7578 again, but zero sized with last set, which triggers the actual error. The actual error is caused by lbuf:fwrite trying to write a zero sized chunk. This is likely not related to the actual problem, but may have been missed before because it used to allow 0 sized chunks.

This frequently seems to hit between 10-20 shots, though I've done runs of 60 without hitting it.

I haven't seen on d10 yet, but I haven't tried many long continuous sequences either.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: CHDK PTP interface
« Reply #1039 on: 09 / August / 2013, 03:51:54 »
Hi reyalp, I've been trying out test versions of CHDK from nafraf for A490 with filewrite. We've run into an error that appears after a (variable) number of rs (or rs -jpg) photos that save jpg files to a connected computer. Sometimes it takes 8 photos for the error to appear, sometimes 18 and sometimes many more. To reproduce the problem, just run separate rs commands many time in a row. I've reproduced the problem on the A2300 and nafraf encounters it on the A495. For the A2300 nafraf has a test version of CHDK ( a2300-100f-1.3.0-noexmem.zip ) that seems to fix the problem. At least 100  photos in a row using rs was successful when I tested it. But nafraf suspects the error may be from a memory issue (the A490 has little internal memory compared to some other cameras).

The error looks like this in interactive mode
Code: [Select]
con 89> rs
time 21.3564
ERROR: timed out uninit a script is already running
Every command sent after that gets the script "already running error" and no photo is taken. After a power off/on the camera works again.
« Last Edit: 09 / August / 2013, 03:56:09 by tpont »

 

Related Topics