CHDKPTP - PC Remote Control Performance Analysis - page 32 - RAW Shooting and Processing - CHDK Forum
« previous next »
Pages: 1 ... 27 28 29 30 31 [32] 33 34 35 36 37 ... 47   Go Down

CHDKPTP - PC Remote Control Performance Analysis

  • 465 Replies
  • 94561 Views
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #310 on: 29 / September / 2012, 21:44:59 »
Advertisements
Phase II compatibility testing on the instrumentation computer has begun

This is at 12.7 fps, the maximum I can get.

Q1. Horizontal tearing?

When the subject is still, the liveview image appears clean and continuous with no distortions.  However when the subject moves, here a pencil from side to side, the effect is splitting or tearing of the horizontal aspect.  The same effect happens if the subject is moved up and down, where a gap horizontal gap appears while in motion.  The gap can occur anywhere in vertical position.  Hence movement appears distorted.  Figure attached.

Q2. Delay?

There seems to be a delay from beginning of subject motion that is longer than 1 frame, perhaps 2 or 3 frames.  In other words, motion seems to be delayed by a few frames.  Is this true?  Any way to mitigate?

Neither of these occur on RemoteCapture, hence my inquiry.
Logged
*

Offline srsa_4c

  • ******
  • 4437
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #311 on: 29 / September / 2012, 22:48:37 »
Quote from: SticK on 29 / September / 2012, 21:44:59
This is at 12.7 fps, the maximum I can get.
Liveview updates at roughly 30 times a second in good lighting conditions. That's why you see
Quote
Horizontal tearing
Remember, the CHDK remote live view implementation works by transferring uncompressed image buffers.
As the transfer is not synchronized to the buffer updates, you can also experience more
Quote
Delay
too.
Quote
Neither of these occur on RemoteCapture, hence my inquiry.
Canon's remote live view implementation
- is tied to buffer updates (achieving this would be very complicated and a source for additional instability)
- transfers a small, highly compressed jpeg
Therefore it's capable of providing 30 fps even over USB 1.1.
There may be a solution for tearing, but it's unknown what happens when the camera liveview is halted and restarted continuously 10-20 times a second - the camera may not tolerate it.
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #312 on: 29 / September / 2012, 23:38:08 »
Changing lighting doesn't affect fps on the S90 // it stays the same dark or light.  This machine is USB 2.0.  On a USB 1.0 I get a max of 1 fps with S90, 3 fps with SX110.

More on motion delay.  I did a crude investigation .... the old S50 and SX110 have no noticeable motion delay with RemoteCapture.  However, since the S90 doesn't work with RemoteCapture, inspecting the camera LCD is enough to see that the delay is intrinsic to this camera even though the movement is smooth (faster fps on camera ??) ... exaggerated, waving a pencil in front of an S90 looks like a wet noodle on its LCD.  So I think the delay here is independent of tearing (synchronization?), and I suppose you'd agree.

Quote "Therefore it's capable of providing 30 fps even over USB 1.1"

Yes RemoteCapture is smooth that way, but its compression degrades the image noticeably compared to CHDKPTP // so therein is probably the tradeoff.  CPU (2-core 2.5 GHz) is only 8% with S90 CHDKPTP // lots of headroom.  Could my 13 fps limitation be tied to 640x480 transfer on the S90 ??

Quote "There may be a solution for tearing, but it's unknown what happens when the camera liveview is halted and restarted continuously 10-20 times a second - the camera may not tolerate it."

Would it be difficult to try out?

Logged
*

Offline reyalp

  • ******
  • 13625
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #313 on: 30 / September / 2012, 00:26:20 »
Quote from: SticK on 29 / September / 2012, 21:44:59
Phase II compatibility testing on the instrumentation computer has begun

This is at 12.7 fps, the maximum I can get.

Q1. Horizontal tearing?
http://chdk.setepontos.com/index.php?topic=8566.msg89561#msg89561
Quote from: me
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.
...
Quote
There seems to be a delay from beginning of subject motion that is longer than 1 frame, perhaps 2 or 3 frames.  In other words, motion seems to be delayed by a few frames.  Is this true?
Yes, vid_get_viewport_live_fb is not implemented for this port yet.
Quote
  Any way to mitigate?
Implement vid_get_viewport_live_fb
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #314 on: 30 / September / 2012, 00:28:15 »
S90.  Something useful to add to my last post ... now that I am testing different aspects of the new hardware on the instrumentation machine, I see that changing ISO and changing Tv *does* change the fps ... higher ISO or longer Tv, lower fps.  I have not tried Av but I think it would effect fps too.  In fact at say 4s Tv, the fps drops down to about 3-4 fps, by eyeball estimate.  Why eyeball?  Because the fps value in CHDKPTP does not change when this happens.  Hmmm // interesting // but expected I'd say: lower light needs a longer integration per frame.
Logged
*

Offline reyalp

  • ******
  • 13625
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #315 on: 30 / September / 2012, 00:33:35 »
Quote from: SticK on 29 / September / 2012, 23:38:08
Changing lighting doesn't affect fps on the S90 // it stays the same dark or light.  This machine is USB 2.0.  On a USB 1.0 I get a max of 1 fps with S90, 3 fps with SX110.
srsa is talking about the rate at which the video hardware updates, not how fast chdkptp transfers the data. This *probably* goes lower in low light.
Quote
Could my 13 fps limitation be tied to 640x480 transfer on the S90 ??
Look at the xfer last ms and frame last ms values.
xfer = 62 ms. That means the maximum possible frame rate would be 1000/62 = 16. But frame drawing doesn't happen in parallel, so you have to add the 15 frame time = 1000(77) = 12, which is what you observe. If you turn off the UI overlay, the xfer time should go down somewhat.
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #316 on: 30 / September / 2012, 00:39:42 »
Quote "Another artifact you may see is tearing. "

Oh yeah .. that's why it's familiar now // this is the first time I actually see it myself and I had forgotten.  Anyway you can refer folks who have a bad memory like me to my picture (save you a 1000 words next time -- my humble contribution).

Quote "Implement vid_get_viewport_live_fb"

Is it difficult?  Can you try it?
Logged
*

Offline reyalp

  • ******
  • 13625
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #317 on: 30 / September / 2012, 00:40:14 »
Quote from: SticK on 30 / September / 2012, 00:28:15
S90.  Something useful to add to my last post ... now that I am testing different aspects of the new hardware on the instrumentation machine, I see that changing ISO and changing Tv *does* change the fps ... higher ISO or longer Tv, lower fps.
If you are talking about the chdkptp frame rate, I suspect you are mistaken. It doesn't know anything about the underlying camera frame rate, it just transfers the data from the frame buffer when requested. That data may be from the same frame transferred previously, or may contain parts of multiple frames (tearing) or may not be valid at all (mode that uses a different buffer)

The chdkptp frame rate will vary somewhat depending how busy the camera firmware is.

Note that with a 62 ms transfer time, you will are very likely to get tearing, since this almost twice the hardwares normal update (33ms/frame) However, that does include the UI overlay, and the viewport is triple buffered, so it might be possible to get without tearing.
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #318 on: 30 / September / 2012, 01:00:17 »
Quote "If you are talking about the chdkptp frame rate, I suspect you are mistaken."

No, I said the CHDKPTP frame rate stays the same.  The camera "underlying" frame rate is what changes, but you see it in CHDKPTP, and, because CHDKPTP's own frame rate does not change, it's an "eyeball" estimate ... and it can go quite low.  I expect that is normal operation and I simply wanted to bring your attention to what happens.

Quote "UI overlay, and the viewport is triple buffered, so it might be possible to get without tearing."

If I turn off UI overlay, I still see tearing but it is not as severe.  UI OFF mode will be the normal usage mode once installed, so it is not too bad // not showstopper.

Nonetheless, can you try vid_get_viewport_live_fb for nice clean undistorted motion anyway?  I'll test it out here.
Logged
*

Offline reyalp

  • ******
  • 13625
Re: CHDKPTP - PC Remote Control Performance Analysis
« Reply #319 on: 30 / September / 2012, 01:14:54 »
Quote from: SticK on 30 / September / 2012, 01:00:17
Nonetheless, can you try vid_get_viewport_live_fb for nice clean undistorted motion anyway?  I'll test it out here.
I don't currently have time. (edit: probably through the next week at least)

Quote
because CHDKPTP's own frame rate does not change
Note that the FPS avg displayed in CHDK is currently a lifetime average (total time/total frames) since the live view was activated, so it's not very useful. You can reset it by toggling the live view on and off. The xfer last ms, xfer last kb/s and frame last ms are probably more useful. Note the frame last is the drawing time only, it doesn't include transfer.

Your transfer rate seems a bit low for a modern camera. On my D10 (older than S90), I get from 14 to 21 mb/s, your screenshot shows 11. It's very unlikely this is something chdk or chdkptp could change, but it might have to do with your USB setup. If there's other devices on the same USB controller, you might try moving them.

edit:
Quote
If I turn off UI overlay, I still see tearing but it is not as severe.
This shouldn't really have much effect, although the tearing may be slightly less obvious at higher frame rates. All I was trying to say is that the 62ms transfer time includes both the UI and viewport.

Without vid_get_viewport_live_fb, you are only effectively getting 10fps anyway, since the buffer it returns will only change for every 3rd canon frame. Implementing it won't prevent tearing, but it will probably make it less obvious.
« Last Edit: 30 / September / 2012, 01:31:56 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 ... 27 28 29 30 31 [32] 33 34 35 36 37 ... 47   Go Up
« previous next »
 

Related Topics