I have an HDR layer I'm trying to color correct a portion of with a filter mask layer - Color Adjustment in this case. As soon as I make any adjustment to the image with the layer, any values above 1 are clamped off. Filter layers exhibit somewhat different behaviour, although in a different way: As soon as a filter layer is applied over an HDR layer, the superbright portions of the HDR image seem to get remapped to fit within a 0-1 colorspace. So unlike with the filter mask layer I used, the values are not outright clamped to 1, but instead remapped in some fashion. This is a bummer, since being able to work with float images is a huge plus for Krita in my book. Reproducible: Always
Were you by any change using 'lightness'? The lightness curve is known to clamp values, being a LAB lightness curve. Use RGB instead, and delete all nodes from the lightness curve(krita then won't process it), if it still clamps regardless, we have a problem. We should probably add a warning there about clamping.
I was using 'RGBA'. Of course, even if the color adjustments didn't clamp, you'd still have the issue that the UI is designed for non-float images - you can't edit values above 0. For the curves tool in Nuke, for example, this is handled by allowing the user to zoom in and out of the adjustment curve, placing nodes wherever they like. It's a bit finicky there, to be honest. What would really be great would be a new color correction tool duplicating the kinds of tools compositing software generally has - Nuke's grade node has everything you need IMO. Basically if you can adjust Blackpoint, Whitepoint, lift, gain, offset, multiply and gamma you can get quite far. Maybe it's best I write a feature request for this...
by 'values above 0' I meant 'above 1', of course.
I can promote this to a wishbug you know :D Yeah, our OCIO expert also suggested we use the offset/gain system, but somehow that seemed to have slipped past. Anyway, I am confirming this, because even without a filter mask I am able to reproduce the same thing.
*** Bug 375915 has been marked as a duplicate of this bug. ***
*** Bug 444439 has been marked as a duplicate of this bug. ***