[v4] implementation of additional image data

[retokromer]

Today the data used for restoration (e.g. from infrared scanning) are often stored into the alpha channel, which is not a proper solution, as discussed in #31. At least proper metadata are needed.

[retokromer]

On the scanner side e.g. Scanity from DTF (aka Prasad) and ARRISCAN from ARRI use this mechanism. On the software side e.g. Diamant from HS-Art Digital Service or DRS Nova from MTI Film.

[JeromeMartinez]

Is there a flag in the created file from such tool indicating that the 4th channel is not really alpha, or do we have to assume it from the e.g. software name?

[retokromer]

I have to check this as the lab. As long as I can remember (but after a stroke my memory is not good anymore, so please take this cum grano salis), the files we had to deal with didn’t have a flag, no one flagged I can remember.

[retokromer]

This week I did some checking on the softwares I can easily access. Sadly, the software name is not a sufficient flag, as one software can usually export different flavours of the same format, in a more or less transparent way. Additionally the metadata are not always consistent between different versions of the same software!

I would suggest again the double strategy I mentioned in Berlin:

• Store all the original metadata of the RGBA image into the FFV1 when encoding (and into Matroska) and retrieve them when decoding. That information is not necessary fully correct, but it is indeed the information generated originally by the software.
• Standardise a way to store this information «natively» in FFV1 (and Matroska).

The only improvement of my suggestion since Berlin is that – following some excellent arguments made on the Cellar list and/or here on GitHub – I changed my mind: I suggest now to store this metadata both in the codec and in the container, and to consider codec over container in case of divergence.

[retokromer]

Closing as open for longtime.

[dericed]

-1

[retokromer]

@dericed It’s useless and may even be confusing, in my opinion, to keep open issues too long. I have understood that in the current version of FFV1 this will not be considered. When the work on the new version will start, I might publish an updated list with my wishes which would include this one.

[JeromeMartinez]

We could decide to have a label "enhancement" for such ticket, in order to have them categorized.
For the moment, it is true that we focus on v0-3 when we have time for improvements, but I think it is good to keep ideas for v4+ in this tracker so we don't forget them.

[michaelni]

@dericed It’s useless and may even be confusing, in my opinion, to keep open issues too long. I have understood that in the current version of FFV1 this will not be considered. When the work on the new version will start, I might publish an updated list with my wishes which would include this one.

I think we can just work on the next version and update and edit the specificiation and implementation as needed. The specification/draft built for IETF needs to omit these possibly but that should not keep us from working on them. We just might need a way for "make" to drop sections that dont belong in the current IETF draft

[ablwr]

Agreed, better to tag with something like 'enhancement' or even 'v4' than to close the issue entirely.

[retokromer]

Seems not to be of interest. I give up.

[michaelni]

I think this should be kept open

[retokromer]

OK, I reopen and unfollow FFV1 as well.

Context: Censored.

[JeromeMartinez]

@retokromer it takes time, right, but taking time does not mean that it is not welcome.
Some words are off topic.

[retokromer]

FYI: Tests with the new ProRes RAW were successful. However, this covers just a little part of my wish about Bayer.

[retokromer]

FYI: Bayer-based content can easily be encoded as greyscale content. It needs just two additional bits to encode a classic RGB filters disposition (e.g. bggr).

[richardpl]

I think best approach is to send patches to ffmpeg-devel with actual implementation?

[retokromer]

My approach is not supported by two out of three authors of the specification, therefore I would just loose my time… That said, I‘m personally in favour of having first an in-depth discussion on the current bit-stream and on the changes which possibly might be necessary in version 4. (And I’ll refrain here from complaining about the toxic climate inside the FFmpeg project.)