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

CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC

  • 68 Replies
  • 17670 Views
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #20 on: 20 / August / 2012, 17:59:26 »
Advertisements
This dump is looking at a captured photo.  It is in the correct A/R, but I notice similar horizontal artifacting as in the live view, but as exaggerated.  Look at the black cable that is in-focus.  There it is easy to see.  It seems to that a horizontal band appears every couple dozen pixels. 

http://www.sendspace.com/file/ipfznw

*

Offline reyalp

  • ******
  • 13449
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #21 on: 20 / August / 2012, 21:40:44 »
Thanks. The dump is the raw data stream, it's not affected by any of the display options.
In other words, there is no need to take dumps with different settings checked!

I'll take a look at them when I get a chance...
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13449
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #22 on: 20 / August / 2012, 23:24:24 »
Here's a test CHDK build that gets the viewport dimensions for live view from firmware functions, rather than the hardcoded 360x240

If you can make one dump in record mode from this build, that would be helpful.

The incorrect height should also affect edge overlay, zebra, histogram and motion detection. The easiest to test is probably probably edge overlay, just enable edge overlay, and press half, and see if the edges line up. Zebra should also be pretty obvious, just aim at a high contrast subject and see if the zebra lines up with the over/under exposed areas, and whether it has garbage in it.
Don't forget what the H stands for.

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #23 on: 20 / August / 2012, 23:27:04 »
Yes I had read and did remember what you said the 1st time.  My rationale was more for the last dump vs the others.  The last dump I felt could help by providing you a visual reference from the LCD screen where it correctly fills the viewport in the right aspect ratio when A/R is checked, in the play mode. 

Following a similar rationale, I provided the others with UI checked so you could have the correct A/R of the UI screen versus the streaming video.

Does that make sense? .. or ... are all streams exactly the same whether I have UI checked or not, and/or whether I have play or record mode set?


*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #24 on: 20 / August / 2012, 23:36:51 »
Do I replace the on-camera files with the new ZIP files ?

*

Offline reyalp

  • ******
  • 13449
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #25 on: 20 / August / 2012, 23:58:39 »
Do I replace the on-camera files with the new ZIP files ?
Yes, the DISKBOOT.BIN, PS.FI2, and everything in CHDK/MODULES

You can upload using chdkptp

Quote
Does that make sense? .. or ... are all streams exactly the same whether I have UI checked or not, and/or whether I have play or record mode set?
The ui and viewport are both captured in the dump, and none of the aspect/size settings have any effect on the dumped data. Obviously if the camera does different things in different states (different sizes in play vs rec or different shooting modes) then the dump will only apply to whatever state the camera was in when the dump was made.
« Last Edit: 21 / August / 2012, 00:04:35 by reyalp »
Don't forget what the H stands for.

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #26 on: 21 / August / 2012, 00:14:31 »
New dump.  I had done it before you replied but now I know I can do it with chdkptp, that will be faster next time.

I see no A/R performance difference, nor do I see a clean image (the horizontal artifacts are still there) ... same as before. 

The only thing that's different is bottom part of the viewfinder in live mode ... that is gray now.

See image.

So not yet.


*

Offline reyalp

  • ******
  • 13449
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #27 on: 21 / August / 2012, 00:32:05 »
Are you sure you have the new version correctly installed ? If you have a multi-partition card (usually larger than 4gb), you need to get the diskboot.bin on the small boot partition.

You can check what build is running by putting
=return get_buildinfo()
in the chdkptp console. The output includes the build date.
Don't forget what the H stands for.


*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #28 on: 21 / August / 2012, 00:44:27 »
Yup, Aug 20, 2102, you must be on east coast.

In a nutshell ... Please refer to my last image.  By eyeball, the difference between camera LCD and LiveView is this: 

  a) The UI icon positions in the PTP viewport match the UI icon positions in the camera LCD, so that appears correct.

However ...

  b) The live viewfinder in PTP does not match the LCD.  In the LCD, the live viewfinder fills the entire screen, (which is the viewport in PTP), whereas, In PTP, the live view is *shrunk* inside the viewport.  That's the main difference.  The aspect ratio is 1.6666:1 instead of being 1.3333:1. 

  c) Unchecking A/R only makes it worse, because then the entire viewport shrinks vertically.

That is why I am giving you the UI for camera viewport reference.  Does this help?

*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: ptpCamGUI 2.0 versus Canon's RemoteCapture DC
« Reply #29 on: 21 / August / 2012, 00:56:06 »
I meant west coast // tired.  So to explain it hypothetically, looking at my last image here it is attached again, if you were able to grab the bottom edge of the live view with the mouse and keep the top edge pegged to the top of the viewport, pull the bottom edge of the live view stretching it so it touches the bottom edge of the viewport, then that would match the LCD. 

This does not you should solve the problem that way however ... it's just for more insight.

 

Related Topics