CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC - RAW Shooting and Processing - CHDK Forum

CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC

  • 68 Replies
  • 13386 Views
*

Offline SticK

  • *****
  • 779
CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« on: 19 / August / 2012, 00:24:44 »
Advertisements
SX110IS.  New to CHDKPTP.  Please comment.

) ptpCamGUI POWER ON SEQUENCE from cold start.  Some of this might be camera-specific, some of the long times might be normal operation because of much handshaking, and some might be CHDK processing times to handle scripts:
  ) Push power button
  ) Camera goes into play mode (going into RECORD MODE on camera is inhibited)
  ) Launch ptpCamGUI
  ) 20 seconds for camera to boot up and ptpCamGUI camera LED to go GREEN
  ) Not yet in RECORD mode
  ) To go into RECORD mode, have move ZOOM SLIDER, no other choice.  Using ZOOM +/- manipulates the current saved photo in play as it does manually on-camera.
     ) Wait 10 seconds for command to execute and wait for LED to go GREEN
     ) Reset ZOOM SLIDER to max aperture
     ) Wait another 5 seconds.
  ) Camera ready is to operate.

Total time 35 seconds before camera is ready to operate from cold start.

If the camera is not used and the viewfinder goes blank, pressing the green [PREFOCUS] button will turn it on again.

                                   ptpCamGUI        RemoteCapture
Remote camera ON         NO                        YES*
Remote camera OFF       YES                        YES

*Lauching RemoteCapture starts the camera, extends the lens, and puts it in record mode.  Response of camera is immediate from cold start as soon as RemoteCapute launches, all less than one second, and is ready to use as soon as the lens extends.

OPERATION  ptpCamGUI : 

  )  Have to watch ptpCamGUI LED to go GREEN before you issue next operation, otherwise there is risk of command confusion and camera shut down.

  ) The ZOOM+/- buttons take 3 seconds to react which includes feedback from CHDK to ptpCamGUI to set the ZOOM SLIDER in the corresponding lens zoom position.

  ) Tested CHDK features Tv 16s, 32s and 64s and all work OK.

  ) It takes about 5 seconds after pressing the [SHUTTER RELEASE] for image acquisition to start (snap a photo if a short exposure).

  ) CAVEAT?:  File handling.  Even under ptpCamGUI, CHDK behaves as though it were being used manually on-camera.  That is, files are stored on SD card.   To get the files, one has to open "DCIM Download."

  ) PROBLEM?: Occasionally, 1 of 5 times say, going to RECORD MODE from cold start by changing the ZOOM SLIDER, -or- changing the ZOOM SLIDER while in normal operation, usually by more than one position typically to the 0 position, will cause the camera to shut down, even if one respects the GREEN LED.  Camera-specific?

OPERATION RemoteCapture :

PROS

Power-ON is very fast.  Streaming viewfinder.  Viewfinder does not go blank after the preset 3 minute timeout, stays on permanently until press SLEEP/AWAKE viewfinder button.  Expected.  SLEEP/AWAKE viewfinder button is immediate.  Expected Shutter release is immediate.  Expected.   Zoom slider action is immediate.  Expected.  JPG file is transferred immediately to computer after exposure.  Expected.

CONS

RAW files are not possible, hence CHDK.  Extended CHDK exposure times are not possible.


Where remote operation with CHDK could use a boost
--------------------------------------------------------------------

  ) Streaming viewfinder on-computer.  This is essential for remote operation where the user has no access to the camera viewfinder.  Is there a way at present to get that functionality?   Can someone implement it if not?  What other choices are there to have the benefits of CHDK features and streaming viewfinder?

  ) Reaction time.  There are two areas: a) overall command processing speed, and b) ptpCamGUI appears to be polling the camera.  Can script command processing speed be increased?  Are asynchronous software events possible (ie camera to computer) to decrease reaction time?

  ) File handling.  As on RemoteCapture, it makes sense to transfer the file right after exposure, and have ptpCamGUI number the file for the disk save (or files if JPG and RAW are requested from CHDK), without using the SD card at all.  Is that possible to implement?



*

