Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#3927 closed enhancement (needs_more_info)

feature request: enable pix_fmt xyz12le / xyz12be for TIFF sequences

Reported by: maweber Owned by:
Priority: wish Component: avcodec
Version: git-master Keywords: tif
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


I think it would be useful to support DCI compliant xyz conversion for image output such as TIFF.
(Not just openjpeg j2c)

to make this possible:

% ffmpeg -i input c:v tiff -pix_fmt xyz12le -f image2 /output/file%06d.tif

Thank you.

Change History (7)

comment:1 Changed 4 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords tif added
  • Priority changed from normal to wish
  • Version changed from 2.3 to git-master

comment:2 Changed 4 years ago by maweber


-pix_fmt rgb12 -c:v tiff

be a better target, easier to implement?
I ask because I know of no other lossless 12 bit/channel picture codec in ffmpeg.


Last edited 4 years ago by maweber (previous) (diff)

comment:3 Changed 4 years ago by cehoyos

Could you provide a sample image (tif xyz)? I thought we have one but I think I was wrong.

comment:4 Changed 4 years ago 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.

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.


Last edited 4 years ago by maweber (previous) (diff)

comment:5 Changed 4 years ago by cehoyos

If you want xyz in tiff, please provide a sample.

comment:6 Changed 3 years ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed

I don't think this can be done without a sample.

comment:7 Changed 3 years ago by maweber

Hi cehoyos
Sorry this got dusty, you did right in closing the thread,
but it was a misunderstanding. I answered above my request was pointless.
This is just as an info (I learned in the meantime):

One can get into XYZ with a suitable LUT.
I use this here for my intermediate LUTed tiffs:

In the example I used the LUT previously on the $input with a source-to-target specific LUT.
For example this one for sRGB-gamma2.1-to-XYZ-gamma-2.6 (ffmpeg can do that):

The 12-bit tiff part (you'll notice the waste of bitdepth):
ffmpeg -loglevel quiet -y -i "$input" -vframes 1 -c:v ppm -pix_fmt rgb48be -f image2pipe -threads 0 - | \

/usr/bin/gm convert ppm:- -depth 12 \
-endian msb -define quantum:format=unsigned -compress None \
-define tiff:bits-per-sample=12 tif:$output

gm is graphicsmagick


Note: See TracTickets for help on using tickets.