Hello.

I'm trying to work in float 16bit and 32bit per channel in Krita, but the color channels are limited to the range [0.0 to 1.0]

I have used other programs to generate/view HDR and OpenEXR files, and they allow to have bits with some channels with values above, for example, 1.0

Therefore I have managed to change the source code to get rid of this limitation in the "Specific Color" docker. For your reference, if you are interested, I have modified the following file:

krita/plugins/extensions/dockers/specificcolorselector/kis_color_input.cc

The modification is to replace the following lines:
QWidget* KisFloatColorInput::createInput()
{
m_dblNumInput = new KDoubleNumInput(this);
m_dblNumInput->setMinimum(0.0);
m_dblNumInput->setMaximum(1.0);

by the next ones, so the new allowed range is [-10000.0 to +10000.0] for example

QWidget* KisFloatColorInput::createInput()
{
m_dblNumInput = new KDoubleNumInput(this);
m_dblNumInput->setMinimum(-10000.0);
m_dblNumInput->setMaximum(10000.0);

It worked for me, allowing me to manually input values for channels from -10000 to +10000 manually in the "Specific Color" docker, and so far I'm being able to use the EXR files generated with Krita with those values in other programs like Blender+Cycles, etc.

Please, give me your thoughts. Thanks and best regards!

Good point, I'll integrate your suggestion this weekend. Thanks!

Thank you!!

If you just modify the range like that it will certainly break some stuff.

Why? I don;t think there's anything in krita that will get shocked by float colors being any number -- even outside 0-1.0. On the other hand, it might be worth it to let users determine their preferred range in the settings.

Colorspace math hardcodes the range to 0.0-1.0. If suddenly the UI starts to put in other values like that I doubt it would still be correct.

Well, I'm not sure about that... Given that it worked for David, and having values outside that range is common practice for HDR painting, I don't think it's a problem. We clamp hdr alpha to 0..1 -- but not colors, afaic.

Thanks to both, this is an interesting discussion.

Just to make my point a bit more clear, I work with Blender+Cycles or Blender+LuxRender and I usually export the rendered image to a high dynamic range format like an EXR file.

If you use strong lights in the blender model, many times you get big channel values in the resulting EXR file (something like R=6.0, G=5.8, B=5.4, etc)

When you use Krita Color Picker, it gives you the right color taken from the selected pixel, but there is no way to modify any of the channels with any known Krita color selection tool. The closest tool I found was the Specific Color tool, but as soon as I entered any value (for example if I tried to change the color to R=5.0, G=5.0, B=5.0), the Specific Color tool "clamped" the values to 1.0, 1.0, 1.0, which was not adequate for me. Therefore, I found the code causing the clamp and I got rid of it in my local installation.

There are other examples of undesired clamping, for example in gradients. Even if you select a color with high values in channels (for example, 5.0), after I apply the gradient the extreme is only at 1.0 or 2.0 depending on the color space selected.

I don't know if there may be any undesireable effect on removing or widening that "clamp", but I have seen no problems so far and I've seen already EXR files coming from other software programs with values outside [0.0-1.0], so I guess they are valid somehow in the HDR float files.

In any case, a possible workaround might be to create an option (active by default) to enforce the clamp to 0.0-1.0 and, if the user deactivates it to get "freedom", a messagebox may inform the user that using values outside 0.0-1.0 may cause unexpected results while applying filters or other computational processes... just an idea.

In any case, thanks again and best regards!

One thing I was wondering about -- are there any "customary" ranges for different kinds of work? I was thinking of having the range as an option in either the settings dialog or the lut docker.

I've tried to look for any such information but I could not find anything yet.

In any case, it's completely normal to work with HDR, EXR, etc outside the range 0.0-1.0. Even some color spaces like scRGB require at least from -0.5 to aprox. 7.5 for compatibility with other color spaces.

In my opinion, if the math for filters, etc, are correct, they should be able to handle any floating point value even outside 0.0-1.0 range. The only important limitation is to respect the file format limitations while storing data in the file.

For example, when using floating point 16 (half precission) the range has to be limited aprox. -60000 to +60000 due to the inherent limitations of 16 bit float (although this may depend on the specific representation of the 16bit float in that particular file format). The limit is much wider for 32 bit floats of course.

That's why I suggested the range -10000 to +10000. It's just an opinion not based in any demonstrable fact or information, but I believe it should fit in any float 16bit file format and still have more than enough room for any "normal" HDR image. +10000 would be so bright that probably no real or rendered image would reach that value. On the other side, allowing up to -10000 may allow to create nice strange effects when using such HDR images for textures in, for example, blender.

In any case, it's only my opinion of course and I'm just a beginner in these matters...

Thanks again and best regards!

Wonder for what you are using Krita here. With values above 1.0 you don't see anything as it out of the display range, so I would assume that it's not painting.

Well, whether it's visible or not depends on the exposure. It's quite valid to want to add extra detail to extreme highlights for film purposes, as far as I understand.

If you could dynamically change the exposure it could be quite useful even for painting. Like painting the dark parts with high exposure and the bright parts with low exposure. The color wheels should adapt to the exposure too, though.

You use the lut docker in 2.6 and git master to set exposure: it's not perfect, though (problems with the shader), and the interaction with the color selectors is a bit broken at the moment.

Just to clarify, I use values higher than 1.0 for very bright parts of the painting. I use that to create textures for 3D renders like Cycles, for example.

Also, the whole point of HDR images is not to depend on the hardware limitations. For example, a display do not show any color brighter than white 255,255,255. However, the beauty of HDR images is that they don't have that limitation at all. In theory, in the future we may have real HDR displays that show the entire range (or a big part of it) of the HDR images, for example seeing a picture of a sunny beach where the sun almost really shines with a very strong light, not equal but similar to the real sun or a very bright light. It's not possible now, we can only use exposure to show parts of the HDR images at a time, but the image in itself is not limited.

Thank you for the interesting discussion. Best regards.