chdkptp - alternative ptp client - page 90 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 ... 85 86 87 88 89 [90] 91 92 93 94 95 ... 111   Go Down

chdkptp - alternative ptp client

  • 1106 Replies
  • 479462 Views
*

Offline 62ndidiot

  • *****
  • 596
Re: alternative ptp client
« Reply #890 on: 27 / August / 2016, 17:33:50 »
Advertisements
As far as integrating the "opacity" buffers into chdkptp, is the favored approach to do the integration on the camera, or in chdkptp? I'm assuming it would be good to maintain backwards compatibility in chdkptp but that might not be so easy. Also, I think there are two opacity buffers: does that mean we need to determine which one is live?
Logged
*

Offline reyalp

  • ******
  • 14037
Re: alternative ptp client
« Reply #891 on: 27 / August / 2016, 18:13:02 »
Quote from: 62ndidiot on 27 / August / 2016, 17:33:50
As far as integrating the "opacity" buffers into chdkptp, is the favored approach to do the integration on the camera, or in chdkptp?
Definitely in chdkptp, doing it on camera would use a large amount of memory and be very slow, unless we figure out how to control the GPU. USB transfers are much slower if you do a lot of calls with small amounts of data, using a small buffer to combine is not a viable option.

There are also the 640x480 RGBA buffers srsa identified, but at the moment they don't contain CHDK output and it's not really clear how they work.

Quote
Also, I think there are two opacity buffers: does that mean we need to determine which one is live?
The current drawing code uses active_bitmap_buffer as an index into opacity_buffer (without the &1 vid_get_active_bitmap_buffer uses :-[). This appears to work. We should probably add a vid_get_active_opacity_buffer function.

Quote
I'm assuming it would be good to maintain backwards compatibility in chdkptp but that might not be so easy.
The live view protocol works by the client polling the camera each time it wants a frame. Each request includes a bitmask of which things it wants  (see core/ptp.h PTP_CHDK_GetDisplayData). My plan is to add another bit for the opacity buffer, along with another lv_fb_type value and lv_framebuffer_desc and offset in the lv_data_header. (see core/live_view.h)

Clients that are unware of the new buffer won't request it, and properly implemented clients should ignore any extra values in the lv_data_header.

Since the opacity buffer is a large amount of data, and isn't needed if you only want the UI display, it should be optional with fallback to the current method.

We also need to define what appears in the palette information.

One downside to the current protocol is that there is really no way for clients to know what to expect (i.e. whether a camera uses paletted live view or YUV+alpha). They can just request everything and decide what to draw based on the response, but this may get awkward as more things are added.

Another minor protocol change needed for g7x is adding 3:2 aspect ratio.

edit:
FWIW, I'm planning to do some work on this over the weekend.
« Last Edit: 27 / August / 2016, 18:37:41 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 509
Re: alternative ptp client
« Reply #892 on: 28 / August / 2016, 05:28:33 »
Quote from: reyalp on 27 / August / 2016, 18:13:02
Another minor protocol change needed for g7x is adding 3:2 aspect ratio.
I think, aspect ratio should be defined by UI overlay.
Please, make checkbox "Scale for A/R" unchecked by default.
Your special build already works fine with various aspect ratios:
« Last Edit: 28 / August / 2016, 05:44:12 by Ant »
Logged
*

Offline reyalp

  • ******
  • 14037
Re: alternative ptp client
« Reply #893 on: 28 / August / 2016, 15:57:01 »
Quote from: Ant on 28 / August / 2016, 05:28:33
I think, aspect ratio should be defined by UI overlay.
Please, make checkbox "Scale for A/R" unchecked by default.
Your special build already works fine with various aspect ratios:
No it doesn't. It's just looks about right on your camera because it has nearly square pixels.

"Scale for AR" produces incorrect results with the hack because it assumes 4:3.

There are several ratios involved:
1) The *physical* aspect ratio of the screen
2) The pixel aspect ratio. Many CHDK cameras have pixels that are very far from square.
3) The aspect ratio setting. This affects where the image appears with in the physical screen.

I understand your desire to have something that works checked in quickly, but I have to think about >100 other cameras, and maintaining the code in the future.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14037
Re: alternative ptp client
« Reply #894 on: 04 / September / 2016, 22:06:50 »
Attached are preliminary patches for full d6 protocol support, including opacity buffer. A windows client build is also attached. I will probably check this in soon, but posting it here for comments and to allow others to update their ports.

This introduces a new minor live view protocol revision (2.2) Arguably, this should be a "major" version, not backward compatible, but old clients should work fine for non-digic 6 cameras, and fail relatively gracefully for digic 6. The updated chdkptp code supports both 2.1 and 2.2.

The G7X port is fully updated. I made my best guess at the required changes for sx280. I haven't attempted to update the sx60 port since I think the svn source is quite a bit behind 62ndidiots.

Things that need attention in digic 6 ports
- The _proper functions for digic 6 should not be 2x the normal values. See g7x examples.
- palette type and size should be 0. This is the default in generic wrappers, so they do not need to be defined.
- vid_get_opacity_active_buffer must be implemented. See g7x
- vid_get_viewport_type must be implemented. Include the live_view.h for constants. Ports like the g7x only need to return LV_FB_YUV8B. The current sx280 code probably needs to return different values for play and rec.
- for playback image display vid_get_viewport_fb_d should be implemented and, dimension functions (*get_viewport_width etc) should return a non-zero value in playback mode
- for full support of different shooting aspect ratios etc, the various vid_*offset functions must be implemented. G7X has a fairly complete implementation, but specifics will vary by camera.
- I have not tested behavior with TV or HDMI out.

