[v4] implementation of additional image data about ffv1 HOT 18 OPEN

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.

from ffv1.

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?

from ffv1.

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.

from ffv1.

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.

from ffv1.

Closing as open for longtime.

from ffv1.

-1

from ffv1.

@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.

from ffv1.

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.

from ffv1.

@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

from ffv1.

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

from ffv1.

Seems not to be of interest. I give up.

from ffv1.

I think this should be kept open

from ffv1.

OK, I reopen and unfollow FFV1 as well.

Context: Censored.

from ffv1.

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

from ffv1.

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

from ffv1.

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).

from ffv1.

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

from ffv1.

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.)

from ffv1.