GNOME Bugzilla – Bug 668253
jpegenc creates broken files with rgb sink caps
Last modified: 2012-05-06 23:23:26 UTC
gst-launch -v videotestsrc num-buffers=1 ! video/x-raw-rgb ! jpegenc ! filesink location=/tmp/RGB.jpg creates a file that apparently has no valid JFIF tag, it cannot be read with some programs/libs (e.g. OpenCV ) or behaves strangely(F-Spot rotate changes colors). file /tmp/RGB.jpg returns: JPEG image data No problems, if jpeg is created with: gst-launch -v videotestsrc num-buffers=1 ! video/x-raw-yuv ! jpegenc ! filesink location=/tmp/YUV.jpg file /tmp/YUV.jpg returns: JPEG image data, JFIF standard 1.01 Tested with 0.10.35 as well as todays` git. Maybe caused by an external lib? The problem occurs both on Suse 11.4 and on U. 11.10
A lookup in the file format docs will be needed to be sure it's a bug in gst and not those programs. FWIW, the GIMP and jpegtopnm can read/convert such an image fine.
http://docs.oracle.com/javase/6/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html has some bits over how RGB content is usually signalled, for what it's worth.
Thanks for the comments, maybe indeed its not a bug but a feature. Gimp handles it correctly. In vi, the RGB file has an "Adope" tag.(?) Anyway, no other jpeg "source" known to me creates or saves files that behave this way, so IMHO it would be better to modify it or at least make this configurable. I made a test with an unbiased device, a LG BluRay with USB: YUV.jpg -> perfect RGB.jpg -> colors mixed up, like F-Spot after rotation, white -> pink, black->green, blue->red, light green->blue I experienced another strange thing: videotestsrc has different color balances on rgb and yuv: Outputs look different (bottom left): gst-launch -v videotestsrc ! video/x-raw-yuv ! ffmpegcolorspace ! ximagesink videotestsrc ! ximagesink Outputs look exactly the same: gst-launch -v videotestsrc ! video/x-raw-rgb ! tee name=t1 ! ffmpegcolorspace ! ximagesink async=0 t1. ! ffmpegcolorspace ! video/x-raw-yuv ! ffmpegcolorspace ! ximagesink async=0 Create another trivial bug for this?
The JFIF doc (http://www.jpeg.org/public/jfif.pdf) says that the JFIF format uses either 1 component (grayscale) or 3 component YCbCr colorspaces. It does not include RGB colorspace. So the lack of a JFIF marker seems correct. Maybe that JFIF doc has been superseeded though, it dates from 1992, though I've also found it as http://www.ijg.org/files/jfif.txt.gz with a filesystem timestamp from 2008. The Java docs above mention that if a JFIF tag is present with RGB input for encoding, the image will be converted to YCbCr. So I think the gst behavior is correct, at least for the JFIF tag being left out. Do other programs generate a RGB JPEG file with a JFIF tag ? For OpenCV not reading those images: does it claim to support RGB in JPEG in the first place ? can it read RGB JPEG files written with another program ? For F-Spot rotate showing wrong colors: Does F-Spot rotate do the same with RGB JPEG files written with another program ? In any case, gst's jpegenc does not write those itself, it's the libjpeg code emitting these, and it's the reference library AFAIK (though aging).
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!