chdkptp - alternative ptp client

reyalp

ladiko
I used a A2500 for testing. Right now it takes up to 20 seconds to take 6 pictures. I know it depends on the settings, but this camera is just too slow. Processing seems to take ages. I look for a camera which can do faster continuous shots and / or "remoteshoot -quick". Which camera would you suggest?

The Canon specs should give you a reasonable idea of the speed differences between cameras. Keep in mind that some cameras have problems with remoteshoot in continuous: http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues

However, without more information about what you are doing, it's hard to say whether a faster camera will actually solve your problem. When you say "Processing seems to take ages" what specifically are you referring to?

jmac698

Hi,
Trying this program but it's only half working. win8.1 x64, connected cam with chdk already loaded in Play mode, used Zadig, installed libusb 1.26, ran chdkptp, clicked connect, pressing buttons causes the lcd to "blink" but doesn't execute button presses. The files section works and I can upload files. The live view doesn't work. Cam has chdk 1.3, sd1200.

Wanted to use this for faster script testing. Cam buttons don't work while connected.

ptpcam gui works fine, no live view though

ps pressed REC then click Viewfinder and it works.

The INSTALL.TXT is missing in the latest download, could you write up a simple step-by-step to get it working like I just did? ie get zadig, activate chdk with load firmware,plugin camera, options show all devices, select cannon digital camera, select libusb, click install, run chdkptp, click connect, click REC, click Liveview.

waterwingz

jmac698
Cam has chdk 1.3, sd1200.

It might be helpful to know what revision of CHDK 1.3.0 you have? You can get that from the Show Build Info menu item in the CHDK Miscellaneous menu.

jmac698

4272

reyalp

jmac698
Hi,
Trying this program but it's only half working. win8.1 x64, connected cam with chdk already loaded in Play mode, used Zadig, installed libusb 1.26, ran chdkptp, clicked connect, pressing buttons causes the lcd to "blink" but doesn't execute button presses. The files section works and I can upload files. The live view doesn't work. Cam has chdk 1.3, sd1200.

It is normal for the camera to ignore key presses when in playback mode with USB connected. On many cameras you can send
=post_levent_to_ui(4484)
in the console to unlock the keys in playback mode. I believe PTPCamGui does this automatically.

When you say the live view "doesn't work", what specifically does it do?

Do you have any images on the camera? Is there a video selected in the camera playback screen?

What does the physical screen on the camera show?

ps pressed REC then click Viewfinder and it works.

Do you mean the viewfinder works, or everything works, or...?

The INSTALL.TXT is missing in the latest download, could you write up a simple step-by-step to get it working like I just did? ie get zadig, activate chdk with load firmware,plugin camera, options show all devices, select cannon digital camera, select libusb, click install, run chdkptp, click connect, click REC, click Liveview.

I can't, because I have not set it up on windows later than Win 7. If someone else can provide clear instructions, I would be happy to included them.

The contents of INSTALL.TXT are approximately https://www.assembla.com/spaces/chdkptp/wiki/Install

Ant

reyalp

Can you add support for Digic6 cameras that have 16 bit/pixel overlays ?

reyalp

Ant
reyalp

Can you add support for Digic6 cameras that have 16 bit/pixel overlays ?

I don't see why not, but someone with one of the cameras will have to work on the camera side and at least provide sample data. This will likely require a live view protocol update. I suspect this is a CHDK 1.5 feature.

Ant

This is my sample data.
viewport: 736 * 480 * 16 bit/pixel
bitmap: 736 * 480 * 16 bit/pixel, but in camera RAM it is 8 bit.

I propose to add one more palette_type (#4 )

chdk_3299_20151012_183314.7z

990.28KB

srsa_4c

@Ant
Since you did not have to change the display routines, your cam very likely has the same kind of overlay buffers as mine.

The usable ones are:
- viewport: resolution may depend on output device (didn't check yet), there are buffers with at least 2 variants of YUV. One of them seems to be the same as the 16bpp variant found in earlier cams. Y411 (12bpp) format is not available.
- overlay: resolution depends on output device, 16bit YUV (UYVY, U and V component values are shifted by 0x80)
- overlay opacity (I called this "stencil" buffer): 8bpp, same resolution as the overlay buffer

Palette is not needed as all buffers are YUV, but a lot more data will have to be transferred for a "full experience" (2 YUV buffers + the opacity buffer). Perhaps we should consider lowering the frame rate for some of them (i.e. don't transfer the overlays every time).

Ant

I already did some changes in live_view.c and lib.c (screen buffer resolution and vp_size)
Stencil buffer in RAM dump is 8bpp, but in chdkptp it is 16bit. Why?

srsa_4c

Ant
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.

Ant

srsa_4c
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

Ant

After replacement in live_view.c

        //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:

reyalp

Ant
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.

srcs_4c wrote:
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.

Ant

reyalp
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 https://chdk.setepontos.com/d/6231/848
as it shown here:

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

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

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 )

srsa_4c

reyalp
(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.

Ant
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.

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.

reyalp

Ant
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.

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 😁

srsa_4c

srsa_4c
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.

remote_liveview_hack_for_d6.7Z

3.22KB

Ant

srsa_4c
Hack for both sides attached

Can you post windows32 binary?

srsa_4c

Ant
Can you post windows32 binary?

Sorry, can't currently do that. Try following the readme.

« Previous Page Next Page »