So, during the roadmap discussion we concluded that I’ll be tackling HDR stuff for the coming year. Generally, I’ll be working on the usability side of things, as the deep display pipeline stuff is tackled by DmitryK. I am tracking the majority of the work in this issue. I’m doing this alongside the text tool work, so you will see me switch between the two over the course of the year.
To summarize, Krita’s HDR and scene linear tools are used today by game and VFX studios to prepare textures for 3d rendering. There’s also artists that illustrate in scene linear as it allows for less muddy color mixes at the expense of more ram.
I’ll be working on…
-
UI issues.
- Particularly, in some places we render directly onto the canvas, and we don’t take HDR into account when doing so, which leads to overly bright output. The tool decorations and reference images are both affected by this. I have already fixed this in krita next, as it was distracting me from other bugfixing.
- General polish like the histogram needing to work with floating point, or making the preferences easier to understand.
-
Auto-generating metadata – A big part of what makes HDR different from SDR workflows is that it takes into account the brightness of the screen. Because different screens have different brightness, displaying an HDR image involves a little bit of adjustment (tone mapping), and to do that adjustment correctly, metadata needs to be stored into the image, in particular the maximum brightness. I want to autogenerate this data so it doesn’t need to be typed in manually.
-
Fixing filters to work with HDR, in particular the curves. This will require a full rewrite of the curves, but I’ll be double checking every filter.
There’s basically two ways of approaching this, the simpler one is to take the linear data and put it through PQ curve, and then use that as the basis to do curve-adjustments on, but I worry that this might lead to you, as artist fighting with the PQ curve too much.Instead, what I’d like to do is the more complex approach: Allow setting the range in which the curve applies, and having this auto-filled with the data we get from the auto-generated metadata.
-
Tone mapping/Gamut Mapping filter/Lut Baking of OCIO lut. This one is mostly interesting for generating final SDR images, which might not be interesting in a studio context, but should be very useful for independent artists.
-
Doing more CICP value handling. We typically use ICC profiles everywhere, but in some cases, like for HDR images, CICP are used instead. Now, Krita handles CICP values pretty well already, but I’d like to make it so you can write it to PNG, or recognise it from the ICC profile metadata.
Stuff that is in limbo:
- Saving/Loading gain maps – Gain maps are a new way of saving HDR, which works by taking an SDR and HDR version of the same image, and then calculating the difference between them, and encoding that as an extra bit of image data. This is a very new standard, and I don’t have access to the ISO standard itself, so I can’t even formulate much of a plan to tackle this. However, if you look at the list above, many of it contains the basic building blocks for gainmap support. Meaning that once we have more information on gainmaps, it should be relatively straightforward to implement.
- HDR color selectors – This one is because we’re currently in a technology transition (QtWidgets to QML, new Windows color management, new Linux color management), and we kinda need to wait around till we have a clear idea of how we’re going to display a HDR color selector without getting a ton of bugs and crashes, which is what we’re getting right now.
Updates
- UI fixes update.
Anyway, feel free to ask questions, comment on the plans, or talk about your workflow and what you’re missing from it.