Offline reyalp

  • ******
  • 12444
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #1 on: 19 / August / 2012, 00:59:39 »
Just to be clear chdkptp and ptpcamgui are two different clients, both of which implement the CHDK PTP Extension.
Quote
If the camera is not used and the viewfinder goes blank, pressing the green [PREFOCUS] button will turn it on again.
You can disable this in the CHDK menu misc, "disable LCD off" = "always". One of these days I'll make an option for when USB is present...
Quote
  ) Streaming viewfinder on-computer.  This is essential for remote operation where the user has no access to the camera viewfinder.
chdkptp supports this.
Don't forget what the H stands for.

*

Offline msl

  • *****
  • 1267
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #2 on: 19 / August / 2012, 05:26:23 »
  ) To go into RECORD mode, have move ZOOM SLIDER, no other choice.

This is wrong. Use the button with the red camera icon. You have three options for this button.

- go into the record mode without shooting
- go into the record mode and take a photo
- go into the record mode and start motion detection

msl
CHDK-DE:  CHDK-DE links

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #3 on: 19 / August / 2012, 10:21:17 »
reyalp, that is an important clarification about the components, thank you.  Hence, since you are saying chdkptp supports streaming, what could I do to obtain both streaming and control the camera like I can with ptpCamGUI, to work together on my computer?  Basically, the idea is to approach RemoteCapture general operation (command reaction time is no too critical in my application, ie 3s to shoot is tolerable), but have the benefits of CHDK.  Is there a 3rd party app?  Is it something I'd need to code?  Some other ideas?

msl, thanks for the clarification.  When I first invoked ptpCamGUI, pushing [camera icon] was my first attempt at RECORD MODE.  It shut down the camera instead, and there were other little timing issues just understanding the app and getting it to work smoothly.  Because I accidentally found that operating the ZOOM SLIDER would set record mode, I did not try the camera icon again.  Perhaps the developer ptpCamGUI could consider a first-time popup that explains RECORD MODE and the LED in that respect.  The most important of these I found for me, is the LED.  Now I always wait until it's GREEN.  It may be possible that I am allowed to issue some commands rapidly and they queued correctly, but I have not tried that yet.  I find using the ZOOM SLIDER though, often shuts down the camera, even if the LED is GREEN.  Any ideas there? 


Note correction to original post: "min aperture" should read "min zoom."


*

Offline srsa_4c

  • ******
  • 4150
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #4 on: 19 / August / 2012, 10:48:47 »
... I find using the ZOOM SLIDER though, often shuts down the camera, even if the LED is GREEN.  Any ideas there?
Many CHDK ports suffer from a similar problem, see http://chdk.setepontos.com/index.php?topic=7071.0 (you can try to run some of the test scripts attached to that thread).

... you are saying chdkptp supports streaming, what could I do to obtain both streaming and control the camera like I can with ptpCamGUI, to work together on my computer?
Have you tried chdkptp?
« Last Edit: 19 / August / 2012, 10:54:49 by srsa_4c »

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #5 on: 19 / August / 2012, 12:11:12 »
Thank you for the zoom problem link.  No, I had not yet tried chdkptp.  I just downloaded it and booted.  Nice.  I will work with it for a day or two and look at it for performance, and may need some starter hand holding.

Right now I am using a USB 1.0 & a 1 GHz machine ... and even though FPS is set to 10, viewfinder update is about 2-3 fps.  With RemoteCapture on this same computer frame rate is full speed, ie smooth live.  Comments?

Please accept my apologies for mixing up the two clients in my post title.  If you have a way to remove "CHDKPTP:", please do so.

*

Offline srsa_4c

  • ******
  • 4150
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #6 on: 19 / August / 2012, 13:08:02 »
Right now I am using a USB 1.0 & a 1 GHz machine ... and even though FPS is set to 10, viewfinder update is about 2-3 fps.  With RemoteCapture on this same computer frame rate is full speed, ie smooth live.  Comments?
It's because the Canon remote liveview is a stream of highly compressed (M)JPEG frames (try to analyse a screenshot, the compression artifacts should be quite visible). The current CHDK implementation uses uncompressed frames.
Quote
Please accept my apologies for mixing up the two clients in my post title.  If you have a way to remove "CHDKPTP:", please do so.
You may be able to edit the first post of this thread (it's yours), including its title :)

*

Offline reyalp

  • ******
  • 12444
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #7 on: 19 / August / 2012, 14:22:06 »
Right now I am using a USB 1.0 & a 1 GHz machine ... and even though FPS is set to 10, viewfinder update is about 2-3 fps.
You will not be able to get more than a few FPS with USB 1, as msl says, we don't currently have a way to compress the frames before sending them.
Don't forget what the H stands for.


*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #8 on: 20 / August / 2012, 00:13:57 »
If I will have a smooth view (ie at least 10 fps) when I move this test setup to the USB 2 desktop computer, uncompressed is greatly preferred.  That's because in my photography application I am doing microscopy, and the higher the resolution and clearer view in the viewfinder the better. 

Let us start with CHDKPTP at the rock bottom.  I attach a difference image between CHDKPTP and RemoteCapture.  I cannot yet compare the two images as you have I suggested because of the horizontal artifact.  The images are in actual screen pixels so you can use a measurement tool.  Nonetheless, I've annotated the areas of interest.

Please comment ....

1) The RemoteCapture image measures 320x240, as expected. 

