chdkptp - alternative ptp client - page 7 - General Discussion and Assistance - CHDK Forum
supplierdeeply

chdkptp - alternative ptp client

  • 1106 Replies
  • 438199 Views
*

Offline msl

  • *****
  • 1277
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: alternative ptp client
« Reply #60 on: 26 / February / 2012, 14:48:28 »
Advertisements
I think you linked the wrong file, that says a620update100f.zip

Sorry, here is the right link: http://www.box.com/s/3ckge952o7big3cnm74c

msl
CHDK-DE:  CHDK-DE links

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: alternative ptp client
« Reply #61 on: 26 / February / 2012, 16:00:23 »
I've uploaded a new binary snapshot (r192) to the files area

Great progress reyalp!  :D

I tried this binary snapshot it on a570 100e and 64-bit Ubuntu 10.04, reyalp-ptp-live rev 1700.

Live view seems to work well.

In normal shooting modes, a few rows in the bottom are dynamic garbage but in normal video mode the live view fills the entire gui window with correct data. In stitch mode, just a small top left area is active, but looks good (with rest of the live view showing previous image). In other video modes only left side of screen is updated and aspect is incorrect. Overlay seems to work fine as well. I suppose Canon's menus are not even supposed to be shown (not that I care for them, really)?

When live view is enabled, camera is slow to respond to commands from the UI buttons (several seconds for commands to get through) unless target fps is reduced to 4 or lower. That 4.9 fps in the attached screenshots is about the maximum I get.

*

Offline reyalp

  • ******
  • 13745
Re: alternative ptp client
« Reply #62 on: 26 / February / 2012, 16:33:33 »
Thanks for testing and detailed report :)
In normal shooting modes, a few rows in the bottom are dynamic garbage but in normal video mode the live view fills the entire gui window with correct data. In stitch mode, just a small top left area is active, but looks good (with rest of the live view showing previous image). In other video modes only left side of screen is updated and aspect is incorrect.
Much of this is due to not having the added functions that get the real dimensions of the viewport. You can see some of these commented in the a540 code in my branch. You can probably find most of these in the old chdkcam code for your camera, although the function names have changed. However, if you use them for the regular frame buffer dimensions used elsewhere in chdk they may have side effects, which is why they are currently commented in my a540 code. In reality, we should use these for md, histogram etc, because otherwise these will be influenced by the garbage areas.

The video modes are odd on these older cameras, some changes in the framebuffer specs will be required to support this.

Quote
Overlay seems to work fine as well. I suppose Canon's menus are not even supposed to be shown (not that I care for them, really)?
If you have overlay enabled, it should show exactly what is on the camera screen. However, if you don't have vid_get_bitmap_active_buffer then you will sometimes see an old version of the bitmap.

The palette will only be correct if *vid_get_bitmap_active_palette() and related functions are implmented. However, the code currently falls back to using a hard coded version of the a540 palette, which is probably pretty close on your camera. Canon menus change the palette though, so they will be wrong.
Quote
When live view is enabled, camera is slow to respond to commands from the UI buttons (several seconds for commands to get through) unless target fps is reduced to 4 or lower. That 4.9 fps in the attached screenshots is
What sort of system is this on ? On my laptop (dual core athlon 64 @1.8ghz) it starts to have trouble around 10fps with a540. On linux I've found that it starts acting badly if the total time for the frame (frame ms + xfer ms) approaches the time required to make the target frame rate (1000/fps). I should probably make it start dropping frames when this happens. Actually the whole scheduling is pretty hokey...

D10 does significantly higher frame rates on my cam, because the xfer time is much lower. (20-3ms for a full frame vs 90ms on a540). Oddly, xfer times on my windows box are quite a bit lower with the a540. I also noticed that they are higher in rec mode vs. play. I assume this is because the camera CPU is busier, since the data is the same size.

There's room for improvement in the performance if the drawing part, I'm not going to worry too much about that until we have the functionality sorted out.
Don't forget what the H stands for.

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: alternative ptp client
« Reply #63 on: 26 / February / 2012, 16:56:26 »
If you have overlay enabled, it should show exactly what is on the camera screen. However, if you don't have vid_get_bitmap_active_buffer then you will sometimes see an old version of the bitmap.

Ah, I gave up on it too soon... I played around with the menu more and it did draw after navigating in the menu. Palette is incorrect (but readable) as expected. No vid_get_bitmap_active_buffer for a570 I believe.

Quote
What sort of system is this on ?
Intel E8400 (dual core 3 GHz) desktop, cam on USB 2.0 port without a hub. I used the Linux26g4_64 binaries from sourceforge for CD and IUP.


Re: alternative ptp client
« Reply #64 on: 26 / February / 2012, 17:00:23 »
Wrote a long reply here, but got logged out while testing.

