So, after living on Boudewijn and Irina’s pantry for a week, we now have Soft Proofing working:
Partially, this week was spent on me recuperating from my exam-week and the Krita Kickstarter. After that, delving into the jungle that is Pigment, which is Krita’s colour management library, for abstracting the caching and handling of colour managed colours. It’s a bit of a jungle of templates and class inheritance. This part is where living at my mentor for a week was helpful, as communicating some of the problems I bumped into(mostly confusing class names and how to avoid having to rewrite the caching graph), would’ve been too difficult to do over IRC.
The second part was setting the toggles via the canvas, taking data from the image and the view and giving that to the openGL textures, as well as caching the transform in pigment.
We can now softproof to a single cmyk colour space, and the softproofing can be done per view, meaning that you can have two views of the same image open, one set to do softproofing. The idea behind this is that softproofing isn’t a destructive transform, when you are modifying your image to look good in the softproof,you are editing the original. So I figured it would be nice to get the softproof working in a separate view, so you can see how the modifications you make influence both images.
Gamut alarms work as well, what is missing is setting the configuration, and saving/loading the configuration from the image file. This latter is important because if you are a professional illustrator, it might be that you need to juggle several projects with several CMYK profiles associated. Rather than to force the user to save the icc profile they optimised the image for right next to the file, so that they may remember which profile they optimised to, it might be better to just save the profile and the whole configuration.
On Thursday, I was running into architecture trouble, and as Boudewijn was away, I decided to do something different: Implement OCIO looks.
OCIO looks are what colour management people call ‘aesthetic transforms’. In other words: They’re a manipulation of the image that serves to make it prettier! In my case, I wanted to use it to see if I could get colour blindness filters to work via it. At the same time, this feature can be used by people who have a custom OCIO config, where such transforms can be stored. The modified advanced colour selector here is a freebie we get from the earlier work to have them be manipulated by OCIO for Scene-reffered/HDR colour picking. But again, we can have the filter happen in a different view than the original.
I am not 100% sure about the implementation, as the OCIO api docs are very confusing about how to use looks, so this right now uses ‘overrides’ but I am not sure if using something called ‘overrides’ that is remarked on being a ‘fallback’ is the right way to go.
Similarly, I will need to still decipher those papers I looked at, and find a good way to redistribute the OCIO config, as Krita has no default one by itself.
After all this is done, I’ll be working on a good core colour selector for Krita, that we can use for filters, but I am satisfied with the progress up till now.
