chdkptp - alternative ptp client - page 17 - General Discussion and Assistance - CHDK Forum  

chdkptp - alternative ptp client

  • 1106 Replies
  • 448516 Views
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: alternative ptp client
« Reply #160 on: 03 / April / 2012, 14:46:08 »
Advertisements
Again, ptpCamGui.exe could downloaded all the images so I think it is an issue with chdkptp.
Not really. It's a PTP/Lua/memory issue.

ptpCamGui uses a different method. The number of possible images will be collected in a  text list and sent to the GUI. The GUI sends for every image a single Lua download command. This method is very slow but safe.

chdkptp works fast and directly. With the GUI of chdkptp we have a nice file browser. The amount of data to be processed can be critical. This is at first a camera issue.

msl
CHDK-DE:  CHDK-DE links

*

Offline reyalp

  • ******
  • 13844
Re: alternative ptp client
« Reply #161 on: 04 / April / 2012, 00:09:13 »
A follow up on the memory issue. I did another test with a borrowed camera that had free_block_max_size=328k  . It began downloading ~300 photos but aborted after saving ~160 photos. I didn't catch any error message.
Without knowing what failed, it's impossible to say. A memory issue seems likely, but of course there could be other bugs too.

I haven't done a lot of testing with large numbers of files.

I have some ideas for improving the memory situation, I'll try to look into it when I get some time. If someone else wants to play with it here are some of the issues:

1) The listing process gathers information about the files (path, stat information) and collects them into an array. When the array reaches batch_size, the whole thing is serialized and turned into a message.  You could monitor free memory (with get_meminfo), and force a batch to be sent earlier if it was low.

2) The message is queued in the PTP code until the PC side fetches it. The script will keep running and adding to the queue until it fills up (16 items) so a lot of memory can be used by stuff waiting in the queue. It would make more sense to send fewer, larger messages, but the message API doesn't make this easy to do. Some testing would be required to see if the queue actually fills up under normal usage. If so, it might make sense to force a sleep at some point (or make it a batcher option). Or improve the message API somehow.

3) Although lua has automatic garbage collection, it's still possible to run out of memory due to uncollected garbage, because the lua memory system doesn't know how much system memory is available. You can use collectgarbage to query memory usage or force collection. You can use get_meminfo to find out how much system memory is available.

4) The serialize function currently generates a LOT of garbage. In lua, each string is a unique value. So if you build a string piecewise by something like
Code: [Select]
while cond do
  foo = foo.."bar"
end
Every intermediate version becomes a lua string, which immediately becomes unreferenced, but might not be collected right away. Re-writing serialize to put all the parts in an array and join them once at the end would probably be a lot more memory friendly.

5) os.listdir lists all the files in a directory into a table, so anything that uses it inevitably uses more memory as the number of files goes up. Implementing a proper directory iterator function (like in lfs.dir() on the PC side) on the camera would solve this.

6) While improving efficiency would be good, it would be better to detect low memory and avoid failing.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13844
Re: alternative ptp client
« Reply #162 on: 29 / May / 2012, 02:30:19 »
New snapshot build r248 uploaded. This is mostly under the hood live protocol changes. You will need to use the latest chdk code from my branch to use live view.

Unless something jumps out has horribly broken in the protocol, I'll probably be moving it over to the trunk fairly soon.
Don't forget what the H stands for.

*

Offline blackhole

  • *****
  • 868
  • A590IS 101b
    • Planetary astrophotography
Re: alternative ptp client
« Reply #163 on: 29 / May / 2012, 05:02:39 »
Looks good on the A590, except impossibility to stop recording video, the camera does not respond to anything but the GUI reports: ERROR: the script is alredy running


*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: alternative ptp client
« Reply #164 on: 29 / May / 2012, 09:38:45 »
Thanks for your work on the live view stuff.

I have made few quick tests. A720 works fine. With the SX220 we have some problems.

1.
Compiler error message because of a double definition;
http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live/platform/sx220hs/sub/101a/stubs_entry.S#L52
http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live/platform/sx220hs/sub/101a/stubs_min.S#L5
I have only checked the SX220 1.01a on this issue. In trunk we haven't this problem.

2.
4:3 live view works not completely - see screenshot. 16:9 works fine.

msl
CHDK-DE:  CHDK-DE links

*

Offline reyalp

  • ******
  • 13844
Re: alternative ptp client
« Reply #165 on: 29 / May / 2012, 13:18:34 »
Looks good on the A590, except impossibility to stop recording video, the camera does not respond to anything but the GUI reports: ERROR: the script is alredy running
This means that whatever you used to start recording video is still running. Probably you used the "shoot" button, which calls shoot(), which is not appropriate for starting video because it tries to wait for still image capture to complete. If you did click('shoot_full') instead, that should work.

Note the previous version might have seemed to work, but it would actually risk some nasty memory corruption since the previous shoot() wasn't ended cleanly.

This is something that needs further thought on the control side. I guess the script called for the shoot button could detect if in a video mode, and do the right thing.

@msl
Thanks for testing. I'll take a look at those a bit later.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13844
Re: alternative ptp client
« Reply #166 on: 30 / May / 2012, 00:31:58 »
4:3 live view works not completely - see screenshot. 16:9 works fine.
This may be fixed with changeset 1875

edit:
or maybe 1877...

edit:
chdkptp r249 now checks if the camera is in video mode and uses click('shoot_full') instead of shoot.
« Last Edit: 30 / May / 2012, 02:38:19 by reyalp »
Don't forget what the H stands for.

*

Offline blackhole

  • *****
  • 868
  • A590IS 101b
    • Planetary astrophotography
Re: alternative ptp client
« Reply #167 on: 30 / May / 2012, 03:28:01 »
It is interesting that the digital zoom works well up to x8.2, then remains fixed the lower part of the picture, which increases along with increasing zoom.
Towards the enhancement of the x13 image appears in the upper left corner where it continues to increase.

edit:
chdkptp r249 now checks if the camera is in video mode and uses click('shoot_full') instead of shoot.
;)

« Last Edit: 30 / May / 2012, 04:17:09 by blackhole »


*

Offline ADamb

  • **
  • 65
  • sx200is
Re: alternative ptp client
« Reply #168 on: 30 / May / 2012, 07:39:36 »
Refresh for sx200is, together with EXMEM support and custom palette.

Should "print" call CHDK menu?
I have Canon print menu in playback and nothing in record modes.

Would it be possible to implement zoom slider?
SX200 IS-100C

*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: alternative ptp client
« Reply #169 on: 30 / May / 2012, 08:10:11 »
4:3 live view works not completely - see screenshot. 16:9 works fine.
This may be fixed with changeset 1875

edit:
or maybe 1877...

Yes, in record mode is all fine.

In playback mode it work not quite correct. The first screenshot shows a 4:3 image. But it seems to display as 1:1. The second screenshot shows the same image with one step zoom in. In this case the camera switches to 16:9, but chdk ptp to 4:3.

msl
CHDK-DE:  CHDK-DE links

 

Related Topics