When I incorporated color management in rawproc, the lure of a library that did all the grunt math in the right order was appealing. I’ve recently considered moving the display transform “in-house” for speed, but when I got the fast_float plugin working the need dissolved…
Right now, the display transform rendering intent is hard-coded relative-colorimetric because I need to re-insert the logic to use the property-specified values in the new display pipeline code. My display pipeline is now on its third rework to make it fast enough while retaining a high-quality color transform. The LCMS fast_float plugin has dithering data types, but I’m finding if I do the color transform float->float, it’s not needed.