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

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.

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.

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.

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.

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...

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.

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.