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

CHDK PTP interface

  • 1241 Replies
  • 493506 Views
*

Offline reyalp

  • ******
  • 14085
Re: CHDK PTP interface
« Reply #760 on: 10 / April / 2012, 00:12:35 »
Advertisements
hello everyone,
i have question about live view.
i am using SX 130 (also a few 120) with the live view.
if the camera is in manual mode, the live view does not reflect or resemble the final picture which will be taken. is it possible for the live view to approximate the final picture. eg if exposure is increased the live view becomming brighter (because the final picture will be brighter)

for the moment i am keeping the camera in Program mode - even when my PC software says Manual - only when the PC requires a shot i switch the camera to Manual, set the parameters, take the shot, download pic and switch the camera back to Program mode.

in Manual mode the Live View is often very dark(almost black)

am i doing it right or is there a better way

Assuming you are talking about CHDK live view over PTP, it should be the same as whatever the LCD display does.  If it's not, then it means Canon is doing something different with the display in different modes, and someone would need to figure out what that was.
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #761 on: 11 / April / 2012, 01:33:46 »
hello everyone,
i have question about live view.
i am using SX 130 (also a few 120) with the live view.
if the camera is in manual mode, the live view does not reflect or resemble the final picture which will be taken. is it possible for the live view to approximate the final picture. eg if exposure is increased the live view becomming brighter (because the final picture will be brighter)

for the moment i am keeping the camera in Program mode - even when my PC software says Manual - only when the PC requires a shot i switch the camera to Manual, set the parameters, take the shot, download pic and switch the camera back to Program mode.

in Manual mode the Live View is often very dark(almost black)

am i doing it right or is there a better way

Assuming you are talking about CHDK live view over PTP, it should be the same as whatever the LCD display does.  If it's not, then it means Canon is doing something different with the display in different modes, and someone would need to figure out what that was.

you are absolutely right reyalp. and the live view does reflect the lcd
what i was doing was that i was setting the TV, AV, ISO etc in the manual mode using the
                        ExecuteScript("set_tv96(" & mTVval & ")")
                        ExecuteScript("set_av96(" & mAVval & ")")
                        ExecuteScript("set_sv96(" & mISOval & ")")
this effectively gave me the intended effect in the final picture however it did not set the on screen setting for these values
i have added
                        ExecuteScript("set_tv96(" & mTVval & ")")
                        ExecuteScript("set_user_tv96(" & mTVval & ") press 'shoot_half'")
...
                        ExecuteScript("set_av96(" & mAVval & ")")
                        ExecuteScript("set_user_av96(" & mAVval & ") press 'shoot_half'")
...
                        ExecuteScript("set_sv96(" & mISOval & ")")
                        ExecuteScript("set_user_sv96(" & mISOval & ") press 'shoot_half'")

and now the LCD as well as the live view resembles the final picture taken (i think - i have not thoroughly tested it - but initial check look ok)

so it turns out it was nothing related to PTP but my (mis)understanding of the method in which the set_tv96 ... etc works.


Re: CHDK PTP interface
« Reply #762 on: 12 / April / 2012, 01:28:55 »
on the off note --
i have been using the libUSBWin32 1.2.3.0 and 1.2.5.0 with the live View and PTP code.
recently browsing the libUSB site i came across a libUsb installer called Zadig. Zadig has an option of replacing the stock drivers to libUSB or WinUSB or libUSBK

although i was not able to use libUSBK with the ptp code ( mostly provided by Mweerden on these pages ) the code worked flawlessly without any changes on the WinUSB drivers, so much so that i have a very strong feeling that it is more stable than libUSB. i have removed most of the delays in the VB.net code on the PC side and the thing looks stable enough. the same did not work with libUSB without the delays.

i would like to have any opinions if someone has tried this, or the view of the gurus of CHDK.

i hope this is not off topic for this thread as i feel it is closely related only with the PTP aspect of CHDK.

edit.
just remembered that ptpcam and therefore ptpcamgui does not work with WinUSB.

« Last Edit: 12 / April / 2012, 01:31:49 by ntstatic »

*

Offline reyalp

  • ******
  • 14085
Re: CHDK PTP interface
« Reply #763 on: 14 / April / 2012, 21:22:29 »
Some unfinished work in progress on the live view protocol, mostly for discussion on IRC
- gets rid of get_handler
- gets rid of lv_base_info / lv_vid_info distinction
- generic description for frame buffers

This doesn't currently implement the different aspect ratios on newer cams, which would theoretically go into visible_buffer_*offset

The old protocol is still there. The chdkptp patch won't talk correctly to previous builds, and lvdump record/playback isn't implemented


« Last Edit: 14 / April / 2012, 21:28:06 by reyalp »
Don't forget what the H stands for.


*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK PTP interface
« Reply #764 on: 14 / April / 2012, 23:20:49 »
Some unfinished work in progress on the live view protocol, mostly for discussion on IRC
- gets rid of get_handler
- gets rid of lv_base_info / lv_vid_info distinction
- generic description for frame buffers

This doesn't currently implement the different aspect ratios on newer cams, which would theoretically go into visible_buffer_*offset

The old protocol is still there. The chdkptp patch won't talk correctly to previous builds, and lvdump record/playback isn't implemented


To get this to work on the G12 and IXUS310 I had to make the following changes:

chdkptp/trunk/liveimg.c, line 221
   const char *p_row = p_yuv + (height + y_offset - 1) * row_inc + (x_offset*12)/8;

core/live_view.c,
line 143
    lv.vp.buffer_height = vid_get_viewport_max_height();
lines 152-153
    lv.vp.visible_buffer_xoffset = vid_get_viewport_xoffset_proper();
    lv.vp.visible_buffer_yoffset = vid_get_viewport_yoffset_proper();

The viewport display was in the wrong place and using the wrong data without these changes.

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

  • ******
  • 14085
Re: CHDK PTP interface
« Reply #765 on: 15 / April / 2012, 19:20:08 »
Thanks Phil.

The liveimg.c one actually applies to the chdkptp trunk as well. Fixed in chdkptp r235.

The offsets are trickier: Currently in a540 and d10, vid_get_viewport_*offset_proper describes an offset of the viewport in what I've "logical" screen, but not the buffer (e.g. stitch, where the image data is in the upper left of the buffer, but is displayed somewhere else on the screen). In your case, the offset is both.

For the Y offset, I'd like to send only the data that is actually valid (calculate viewport buffer + y offset in the chdk code, only send the portion that has valid data), meaning we could drop the buffer offset completely. The offset value would still have to go in the logical offset. The X buffer offset can't get the same treatment though, because extracting the partial lines from the buffer would be slow.

What I've called the "logical" screen is meant to represent the physical screen on the camera (I'm open to better names!) in "buffer dimensions" In other words, the logical height is how tall the buffer would be if it filled the whole screen. In the old implementation, this was essentially vid_get_viewport_max_height and vid_get_viewport_max_width, but they can actually change in various cases.

On cameras like the g12, it looks like the height of a full screen viewport is always 480, but on a540 it can be 528 (640x480 video mode) 240 (playback, most capture modes), or down to ~60 depending on digital zoom. On D10, max digital zoom is also drops to half width.

I'm still struggling to find a way represent this in a way that is convenient and doesn't require a ridiculous number of new lib.c functions.

I think putting everything in one call (no get_handler, no distinction between base_info and vid_info) is the right thing to do, but I'm not really satisfied with the current data structure and the functions that populate it.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK PTP interface
« Reply #766 on: 20 / April / 2012, 18:27:50 »
What I've called the "logical" screen is meant to represent the physical screen on the camera (I'm open to better names!) in "buffer dimensions" In other words, the logical height is how tall the buffer would be if it filled the whole screen. In the old implementation, this was essentially vid_get_viewport_max_height and vid_get_viewport_max_width, but they can actually change in various cases.

On cameras like the g12, it looks like the height of a full screen viewport is always 480, but on a540 it can be 528 (640x480 video mode) 240 (playback, most capture modes), or down to ~60 depending on digital zoom. On D10, max digital zoom is also drops to half width.

I'm still struggling to find a way represent this in a way that is convenient and doesn't require a ridiculous number of new lib.c functions.

I've been struggling with trying to come up with a good model for this all week - one thing I'm unclear on is how does the logical viewport size relate to the OSD bitmap screen size (and ultimately the live image view) when it gets displayed on the PC?

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

  • ******
  • 14085
Re: CHDK PTP interface
« Reply #767 on: 21 / April / 2012, 17:49:52 »
I've been struggling with trying to come up with a good model for this all week - one thing I'm unclear on is how does the logical viewport size relate to the OSD bitmap screen size (and ultimately the live image view) when it gets displayed on the PC?
We discussed this a bit in IRC, but I'll try to elaborate a bit.

The idea of the "logical size" is to tell the client how the valid viewport data (called "visible size" in my test code) relates to the physical screen on the camera. For example, if the viewport data has 120 lines, the client needs to know if this is a 120 line high window inside a 240 line high screen (like stitch), or a whether it is a full screen buffer (like digital zoom, or low res video)

This information was missing from the old information, which effectively assumed vid_get_viewport_max_height was always the full screen height, which is generally true on cameras like the g12, but not true everywhere.

The "logical size" is given in units of buffer pixels, because these are easily available, and convenient for calculation with other offsets etc. The "logical size" that represents a full screen camera display is not fixed. Full screen is indicated by logical size == visible size.

I've been thinking it might be clearer to define the "logical size" in terms of margins, so "logical height" equals top margin + visible height + bottom margin. The top/ left already exist as offsets, and most cases are symmetric.

The offsets are complicated by the fact that there are offsets within the buffer (e.g. 16:9 on G12) and offsets of the buffer data on the screen (e.g stitch, g1x).

The Y offset within the buffer can (and IMO should) go away, so the appropriate offset from the real buffer is calculated on the camera, and only the useful data is sent. But as mentioned earlier, we really can't do this with the X offset.

The final rendering is up to the client. Given the physical aspect ratio of the camera screen, the client can display any size window it wants. The "logical size", "visible size" and offsets tell it how to display the data relative to the window. The current chdkptp code (if correct aspect ratio is selected) fixes width at 1:1 or 1:2 viewport pixels and then scales height for aspect ratio, but this is just because it was convenient to write that way. Clients that want aspect ratio correct display will generally have to do arbitrary non-integer scaling anyway.

Re the bitmap:
As far as we know, the bitmap is always full screen, but the resolution doesn't have a fixed relationship to viewport. (e.g on a540 the visible bitmap data is always 352x240, but the viewport might be 704x240, 704x528, 352x240, 704x60....)

My current test code uses the same lv_framebuffer_desc structure as the viewport, but this is probably overkill.

The "logical sizes" given in the in the viewport and bitmap descriptions are each in their own units (buffer pixels of that buffer), but can be used to display correctly because be the logical size tells you how much of the camera screen each one covers.

Considerations for existing on camera viewport/bitmap code:
Unfortunately, the existing CHDK code isn't aware of a lot of these variations. For example, on cameras where digital zoom varies the size of the buffer, zebra, histogram and md will all be wrong when it is used.

On cameras like a540, the viewport and bitmap are assumed to be 360x240, (using every other Y value in the viewport) but in fact only 352x240 have valid data, which means the histogram will have some junk in it, and md might be spuriously triggered. MD also won't work correctly in video modes on these cameras.

There's is also quite a bit of cruft due to adapting newer cameras with different resolutions to CHDK units.

It would be nice to use the correct dimensions everywhere, but I'd rather leave that as a project for another day. If we get all the values for live view, that will give us a step in the right direction. The downside is we will get more function that return similar but not exactly equivalent values.

Ugh, that was long :(
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #768 on: 21 / April / 2012, 18:22:13 »
@reyalp
Sorry for this off-topic, but you always seem to mention that the A540's viewport resolution is 704 pixels wide inside the 720px wide buffer. The cameras I've seen change their viewport width from 720px to 704 when they sense that TV-out is in use (this happens on-the-fly). Do you have something plugged into that camera?  :)

*

Offline reyalp

  • ******
  • 14085
Re: CHDK PTP interface
« Reply #769 on: 21 / April / 2012, 18:36:49 »
@reyalp
Sorry for this off-topic, but you always seem to mention that the A540's viewport resolution is 704 pixels wide inside the 720px wide buffer. The cameras I've seen change their viewport width from 720px to 704 when they sense that TV-out is in use (this happens on-the-fly). Do you have something plugged into that camera?  :)
That's useful info, I wondered if TV out would change it. Would also be worth checking modern cameras that have HDMI too. Maybe we don't have to worry about the ones with combined USB/video (can you make a splitter ?)

I don't have anything plugged in. The screen would turn off, so it can't be a stuck switch either.

It turns out that plugging in the TV out does change the height though (probably to 528), and worse, doesn't change the value I've been using to get the actual viewport height.

edit:
Ooops, change in viewport height is in playback mode, which I have hard coded because that value never works in playback. In rec mode, it seems to be normal with TV out connected.
« Last Edit: 21 / April / 2012, 18:43:27 by reyalp »
Don't forget what the H stands for.

 

Related Topics