You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
* internal representation now uses premultiplied alpha, addressing most of issue #107
* the image view now properly displays premultiplied alpha images, including "emissive" pixels with A < RGB
* some GUI elements still need to be updated to consider premultipled alpha colors (e.g. HDR color selector widget, eyedropper overlay)
* the image view now also displays things a bit differently when looking at individual channels
* when viewing the RGB channel, the alpha is used as transparency
* when viewing just R, G, B or A individually, the channel content is displayed without any transparency (to be able to see the actual pixel values even where A = 0)
* added a gradient tool which can draw linear, radial, and angular gradients
* the background of the image view can be customized among a few fixed options, or set to a custom color
* some refactoring, renaming, and snake_casing
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.
The text was updated successfully, but these errors were encountered: