Subject: Re: [Cellar] Colour Format proposal

From: Kieran O Leary <[email-masked]>
Date: Sun, 4 Sep 2016 15:40:23 +0100

Hi everyone,

I'd like to revisit this topic as I've been thinking about it a lot lately.

On Tue, Feb 16, 2016 at 7:27 PM, Reto Kromer <[email-masked]> wrote:
> Peter B. wrote:
>
>>I wouldn't want to rule out the option of transcoding from
>>DPX to FFV1/MKV.
>>But on the other hand, I'm very much in favor of keeping
>>things simple - and not overdoing it.
>>
>>I think being able to handle non-linear color values (as
>>often found in DPX scans) is important, but I wouldn't go
>>as far as putting something like "printing density" into
>>the standard.
>

I think keeping it simple is important, especially as I doubt that
'Printing Density' is ever used outside of DPX film scanning. Speaking
anecdotally , I have not seen many 'Log' values in the color
primaries/transfer characteristics fields in DPX files. I'm basing
this on seeing the output of DPX from about 5 different scanners and
from files that have passed through Da Vinci Resolve. It's often
'Printing Density', 'Linear', or just no value at all, which shows up
as '0' for the 801/802 values. I think that there is a value in adding
'Printing Density' to the list of Matroska values for Transfer
Characteristic, as I'm sure that it appears frequently in film
archives. While it would be ideal if FFV1 could hold these values on a
codec level, having Matroska support would be great.

There is a good chance (I will write another post to CELLAR about this
next week) that the ffmpeg DPX encoder should be able to read a color
primary/transfer characteristic value from a source file (DPX or
FFV1.MKV), and then encode the correct colour value into the output
DPX file. From what I understand, this would be done via
AvCodecContext. I do not know enough about the inner workings of
ffmpeg (does it look at container values?) to know if these kinds of
color values could be passed from a container -> AvCodecContext ->DPX
encoder. If so, then it would be good to know that Printing Density
values could be passed correctly, not just Log and Linear.

Best,

Kieran.

---

From: Kieran O Leary <[email-masked]>
Date: Sun, 4 Sep 2016 16:02:10 +0100

Hi

On 4 Sep 2016 3:40 p.m., "Kieran O Leary" <[email-masked]> wrote:
>
>
> From what I understand, this would be done via
> ffmpeg (does it look at container values?)

This was confusing when I re-read. I meant, does AvCodecContext look at
container values? Probably a stupid question, but the 'codec' in the name
has put some doubt in my head.

---

From: Dave Rice <[email-masked]>
Date: Sun, 4 Sep 2016 15:48:13 -0400

> On Sep 4, 2016, at 10:40 AM, Kieran O Leary <[email-masked]> wrote:
> 
> Hi everyone,
> 

For reference the color format data of DPX is defined in S268M, copy archived at http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s268m.pdf. See page 14 in particular. These lists only partially overlap with what is already proposed for Matroska. Interestingly at the end of page 23 it states that "The term 'logarithmic' is considered to be inadequately defined to achieve interchange between different implementations."
Dave Rice