[FFmpeg-devel] ffmpeg gama problem (Was: Fwd: Re: [Ffmpeg-user] jpg frame export : gama problem)

[Nicolas Jauffret]

On Tue, 24 Jul 2007 11:10:35 +0200, Nicolas Jauffret <nicolas at buf.fr>  
wrote:

> Hello,
>
> On Wed, 11 Jul 2007 15:01:58 +0200, Nicolas Jauffret <nicolas at buf.fr>
> wrote:
>
>> Hi,
>>
>> On Wed, 04 Jul 2007 15:23:17 +0200, Nicolas Jauffret <nicolas at buf.fr>
>> wrote:
>>
>>> 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
>>
>> I won't be able to patch it, but found similar problems when compressing
>> from jpeg image sequences.
>>
>> There are some strange gama differences when compressing from a jpg  
>> images
>> sequence or a png images sequence.
>>
>> I made a test example and wrote a detailed README file to go with.
>> You can find these in the mplayer FTP repository :
>>
>>     upload.mplayerhq.hu:/MPlayer/incoming/gama_problem
>>
>> Thank you for your time and support,
>
> Have you had time to check out my test files ?
> It seems like an overall gama conversion problem.
> Regards,

ping?
I reposted the files to :

   upload.mplayerhq.hu:/MPlayer/incoming/gama_problem_resent

Please take time to read the README file.
Thank you for your attention concerning this problem.
Best regards,

Nick