2)  The CHDKPTP image appears horizontally stretched, 360 pixels instead of 320.

3) The stretch causes horizontal pixelization artifacts to appear.

4) The image space seems oversized ie 360x270 instead of 320x240.  Is 360x270 the actual size of the SX110 LCD screen?

5) Note the 2nd artifact at the bottom of the viewfinder.  That is a remnant of an earlier shot photo of the same scene that was in the play mode.  Sometimes this area shows up as moving gray horizontal lines while live record mode, and sometimes an photo remnant, like in this example.

6) I tried playing with options and could not alter the aspect ratio right.

*

Offline reyalp

  • ******
  • 12444
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #9 on: 20 / August / 2012, 03:22:45 »
If I will have a smooth view (ie at least 10 fps) when I move this test setup to the USB 2 desktop computer, uncompressed is greatly preferred.
You should be able to get 10 fps on a USB 2.0 system with any sort of remotely recent CPU. Waterwingz reported getting over 10fps on raspberry pi.
Quote
2)  The CHDKPTP image appears horizontally stretched, 360 pixels instead of 320.
3) The stretch causes horizontal pixelization artifacts to appear.
The actual size of the viewport is a slightly complicated topic. The viewport is a YUV framebuffer, with 4 Y values for each UV pair. (See also http://chdk.wikia.com/wiki/Frame_buffers#Viewport).

If you take each Y value as a "pixel" (re-using the U and V as needed) then the viewport on typical cameras is 720 wide. Internally, CHDK often uses every other Y value, effectively making it 360 wide.

The height on typical cameras is 240 pixels, in standard shooting modes.

You'll notice that 360x240 does not match the screens aspect ratio if the pixels are square. So to display with the correct aspect ratio, you must scale something in one direction or the other.

The above applies to standard settings, there are a lot of exceptions
1) Shooting modes, like movie modes, stitch assist, letter box etc
2) Digital zoom. On many cameras, digital zoom decreases the number of lines, without changing the width. Sometimes the max zoom is also half width.
3) Playback vs record.
4) TV out connector connected or not.

Some cameras basic dimensions are different from 720x240.

How does all this relate to the chdkptp options ?
1) chdkptp keeps the width fixed, so each pixel exactly corresponds to either 1 or 2 Y values in the original framebuffer.
2) If "Viewfinder 1:1" is checked, then each Y value is used for a pixel (=720 wide). Unchecked, every other Y value is used (=360 wide).
3) If "Scale for A/R" is checked, then the image is stretched vertically to achieve the correct aspect ratio. If unchecked, then each row is used as is (=incorrect aspect ratio on typical PC displays)

Quote
4) The image space seems oversized ie 360x270 instead of 320x240.  Is 360x270 the actual size of the SX110 LCD screen?
As far as CHDK is concerned, the height on the sx110 is 240:
Code: [Select]
long vid_get_viewport_height()
{
    return 240;
}
This not be correct. The artifact in the bottom of your screenshot does look like what happens when the actual framebuffer has less rows than expected, for example when using digital zoom.

You can provide me useful information on what it's actually doing by using the "quick dump" button on the live view debug tab and uploading the resulting file somewhere.

The sx110 port does not currently implement the code that corrects for any of the nonstandard viewport modes. This mean that any mode/setting that doesn't use 720x240 will not display correctly. This can be corrected if you are willing to test.

Another artifact you may see is tearing. The CHDK live view is not synchronized with display refresh, so with moving subjects may appear to tear.
Don't forget what the H stands for.

 

Related Topics