Quantcast

[Zbarw-devel] ticket #7 rgb24 support

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Zbarw-devel] ticket #7 rgb24 support

klaus triendl
Am Tue, 12 Jun 2012 05:33:31 +0000
schrieb "Jarek Czekalski" <[hidden email]>:

> Looks like I have little time these days, so I can only answer now
> (thinking about your release), work later. I don't know if you want
> to have this functionality in your release. If this is the case I
> could commit it as is, and you make further changes. I'll be
> available again about 15:00.

No hurry, rgb24 support isn't required for this project.


> >more generic?
>
> [...] But in the first step there is only
> single format support.

Agreed. But read on.


> >What if we extend the mjpg mapping machinery?
>
> The mapping machinery handles conversion between different formats.
> Here we have one format with different symbols. So that's the
> difference that I had in mind when deciding not to use the mapping.
> Do you think there is a better way of handling rgb24? Please give
> more details then, maybe a sketch of the solution.


My idea is actually very simple:
1) We query the camera for its list of formats - those are the source or
internal formats how we call it.
2) We map these formats to zbar input formats (like it's already
implemented for MJPG).
3) In dshow_init() we set the camera format (internal format).
4) We also detect whether the format is mapped and act accordingly.
a) for MJPG we create a decompression graph, other formats may require
different things.
b) handle image flipping for uncompressed bitmaps.


This would require the state->int_fmts array to not only contain the
fourcc format (uint32_t) but parts of the media type in terms of
directshow: the media subtype (GUID) and the compression format from
the BMIH, eventually also the bitcount if required.

The new structure would look like this:
struct camera_mt
{
    GUID subtype;
    uint32_t fmt; // or biCompression
};

So, for 3 exemplary camera formats RGB24, MJPG and YUY2 we would have
the following mapping:

{ MEDIASUBTYPE_RGB24, BI_RGB } -> BGR3
{ MEDIASUBTYPE_MJPG, 'MJPG' } -> BGR4
{ MEDIASUBTYPE_YUY2, 'YUY2' } -> YUY2


Note that in case the camera would provide RGB32 and MJPG then RGB32
(like BGR4) would be preferred over MJPG and MJPG wouldn't make it into
the formats list.


The advantages I see are:
1) we have just one routine (build_format_mapping) that a) decides the
mapping and b) decides which formats make it into the list at all
2) there's just one routine (dshow_init) that deals with specialities
like changing the filter graph


The term 'mapping' may be a little unfortunate if we actually don't
have a mapping like for YUY2, but I think you get my idea.


Regards,
Klaus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Zbarw-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/zbarw-devel
Loading...