[FFmpeg-trac] #1279(swscale:closed): Transform X'Y'Z' to RGB via colormatrix

[FFmpeg]

#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