W3C Workshop
on Wide Color Gamut
and High Dynamic Range
for the Web

Hello, my name is Mitra Kazakov.

I'm a developer in Krita Foundation.

In this video, I would like to look at the HDR technology from the side of all the content artists or at least how we see it and use it in Krita.

As you might know, Krita is a painting application targeted for artists who do concept art, texture, and matte painting.

Krita supported HDR workflow for at least a decade, it was mostly used by 3D artists who wanted to paint the textures or matte painting over shots, that is they created the scene in 3D application like Blender, then exported it into Krita using EXR file format.

Then they pass it back to 3D pipeline, important point here was that Krita was never the final step of the HDR pipeline.

The assets were supposed to be returned back where they were converted into SDR range at the final color grade step which was usually done in compositing software.

And with appearance of HDR displays, the situation has changed, now Krita should not only prepare assets for the HDR based pipeline but it should also create HDR content that is the final result itself.

It was implemented in Krita in 2019, so now the user can see the HDR image directly on screen and paint on it.

So first about how to prepare HDR content in Krita.

If you have an HDR Capable display, then creating such content is very easy.

You can just use a special HDR Capable color selector.

You select the desired nits range, the desired brightness range, pick any color and paint with it on the canvas.

The interesting thing here is that in HDR mode, when you paint on the canvas, you don't paint with color, but you paint with light.

It looks very interesting and it mostly looks like that special photography style called freeze light, when you set your camera to very long exposure like several minutes and highlight the necessary objects with a hand torch.

So if you have an HDR screen, that's very easy but if you have only an SDR screen it is also possible to create HDR content.

And that is basically what people did for ages in 3D pipeline.

In Krita, we use OpenColorIO technology for this purpose.

OpenColorIO is a technology used on studios.

It is basically, a set of standardized config files which are distributed to every workstation in the studio.

So every artist working in every software can apply the same transfer functions to see HDR assets on the displays in the same way.

It might be very hmm, people might dislike this comparison but, basically OpenColorIO does the same thing in HDR world that ICC does in legacy as SDR would.

They are very different of course but very roughly we can call them this way.

So if you have SDR screen and you want to work with HDR, you just open OpenColorIO docker and decrease the exposure of the image.

In this case, the full HDR range is compressed into smaller range to feed the SDR range of the display.

At the same time, the color selectors, like on the next slide, we have a triangular color selector which is legacy color selector.

So it doesn't support the HDR.

This color selector is mapped to the full SDR range of the display.

In some terms, it may be called that the image is scene-referred and the color selectors are, the legacy color selectors are display-referred.

So if you have like, like on this image, the image that, the exposure of the image is set to three, minus 3.5.

And if I select white color in the legacy color selector, I will basically paint with a light source of 1,000 nits.

In Krita, I will see it as just white color, but if I open this image on an HDR capable display it will be very bright spot of 1,000 nits.

On the next slide.

I try to do some illustration of this compression.

I'm not sure if it helps actually, but that's the same what I said, the full range of the image is compressed.

So and the range of the legacy sliders is not compressed.

So they start to map to the entire HDR range.

Of course, there are some drawbacks in this approach.

When the legacy slider, legacy color selectors are display referred, it means that sometimes we have to convert the color into the display color space which might be more narrow than the HDR color space.

But in some circumstances this is perfectly acceptable.

For example, you may have a primarily SDR image, which you want, which is where you finished, and you want to adapt it to HDR environment, like add some highlights or speculars, or make the sun brighter.

In this case, you just open this on a normal SDR display, decrease exposure, and paint with normal colors, and that's it.

And you don't really care that your sun will belong to Rec 709 color space instead of Rec 2020 color space.

The image itself, the data in the image is not affected only the colors you highlight with is affected.

But anyway, all those drawbacks do not exist if you have HDR display and use HDR color selectors.

The next point I would like to talk about is exporting HDR content.

Traditionally, Krita used open EXR file format for exporting (and importing, as well).

