[FFmpeg-devel] Fwd: Re: [Ffmpeg-user] jpg frame export : gama problem

[Michael Niedermayer]

Hi

On Fri, Jun 29, 2007 at 11:14:53AM +0200, Nicolas Jauffret wrote:
> On Thu, 21 Jun 2007 19:08:54 +0200, Nicolas Jauffret <nicolas at buf.fr>  
> wrote:
> 
> > Hello,
> > here is a discussion thread about a jpg export gama problem.
> > Thank you for your time and support.
> > Best regards,
> >
> > Nick
> >
> > ------- Forwarded message -------
> > From: "Nicolas Jauffret" <nicolas at buf.fr>
> > To: "FFmpeg user questions and RTFMs" <ffmpeg-user at mplayerhq.hu>
> > Cc:
> > Subject: Re: [Ffmpeg-user] jpg frame export : gama problem
> > Date: Thu, 21 Jun 2007 18:58:17 +0200
> >
> > On Thu, 21 Jun 2007 18:08:44 +0200, Michel Bardiaux
> > <mbardiaux at mediaxim.be> wrote:
> >
> >> Nicolas Jauffret wrote:
> >>> Hello,
> >>>
> >>> When I try to extract a frame from a dv video with this command :
> >>>
> >>>    ffmpeg -i "input.mov" -vframes 1 -ss 0.0000 -t 0.0400 "out.%08d.jpg"
> >>
> >> You should always post the complete output messages too.
> >>
> >>>
> >>> I have a gama problem : the initial black RGB(0,0,0) becomes  
> >>> RGB(16,16,16).
> >>> ffmpeg doesn't seem to do a yuv level range conversion when exporting  
> >>> to
> >>> jpeg.
> >>>
> >>>
> >>> If I choose png file format for output, I have no problem.
> >>> I get a pure black RGB(0,0,0) in my exported frame.
> >>>
> >>>    ffmpeg -i "input.mov" -vframes 1 -ss 0.0000 -t 0.0400 "out.%08d.png"
> >>>
> >>
> >> If only a few pixels of that image are black, well, JPEG is lossy, so
> >> its no surprise it takes liberties with some pixels. Make an all-black
> >> image as a BMP or raw or other lossless format, and convert it to JPEG
> >> with ffmpeg. If still not black, then report the bug.
> >
> > Of course, I have done that with a black images test sequence.
> >
> > I confirm that there is a problem doing this:
> >
> > $ ffmpeg -i input.bmp -f image2 output.%d.jpg
> > FFmpeg version SVN-r9377, Copyright (c) 2000-2007 Fabrice Bellard, et al.
> >     configuration: --enable-gpl --enable-static --enable-swscaler
> > --enable-pthreads --enable-libmp3lame --enable-libogg --enable-libxvid
> > --disable-ffserver --enable-memalign-hack --enable-libx264  
> > --enable-liba52
> > --extra-ldflags=-l m
> >     libavutil version: 49.4.0
> >     libavcodec version: 51.40.4
> >     libavformat version: 51.12.1
> >     built on Jun 21 2007 16:36:33, gcc: 3.3.5 (Debian 1:3.3.5-13)
> > Input #0, image2, from 'input.bmp':
> >     Duration: 00:00:00.0, start: 0.000000, bitrate: N/A
> >     Stream #0.0: Video: bmp, bgr24, 420x300, 25.00 fps(r)
> > Output #0, image2, to 'output.%d.jpg':
> >     Stream #0.0: Video: mjpeg, yuvj420p, 420x300, q=2-31, 200 kb/s, 25.00
> > fps(c)
> > Stream mapping:
> >     Stream #0.0 -> #0.0
> > Press [q] to stop encoding
> > Compiler did not align stack variables. Libavcodec has been miscompiled
> > and may be very slow or crash. This is not a bug in libavcodec,
> > but in the compiler. Do not report crashes to FFmpeg developers.
> > frame=    1 fps=  0 q=3.5 Lsize=       0kB time=0.0 bitrate=   0.0kbits/s
> > video:3kB audio:0kB global headers:0kB muxing overhead -100.000000%
> >
> > Although, the "input.bmp" is a full black RGB(0,0,0) image,
> > the "output.1.jpg" is not black : RGB(16,16,16).
> >
> > I am going to report this issue to the devel mailing list.
> > Best regards,
> >
> > Nick
> 
> Ping ?
> Have you well received my mail ?

yes and patch welcome, its likely a problem with the colorspace convertion
see sws_setColorspaceDetails() and the code responsible for RGB->YUV

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070629/4f9fe47b/attachment.pgp>