Summary: | Colour adjustment filter layers clamp HDR images | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | rebuilderster |
Component: | Filter Layers | Assignee: | Krita Bugs <krita-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | alexbal2666, amy, eneeen, griffinvalley, manuel.snudl.zeidler |
Priority: | NOR | ||
Version: | 2.9.8 | ||
Target Milestone: | --- | ||
Platform: | Mint (Ubuntu based) | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Bug Depends on: | |||
Bug Blocks: | 463651 |
Description
rebuilderster
2015-11-22 12:17:35 UTC
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. *** |