Suggestion: Add lossless/loosy information to the VP8X header

[midora]

In the moment WebPGetFeatures returns the WebPBitstreamFeatures.format undefined/loosy/lossless. This value is not explicitly stored but calculated on load from the file content. In case of an animation the value is always undefined.

I would propose to store this info in the two RSV bits if the VP8X header which are currently zero. I.e.:

0: undefined  (as now)

1: loosy

2: lossless

3: mixed

I guess it's not too complex to accumulate the value during encoding.

[James Zern]

On Tue, Jan 11, 2022 at 9:40 AM midora <martin...@proregia.ch> wrote:

In the moment WebPGetFeatures returns the WebPBitstreamFeatures.format undefined/loosy/lossless. This value is not explicitly stored but calculated on load from the file content. In case of an animation the value is always undefined.

Correct. WebPGetFeatures doesn't parse animated images, but something using the WebPDemux interface could walk the chunks if knowledge about the data was useful to an application. Otherwise webpinfo/webpmux can be used to inspect a file.

 

I would propose to store this info in the two RSV bits if the VP8X header which are currently zero. I.e.:

0: undefined  (as now)

1: loosy

2: lossless

3: mixed

I guess it's not too complex to accumulate the value during encoding.

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/61d083bb-d9c4-482a-aef1-1c07570b87een%40webmproject.org.

[midora]

>> Correct. WebPGetFeatures doesn't parse animated images, but something using the WebPDemux interface could walk the chunks if knowledge about the data was useful to an application. Otherwise webpinfo/webpmux can be used to inspect a file.

You are talking about a workaround. I'm talking about an improvement of the file format. You can solve all problems on a low level interface. You can even read it byte by byte. It just takes more and more time to parse a file. You could also simplify WebPGetFeaturesby just returning the new bits in the VP8X header.

[James Zern]

On Tue, Jan 11, 2022 at 1:36 PM midora <martin...@proregia.ch> wrote:

>> Correct. WebPGetFeatures doesn't parse animated images, but something using the WebPDemux interface could walk the chunks if knowledge about the data was useful to an application. Otherwise webpinfo/webpmux can be used to inspect a file.

You are talking about a workaround. I'm talking about an improvement of the file format. You can solve all problems on a low level interface. You can even read it byte by byte. It just takes more and more time to parse a file. You could also simplify WebPGetFeaturesby just returning the new bits in the VP8X header.

You're right, I was talking about a workaround. We left some space in the header while the format was under development, but I'd like to be cautious of any changes to the format as widely deployed as it is now. In this case the bit would be informative, but could fall out of sync with the content and I don't think that knowing the contents up front would change the processing path for example.

[Pascal Massimino]

Hi,

On Wed, Jan 12, 2022 at 8:19 PM 'James Zern' via WebP Discussion <webp-d...@webmproject.org> wrote:

On Tue, Jan 11, 2022 at 1:36 PM midora <martin...@proregia.ch> wrote:

>> Correct. WebPGetFeatures doesn't parse animated images, but something using the WebPDemux interface could walk the chunks if knowledge about the data was useful to an application. Otherwise webpinfo/webpmux can be used to inspect a file.

You are talking about a workaround. I'm talking about an improvement of the file format. You can solve all problems on a low level interface. You can even read it byte by byte. It just takes more and more time to parse a file. You could also simplify WebPGetFeaturesby just returning the new bits in the VP8X header.

You're right, I was talking about a workaround. We left some space in the header while the format was under development, but I'd like to be cautious of any changes to the format as widely deployed as it is now. In this case the bit would be informative, but could fall out of sync with the content and I don't think that knowing the contents up front would change the processing path for example.

Indeed, knowing the underlying format of each frame (or even single frame) is somewhat 'arcane' for most users and of limited practical use.

All the more that it's easy to instantiate a Demuxer object and jump over chunks to retrieve this information at almost no cost, should it be useful.

But more importantly, it certainly is too late to change the format bitstream after such a long time of deployment (a lot of potential breakage on the user side can happen!).

And also, this would make the format less resilient to on-the-fly editing (e.g.: dropping the last chunk or adding one. You'd have to go back and update the VP8X chunk's with new information).

Nevertheless, I think the function you wrote to retrieve the lossy/lossless/mixed info for an animation could be a good addition to the 'extra' lib in extras/, as a general utility.

If you feel like contributing it to the repo, please do!

skal/

 

 

 

On Tuesday, 11 January 2022 at 21:34:52 UTC+1 James Zern wrote:

On Tue, Jan 11, 2022 at 9:40 AM midora <martin...@proregia.ch> wrote:

In the moment WebPGetFeatures returns the WebPBitstreamFeatures.format undefined/loosy/lossless. This value is not explicitly stored but calculated on load from the file content. In case of an animation the value is always undefined.

Correct. WebPGetFeatures doesn't parse animated images, but something using the WebPDemux interface could walk the chunks if knowledge about the data was useful to an application. Otherwise webpinfo/webpmux can be used to inspect a file.

 

I would propose to store this info in the two RSV bits if the VP8X header which are currently zero. I.e.:

0: undefined  (as now)

1: loosy

2: lossless

3: mixed

I guess it's not too complex to accumulate the value during encoding.

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/61d083bb-d9c4-482a-aef1-1c07570b87een%40webmproject.org.

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.

To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/CABWgkXKxd_EcrdaRyZBmJb0mnP%3DJ3T4btSFKQR-RGKGJ_J6wPA%40mail.gmail.com.

[midora]

The main reason for the suggestion is not about loading of a file. It is about creating a list of files you can present to a user depending on some properties. This must be a fast operation. There is just not the time to scan the content of a bunch of files to collect this information.

I'm happy that there are the animation and alpha bits in the VP8X header. I would be more happy to get the lossless/loosy/mixed information :-)

I'm not complaining. This was just a suggestion which adds some meaning to an existing reserved field which must be zero in old files. The change is fully compatible with the current specification. If some applications interpret these bits in the moment then they are buggy for sure .

The argument that editing the files could create wrong information would be the same for the alpha bit.

IMHO to create an extra tool would only make sense to parse old files and set these bits. In the moment I will enter the info into a database. This is not the best solution but better than always parsing the files.

cu Martin