Anwyay, tested this on my Ixus 100IS (SD780) and works perfectly.
Built and ran on windows using CHDKShell (though I couldn't get it to pickup revision 1700, am stuck on 1686).

- 30 FPS target averages at 21 FPS with no noticeable CPU/memory usage on my i7.
- The overlay colours are very strange: the grey gradients become rainbow coloured.
- The only big thing I found that doesn't work is that after shooting, the preview mode it goes into throws off the liveview. It starts "snowing" or goes black, and stays that way till the camera goes back to record mode.

If there's anymore info I can help with, let me know. There's something about a raw palette dump?
(you might want to start a seperate thread btw, the info about live view is kind of spread out across two threads)

My use case is a photobooth: the live view will save me lots of time/money getting hold of a ExtUSB plug for video and routing the video through a TV tuner into my PC. It would be cool if your client had some sort of "general use scripting" (respond to keystrokes, basic automation, etc). Best would ofcourse be some sort of API to build applications off of, but assume that's a ways of.

*

Offline reyalp

  • ******
  • 13745
Re: alternative ptp client
« Reply #65 on: 26 / February / 2012, 17:17:43 »
Intel E8400 (dual core 3 GHz) desktop, cam on USB 2.0 port without a hub. I used the Linux26g4_64 binaries from sourceforge for CD and IUP.
Well that certainly should be faster than my laptop. However, looking at your screenshots, "last xfer ms" is ~250, which is a lot. If xfer time is really 250 ms, then 4 fps is all you can get :/

Can you check the value of xfer ms when target frame rate is below the point where things start to slow down ?

Is there other software that might be trying to talk to the camera ? (desktop integration etc)

- The overlay colours are very strange: the grey gradients become rainbow coloured.
This is expected until the palette functions are implemented.
Quote
- The only big thing I found that doesn't work is that after shooting, the preview mode it goes into throws off the liveview. It starts "snowing" or goes black, and stays that way till the camera goes back to record mode.
If you mean this happens while shooting, I think this is expected. The "live" view buffer shares the same address space with the raw buffer on many (most ? all ?) cameras.

If it happens in recreview mode (e.g. if you set review time > 0, or hold the shutter down after shooting) then that might be fixable, but will require yet another live view address be found.

Quote
If there's anymore info I can help with, let me know. There's something about a raw palette dump?
Yes, but first the function to get the palette needs to be implemented for your camera. If I get time, I'll look into finding that for your camera.

Quote
Best would ofcourse be some sort of API to build applications off of, but assume that's a ways of.
In fact, the entire gui and most of the application logic is written in lua (using http://www.tecgraf.puc-rio.br/iup/ and http://www.tecgraf.puc-rio.br/cd/ ), so you can customize it to your hearts content, or roll your own gui from scratch. But you probably want to hold off on that until the code is modularized and documented a bit better. It is certainly my intention to make it easily customizable.

I plan to rework the gui a lot at some point, what's there now is mostly thrown together to test various things. Just need to quit my day job... :haha
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #66 on: 26 / February / 2012, 17:22:21 »
Yeah, saw it's all lua after I posted that.

Just tested it on my A560 and works well there too, as much as can be expected. The A560 doesn't have working PTP in record mode, it always stays in preview mode, but that's a seperate issue.

If it happens in recreview mode (e.g. if you set review time > 0, or hold the shutter down after shooting) then that might be fixable, but will require yet another live view address be found.
Yes, should have explained that better, but the screen goes black/snowy during the review time, and recovers afterwards.

*

Offline reyalp

  • ******
  • 13745
Re: alternative ptp client
« Reply #67 on: 27 / February / 2012, 00:55:40 »
Yes, should have explained that better, but the screen goes black/snowy during the review time, and recovers afterwards.
OK, that means there is yet another live view address that needs to be found. Possibly worth checking if the normal playback one works. I'll try to investigate this on my cameras later.

I've uploaded a new binary snapshot (r201). The main change is in how the display area is sized. It now uses the maximum buffer size, and displays the live view within that. In cropped / letterboxed views, the surrounding area will be white. This is wrong for video in cameras like the a540, where the actual viewport buffer gets bigger.

I've fixed some issues related to different display aspect ratios/letterboxing etc. Most should now see a comprehensible image, but the aspect ratio is likely to be wrong for many.

Another known issue: The ui is always cropped to fit inside the liveview, which is wrong for non-full screen displays.

I added a "quick dump" button, which makes a dump with just 5 frames. This should be sufficient for most diagnostics. There is also a cli command, dumpframes, which can be used to record the live view stream without using the gui at all.

Dump playback is changed such that the viewport and ui checkboxes will control whats drawn. Of course, if one of the buffers was not recorded, it won't be drawn no matter what. Playback doesn't work correctly if you are connected to a camera.
« Last Edit: 27 / February / 2012, 01:01:56 by reyalp »
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 13745
Re: alternative ptp client
« Reply #68 on: 27 / February / 2012, 01:01:26 »
I have create a SX220 liveview dump, maybe usefull for the analysis:
Do zebra and edge overlay work on this camera ?

Looking at the dump, the camera is claiming the viewport is an ordinary 720x240, but the data seems very wrong. There is image there, so it's not completely the wrong address, but it seems like the dimensions are off.
Don't forget what the H stands for.

*

Offline msl

  • *****
  • 1277
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: alternative ptp client
« Reply #69 on: 27 / February / 2012, 04:42:44 »
Do zebra and edge overlay work on this camera ?

Yes & no.

Zebra works.

Edge overlay don't work. The dimensions are ok (tested with 4:3 & 16:9), but is it more a solid color area. I can not detect some  contours, evt. some vertical stripes.

Tested with CHDK-DE, CHDK (release 1.0 branch) & live view branch, everywhere the same result.

Some time ago edge overlay works fine. Unfortunately I don't know which version. It is difficult to review all changes.

msl
CHDK-DE:  CHDK-DE links

 

Related Topics