This is basically a standard for restore data exchange in 3D software world.

Mostly, I think majority of 3D packages support that, it is a good format for using in-house in studios for intermediate work but this is not very good format for distributing the work.

The problem is that the file format, EXR file format does not support any colorspace tagging.

It just stores, raw pixel data in a lossless way.

And the user is expected to know exactly what this data is and how to deal with that.

It is possible to write some extensions via metadata, but there is no standard for it.

That is why it is not good for distributing the work.

That's why in 2019, Krita started to support HDR extension for PNG file format.

There is a specification for it by World Wide Web Consortium, you can find a link at the bottom of the slide.

This is a normal PNG file, 16 bit PNG file encoded with perceptual quantifier the only difference to a normal file is that its iCCP chunk contains a special fixed string defined by the standard.

If application supports HDR, it should recognize this string and treat the file differently.

If it is a legacy application and it knows nothing about HDR, then there is a special ICC profile attached to this file.

You cannot represent perceptual quantizer with ICC profile.

So this is just a fallback profile that should never be used unless you are a legacy application.

It just, doubly compress the entire rate range into the SRGB space.

On the next slide, you can see the difference and the left, the image with just clipped at some area and at the right this image shown within the legacy application with this fallback profile.

So yes, you can see all the data but the image will not look nice.

Next, I would like to talk about two file formats we are working with at the moment, on which support we are working in the moment we're not working on the file formats themselves of course.

It's HEIF and AVIF.

These file formats support HDR and Krita will do support that, I think this patch will land in a couple of weeks and Krita file, Krita 5 will surely have a support of these file formats.

The next, I would like to say just a few words about implementation of HDR display in Krita.

First, it is supported only on Windows because we have to use DirectX for, for that.

That was also a problem because Krita's canvas uses OpenGL for rendering image data.

Therefore, we had to use ANGLE library by Google which converts OpenGL API into DirectX API.

We also had to implement three extensions to this library.

These are standard extensions to EGL protocol but they were not present in ANGLE so we had to implement that.

If you want to know more information about it, check additional information section.

I will put the link to the full article about technical details there.

And finally, I would like to talk about one problem we faced when implementing HDR capabilities in Krita.

That is color proofing, or probably for HDR case, we should call it light proofing.

For example, if I'm an artist and I own a 1000 nits display and I would like to check how my content would look on 400 nits display, or on 600 nits display, right now I cannot do that.

That happens because of the technical, technical problems which are addressed by the standard.

There is a illustration or the next slide.

You might see the red block, which is actually problem.

We, as application, we send data to the DirectX API in Rec 2020 PQ color space.

And the GPU sends this data to to the display in almost the same color space.

The most important thing for us is that the communication between the GPU and the driver or the GPU and the display is very wide range.

It's 10,000 nits.

And the display itself, its controller is free to decide how to convert this wide range of 10,000 nits into the actual brightness range supported by the display, which is usually from 400 nits to 1000 nits.

And we have no control about, we have no control over this transfer function.

So basically we don't know how the display will show our color in comparison.

There is the next slide, I tried to draw how it looks in ICC world.

We have ICC profile, which describes the display for us.

So we know what color it will be if we send specific RGB value to the display.

Of course, it also has some, its own drawbacks but basically it allows us to do color proofing.

And there is nothing like that in HDR world.

I'm not really sure that this problem can be solved or at least it cannot solved easily because I understand that the display controller is allowed to highlight some areas on the, on the screen or dim some other areas on the screen, on the screen.

And so basically transfer function among the whole surface of the screen may be not uniform but I think at least it will be very useful for the content creators to have at least some, at least some solution to address this problem.

At least in some way probably not ideal, but some approximation.

Well, that was everything I wanted to tell, if you have any questions or comments or if you have some ideas how to solve this color proofing problem, please add your comments or write to me directly, there is an email in the first slide.

And thank you very much for listening.

Have a good day.