CHDK PTP interface - page 76 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 71 72 73 74 75 [76] 77 78 79 80 81 ... 125   Go Down

CHDK PTP interface

  • 1244 Replies
  • 532865 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: CHDK PTP interface
« Reply #750 on: 15 / March / 2012, 15:04:40 »
Advertisements
Quote from: asmodyne on 15 / March / 2012, 12:44:23
Quote from: philmoz on 14 / March / 2012, 15:42:27
Even if you could transfer the the raw sensor data you would be lucky to get 1 frame every 5 seconds over USB.
Phil.
Eeeyup, but as I said somewhere in this thread, using shaders here isn't about framerate, it's for quick image data preparation, for futher use : One would appreciate from the client library to provide quick convolution filters on large stills. And GPU shaders are the faster way to achieve it nowadays.
That's why I plan on using GLSL for this: Shaders-processed filters for big stills. Using it to decode Bayer mosaic frames or translate YUV to RGB bitmaps is just gravy. But I love gravy.  :P
By the way, since OpenGL is already usable to present the live view frames in CHDKPTP, having some minds to dig into the GLSL option isn't such a bad idea.

Your use of terminology is confusing, specifically 'live view'.

When we talk about live view we are referring to the ability to show the same image that is displayed on the cameras LCD - when the camera is not taking a photo.

AFAIK the sensor raw data is not available at this time. I believe the viewport YUV image is generated using a special read-out mode of the sensor.

The raw sensor data is only available to CHDK immediately after a photo is taken and before the camera saves the JPEG image. The raw data is corrupted during the JPEG image generation.

If I understand correctly, what you're talking about is downloading the saved RAW file from the SD card, after taking a photo, and being able to display it immediately on your PC.
If this is the case why not use the JPEG image - and avoid the demosaicing and all the other processing required to handle a raw image (it will also transfer a lot faster)?

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #751 on: 15 / March / 2012, 16:11:09 »
Aaawww, please, don't make me explain everything again.  :'(

I know pretty well what the words "live view" or "liveview" (whatever) refers to, since I've been studying reyalp's DE trunk for about a month now.
My point is, adding GLSL handling in the PTP/CHDK extension .Net library I'm implementing may be useful in any stage/phase/step of the data acquisition since :
  • I intend to make it an Open Source Managed dll, for anyone to use easily in his/her own .Net/Mono application.
  • The dll users (i.e programmers) may use it to communicate with CHDK devices in any way they want. It's up to them to freeze the ARM before the JPEG encoding in order to grab the sensor's raw data copy, or the final JPEG buffer, or the stored JPEG object, or the OSD and/or the viewport's buffer as Reyalp do with the "live view",
  • This dll is made to manipulate BITMAP BUFFERS (whatever the color space is, it's up the programmer to know what he have to decode). Since those BITMAP BUFFERS may (and surely will) have tremendous sizes, delegating their processing to the GPU is not a luxury nowadays. Hence embedding GLSL capabilities into my managed dll project.

Can we move on now ? Please ? :(

Addendum : for my OWN use, which isn't relevant i.m.o, but since you all seem to wonder about it : stored JPEG file are more than sufficient:  they're precompressed, thus quickly transferred, and already corrected against known lenses aberrations. But MY personal usage of isn't relevant in this case.
« Last Edit: 15 / March / 2012, 16:17:54 by asmodyne »
Logged
*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #752 on: 15 / March / 2012, 16:14:42 »
Quote from: asmodyne on 15 / March / 2012, 13:00:17
I know this will sound dumb (well, I am !), but I'm wondering... what's actually changing ?  :blink:
The palette changes. Note that this applies to the bitmap (ui overlay) which is separate from the viewfinder live view.

The viewfinder changes size, buffer size and effective pixel aspect ratio on different cameras for various reasons. Some include
1) play / rec mode
2) video recording mode (may be different from still, and different video modes may be different)
3) digital zoom
4) camera aspect ratio setting
5) stitch mode

I'm not aware of any situations where the bitmap changes size at run time, but I wouldn't rule out the possibility yet.
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #753 on: 15 / March / 2012, 16:48:58 »
Yes, I understood that the palette was only applicable to the UI's overlay.

