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

CHDK PTP interface

  • 1227 Replies
  • 380119 Views
Re: CHDK PTP interface
« Reply #470 on: 09 / April / 2011, 18:37:31 »
Advertisements

*

Offline msl

  • *****
  • 1276
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: CHDK PTP interface
« Reply #471 on: 09 / April / 2011, 19:09:47 »
Hello and welcome,

at the moment is it not possible to switch in the CHDK menu over ptpCamGui.

msl
CHDK-DE:  CHDK-DE links

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: CHDK PTP interface
« Reply #472 on: 15 / April / 2011, 08:38:57 »
ptpCamGui:

The command luar post_levent_to_ui(4484) to unlock the keys in play mode is now a start option for all DryOS cameras.  That means, for all DryOS camera the keys are directly after GUI start unlocked.

I hope the value 4484 is really valid for all DryOS cameras.

msl

luar post_levent_to_ui(4484) works for G12 and SX30.

I did notice that after using 'Download' with 'Delete files' option checked the camera was rebooted after deleting the files; but it did not do the luar post_levent_to_ui(4484) command so the keys were locked again.

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 msl

  • *****
  • 1276
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: CHDK PTP interface
« Reply #473 on: 15 / April / 2011, 09:17:58 »
I did notice that after using 'Download' with 'Delete files' option checked the camera was rebooted after deleting the files; but it did not do the luar post_levent_to_ui(4484) command so the keys were locked again.

Thx for the informations. The problem should be solved with the new GUI version (revision 92).

msl
CHDK-DE:  CHDK-DE links


*

Offline reyalp

  • ******
  • 13439
Re: CHDK PTP interface
« Reply #474 on: 17 / April / 2011, 15:29:11 »
I've tried to bring the wiki up to date to reflect the fact that this is now standard in the trunk and also mention ptpcamgui and chdkptp http://chdk.wikia.com/wiki/PTP_Extension Further improvements are welcome!

I am considering another change to the PTP protocol:
Currently, tables are returned as PTP_CHDK_TYPE_STRING. I would like to return them as PTP_CHDK_TYPE_TABLE. This will still be string, but it will be easier for the client to know what it is supposed to be. This will be a "major" protocol change since it's incompatible with current code, but supporting it should be easy.

I would also like to change the format that tables are returned with. Currently, in chdkptp, I override usb_msg_table_to_string on every call, which is slightly annoying.

For me, the ideal format would be the output of the serialize function in chdkptp chdku.lua but I don't know if this will be too hard to parse in ptpcamgui ? If it is, I can continue overriding usb_msg_table_to_string, this is less of an issue than the type. Or maybe we can add an option for a simplified format in serialize().

It would be nice to be able to set some 'standard libraries' that can be uploaded once and remain available to every ptp lua execution, but don't have to loaded from disk or over ptp every time, and don't have to be in memory when PTP isn't in use.

One way of doing this
add_ram_module("name","lua code")
this stores the lua code in regular malloc memory. require is updated so require("name") runs the code. Lua require already has provisions for various custom loading methods, so this should be easy.
you'd also want remove_ram_module("name") and remove_all_ram_modules(). Names subject to change ;)
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #475 on: 18 / April / 2011, 15:27:14 »
I have obviously missed something, but I have tried to follow the instructions as best I could, but I get the same error every time I try to run the PTP interface.  The attached .jpg shows the error, and I think I just need to know where to put the libusb0.dll file, but I don't have a clue.

*

Offline msl

  • *****
  • 1276
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: CHDK PTP interface
« Reply #476 on: 18 / April / 2011, 16:25:43 »
You need an alternative USB driver: http://sourceforge.net/projects/libusb-win32/

See also here.

msl
CHDK-DE:  CHDK-DE links

Re: CHDK PTP interface
« Reply #477 on: 19 / April / 2011, 15:00:07 »
I finally got it to recognize the camera, but I now get a continuous loop that I have let run for over 5 minutes before aborting.  The loop goes like this:

** i** init()** init() start ...
>> version << ptpcam: 1.0
camera: 1.0 (Length: 24)
>> script-support << script-support:0x1 lua=yes (Length: 26)
>> luar not(os.stat("A/CHDK/LUALIB/lptpgui.lua")==nil) << script:8
8:ret:false (Length: 21)
>> upload lptpgui.lua A/CHDK/LUALIB/lptpgui.lua
** init() fail
>> reset <<  (Length: 0) [ERROR: Could not close session! (Length: 31)]
** init() start ...
>> version << ptpcam: 1.0
camera: 1.0 (Length: 24)
>> script-support << script-support:0x1 lua=yes (Length: 26)
>> luar not(os.stat("A/CHDK/LUALIB/lptpgui.lua")==nil) << script:9
9:ret:false (Length: 21)
>> upload lptpgui.lua A/CHDK/LUALIB/lptpgui.lua

It will not ever go into the PTP GUI so that I might test it out.  I'm using an SD940 with firmware version 1.03c.


Re: CHDK PTP interface
« Reply #478 on: 19 / April / 2011, 16:58:37 »
I finally got it to recognize the camera, but I now get a continuous loop that I have let run for over 5 minutes before aborting.
You'll have to make sure the directory A/CHDK/LUALIB is already created. The tool should probably do a "mkdir -p" before trying to upload. (I encountered this my self one or two days ago but didn't get around to posting it yet.)

Re: CHDK PTP interface
« Reply #479 on: 20 / April / 2011, 06:56:51 »
At the moment I'm working on remote live preview (or whatever it should be called) and I would like to do it in such a way that it can be added to CHDK permanently. So here's is my proposal (and related questions).

There essentially two extensions. One is to retrieve the various details such as image dimensions and buffer addresses. The other is to obtain a live image but also deal with the fact that buffer addresses are typically rotated.

For the latter I propose to add an flags parameter to the PTP_CHDK_GetMemory command. The currently only flag (0x1) will indicate that the first parameter is not a buffer address, but a pointer to function for obtaining the address. So if the flag is set, the camera will essentially first do "addr = ((ftype) addr)();". This seems a nice minimal adjustment to the PTP code.

For the details (such as the function to use above), I propose to introduce a Lua function. This function (I called it "get_video_details()") would either return a string containing a C struct with all the details or perhaps make a nice Lua table for it. The type of result probably depends on how often it will be called, but more on that later.

As for the details themselves, we need the following:

  • actual live image dimensions (= bitmap dimensions?)
  • (function to get) address of relevant viewport buffer
  • width and height of viewport image
  • width of viewport buffer (height shouldn't matter as the height of the image is all we need)
  • x/y offset of viewport image in buffer
  • (function to get address) of bitmap buffer
  • width and height of bitmap image
  • width of bitmap buffer (again no height)
  • value or function to determine whether bitmap is shown
  • palette (either as a whole or just CAM_BITMAP_PALETTE)

Now one question is how stable is this information and as a consequence how often do we retrieve it? I already assumed we would use a function instead of an address for getting the buffers, but if we get all of this information every time before we get a buffer that seems kind of pointless. The reason I assumed a function is because the other data is relative stable. Only when switching aspect ratio these seem to change. Perhaps it's better to do a less frequent check for such a change?

If details are "unstable" or we just decide to get them every time, perhaps it is a good idea to consider making a function that provides both the details and the buffer(s) together. To keep the PTP code relatively clean we could "export" some functions for sending data that can be used for the big send_details_and_buffers() function. And in this case the proposed change to GetMemory has to be adapted to just call the function instead of using its result to send data. That or adapt CallFunction such that a flag indicates that the address is in Param2 instead of sent as data (to free up the data phase).

Another question is which actual dimensions one should use in displaying images and how the various components are composed in that image. This is not something that appears in CHDK code, but it is important in the use of it. It seems the bitmap image corresponds to the actual dimensions, but I not 100% sure. Do you just stretch the viewport image to those dimensions or should you add black borders to get the maximum viewport dimensions and stretch that?

If I interpret the comments of image_offset and row_offset correctly the image buffer actually already has black borders where needed and we can just always use the maximum viewport dimensions. This does mean some code needs to be added for some platforms to get this maximum. (Although at the moment this is just relevant for G12 en SX30, right?)

With respect to the palette I was thinking of just sending CAM_BITMAP_PALETTE and let tools have the (currently) used palettes hard coded in them. This way you don't have to transfer it, but more importantly it seems that this is the only detail that currently isn't readily available.

Some small things:
  • In include/platform.h some vid_* functions return long, some int. I don't think there is a reason, but I'd like to be sure.
  • In image_offset and row_offset in platform/g12/lib.c I'm a bit confused about the "*3". Shouldn't it be 6 bytes per 4 pixels instead of 3 per 1?
  • Also, shouldn't the version of row_offset in generic be buffer_width-width to be safe?
  • I was also wondering where viewport_fb exactly fits in. It is used differently in various places: as default for record mode, as "slow" fallback in record mode, as fallback in any mode, in case of "KEY_SHOOT_HALF"...
  • Looking at ewavr's old code I noticed that he introduced special _for_ptp functions (e.g. vid_get_bitmap_fb_for_ptp) that differ from their "non-ptp" variant. Not sure what's going on there. I would not expect this code to depend on using PTP or not.


Please let me know what you think about all this. And thanks for reading it all. You did read it all, didn't you? ;)



To really conclude some side notes:

Proper serialisation in Lua looks nice, but also complicated/expensive. And it would indeed bump up the PTP version. Perhaps an option is to leave implicit serialisation as it is now and just provide a proper serialise function for Lua programmers to use if they want to communicate more complex things (as is the case in most languages I believe).

I would also like to note that my experience with installing and figuring out how to draw an image with IUP has been quite frustrating. In the end I just piped the data to an external program. It definitely has resulted in my not being a fan of it. Just wanted to get that of my chest. ;)

On a more positive note, I've found a nice project: LibUsbDotNet This provides a cross-platform .NET interface to libusb (and something similar(?) called WinUsb). I haven't really tested in on Linux yet, but it seems to work. I'm using C# to make a (CHDK-)PTP layer on top of it.

 

Related Topics