CHDK PTP interface - page 59 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 ... 54 55 56 57 58 [59] 60 61 62 63 64 ... 123   Go Down

CHDK PTP interface

  • 1227 Replies
  • 381282 Views
*

Offline mweerden

  • ***
  • 194
Re: CHDK PTP interface
« Reply #580 on: 06 / September / 2011, 19:36:49 »
Advertisements
Quote from: philmoz on 06 / September / 2011, 18:40:19
But making it harder to support older versions won't help encourage people to do it :)
Not sure I see how it's harder than other obvious options.

Quote
Giving the end user accurate information is important - a generic 'somethings wrong' message is not good. Being able to tell the user that 'you don't have the live view extensions in CHDK', or 'you have and older/newer version you need to update your CHDK/client program' is preferable.
In principle I agree. However, I think "no or incompatible support" is about as accurate and useful as you can get. The extra distinction doesn't seem 100% reliable to me and still means that the user has to go out and find compatible versions of CHDK and "client".

Quote
It's also about style.
To me, changing the function name implies that something has changed about the function itself (new signature, different return value etc).
The function does change. Only looking at its signature or something is rather arbitrary. :P
Logged
*

Offline reyalp

  • ******
  • 13457
Re: CHDK PTP interface
« Reply #581 on: 06 / September / 2011, 22:31:42 »
Quote from: philmoz on 06 / September / 2011, 04:35:26
Apart from the change to PTP_CHDK_CallFunction I'm not sure I really see much difference between the two approaches. One puts the code in Lua although this could be refined (see below), the other puts it in PTP - does the distinction really make a difference?
The distinction is the Lua part is completely artificial. There is no use for it in Lua, it is, as mweerden said, just a way of calling a function by name, so you can pretend that the protocol hasn't changed. This is not helpful, because anything that actually *uses* it will be affected by changes just the same as a protocol change. It just makes the whole thing more opaque and complicated.

The compatibility problems are the same, you are just making them less centrally documented. Imagine a third party wants to implement live view (gphoto actually picked up ewavrs old code, so this isn't just theoretical. Hopefully once we've got this stabilized we can get them to support the trunk version instead) If it's in the protocol, then they only have to update when the protocol changes, which is visible, centralized and has a well defined way to check protocol compatibility. If it's defined elsewhere, then (as you discuss with mweerden in the following posts) you have to add versioning to that elsewhere, which makes things more complicated.

That's why I'm arguing for putting it in the protocol. Once you get the protocol right it shouldn't need to change too often.
Quote from: mweerden on 06 / September / 2011, 11:31:23
To me that is (almost) like saying HTTP is part of TCP.
Right, if you want to define another protocol for live view, that runs on top of CHDK PTP, but IMO that's not warranted.
Quote
that's also why I wouldn't be a fan of your monolithic PTP_CHDK_GetStreamingData. It only takes one of the flags to change in meaning to destroy backwards compatibility.
Then don't change the flags unless you really need to, deprecate them, add new ones, and only drop them when you are forced to make a protocol change for other reasons. If you use up all 128 bits of params to PTP_CHDK_GetStreamingData, you can always add PTP_CHDK_GetStreamingDataEx if you really want to ;)

The same thing happens if change the flags in your system, it just less clearly defined.

Centralizing other things that a client would also want to poll also has real value. If getting the palette and frame buffer separately hurts frame rate, then polling script status and live view will do the same.

There are other ways you could set it up rather than using flags, but honestly I don't see us using more than a couple ints worth.
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: CHDK PTP interface
« Reply #582 on: 06 / September / 2011, 23:01:15 »
Quote from: reyalp on 06 / September / 2011, 22:31:42
Quote from: mweerden on 06 / September / 2011, 11:31:23
To me that is (almost) like saying HTTP is part of TCP.
Right, if you want to define another protocol for live view, that runs on top of CHDK PTP, but IMO that's not warranted.

I think it makes sense to define the live view data transfer as a seperate protocol on top of PTP.
It's a complex transfer including metadata, isolating it away from the core PTP keeps things cleaner.
PTP becomes a means to initiate the live view transfer (and the conduit over which the data travels), other than that it shouldn't care what's going on.
The model is extensible to other data transfers (no idea what this might be) without changing the PTP protocol again.

Tonight I'll try a PTP only version of the previous patch for comparison.
I have a feeling that reyalp's right and the resulting code will be cleaner and easier to understand.

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

  • *****
  • 3332
    • Photos
Re: CHDK PTP interface
« Reply #583 on: 07 / September / 2011, 06:04:17 »
PTP based version for comparison / review.

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 mweerden

  • ***
  • 194
Re: CHDK PTP interface
« Reply #584 on: 07 / September / 2011, 10:57:49 »
Quote from: philmoz on 06 / September / 2011, 23:01:15
I think it makes sense to define the live view data transfer as a seperate protocol on top of PTP.
It's a complex transfer including metadata, isolating it away from the core PTP keeps things cleaner.
PTP becomes a means to initiate the live view transfer (and the conduit over which the data travels), other than that it shouldn't care what's going on.
The model is extensible to other data transfers (no idea what this might be) without changing the PTP protocol again.
Exactly. And because of this tools that do not user remove live view should never feel any consequences of changes to it.

In my eyes it is this approach that is actually less complicated and I really don't see how it makes things  less clearly defined. Except perhaps that at this moment remote live view isn't really defined other than in code. ;)

Quote from: reyalp on 06 / September / 2011, 22:31:42
Centralizing other things that a client would also want to poll also has real value. If getting the palette and frame buffer separately hurts frame rate, then polling script status and live view will do the same.
Now this is an actual argument for centralization. However, as I understand it the PC dealing with the image data is the main bottleneck at the moment. As mentioned a while back, I got a significantly higher fps by just dumping the image data in a file. I remember Phil having a similar result. So I wouldn't want to jump too quickly to this option.
Logged
*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: CHDK PTP interface
« Reply #585 on: 07 / September / 2011, 16:15:44 »
Quote from: mweerden on 07 / September / 2011, 10:57:49
Quote from: reyalp on 06 / September / 2011, 22:31:42
Centralizing other things that a client would also want to poll also has real value. If getting the palette and frame buffer separately hurts frame rate, then polling script status and live view will do the same.
Now this is an actual argument for centralization. However, as I understand it the PC dealing with the image data is the main bottleneck at the moment. As mentioned a while back, I got a significantly higher fps by just dumping the image data in a file. I remember Phil having a similar result. So I wouldn't want to jump too quickly to this option.

There's no polling required for live view - whatever data is required is sent in each call (unless I'm mis-understanding what you mean by polling here).
Although the client sample code doesn't currently use it, the CHDK code is set up so that it can return any or all of the viewport, bitmap & palette buffers in one call to the handler.

On the G12 I can transfer the viewport data 100 times in 6.4 seconds if I don't display it. When I was using PTP_CHDK_GetMemory I had to make two calls for each frame (one to get the current buffer address and then another to get the data).
This took 7.2 seconds to get 100 viewport images - so even just one extra PTP round trip makes a difference.

The sample .Net code can display the viewport at ~6fps so the conversion from YUV to RGB and subsequent display is a bottleneck.

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 ntstatic

  • ***
  • 246
Re: CHDK PTP interface
« Reply #586 on: 09 / September / 2011, 04:35:14 »
just my 2 cents... (not that they are worth too much ... at least in terms of CHDK as i have very shallow experience )

the function to provide the live preview should be a proper function and a part of PTP. it may not be realised immediately but live preview is an important part of PTP and that in itself would warrant its role in PTP. it may or may not be overloaded to provide other functions.

the polling ('per se') is not a problem and repeated calls to the PTP to get the live view are perfectly ok. the bottleneck at the client end - the conversion to RGB and the subsequent display - can be optimized by the end user any way.

having said that ... i have had a very stable connection with mweerdens' code and have kept the live view running while doing other operations - zoom, capture, changing properties etc - without any problems (SX 120 and SX 130). although not part of lua the function is the quickest workaround to getting the live view with minimum patching. and as long as it was not a proper part of the trunk, it is imho a most efficient implementation !!
Logged
*

Offline newmedia42

  • *
  • 8
Re: CHDK PTP interface
« Reply #587 on: 30 / September / 2011, 19:31:44 »
I have a quick question - I'm currently using the PTP interface, and apart from having a heck of a time figuring out what LUA side of things, the PTP side has been pretty painless.

One thing that is problematic for me is that the USB connection resets (or at least disconnects/reconnects) when you erase an image (ptp_deleteobject).  I seem to recall that this was needed in order to refresh the directory or something to that effect.  What I would like to know is if there is another way I could delete the file without causing this reset (maybe via os.remove)?  Is there anything that might be an issue with doing this?  Thanks, and great job on PTP - finally makes my cameras worth playing with!
Logged
SD1100IS / SD1200IS / SX130IS / SX30IS
*

Offline reyalp

  • ******
  • 13457
Re: CHDK PTP interface
« Reply #588 on: 30 / September / 2011, 23:20:13 »
Quote from: newmedia42 on 30 / September / 2011, 19:31:44
What I would like to know is if there is another way I could delete the file without causing this reset (maybe via os.remove)?
os.remove from lua should be fine. Note that some parts of the camera OS may not notice that it has been deleted, so for example if you are browsing images in playback mode or over a regular ptp file browser, you might see the names of images that aren't really there. This is the same as if you delete from the CHDK file browser.
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #589 on: 01 / October / 2011, 06:51:16 »
Quote from: newmedia42 on 30 / September / 2011, 19:31:44
the USB connection resets (or at least disconnects/reconnects) when you erase an image (ptp_deleteobject).

Strange, that works fine for me with A620 and SX130is.


David
Logged
Pages: 1 ... 54 55 56 57 58 [59] 60 61 62 63 64 ... 123   Go Up
« previous next »
 

Related Topics