[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Proposed Module: Camera



The current revision in my repo has get_raw().  I'd appreciate it if
you could try it out and see if it does what you were looking for.

Nirav

On Wed, Jun 18, 2008 at 2:37 AM, Michael <zathras@xxxxxxxxxxxxx> wrote:
> On Monday 16 June 2008 01:42:37 Nirav Patel wrote:
>> Both YUV and HSV would be very useful for vision, but I don't think
>> there's a clean solution to it.
>
> You could choose to simply pass back in a Buffer[1] what you managed to
> get from the camera without conversion as well. As long as you made it clear
> what the type of the data was inside that buffer (ie whether you got YUV, RGB
> etc), then it would be incredibly useful.
>
>   [1] As in one of these: http://docs.python.org/api/bufferObjects.html -
>        which IIRC maps back to this:
>        >>> buffer
>        <type 'buffer'>
>
>> It just doesn't feel right to store
>> it as an RGB surface and leave the user to track what the actual
>> colorspace is.
>
> Indeed that would be an awful situation IMO... Just to clarify - I wasn't
> suggesting that! :)
>
> Having non-RGB surfaces available could be useful of course - but non-RGB
> surfaces stored in surfaces that think they're RGB strikes me as a bad bad
> thing.
>
>> The other issue is that there would still be
>> conversion involved.  Both YUYV and YUV420 would still need some
>> computation to turn it into 24bit packed YUV.
>
> It depends actually. The codec I'm expecting to throw it back out to is Dirac,
> which can handle a variety of input formats (including YUYV and YUV420
> since they're common formats).
>
> Essentially, I'm hoping I can use wrap your camera code and use it as a
> replacement for this code:
>  * http://edit.kamaelia.org/Components/pydoc/Kamaelia.Codec.RawYUVFramer.html
>
> For working with live video for certain cameras. Doing a conversion to RGB and
> back to YUV is less than optimal, especially if the camera can support YUV420
> out and the codec can also accept that.
>
>> Would there then also
>> be support to output YUV from an RGB camera, or would an error be
>> thrown? I could add support to go from * to RGB, YUV, HSV, or
>> Greyscale,
>
> Personally, I would suggest this:
>   * Having conversions for * to RGB, YUV, HSV and greyscale are useful.
>   * Having * to RGB & YUV is more critical. (YUV420 being sufficient for
>      many tasks after all)
>   * Failing that, being able to get access to the raw data that you capture
>      tagged with it's type would enable anyone using your code to use it as
>      a source for doing 1 & 2.
>
>> but would that be making the module too big for inclusion
>> in pygame?  The .so is above 50kb as is.
>
> I've no idea. :-) My personal opinion (I am not the world :) is that:
>    * doing "3" would be a huge benefit for very little effort.
>    * doing "2" & "3" would be a much bigger benefit for a bit more work, and
>       just mirrors a conversion you already make available.
>    * However I'm less convinced of the benefit of the jump from "2" & "3"
>       to "1", "2" and "3".
>
>> There are other libraries (pygstreamer for example) that are much
>> better for encoding to video, but you're right that I do need to come
>> up with something for image processing.
>
> Well, I maintain the python bindings for the Dirac video codec, which is where
> I'm coming from with this request.
>
> Also, it would be really neat to be able to build a simple video link tool by
> doing this:
> Server:
>   Pipeline( VideoCaptureSource(format=raw),
>                 EnsureYUVFrames(),
>                 DiracEncoder(),
>                 SingleServer(port=1600)).run()
>
> Client:
>   Pipeline( TCPClient("server.com", 1600),
>                 DiracDecoder(),
>                 MessageRateLimit(15,15),
>                 VideoOverlay()).run()
>
> Currently all the above Kamaelia components exist, sans the YUV
> output/enforcer...
>
> (The VideoOverlay() component at the end is pygame based as well, so simply
> being able get hold of the raw YUV data (if available) and only converting if
> it isn't, would be really really useful.)
>
>> The image quality improvements are probably the result of your webcam
>> supporting one of the pixelformats added recently.  Cameras do strange
>> things with different pixelformats.
>
> Cool.
>
> Anyway, whatever you decide, this is really neat work and lots of fun to play
> with :-)
>
>
> Michael.
>