Premultiplied alpha not handled properly

[wkjarosz]

HDRView currently uses a straight alpha representation internally for it's entire pipeline. This means that OpenEXR files, which according to spec always have premultiplied alpha, are interpreted/displayed incorrectly.

Handling this correctly would likely be a major change, so I am still evaluating the best way to approach it. Converting (if necessary) all images (like PNGs) to premultiplied upon load and switching the entire display pipeline to assume premultiplied seems like a reasonable choice [caveat], but I need to figure out how to make things like the "photoshop"-style blend modes, paint brush, and erasure to work as expected.

Another question is how the color picker should work. As far as I understand, color selector UIs for paint brushes typically use a straight alpha interpretation, so how should this be handled if the internal representation is premultiplied? Convert the color picker's straight alpha to a premultiplied alpha when painting? This would work, and I think is how a user would expect things to work when picking e.g RGBA=(1,0,0,0.5). But it would never allow painting emissive pixels. Another option is to add a checkbox to the color picker whether the user is specifying straight or premultiplied alpha.

[caveat] Still not clear on how to properly preserve edge cases for straight-alpha PNG files. If we take a PNG with alpha 0 and premultiply all RGB for our internal representation, then we loose the color information upon saving again.