Linearizing RGB after conversion from YCbCr rec709 transfer

[yellow]

Having succeeded in getting my YCbCr sources piped out of Avisynth as 48bit RGB, and writing them to .exr with Imagemagick via Avs2yuv I need to linearise the IM EXR output, as EXR's should really be linear not gamma encoded and the app I using to import EXR's assumes linear.

My understanding is that the YCbCr sources were gamma encoded with a Rec709 Transfer Curve, but although they are now RGB data, they are not strictly sRGB gamma encoded, handling them as such in the linear conversion I believe will produce marginally incorrect results, a Rec709 transfer curve being a little different to an sRGB one (a linear portion near it's base), ie: not Scene referred and as a result shadow detail in that region will be crushed a little.

To clarify, this is with regard to intermediate files, the application I'm using to import the EXR's expects them to be linear and applies an sRGB 2.2 gamma conversion to previews for display but all ops in the application are done in linear.

So I'm unsure how to linearise the rec709 curve with IM.

[anthony]

Thats can be tricky as IM version 6 is a little confused as to the difference between sRGB (non-linear) and RGB (linear).

By default when it reads an image is (mostly) assumes the image is linear RGB. Of course that assumption is actually wrong and most images are actually sRGB.

Now -colorspace sRGB actually converts To a linear rgb from sRGB. That is it actually does non-linear RGB to linear RGB
and then internall makes it as being sRGB, even though it is now linear RGB

that is -colorspace sRGB maps TO linear RGB

The problem is what does other -colorspace methods do. Do thay assume a just read image (marked RGB) is linear or non-linear. Without knowing that, I can't answer your question.

I suggest you check the formulas on the main IM home website and test them against some test images.

WARNING: IM will automatically convert from a linear RGB image marked sRGB to non-liear form when saving to some file formats like PNG This can confuse things.

See my current notes about sRGB handling in
http://www.imagemagick.org/Usage/resize ... colorspace
and
http://www.imagemagick.org/Usage/draw/#colorspace

In summery IMv6 colorspace handling is a little screwed up. and is something that marked for fixing in IMv7 (in development)

[yellow]

Anthony, thanks for the response, when I read sRGB in your reply I assume you're talking about 2.2 gamma encoding rather than color primaries of which my original YCbCr source and RGB output share.

So sRGB gamma 2.2 doesn't really come into my query ?, the RGB images I'm generating from YCbCr source are Rec709 gamma, ie: something more like 2.35, (ie: it was a Rec709 transfer curve that originally gamma encoded the linear data off the camera sensor and that is slightly different to sRGB curve)

The raw RGB data fed into IM from AVISynth which handled the controlled conversion from YCbCr to RGB, has had no gamma adjustment ie YCbCr to sRGB, so what I'm looking for is a method of IM linearising RGB data originally encoded with a Rec709 gamma curve to linear RGB.

From there I can either view that in preview with a Rec709 or sRGB gamma curve lut depending on final intended delivery.

Can IM be told that the incoming image is rec709 gamma and linerise based on that or does it assume sRGB whatever?

Thanks for your reply, didn't think I was going to get one.

[anthony]

Sorry I don't know how "rec709 gamma" relates to "rec709" or how it needs to be converted.
I think you may need to work out the mathematics needed for that.

I am however willing to help in whatever way I can.

[fmw42]

I don't know much about this but see Transfer characteristics at http://en.wikipedia.org/wiki/Rec._709

"Rec. 709 is written as if it specifies the capture and transfer characteristics of HDTV encoding - that is, as if it were scene-referred. However, in practice it is output (display) referred with the convention of a 2.4-power function display [2.35 power function in EBU recommendations]. (Rec. 709 and sRGB share the same primary chromaticities and white point chromaticity; however, sRGB is explicitly output (display) referred with an average gamma of 2.2.)"

I don't know if this relates to the issue here or not.

[yellow]

anthony, thank you for your reply and offer of help.

fmw42, yes that's it. Rec709 transfer is Scene referred where as sRGB gamma is Display referred.

So my understanding is that to linearise a Rec709 capture and get the exposure / color values that we're actually captured in the 'Scene' originally, a reverse of the transfer curve is needed, as opposed to the typical approach that as the image is going to be 'Displayed' on a sRGB monitor therefore a 0.45 value is used to linearise, based on 2.2 gamma.

But whether that is as simple as linearising based on a power function I am unsure, does that approach reproduce the inverse of the transfer curve or maybe more maths is needed due to the curve been linear at the base then curving more like sRGB after.

The second post on this thread, explains rec709 curve, disregard rec601 and display discussion, the purpose for me is to get Scene referred linear data for compositing in linear light and apply a viewing LUT for sRGB or whatever target display.

http://www.cine-tal.com/forum/viewtopic ... 7be6ce8b78

[fmw42]

Perhaps if you figure this all out, you might post some notes so that Anthony can add that to his Examples pages. I would welcome learning more about the different image formats REC etc with and without gamma, etc, and when to use them and under what circumstances they need to be gamma corrected and such.

[anthony]

Ditto.

this may be important as IMv7 will have some work done to fix the colorspace handling being used, with sRGB being the default colorspace.

Also I will be looking into the use of another colorspace, XYZ, which is the standard reference, and is also linear.

[yellow]

I'm hoping to add details to my blog once I've worked out one last problem which I think from anthonys previous comment is due to IMs approach to colorspace handling.

I'm using a great update to the Dither plugin within AVIsynth which now does the linearising based on a choice between rec709 and sRGB.

The problem I have with the image sequences written out by IM after been fed in by piping with avs2yuv is that for any linearised RGB data done with the rec709 inverse curve the images created by IM have spiked 'luma' whereas those done with the inverse sRGB curve have no spikes, so I think IM is indeed as suggested doing some unecessary colorspace ops.

Is there any way to circumvent that and just deliver the RGB data in an image format as it arrived from Avisynth?

[fmw42]

have you tried

... | convert - -set colorspace RGB resultimage

or

... | convert - -set colorspace sRGB -colorspace RGB resultimage

[anthony]

Warning using -set colorspace sRGB -colorspace RGB does not do what you may expect as IM treats RGB and sRGB in a reversed order (something that will be fixed in IMv7). This means that that sequence converts from linear-RGB to non-linear sRGB for saving. The reason for this is historical, but is becoming more and more important.

[anthony]

Looking at that other "cineSpace" forum
http://www.cine-tal.com/forum/viewtopic.php?p=48#48

It looks as if Rec709 also has a non-linear form. Or is that color space non-linear by its definition?

If it does then that means there are now non-linear forms for RGB (sRGB), Grayscale, and Rec709. And by non-linear I do not mean just a simple gamma adjustment, but a mix of a stronger gamma plus a linear slope for the darker colors.

[fmw42]

I read that somewhere also, possibly http://en.wikipedia.org/wiki/Luma_(video)

but also see
http://www.tweaksoftware.com/static/doc ... anual.html
http://www.13thmonkey.org/~boris/gammacorrection/

I am not sure if IM is using only the linear version or not. Someone needs to look at the code.

[anthony]

Okay so the Luma channel of Rec709 is a mix of gamma compressed RGB. As such Rec708 is non-linear.
However if the colorspace info on IM command line options is right, then converting Rec709 to RGB and then to sRGB (or more directly) will get you linear RGB. Of course you would then need to -set colorspace RGB if you want to save the image values in linear form for image formats like PNG. Also for PPM (after a quick test)

[yellow]

anthony & fred, thanks for the replies.

Warning using -set colorspace sRGB -colorspace RGB does not do what you may expect as IM treats RGB and sRGB in a reversed order (something that will be fixed in IMv7). This means that that sequence converts from linear-RGB to non-linear sRGB for saving. The reason for this is historical, but is becoming more and more important.

I've been using RGB & RGB ie: to keep it linear, I'm now able to feed linearised RGB into IM from Avisynth via an updated plugin.

Looking at that other "cineSpace" forum
http://www.cine-tal.com/forum/viewtopic.php?p=48#48

And by non-linear I do not mean just a simple gamma adjustment, but a mix of a stronger gamma plus a linear slope for the darker colors.

Yes, two parts to the curve, which is where my initial query comes from, so many times we see video with a rec709 curve being linearised for compositing with the inverse of a sRGB curve resulting in more crushed shadows, apart from the scaling of luma levels to RGB but that's a separate thing.

Okay so the Luma channel of Rec709 is a mix of gamma compressed RGB. As such Rec708 is non-linear.
However if the colorspace info on IM command line options is right, then converting Rec709 to RGB" and then to sRGB (or more directly) will get you linear RGB.

Sorry not sure if I follow, if IM assumes all images are to be handled as if gamma encoded 2.2 or to linearise based on 2.2 then there has been no accounting for the differing curve of rec709 and the linear output will be 'Display' referred not 'Scene' referred linear? Sorry if I misunderstand.

Of course you would then need to -set colorspace RGB if you want to save the image values in linear form for image formats like PNG. Also for PPM (after a quick test)

Yes using RGB & RGB to keep it Scene linear, then using a ICC profile / 1D LUT for display in my apps.

Thanks for your input again, I would like to be able to ascertain for sure that IM is handling the data correctly by using RGB & RGB, writing out linear 16bit tif / exr. It appears to be.