Fix iOS image loading process outputting alpha-premultiplied colours #6454
+29
−12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Marking as draft pending performance profiling and figuring out why there are still noticeable artifacts in intro even with this PR...;
By the nature of iOS, no image can be provided as raw pixel data without the colour components already being alpha-premultiplied, so we have to unapply that to have things working.
Since the processing logic was directly converting the image to raw pixel data in
RGBA8
format, premultiplication becomes a very lossy process as the alpha component approaches zero. In other words, a pixel of(79, 79, 79, 4)
when premultiplied becomes ~(1, 1, 1, 4)
, unapplying on the result yields(64, 64, 64, 4)
, which is off from the original by 15 degrees.Therefore, I've rewritten the logic to render in floating-point format, giving enough precision to handle the case above. I'm not 100% sure about the performance implications of this but I would like to hope it's far less than loading the image through ImageSharp.