General chdkptp notes
- I added a checkbox to skip the d6 opacity buffer. Since all the protocol data is sent in every frame, this is available whether it makes sense for the camera or not.
- lvdump, lvdumpimg and screenshots should work. lvdumps should be compatible to the same extent real live view is.
- I made a zero image size (which can happen if the viewport sizes aren't correctly implemented) treated the same as no data returned (e.g. if viewport address is null)
- chdkptp live code now checks the live protocol version, which it did not before.

Other CHDK notes
- Pulling the live view headers into  lib.c / wrappers.c is not really clean, but using the same constants makes sense.
- The opacity buffer description is sent regardless of whether the camera has one or whether opacity data was requested. It's only ~36 bytes, not significant compared to any of the frame buffers. The type is set to LV_FB_OPACITY8 regardless, because we don't have a "none" type. Possibly, it would make more sense not to send the description at all on cameras that don't support it (e.g. lv->bmo_desc_start = 0). The rational for sending the description for buffers that don't have data selected is that it allows clients to determine what kinds of buffers are present.
- The use of THUMB_FW to decide various things in live_view.c probably isn't great, we should probably have defines and/or functions for the specific characteristics. I added a function for the viewport type, since on SX280 it varies between modes.
- I did not define a wrappers.c default vid_get_opacity_active_buffer. d6 ports must implement it. Others should not.
- I defined the wrappers.c default vid_get_viewport_type for pre-d6 only, since all those cameras to date use the same format.
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 509
Re: alternative ptp client
« Reply #895 on: 05 / September / 2016, 11:51:10 »
Tested on EOS M3 - fine!

But when I turn on camera with connected USB cable I get an error:
Code: [Select]
e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:527: width  > buffer_width
stack traceback:
[C]: in function 'get_viewport_pimg'
e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:527: in function <e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:516>
(...tail calls...)
[C]: in function 'MainLoop'
e:\Foto\EOS M3\ptpCHDK\lua\gui.lua:758: in function <e:\Foto\EOS M3\ptpCHDK\lua\gui.lua:731>
(...tail calls...)
e:\Foto\EOS M3\ptpCHDK\lua\main.lua:286: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunkFor normal work I need to switch camera to Rec mode from PC.
This problem was present in previous builds too...
« Last Edit: 05 / September / 2016, 11:55:54 by Ant »
Logged
*

Offline 62ndidiot

  • *****
  • 596
Re: alternative ptp client
« Reply #896 on: 05 / September / 2016, 12:05:34 »
It will be a few days before I can test SX60, but I don't foresee any problems.
Logged
*

Offline reyalp

  • ******
  • 14037
Re: alternative ptp client
« Reply #897 on: 05 / September / 2016, 13:37:36 »
Quote from: Ant on 05 / September / 2016, 11:51:10
Tested on EOS M3 - fine!

But when I turn on camera with connected USB cable I get an error:
Code: [Select]
e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:527: width  > buffer_width
stack traceback:
[C]: in function 'get_viewport_pimg'
e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:527: in function <e:\Foto\EOS M3\ptpCHDK\lua\gui_live.lua:516>
(...tail calls...)
[C]: in function 'MainLoop'
e:\Foto\EOS M3\ptpCHDK\lua\gui.lua:758: in function <e:\Foto\EOS M3\ptpCHDK\lua\gui.lua:731>
(...tail calls...)
e:\Foto\EOS M3\ptpCHDK\lua\main.lua:286: in main chunk
[C]: in function 'require'
[string "require('main')"]:1: in main chunkFor normal work I need to switch camera to Rec mode from PC.
This problem was present in previous builds too...
Your port is sending incorrect dimensions for the viewport buffer. Probably you need to have a check for playback mode.

If you enter
Code: [Select]
set gui_verbose=2
in the chdkptp console before connecting, you should see all the dimensions sent in the live view frame.

Looking at your svn, I see some direct variable references like
Code: [Select]
int vid_get_viewport_buffer_width_proper() { return (*(int*)(0x00053CBC) ); }
These variables might not be initialized in playback.

Also, fwiw platform/<cam>/lib.c should not reference variables directly, because addresses are likely to vary between firmware versions. You can define the variable in stubs_min.S or implement the function in sub/<fw>/lib.c
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 509
Re: alternative ptp client
« Reply #898 on: 05 / September / 2016, 15:26:48 »
Quote from: reyalp on 05 / September / 2016, 13:37:36
Code: [Select]
int vid_get_viewport_buffer_width_proper() { return (*(int*)(0x00053CBC) ); }
These variables might not be initialized in playback.
You was right. Now I had replaced it by camera_screen.buffer_width

Can you add button "CR2 Remote Shoot" ?
Logged
*

Offline reyalp

  • ******
  • 14037
Re: alternative ptp client
« Reply #899 on: 06 / September / 2016, 02:03:02 »
I've checked in the changes from the previous posts, chdk r4680, chdkptp r712.  In r4681 I checked in minimal changes to sx60 to allow to compile, but I didn't attempt to fix any of the other stuff.

I'll post updated builds for all the chdkptp platforms in the next few days.
Logged
Don't forget what the H stands for.
Pages: 1 ... 85 86 87 88 89 [90] 91 92 93 94 95 ... 111   Go Up
« previous next »
 

Related Topics