Okay, so, the good news are : device as old as the A430 HAVE (yay !) all the events implemented to declare the status changes than can/may alter the frame properties :

Here, have a look :

*for DevicePropChanged, that is.

I'll bet my right hand on the fact that Canon had those implemented on every devices they release, at least since the A430.
Thus :
  • if play/rec mode changes -> DeviceInfoChanged or DevicePropChanged will certainly rise.
  • video recording mode -> this may prove difficult if there is special tricks to it. Sending it over PTP may affect the movie encoding process on device relying on their Digic to do the USB handling.
  • Digital zoom -> nasty thing... But I'm pretty confident the zoom value is one the the vendor-specific property, so DevicePropChanged should appear.
  • Camera aspect ratio setting -> same as #3.
  • stitch mode ? You mean panoramas ? Aren't those supposed to be handled as associated objects in the PTP specifications ?

Also, ALL, and I mean ALL of the device props the A430 exposes in its PTP DeviceInfo dataset are Vendor-specific (i.e the property codes MSBs all equals 0xD0.)
Buuut HURRRAAAAAY : the GetDevicePropDesc command is reported as IMPLEMENTED, so we may be able to find out what those proprietary values are.

Logged
*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #754 on: 15 / March / 2012, 16:50:54 »
Quote from: asmodyne on 15 / March / 2012, 16:11:09
I know pretty well what the words "live view" or "liveview" (whatever) refers to,
This is not at all apparent from you posts. If you understood our usage of live view, you would know bayer is completely irrelevant to it.

