Obsolete
Status Update
Comments
ms...@google.com <ms...@google.com>
ms...@google.com <ms...@google.com> #2
I filed an issue with TinyEXR about hardening the decompression API.
https://github.com/syoyo/tinyexr/issues/29
If they're willing to work with us (and we set up a fuzzer), I think TinyEXR may be viable.
EXR seems like the right format for us, I think it'd be a shame to avoid it just because the library needs a bit of work.
If they're willing to work with us (and we set up a fuzzer), I think TinyEXR may be viable.
EXR seems like the right format for us, I think it'd be a shame to avoid it just because the library needs a bit of work.
ms...@google.com <ms...@google.com> #3
A few comments on compression:
mandrill (512x512, decompressed to RGB F16) is 512*512*3*2 = 1.5 MB
Using TINYEXR_COMPRESSIONTYPE_PIZ, the output is 640 KB.
Using optional dependency ZFP (https://github.com/LLNL/ZFP ), the output is 196 KB. This requires converting to full floats for input (and is also probably lossy).
mandrill (512x512, decompressed to RGB F16) is 512*512*3*2 = 1.5 MB
Using TINYEXR_COMPRESSIONTYPE_PIZ, the output is 640 KB.
Using optional dependency ZFP (
ms...@google.com <ms...@google.com> #4
I never got very far on this, and haven't looked at it recently, but here are a few intermediate conclusions that I came to.
(1) TinyEXR is a little bit far away from being usable by Skia. Probably not worth the effort.
(2) OpenEXR is a very large library. It's not clear that the lossless modes provide significant compression (see PIZ in #1).
A long time ago, I did actually have a working Skia EXR encoder and plans to experimentally compile the library.
https://codereview.chromium.org/2344523002/
https://skia-review.googlesource.com/c/3882/
We recently heard from the webp team that they were starting to think about a high precision format. That may be an interesting direction to look in as well.
(1) TinyEXR is a little bit far away from being usable by Skia. Probably not worth the effort.
(2) OpenEXR is a very large library. It's not clear that the lossless modes provide significant compression (see PIZ in #1).
A long time ago, I did actually have a working Skia EXR encoder and plans to experimentally compile the library.
We recently heard from the webp team that they were starting to think about a high precision format. That may be an interesting direction to look in as well.
mt...@google.com <mt...@google.com> #5
[Empty comment from Monorail migration]
Description
We still don't have support for F16 and Alpha8. EXR seems like a good choice because it compresses variable channel sizes (and number of channels), including explicit support for F16. Adding an EXR encoder/decoder should allow us to close 5616.
The official OpenEXR library is here:
As far as I can tell, it is unusable by Skia. It seems to just build into binaries and doesn't actually have any headers.
TinyEXR seems to be an effort to expose an API for encoding and decoding EXR. Romain suggested looking at this library.
I've started experimenting with EXR in Skia. Encoding seems to work (with bugs).
Decoding looks to be a problem though. The TinyEXR API accepts a pointer to memory without a length! And throughout the decode it seems to just assume there is enough memory to do the decode operation. Doesn't seem like something we can ship right now.
I'm concerned that adding an EXR decoder would involve a significant amount of work improving the TinyEXR library. Or writing our own code to handle EXR.
I'm hoping that I'm wrong or that there is another option out there, just wanted to shared my thoughts so far.