> additional image format is a bad thing? > Anyway, can someone provide a good reason why implementing support for one Otherwise everyone will continue to use PNG32 images for this (which are typically 4-5 times bigger). Put it back together via an off-screen canvas.Īs you can probably tell this is needlessly complicated. Send this as gzipped b64 mxhr thing or as binary blob.Ĥ. Create something which splits a PNG32 into JPG + PNG or JPG + JPG. Well, you can use something like JNG today, but it isn't even remotely practical:ġ. If this chance is missed, things will be delayed even further - again. WebP is the just the closest available lossy RGBA thing. I mean, it took over 10 years to identify this problem and right now there are approximately 2 people who care about it.
The next thing was SVG, but that masking issue will probably take years until it's sorted out. JNG was the obvious route, but Mozilla killed it along with MNG. It's been a while since I've done anything with libpr0n, so comments, questions, etc. Should YUV be supported directly as a gfxASurface ImageFormat? How is it done for WebM? I'm assuming that there's a more global way to do this that would entail hardware acceleration.
Said functions involve the YUV to RGB colorspace conversion.
I'm not sure whether I denoted this properly in the license block. Most of the code is my own, but it was based on the BMP decoder and includes a couple functions from the reference WebP decoder.
#QUPZILLA GOOGLE PHOTOS PATCH#
This patch does not have progressive decoding because I'm not sure whether libvpx supports incomplete data (anybody know?) If somebody could help me with the best way to add the necessary linking, it would be appreciated. This will not compile using -disable-libxul due to the dependency on libvpx. I believe it is fully functional, but if there are problems, please let me know. Splinter Review Here is an implementation of WebP.
0 kommentar(er)
