On 18/12/17 13:50, Laurent Pinchart wrote:
That's an option too. I had a look at the code once to find out how
ImageMagick was performing scaling and gave up with a headache soon
afterwards. We need more formats than what ImageMagick currently supports
(it's mostly focused on image file formats instead of raw image formats), with
all kind of RGB, YUV (and ideally Bayer) formats, and I don't think extending
ImageMagick would be the way to go.
Yep, I can image that ImageMagick can't handle it all. I don't really
have much experience with it. I did find that it has enough tunables to
manage rgbx8888 with different byte orders and the "extra" alpha channel:
convert -depth 8 -size $1x$2 -color-matrix "0 0 1 0 1 0 1 0 0" -alpha
deactivate rgba:$3 png:-
But things like argb1555 or yuv422 might prove to be too difficult for
ImageMagick.
Where's the source for v4l2convert? What does it do?
I wonder how difficult it would be to create a
brute-force-no-optimizations style of a function to which you give the
exact bit definition of the buffer's pixel format, and which gives you
RGB888 or YUV444, depending on the input format (I presume most image
encoders would accept RGB888 & YUV444).
I think the function wouldn't even need to care whether the data is RGB
or YUV, it would just unpack it according to the format definition.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