This isn't just pedantry for the sake of it. My reaction to your post was the same as phils, I genuinely have difficulty understanding what you are talking about and how it relates to the stuff I'm working on.
Quote
since I've been studying reyalp's DE trunk for about a month now.
"reyalps DE trunk" ? I honestly don't understand what you are referring to. There are two svns relevant to my live view work:
1) The camera side code is in a branch of the chdk code (not CHDKDE, which is a separate repository): http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live
2) The client code is in the chdkptp trunk: http://trac.assembla.com/chdkptp/browser/trunk
Quote
This dll is made to manipulate BITMAP BUFFERS (whatever the color space is, it's up the programmer to know what he have to decode).
In CHDK "bitmap" refers specifically to the paletted UI overlay portion of the camera display.
viewport refers specifically to the UYVYYY display used for "live" images and displaying images stored on the camera.
Raw refers to the bayer, 10 or 12 bpp packed buffer for raw images, which is only available in certain shooting modes and at certain points in the shooting process.

http://chdk.wikia.com/wiki/Frame_buffers is the canonical reference.

"Live view" in chdkptp refers the (near) real-time replication of the camera display (the viewport, the bitmap or both) over PTP to a PC.

chdkptp (all one word) refers specifically to the client tool I wrote based on ptpcam. CHDK PTP protocol, PTP Extension refer to the protocol.

If you want to have a coherent discussion with us about these topics, you would be well served by using the same terminology we use. If you have ideas for other functions (for example, transferring raw data over PTP before it is written) then I suggest you use distinct terminology for that.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #755 on: 15 / March / 2012, 17:07:24 »
Quote from: asmodyne on 15 / March / 2012, 16:48:58
Okay, so, the good news are : device as old as the A430 HAVE (yay !) all the events implemented to declare the status changes than can/may alter the frame properties I'll bet my right hand on the fact that Canon had those implemented on every devices they release, at least since the A430.
Thus :
You appear to be deeply confused. I would strongly suggest making an effort to understand how the existing system works.
Quote
if play/rec mode changes -> DeviceInfoChanged or DevicePropChanged will certainly rise.
Since many of the cameras do not support remote shooting in the canon firmware, there is no reason to expect them to send events when shooting related properties change, and even if they do, I would bet they don't send the information we'd need to correctly interpret the viewport data. We don't need to know the camera changed from play to rec (we already have that information), we need to know how the viewport dimensions changed. Since this behavior varies by camera model, just knowing the mode changed is not useful.
Quote
video recording mode -> this may prove difficult if there is special tricks to it. Sending it over PTP may affect the movie encoding process on device relying on their Digic to do the USB handling.
Again, I was talking *specifically* about the behavior of the viewport when the camera is  in movie mode. Example: on a540, which you switch to 640x480 video mode, the viewport buffer becomes 704x528 (vs the normal 704x240).

This has *nothing* to do with intercepting movie recording. It applies when you are in video mode, regardless of whether you are recording or not.
Quote
Digital zoom -> nasty thing... But I'm pretty confident the zoom value is one the the vendor-specific property, so DevicePropChanged should appear.
Even if it does, this won't tell us how many lines the current viewport buffer has.
Quote
Camera aspect ratio setting -> same as #3.
As above.
Quote
stitch mode ? You mean panoramas ? Aren't those supposed to be handled as associated objects in the PTP specifications ?
Again, all I'm talking about is the behavior of the camera viewport buffer. When the camera is in stitch mode, the viewport buffer becomes smaller. This has absolutely nothing to do with anything in the PTP specification.
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #756 on: 15 / March / 2012, 17:30:46 »
What I meant by "bitmap" is exactly what its stands for : an array of values containing pixel data. I'm not referring to any specific buffer, I was just stating that most of bitmap manipulation handled by the PC's cpu can be implemented in GLSL and passed to the GPU, wherever the data came from.

About the events : of course they're not supposed to give you actual informations about the viewport, since you hacked your way to its buffer, but you can expect actual changes on the viewport buffer when a property change is reported by the device.

I used USBTrace to monitor the A430's activity, a camera which doesn't offer remote shooting. The StorageInfoChanged event is fired every time you make a remote shooting through a Lua script over PTP.

Was I unclear to the point I lead everyone think I assumed the PTP protocol would report device changes that are usually private to the firmware (such as the viewport's wherebouts), and we only can access to using the CHDK and its functionalities ?

Did I mention that english isn't my native language btw ?
Logged
*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #757 on: 15 / March / 2012, 17:49:23 »
Quote from: asmodyne on 15 / March / 2012, 17:30:46
About the events : of course they're not supposed to give you actual informations about the viewport, since you hacked your way to its buffer, but you can expect actual changes on the viewport buffer when a property change is reported by the device.
What use is this when you have to get and transfer the actual information anyway ? Sending a few extra ints with every 200k+ frame isn't going to be significant, and it makes things very simple. Plus the code to do it this way is pretty mostly already written and working on both the camera and client.
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #758 on: 15 / March / 2012, 18:09:52 »
Quote from: reyalp on 15 / March / 2012, 17:49:23
Quote from: asmodyne on 15 / March / 2012, 17:30:46
About the events : of course they're not supposed to give you actual informations about the viewport, since you hacked your way to its buffer, but you can expect actual changes on the viewport buffer when a property change is reported by the device.
What use is this when you have to get and transfer the actual information anyway ? Sending a few extra ints with every 200k+ frame isn't going to be significant, and it makes things very simple. Plus the code to do it this way is pretty mostly already written and working on both the camera and client.

I think I've pinned the source of the confusion about my post : I had two active discussion topics relevant to this thread, the first being live view, which relies on requesting viewport frames from the device as you do in chdkptp, and the second one is including GLSL capabilities to "my" managed dll in order to process bitmaps.

Thus, I sometimes asked you about the nature of the header declared in live_view.h and how it may vary in runtime, and other times answered questions about the purpose of my dll, or pointed interesting links about GLSL usage in still image processing.

Next time, I should use PM to answer questions or ask new ones.  Sorry about that.  :(
Logged
*

Offline ntstatic

  • ***
  • 246
Re: CHDK PTP interface
« Reply #759 on: 09 / April / 2012, 08:19:22 »
hello everyone,
i have question about live view.
i am using SX 130 (also a few 120) with the live view.
if the camera is in manual mode, the live view does not reflect or resemble the final picture which will be taken. is it possible for the live view to approximate the final picture. eg if exposure is increased the live view becomming brighter (because the final picture will be brighter)

for the moment i am keeping the camera in Program mode - even when my PC software says Manual - only when the PC requires a shot i switch the camera to Manual, set the parameters, take the shot, download pic and switch the camera back to Program mode.

in Manual mode the Live View is often very dark(almost black)

am i doing it right or is there a better way
Logged
Pages: 1 ... 71 72 73 74 75 [76] 77 78 79 80 81 ... 125   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal