[FFmpeg-trac] #3927(avcodec:new): feature request: enable pix_fmt xyz12le / xyz12be for TIFF sequences

FFmpeg trac at avcodec.org
Sat Dec 13 23:40:13 CET 2014


#3927: feature request: enable pix_fmt xyz12le / xyz12be for TIFF sequences
-------------------------------------+-----------------------------------
             Reporter:  maweber      |                    Owner:
                 Type:  enhancement  |                   Status:  new
             Priority:  wish         |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  tif          |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-----------------------------------

Comment (by maweber):

 Hi cehoyos, thanks

 I was quite deep into this topic the last weeks and '''may now have to
 correct myself'''.

 XYZ is a colour space. a definition of primaries/gamma/whitepoint,
 suitable for hosting/simulating any other colourspace, since its so huge.
 it is used for DCI cinema movie packages by definition.
 I understand that a 12 bit TIFF with three components is "electrically"
 the same, whether it's YUV, XYZ or RGB.

 info:
 [https://en.wikipedia.org/wiki/CIE_1931_color_space Wikipedia on XYZ]

 -pix_fmt xyz12 was I think introduced by ffmpeg as a quick way for
 openjpeg jpeg2000 to scale into the cinema DCI colourspace. but I think
 this conversion is problematic. because the conversion to DCI XYZ involves
 the identification of the source colourspace as well as the source
 gamma/whitepoint. Therefore I think possibilities/errors are endless. (I
 now do it partly with a range of LUTs in ffmpeg.)

 Thats why I think there needs to be good control to go to XYZ, not one
 simple way with -pix_fmt. Thus making my request partly pointless.

 But there is a consideration:
 '''It might be useful, to output 3 component RGB 12bit TIFFs from
 ffmpeg.'''
 Because there is a big overhead/bandwidth problem, to convert it to 16bit
 (48bit), whether TIFF or PNG, just '''not''' to go under 12 bit.
 So having an 12 bit TIFF output which I could even further compress
 losslessly with ffmpeg options, would save space, streamlining it for a
 DCI pipeline.

 I can provide a 12bit uncompressed RGB TIFF, only please suggest to me how
 I would provide the file best to you.
 If you wish an XYZ example for the idea, I can add that too.
 If you're willing to set it as an open issue...

 thanks
 m

--
Ticket URL: <https://trac.ffmpeg.org/ticket/3927#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list