New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support premultiplied alpha in fetch
tool.
#1030
Comments
fetch
tool.fetch
tool.
@johnoneil It looks like the PNG spec and the WebP spec both mandate non-premultiplied alpha. So I think DC is doing the right thing, and so long as we use PNGs we should honor the spec because we have multiple decoders (e.g.: the native Rust one and the Kotlin one... which uses the Android image decoder), so we don't get unexpected results if a DCF generated with one set of flags is used with a renderer that doesn't know how to interpret them. So I think so long as its PNGs, we need to fix our impeller binding to apply the premultiplication or see if there's a different impeller image format we need to use such that the sampler or impeller's shaders do the full multiplication. But, I agree it's silly to spend a bunch of CPU time at startup multiplying |
Okay. I currently have a hack in place to eliminate the need for pre-multiplication, but when I next update our renderer, I will remove that hack and include code to pre-multiply image content where needed (I believe I can detect cases where raw image data is apparently not premultiplied). |
I'll run down the info that kicked this off below, but the bottom line is, our use of the Impeller renderer requires all textures we use to have pre-multiplied alpha.
So, to begin with: when we currently load some .png images from serialized design docs, some render incorrectly.
Note the "cloud" above the car in this image:
This image renders incorrectly because the PNG for this element packed into the serialized document file does not contain premultiplied alpha. It contains what's called "straight" or non-premultiplied alpha.
Strictly speaking that is correct because PNG files should not contain premultiplied alpha. That is addressed in the PNG spec. See here.
The question then arises, if our renderer requires premultiplied alpha, where should that pre-multiplication be applied?
We could apply this pre-multiplication after we unpack the PNGs from the serialized file (at runtime), but that would incur a runtime cost. We're already seeing some impact to start time from large image loading, so I'm wary of making that worse.
Still, applying the premultiplication to loaded images at runtime may be the correct approach.
But to obviate the need for a runtime cost, I think the proper fix is further up the pipeline. My current only thought is to do it in some way when the binary file is packed.
I would suggest we allow the
fetch
tool to have an additional command line parameter to allow packing PNG (or all images?) with premultiplied alpha applied. Or maybe convert them to a format which usually handles premultiplied alpha.The text was updated successfully, but these errors were encountered: