Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#1279 closed enhancement (fixed)

Transform X'Y'Z' to RGB via colormatrix

Reported by: wolfgangw Owned by:
Priority: wish Component: swscale
Version: git-master Keywords: XYZ j2k colormatrix
Cc: valli@valli.org, onemda@gmail.com, nicoinattendu@gmail.com Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description (last modified by richardpl)

In order to do a colorspace transform (like X'Y'Z' to RGB) one would need to apply a 3x3 transformation matrix. It would be a very handy feature if one could do this in colormatrix.

Removed vf_lut nonsense as it is very slow approach.

Attachments (4)

j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf (1.5 MB) - added by wolfgangw 4 years ago.
JPEG2000 essence in MXF container (X'Y'Z')
rgb-bary-12bpc.preview.jpg (64.1 KB) - added by wolfgangw 4 years ago.
Compressed version of the MXF's source file (which is a 12bpc TIFF)
j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6__000000.j2c (61.4 KB) - added by wolfgangw 4 years ago.
JPEG2000 image (extracted from MXF)
ffplay.j2k-mxf-playback.messages (1.5 KB) - added by wolfgangw 4 years ago.
ffplay messages for playback of the attached MXF file

Download all attachments as: .zip

Change History (52)

Changed 4 years ago by wolfgangw

JPEG2000 essence in MXF container (X'Y'Z')

Changed 4 years ago by wolfgangw

Compressed version of the MXF's source file (which is a 12bpc TIFF)

comment:1 follow-up: Changed 4 years ago by cehoyos

  • Component changed from FFplay to undetermined
  • Keywords j2k added; X'Y'Z' RGB 3x3 matrix transform removed
  • Priority changed from normal to wish

Does the mxf file contain a tiff or a jpeg2000?

Can you extract the image from mxf and attach it?

Changed 4 years ago by wolfgangw

JPEG2000 image (extracted from MXF)

comment:2 in reply to: ↑ 1 Changed 4 years ago by wolfgangw

Replying to cehoyos:

Does the mxf file contain a tiff or a jpeg2000?
Can you extract the image from mxf and attach it?

Done, see j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6-000000.j2c (The tiny jpg file is here to illustrate what the RGB TIFF source for the JPEG2000 looks like).

The attached MXF is of the kind used worldwide in Digital Cinema. These MXF variants can be inspected with e.g. asdcplib's tools (see http://www.cinecert.com/asdcplib/), like

$ asdcp-info j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf

which will produce

File essence type is JPEG 2000 pictures.
       ProductUUID: 7d836e16-37c7-4c22-b2e0-46a717e84f42
    ProductVersion: 1.9.45
       CompanyName: WidgetCo
       ProductName: asdcp-test
  EncryptedEssence: No
         AssetUUID: 10db24e2-0c6f-4ca2-9af7-a90a3685a0d6
    Label Set Type: SMPTE
       AspectRatio: 1998/1080
          EditRate: 24/1
        SampleRate: 24/1
       StoredWidth: 1998
      StoredHeight: 1080
             Rsize: 3
             Xsize: 1998
             Ysize: 1080
            XOsize: 0
            YOsize: 0
            XTsize: 1998
            YTsize: 1080
           XTOsize: 0
           YTOsize: 0
 ContainerDuration: 24
-- JPEG 2000 Metadata --
    ImageComponents:
  bits  h-sep v-sep
    12      1     1
    12      1     1
    12      1     1
               Scod: 1
   ProgressionOrder: 4
     NumberOfLayers: 1
 MultiCompTransform: 1
DecompositionLevels: 5
     CodeblockWidth: 3
    CodeblockHeight: 3
     CodeblockStyle: 0
     Transformation: 0
          Precincts: 6
precinct dimensions:
    1: 128 x 128
    2: 256 x 256
    3: 256 x 256
    4: 256 x 256
    5: 256 x 256
    6: 256 x 256
               Sqcd: 66
              SPqcd: 972096f096f096c08f008f008ee087508750876870057005704777d377d37762

comment:3 Changed 4 years ago by cehoyos

Am I correct that "XYZ" is independent from 12-bit?
If yes, is it possible to create a similar sample with 8bpp? The reason I ask is that I see three different problems with the sample you provided, the first being that the libopenjpeg decoder wrapper currently only supports 8 and 16 bpp and refuses to decode 12bpp. The second problem will be that the jp2 image does not say anything about its colour-space (OPJ_COLOR_SPACE == 0) so I suspect it will be detected as RGB, only the third problem will be the transformation from XYZ to RGB.

(And could you create a 12bpp RGB sample?)

comment:4 follow-up: Changed 4 years ago by wolfgangw

Yes, XYZ denotes a colorspace (See http://en.wikipedia.org/wiki/CIE_1931_color_space for details). It is used in Digital Cinema systems where image essence (in the form of JPEG2000 files wrapped in MXF containers like the one attached) is delivered in X'Y'Z' (the 's denote a gamma compound to 2.6). The reasoning behind this decision was to accommodate for possible future display devices (projectors) with wider gamuts.

12 bits per component is mandatory for image essence wrapped in those MXF containers used in Digital Cinema.

Re. libopenjpeg decoder and bit depths: Something seems to be amiss in your testing. A build of ffmpeg/libopenjpeg here (version N-34352-gf68742b) will decode and playback the attached MXF (or any other Digital Cinema compliant image MXF) just fine. See the attached ffplay.j2k-mxf-playback.messages. It seems that it is forced to rgb24, though, indeed.

Re. 12bpc RGB sample: See https://github.com/downloads/wolfgangw/digital_cinema_tools/rgb-bary-12bpc.tiff. This is the source for the attached JPEG2000 image

Re. OPJ_COLOR_SPACE: Yes, that is a problem, if merely a cosmetic one. I'll look into it. Note that Digital Cinema installations will assume X'Y'Z' and produce correct colors from this file.

PS: There is an easy way to generate and reproduce the Digital Cinema specific files mentioned here: See https://github.com/wolfgangw/digital_cinema_tools_distribution/wiki for a setup script to install cinemaslides (and a bunch of related tools), a tool to build slideshow DCPs (Digital Cinema Packages). You can throw pretty much any type of image file at it. You will be able to inspect the intermediary files generated: DCDM source, JPEG2000 result, MXF container. The setup works on linux systems, virtualboxes too.

PPS: In case the reader is stumbling over the uppercase "Digital Cinema" notation: I write it like so in order to emphasize the "platform" character of all this. "Digital Cinema" is the standardized systems environment that is currently replacing film projection worldwide (if interested start with SMPTE 429-2).

Pretty much all of its properties are well-defined in standards documents. X'Y'Z', colorspace transforms, gamma 2.6, 12 bits per component, possibly encrypted essence, XML infrastructure files, DCP (Digital Cinema Package): All these are bread and butter for everyone working with Digital Cinema.

It's a big one and it would be awesome if we could improve ffmpeg's related feature set. Carlos, thanks for looking into it!

Changed 4 years ago by wolfgangw

ffplay messages for playback of the attached MXF file

comment:5 in reply to: ↑ 4 ; follow-up: Changed 4 years ago by cehoyos

  • Status changed from new to open

Replying to wolfgangw:

Re. libopenjpeg decoder and bit depths: Something seems to be amiss in your testing. A build of ffmpeg/libopenjpeg here (version N-34352-gf68742b)

This is old, current FFmpeg fails, I sent a patch today - perhaps you could test it?

will decode and playback the attached MXF (or any other Digital Cinema compliant image MXF) just fine. See the attached ffplay.j2k-mxf-playback.messages.

It seems that it is forced to rgb24, though, indeed.

Which is bad since FFmpeg does support up to 16 bit per component.

Re. 12bpc RGB sample: See https://github.com/downloads/wolfgangw/digital_cinema_tools/rgb-bary-12bpc.tiff. This is the source for the attached JPEG2000 image

Re. OPJ_COLOR_SPACE: Yes, that is a problem, if merely a cosmetic one. I'll look into it.

Since libopenjpeg does not define XYZ, this will be impossible to solve afaict.

I cannot really comment on XYZ vs RGB and lut, the decoding problem in current FFmpeg will hopefully be fixed soon.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 4 years ago by wolfgangw

Carlos, I'll test definitely. Is your patch upstream yet?

comment:7 in reply to: ↑ 6 Changed 4 years ago by cehoyos

Replying to wolfgangw:

Carlos, I'll test definitely. Is your patch upstream yet?

It's on ffmpeg-devel:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/144397

comment:8 Changed 4 years ago by wolfgangw

Source from git://source.ffmpeg.org/ffmpeg.git, configure --enable-libopenjpeg --prefix=<some path> && make && make install:

Will not play the attached MXF.

cd ffmpeg && patch -p1 ../trac-ticket-1279/144397-001.bin && make && make install

will play the attached MXF (and others):

Input #0, mxf, from '../../trac-ticket-1279/BARY12BPC/j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf':
  Metadata:
    timecode        : 00:00:00:00
  Duration: 00:00:01.00, start: 0.000000, bitrate: 12218 kb/s
    Stream #0:0: Video: j2k, rgb48le, 1998x1080, 24 tbr, 24 tbn, 24 tbc
[buffersink @ 0x9c16b20] auto-inserting filter 'auto-inserted scale 0' between the filter 'src' and the filter 'out'
[scale @ 0x9c16f60] w:1998 h:1080 fmt:rgb48le sar:0/1 -> w:1998 h:1080 fmt:yuv420p sar:0/1 flags:0x4
   1.60 A-V:  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   0/0   

Seeing rgb48le. So ffmpeg was able to do it before the patch but bailed at the bpc check?

By the way: Jasper was not involved in the encoding of the attached j2c and MXF files. They were encoded with openjpeg 1.5.

comment:9 Changed 4 years ago by cehoyos

Decoding of the original sample is now possible with libopenjpeg, I cannot comment on the XYZ vs RGB issue.

comment:10 Changed 4 years ago by richardpl

  • Component changed from undetermined to swscale

XYZ is pixel format and swscale does not support it yet.

comment:11 follow-ups: Changed 4 years ago by wolfgangw

This enhancement request is about the possible right-hand-side values in -vf lutrgb ... not at all specific to XYZ. I'm pretty sure swscale has nothing to do with it either.

Also I'm seeing only now that Carlos had changed the keywords from "RGB 3x3 matrix transform" to "j2k". This is not about j2k at all. Can you correct that? Would be a shame if this turns "unfindable"

Again, I'm asking for how to make r, g and b availabe on the right-hand-side expressions in -vf lutrgb. As of now the possible values (according to http://ffmpeg.org/libavfilter.html#lut_002c-lutrgb_002c-lutyuv) are w, h, val, clipval, minval, maxval, negval and clip(val).

Usefulness of lutrgb would explode if r, g and b were available in those expressions (rhs).

Version 0, edited 4 years ago by wolfgangw (next)

comment:12 in reply to: ↑ 11 Changed 4 years ago by cehoyos

Replying to wolfgangw:

Also I'm seeing only now that Carlos had changed the keywords from "RGB 3x3 matrix transform" to "j2k". This is not about j2k at all. Can you correct that? Would be a shame if this turns "unfindable"

Since no other tickets contain "3x3" and trac has a very usable full-text search function, I don't think a keyword 3x3 would make much sense, otoh, this ticket made us aware about a j2k regression, so this keyword is needed.

comment:13 Changed 4 years ago by wolfgangw

"3x3 matrix transform" rings a bell immediately for anyone who is doing colorspace transforms -- Colorspace transform LUTs are calculated with those.

But hey, ok, and you mention capable trac search. No biggie then.

I would like to keep this ticket on track, though. Let me know if filing a new ticket with a more generic subject would help, thanks.

comment:14 in reply to: ↑ 11 Changed 4 years ago by richardpl

  • Component changed from swscale to avfilter

Replying to wolfgangw:

This enhancement request is about the possible right-hand-side values in -vf lutrgb ... not at all specific to XYZ. I'm pretty sure swscale has nothing to do with it either.

Indeed.

comment:15 Changed 4 years ago by cehoyos

  • Keywords lut added

comment:16 Changed 4 years ago by richardpl

why lut, isn't colormatrix filter better place?

comment:17 Changed 4 years ago by valli

Extendig vf_colormatrix.c would be perfect.
There's also another xyz2rgb video filter for ffmpeg around:
http://www.belle-nuit.com/xyz2rgb-video-filter

comment:18 Changed 4 years ago by valli

  • Cc valli@valli.org added
  • Keywords colormatrix added

comment:19 Changed 3 years ago by richardpl

  • Description modified (diff)
  • Summary changed from Transform X'Y'Z' to RGB via lutrgb to Transform X'Y'Z' to RGB via colormatrix

comment:20 Changed 3 years ago by richardpl

  • Keywords lut removed

comment:21 follow-up: Changed 3 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed

Implemented by Nicolas Bertrand and Michael, tests definitely welcome!

comment:22 Changed 3 years ago by wolfgangw

I'll test. Would you outline how to use it?

comment:23 Changed 3 years ago by cehoyos

  • Component changed from avfilter to swscale

libswscale now accepts XYZ as input colour space, no special treatment is necessary:
$ ffmpeg -i j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6__000000.j2c out.png
$ ffmpeg -i j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf out.mp4

comment:24 follow-up: Changed 3 years ago by wolfgangw

Hm, it not only seems to accept X'Y'Z' but apparently it assumes X'Y'Z. Which will make DCinema people happy (me happy :) and everyone else using JPEG 2000 rather unhappy. The latter will get a color transform they did not and would not ask for.

It is not at all safe to assume X'Y'Z' in JPEG 2000 in general. There needs to be a switch.

Also with git HEAD -lowres n nags about highest possible value 0 and Nicolas just posted a patch to suppress the option entirely in libavcodec/jpeg2000dec.c. What's the reasoning behind this?

comment:25 follow-up: Changed 3 years ago by heleppkes

The current JPEG2000 decoder is only designed for DCinema, the other profiles are not fully implemented yet.

AFAIK you don't need to "assume" if its XYZ or RGB or something else, the profile value indicates this in the bitstream (DCinema profiles use XYZ, everything else RGB), however not everything is implemented yet.

comment:26 follow-up: Changed 3 years ago by cehoyos

Replying to wolfgangw:

Hm, it not only seems to accept X'Y'Z' but apparently it assumes X'Y'Z. Which will make DCinema people happy (me happy :) and everyone else using JPEG 2000 rather unhappy. The latter will get a color transform they did not and would not ask for.

This indeed sounds like a serious regression, could you upload a sample that allows to reproduce this (I see a similar problem here, but not the one you describe)?

Also with git HEAD -lowres n nags about highest possible value 0 and Nicolas just posted a patch to suppress the option entirely in libavcodec/jpeg2000dec.c. What's the reasoning behind this?

lowres works fine here with the two samples you uploaded, please provide your failing command line together with the complete, uncut console output if you see a problem.

comment:27 in reply to: ↑ 24 Changed 3 years ago by Buxiness

Replying to wolfgangw:

Hm, it not only seems to accept X'Y'Z' but apparently it assumes X'Y'Z. Which will make DCinema people happy (me happy :) and everyone else using JPEG 2000 rather unhappy. The latter will get a color transform they did not and would not ask for.

It is not at all safe to assume X'Y'Z' in JPEG 2000 in general. There needs to be a switch.

X'Y'Z' is only set in case of JPEG2000 dcinema profiles

Also with git HEAD -lowres n nags about highest possible value 0 and Nicolas just posted a patch to suppress the option entirely in libavcodec/jpeg2000dec.c. What's the reasoning behind this?

Actually its not suppressed all all. but activated for ffmpeg and ffplay
you can use ffplay -lowres 3 path/to/j2k/MXF

comment:28 follow-up: Changed 3 years ago by wolfgangw

Wrt lowres, Nicolas just let me know that he is merely removing the JPEG 2000-specific portions as lowres lives in avcodec.h. Thanks for the heads-up, Nicolas (and Carl and Buxiness).

Still, while using -lowres in something like

$ ffmpeg -lowres 3 -i j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf out.mkv

works as expected it is not working for my build of ffplay:

$ ffplay -lowres 3 j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf
ffplay version N-52554-gb691bc4 Copyright (c) 2003-2013 the FFmpeg developers
  built on Apr 29 2013 05:04:12 with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
  configuration: --extra-ldflags=-L/Users/wolfgang/.digital_cinema_tools/.lib/openjpeg/openjpeg-1.5.0/libopenjpeg/.libs --extra-cflags=-I/Users/wolfgang/.digital_cinema_tools/.lib/openjpeg/openjpeg-1.5.0/libopenjpeg --enable-libopenjpeg --enable-avfilter --enable-libfreetype --enable-gpl --enable-nonfree --enable-pthreads --enable-postproc --target-os=darwin --arch=x86_64 --enable-libx264 --prefix=/Users/wolfgang/local
  libavutil      52. 27.101 / 52. 27.101
  libavcodec     55.  6.100 / 55.  6.100
  libavformat    55.  3.100 / 55.  3.100
  libavdevice    55.  0.100 / 55.  0.100
  libavfilter     3. 61.101 /  3. 61.101
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  3.100 / 52.  3.100
[mxf @ 0x7f82aa011800] "OPAtom" with 2 ECs - assuming OP1aB f=0/0   
Input #0, mxf, from 'j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf':
  Metadata:
    uid             : 40f4565c-da34-4dfa-b584-6ba4172762c4
    generation_uid  : dac76343-429f-452b-858b-a697bac70b44
    company_name    : WidgetCo
    product_name    : asdcp-test
    product_version : 1.9.45
    product_uid     : 7d836e16-37c7-4c22-b2e0-46a717e84f42
    modification_date: 2012-05-06 11:46:09
    application_platform: i686-pc-linux-gnu
    timecode        : 00:00:00:00
  Duration: 00:00:01.00, start: 0.000000, bitrate: 12218 kb/s
    Stream #0:0: Video: jpeg2000 (JPEG 2000 digital cinema 2K), xyz12le, 1998x1080, 24 tbr, 24 tbn, 24 tbc
[NULL @ 0x7f82aa012400] The maximum value for lowres supported by the decoder is 0
   1.66 A-V:  0.000 fd=   8 aq=    0KB vq=  369KB sq=    0B f=0/0   

(j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf is one of the samples attached to this ticket). It will playback color transformed but full size.

If something jumps out at you as to why my ffplay build seems borked I'd appreciate a hint. I'll try and figure this out.

Last edited 3 years ago by wolfgangw (previous) (diff)

comment:29 Changed 3 years ago by cehoyos

The global option currently clobbers the private option, this will hopefully be fixed by Nicolas' patch (and it is not reproducible with ffmpeg).

comment:30 in reply to: ↑ 28 ; follow-up: Changed 3 years ago by Buxiness

Replying to wolfgangw:

Wrt lowres, Nicolas just let me know that he is merely removing the JPEG 2000-specific portions as lowres lives in avcodec.h. Thanks for the heads-up, Nicolas (and Carl and Buxiness).

Nicolas = Buxiness :)

Still, while using -lowres in something like

$ ffmpeg -lowres 3 -i j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf out.mkv

works as expected it is not working for my build of ffplay:

$ ffplay -lowres 3 j2c_10db24e2-0c6f-4ca2-9af7-a90a3685a0d6_.mxf

Do you apply the lowres patch? Its not yet pushed in ffmpeg

comment:31 in reply to: ↑ 30 Changed 3 years ago by wolfgangw

Replying to Buxiness:

Do you apply the lowres patch? Its not yet pushed in ffmpeg

Oh ok, I'll try that.

You guys are awesome. But then everybody knows :!

comment:32 follow-up: Changed 3 years ago by BenjaminG

I've tested on Linux and MacOS
For MacOS :

port install libopenjpeg
export CFLAGS="-I/opt/local/include/"
export LDFLAGS="-L/opt//local/lib/"
./configure --enable-libopenjpeg --prefix=/your/path/of/ffmpeg/
make
./ffplay -lowres 2 dcp/synchrojpeg2000-feature/jp2k_d9842703-519f-b145-91fa-8de1a220f16b_video.mxf

Playing...

Input #0, mxf, from 'dcp/synchrojpeg2000-feature/jp2k_d9842703-519f-b145-91fa-8de1a220f16b_video.mxf':
  Metadata:
    company_name    : Doremi Labs, Inc.
    product_name    : Orca
    product_version : 1.2.9
    product_uid     : a1ed80d7-c157-6f4c-9b6b-03955342f5b9
    modification_date: 2006-02-02 01:11:58
    uid             : d601a4de-3338-b448-8d37-bec4526a321d
    generation_uid  : cb7f50b0-8935-1441-973a-3e6fa50df97f
    timecode        : 00:00:00:00
  Duration: 00:01:03.92, start: 0.000000, bitrate: 8686 kb/s
    Stream #0:0: Video: jpeg2000 (JPEG 2000 digital cinema 2K), xyz12le, 2048x1080, 24 tbr, 24 tbn, 24 tbc
   0.85 A-V:  0.000 fd=   0 aq=    0KB vq=  864KB sq=    0B f=0/0

Works with lowres 1 to 3.
I see some freeze in some DCP

In attachment, 2 outputs display.
First: DCP Test from Eclair Laboratoires
Second: DCP Terminator Salvation.

Colorspace seems to be good for me (I should do this test on a DCP2000 player when it's possible).

http://s23.postimg.org/uzx5csxjf/Capture_d_cran_2013_04_29_14_42_37.png
http://s21.postimg.org/p0jjqx1vb/Capture_d_cran_2013_04_29_14_43_55.png

Good job guys ;-)

comment:33 in reply to: ↑ 32 Changed 3 years ago by Buxiness

Replying to BenjaminG:

Good job guys ;-)

Thanks ;-)

comment:34 Changed 3 years ago by valli

Just converted some DCP DCinema Trailers to mp4.
It works like a charm.
I've done this via the xyz2rgb-video-filter
( http://www.belle-nuit.com/xyz2rgb-video-filter )
up to now. Results are the same.

comment:35 in reply to: ↑ 25 Changed 3 years ago by wolfgangw

Replying to heleppkes:

AFAIK you don't need to "assume" if its XYZ or RGB or something else, the profile value indicates this in the bitstream (DCinema profiles use XYZ, everything else RGB), however not everything is implemented yet.

I'll maintain that profiles 3/4, i.e. ISO/IEC 15444-1:2004/Amd.1:2006 (E), do not imply X'Y'Z' (the 2006 amendment adds these to the core coding system). There are SMPTE test DCPs (StEM) in both X'Y'Z' and R'G'B'.

comment:36 in reply to: ↑ 26 Changed 3 years ago by wolfgangw

Replying to cehoyos:

(I see a similar problem here, but not the one you describe)?

Can you elaborate?

comment:37 in reply to: ↑ 21 Changed 3 years ago by wolfgangw

Replying to cehoyos:

Implemented by Nicolas Bertrand and Michael, tests definitely welcome!

With the no-choice matrix used in xyz12Torgb48() / fill_xyztables() this really only allows to take input to sRGB (with a low-blacks crush along the way through approximated sRGB gamma instead of correct sRGB gamma). What if users need to take it to P3?

Wrt sRGB gamma: It's entirely possible that people will have sRGB source with correct gamma and others with approximated gamma (straight out of their image mastering). Apparently not all apps use correct sRGB gamma, both internally and in exports.

Don't get me wrong: This is great for many scenarios. But I'm afraid it'll need a bunch of switches to live up to its potential.

Last edited 3 years ago by wolfgangw (previous) (diff)

comment:38 Changed 3 years ago by wolfgangw

Wrt sRGB gamma: See https://github.com/wolfgangw/digital_cinema_tools/wiki/Open-source-tools-for-a-digital-cinema-pipeline#wiki-srgb-gamma for a note. While the page is rather outdated re used tools I believe the sRGB linearization and compounding math are correct.

Last edited 3 years ago by wolfgangw (previous) (diff)

comment:39 Changed 3 years ago by cehoyos

If you have failing samples, please feel free to provide them!

comment:40 follow-up: Changed 3 years ago 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.

comment:41 follow-up: Changed 3 years ago by richardpl

  • Cc onemda@gmail.com added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Implemented XYZ in swscale is unacceptable solution.

There is also no output for XYZ.

comment:42 in reply to: ↑ 40 Changed 3 years ago by cehoyos

Replying to rexbron:

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.

I don't see why this shouldn't be possible with the current solution: Converting the colour space is absolutely not mandatory. Also please test mplayer -vo gl

For which application is another matrix needed, ie when would it help if a matrix can be specified?

What I can say is that FFmpeg often makes colorspace assumptions based on pixel format, which can be incorrect.

Please provide samples.

Not necessarily related to above:
FFmpeg provides a media conversion command line application and a set of libraries. Both work well now with the sample provided in this ticket (see mplayer -vo gl). FFplay is a very useful tool, but it currently is not the answer when you are searching for a playback application and that it only works on sRGB screens is imo unrelated to this ticket.

comment:43 in reply to: ↑ 41 Changed 3 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to richardpl:

Implemented XYZ in swscale is unacceptable solution.

There is also no output for XYZ.

XYZ output works fine here.

comment:44 Changed 3 years ago by richardpl

Then why I get this?

I.... xyz12le                3            36
I.... xyz12be                3            36

comment:45 Changed 3 years ago by Buxiness

  • Cc nicoinattendu@gmail.com added

comment:46 Changed 3 years ago by cehoyos

I meant lavc supports outputting XYZ and lsws supports conversion to other colourspaces.
No encoder can use XYZ, I therefore think that conversion to XYZ is currently not urgently needed. Apart from that, I don't see how it is related to this ticket.

comment:47 follow-up: Changed 3 years ago by wolfgangw

Could you be bothered to provide an example for untransformed output? And one for a different transform graph through libswscale?

When I try to follow a frame's path through the code I run into AV_PIX_FMT_XYZ12BE/LE and

case AV_PIX_FMT_XYZ12BE : *format = AV_PIX_FMT_RGB48BE; return 1;

in libswscale/utils.c. I don't see another path and that is of course entirely due to a lack of understanding how things are done in FFmpeg. Tia.

comment:48 in reply to: ↑ 47 Changed 3 years ago by cehoyos

Replying to wolfgangw:

Could you be bothered to provide an example for untransformed output?

ffmpeg -i input -f rawvideo out but as said, the more useful example is mplayer -vo gl

And one for a different transform graph through libswscale?

Please explain the usecase for another transform (in an as-simple-as-possible language) so we can open a ticket for that feature request.

When I try to follow a frame's path through the code I run into AV_PIX_FMT_XYZ12BE/LE and

case AV_PIX_FMT_XYZ12BE : *format = AV_PIX_FMT_RGB48BE; return 1;

in libswscale/utils.c.

If you want XYZ output, you have to avoid libswscale (which does not support XYZ output).

Note: See TracTickets for help on using tickets.