[Cellar] Re: Proposal to embed FFV1 as a compression method into PNG or another format

[Jerome Martinez <[e-mail]>]

Hello,

On 25/05/2024 21:57, K Y Ō D Ʌ I K Ξ N wrote:
>
> I am working on an image container format and tested several loslsess 
> single (still) image formats.
> FFV1 is the fastest with very good compression, sometimes even 
> rivaling jxl's lossless compression depending on the content of the 
> image and jxl's compression effort level.
>
Happy to read that, because usually the speed is criticized.


> [...] Proposal to embed FFV1 as a compression method into PNG or 
> another format
>
This is at the edge of the scope of this working group, which is focused 
on FFV1 and Matroska but participants like me already worked on having 
FFV1 registered elsewhere, for example in MXF (SMPTE RDD48:2018 
Amendment 1).
During FFV1 spec development we also worked on indicating how it is 
stored in a couple of containers:
https://www.rfc-editor.org/rfc/rfc9043.html#name-mapping-ffv1-into-container
but it was easy, it was already de facto there and there is less risk of 
conflict with other people willing to use the same codec identifier when 
e.g. 4-byte identifiers are used.

back to PNG:
PNG 1.0 was handled by IETF
PNG 1.2 and later is handled by W3C
A PNG third edition is in draft:
https://www.w3.org/TR/png-3/#10Compression
With development activity at this place:
https://github.com/w3c/PNG-spec

There is a 8-bit (256 possibilities) "compression method" field:
https://www.w3.org/TR/png-3/#10Compression
Currently only value 0, meaning "deflate" compression, is registered.

So the first task, before adapting encoders and decoders e.g. FFmpeg for 
handling such file, is to register a compression method number with the 
PNG working group.
We talked during our IETF meeting about that, nothing is technically 
blocking to have FFV1 in PNG (there is no spec update to do) but there 
is this need of convincing the PNG working group to accept to register a 
compression method number for FFV1 and as there is currently only 1 
value registered it may be an hard task.
We could also arbitrary use a (more or less) random value and try to 
make it a defacto number for FFV1 but in that case there is a huge task 
of convincing every major PNG tool (including PNG) maintainer to support 
that.


A similar work could be done with TIFF.
The most up to date (de facto?) list of compression identifiers I found 
is at:
https://www.awaresystems.be/imaging/tiff/tifftags/compression.html
But I don't know if there is an more official registry, looks like that 
there is a common usage of choosing a random value above 32768 when it 
comes to support a new compression method.

Personally I would be happy to see FFV1 used in PNG and TIFF but I don't 
have the time for trying to convince the PNG working group and tools 
developers to accept FFV1 compression method in PNG or TIFF (or another 
image format).
Would you try to convince the PNG working group to accept FFV1 
compression method in their specs?

Note that for FFV1 v3 there is also the need to register a PNG or TIFF 
chunk for storing the FFV1 configuration Record but it not the biggest task.


> [...] Additionally, this could also be interesting for NASA, 
> especially with the v4 proposals for arbitrary channel formats.

Do you have any point of contact of someone interested in using FFV1 in 
PNG (or other image container) there or is it only a speculation?


> The maximum canvas size should be increased, for example like PNG, 
> which is the maximum number of 31 bit per dimension.
>

Is there a need of width of more than 4 billion (PNG uses 32-bit 
unsigned integers for width and height) pixels somewhere, or even just 
100 times less?
As far as I know, even BigTIFF (used by entities using huge pictures) 
authors didn't want to go there and they worked on having 4+ GB images, 
but the list of TIFF fields authorized to be more than 32-bit does not 
include width and height, only the ones related to the file size. And 
this part is for the image format spec authors, not related to FFV1 
itself (width/height is currently not stored in FFV1 bitstream).

Jérôme