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: loosy2: lossless3: mixedI 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.
>> 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.
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.
--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: loosy2: lossless3: mixedI 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.