[FFmpeg-trac] #1279(swscale:closed): Transform X'Y'Z' to RGB via colormatrix
FFmpeg
trac at avcodec.org
Tue May 14 16:45:25 CEST 2013
#1279: Transform X'Y'Z' to RGB via colormatrix
-------------------------------------+-------------------------------------
Reporter: wolfgangw | Owner:
Type: enhancement | Status: closed
Priority: wish | Component: swscale
Version: git-master | Resolution: fixed
Keywords: XYZ j2k | Blocked By:
colormatrix | Reproduced by developer: 0
Blocking: |
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by rexbron):
Cehoyos,
Forgive me if I make incorrect assumptions or have a mistaken
understanding on what is going on within FFmpeg. I speak as someone who is
familiar with Digital Cinema and it's creation, both as a cinematographer
and colorist, not as an engineer.
I think what wolfgangw is trying to get at is that sRGB is not always the
target color space for display and that current code assumes that (which
is not a bad default).
If one was using FFmpeg and an SDI playout card like a Blackmagic, the
projector would need to be fed the decoded but untransformed 12bit X'Y'Z'
signal. It would be fantasic if FFplay could do that. Currently there is
no open source DCP player, let alone an FOSS tool that can even playback
jpeg2000's in real time on a Digital Cinema projector. FFplay comes very
close!
The only way to know for sure that the correct transform is being applied
is to leave it in the hands of the skilled user. That uncertainty is part
of why flexible color management systems like OpenColorIO were created for
authoring media at the high end (where you do assume that everyone knows
what they are doing and will chose correctly).
What was requested initially was to control the RGB matrix values allowing
a skilled user to transform the X'Y'Z' data into whatever space they
required. Wiether that is the best place to expose that functionality, I
can't say.
What I can say is that FFmpeg often makes colorspace assumptions based on
pixel format, which can be incorrect. It is quite forgiveable; very few
software engineers ever look at displays which _arn't_ sRGB and assume
that no one else does either.
Blender went through a similar painful process of bring the developers
into an understanding of color management and it's importance. As FFmpeg
gains prominence as a tool used by professionals, those growing pains will
increase until something is done about it.
Hopefully this hasn't rambled too far off topic and is of some use to you
fantastic devs.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1279#comment:40>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list