chdkptp - alternative ptp client - page 86 - General Discussion and Assistance

srsa_4c

4451

Re: alternative ptp client

« Reply #850 on: 12 / October / 2015, 13:07:35 »

Advertisements

Quote from: Ant on 12 / October / 2015, 12:45:01

Stencil buffer in RAM dump is 8bpp, but in chdkptp it is 16bit. Why?

CHDKPTP can only handle 2 kinds of buffers (plus the palette which we don't need) at the moment. The display data appearing on your attached picture does not seem to include the stencil data as both buffers are obviously 16 bpp.
I'd also recommend using the newer hexplorer release (sent you a link a few days ago) since that supports the new YUV variants found in DIGIC 6 cameras.

Logged

Ant

Re: alternative ptp client

« Reply #851 on: 12 / October / 2015, 13:52:15 »

Quote from: srsa_4c on 12 / October / 2015, 13:07:35

I'd also recommend using the newer hexplorer release

Ok, it is not stencil data (lower frame) , but now colours are the same as on camera display

ptp_new.png (347.4 kB, 1261x935 - viewed 427 times.)

Logged

Ant

Re: alternative ptp client

« Reply #852 on: 12 / October / 2015, 15:43:27 »

After replacement in live_view.c

Code: [Select]

        //data->send_data(data->handle,vid_get_bitmap_active_buffer(),bm_size,0,0,0,0);
        data->send_data(data->handle,vid_get_bitmap_active_stencil(),bm_size,0,0,0,0);

I got:

ptp-stencil.png (465.9 kB, 1078x656 - viewed 451 times.)

« Last Edit: 12 / October / 2015, 15:44:59 by Ant »

Logged

reyalp

13882

Re: alternative ptp client

« Reply #853 on: 12 / October / 2015, 16:31:04 »

Quote from: Ant on 12 / October / 2015, 15:43:27

After replacement in live_view.c

Have you modified the chdkptp code at all? It will need quite significant changes to handle this.

If you can upload a sample memory dump of a viewport, overlay and stencil, along with the dimension and format, I may be able to help (but not till the end of the week, at least)

To support this properly, I think we need:
* new lv_fb_type for stencil and the new YUV format(s)
* new TFR flag for "stencil" (I suspect this is an alpha channel, not it actually stencil?). If you only want the UI, you probably don't need it.
* add stencil buffer offset lv_fb_desc. I guess we could overload palette for this (new type, size is size of the buffer, fb_desc stuffed at the start) but this seems like it might be confusing. Would be OK for a quick hack testing though.

Quote from: srcs_4c

Perhaps we should consider lowering the frame rate for some of them (i.e. don't transfer the overlays every time).

Since the TFR flags are set on each lv update call, it would be pretty easy to make chdkptp only ask for the UI overlay every Nth frame.

Logged

Don't forget what the H stands for.

Ant

Re: alternative ptp client

« Reply #854 on: 12 / October / 2015, 17:15:24 »

Quote from: reyalp on 12 / October / 2015, 16:31:04

If you can upload a sample memory dump of a viewport, overlay and stencil, along with the dimension and format, I may be able to help (but not till the end of the week, at least)

Did you read all my previous messages?

I just want to get correct rendering of viewport and bitmap(not stencil) data provided at http://chdk.setepontos.com/index.php?topic=6231.msg125026#msg125026
as it shown here:

Quote

(I suspect this is an alpha channel, not it actually stencil?)

This is buffer, that now used for correctly drawing CHDK GUI.

Quote

To support this properly, I think we need:
* new lv_fb_type for stencil and the new YUV format(s)
* new TFR flag for "stencil" (I suspect this is an alpha channel, not it actually stencil?). If you only want the UI, you probably don't need it.

I don't need stencil. New viewport and bitmap buffer format (UYVY 16 bit) can be detected by palette size(0 or -1) or type ( 4 )

« Last Edit: 12 / October / 2015, 17:38:11 by Ant »

Logged

srsa_4c

4451

Re: alternative ptp client

« Reply #855 on: 12 / October / 2015, 18:11:30 »

Quote from: reyalp on 12 / October / 2015, 16:31:04

(I suspect this is an alpha channel, not it actually stencil?).

It is alpha channel or opacity. At the time I named this buffer, I thought the firmware was using OpenGL. As I found out later, the CPU core CHDK runs on doesn't have access to OpenGL, there is a separate CPU core (with its own firmware) for that.

Quote from: Ant on 12 / October / 2015, 17:15:24

I just want to get correct rendering of viewport and bitmap(not stencil) data

If this can't wait until next week, you'll have to start hacking the CHDKPTP source too.

Quote

I don't need stencil. New viewport and bitmap buffer format (UYVY 16 bit) can be detected by palette size(0 or -1) or type ( 4 )

It might be possible to skip rendering of overlay pixels if their value corresponds to the background color (0x80, 0x00, 0x80, 0x00 for two pixels on my cam). This won't be perfect as the Canon graphics have transparent parts.

Logged

reyalp

13882

Re: alternative ptp client

« Reply #856 on: 12 / October / 2015, 21:57:42 »

Quote from: Ant on 12 / October / 2015, 17:15:24

Did you read all my previous messages?

Yes, but maybe I missed something. An lvdump is a protocol dump, but since the protocol doesn't actually support your camera and you've made unspecified changes to the camera side (?), it's not clear what it contains.

Quote

I don't need stencil. New viewport and bitmap buffer format (UYVY 16 bit) can be detected by palette size(0 or -1) or type ( 4 )

That's fine, but my goal is not just make a one-off hack for your immediate need. It's clear that full support needs the alpha channel.

edit:
To be clear, I do appreciate you bringing thus up and working on it. Good stuff

« Last Edit: 12 / October / 2015, 22:16:13 by reyalp »

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: alternative ptp client

« Reply #857 on: 13 / October / 2015, 14:08:13 »

Quote from: srsa_4c on 12 / October / 2015, 18:11:30

It might be possible to skip rendering of overlay pixels if their value corresponds to the background color (0x80, 0x00, 0x80, 0x00 for two pixels on my cam). This won't be perfect as the Canon graphics have transparent parts.

Hack for both sides attached. Can't guarantee it will work for ports other than mine. Alpha channel is guessed, see quote above.