Some definitions: sRGB= "monitor" colorspace and so mainstream output colorspace (but "bad" 2.2 gamma curve to adapt color spectre width to small 8bit range...) scRGB= example of linear RGB colorspace. linear colorspace= "perfect" color encoding with a linear "1" gamma curve exploiting the wide range of 16bit+ RGB to store equally all parts of the spectre. First I made some test comparing synfig colors with different settings with colors in Krita 16bit float linear scRGB and sRGB (and using a desktop screen color picker to compare resulting output) -Using synfig render engine, with gamma set to 1 and "visually linear color selection" option OFF, I apply a 20,0 36,0 100,0 color (deep blue), screen color picker value is 51 92 255. In Krita, in 16bit float sRGB canvas, I paint a stroke with color 0,20 0,36 1,00 (yes Synfig use 0,0 to 100,0 range while Krita use 0,00 to 1,00 ..), screen color picker value is 51 92 255 too. -If I change Synfig gamma back to 2.2, but keep "visually linear color selection" option OFF, the previous blue object appear a lighter blue, but color value stay the same 20,0 36,0 100,0, and screen color picker value is 123 160 255. Now in Krita 16bit float LINEAR scRGB canvas, I paint a stroke with color 0,20 0,36 1,00 , and screen color picker value is 116 161 252 (=almost equal..) -If I change Synfig gamma back to 2.2, and activate "visually linear color selection" option ON, again the previous blue object appear a lighter blue, but now color value become 48,1 62,9 100, and screen color picker value is 123 160 255. Now in Krita 16bit float sRGB canvas, I paint a stroke with color 0,48 0,63 1,00, screen color picker value is 122 161 255 (=almost equal..) -Another experience is: in Synfig, with default gamma:2,2 and "visually linear color selection" option OFF, create a pure 100% blue object. Then create a pure 100% red object on top of it, with 50% opacity. The resulting mixed color is a perfect 50% blue 50% red, which shows the engine works in a linear color space (which is very good and wanted!..Do the same experience in Krita 16bit float linear scRGB colorspace, you get the same result). then switching the "visually linear color selection option ON, we get the value converted in (more common) sRGB colorspace (73%blue 73%red). These experiences show me that Synfig internally use a linear colorspace (maybe even more linear than the scRGB colorspace..). And then as a "basic color-management" system: -it always converts the output on canvas and render to (8bit) sRGB/gamma2.2 (that is somehow necessary for output/screen color management but shouldn't be hardcoded, see proposal below..). -use the "visually linear color selection" option to get the equivalent color values in sRGB colorspace (easier to share color values from other applications and color html code..). What we have now: -Internal renderer, working on a 16bit float RGB linear colorspace (gamma=1), and then always converting output to gamma:2.2(sRGB) as a minimal hardcoded color management system. -A Gamma setting that change (again?) the gamma of canvas render, to adapt to the screen actual gamma. Doesn't apply on render nor on cairo canvas. -A "visually linear color selection" option that converts the original linear color values to sRGB ones (so we get the actual color values of the canvas/render with gamma 2.2) Please correct me if anything above is wrong. In any case, what we need is: ICC based color management (lcms based) -Internal colorspace (so-called working colorspace) 16 bit float linear RGB is good for this. We'll probably need to provide an .icc color profile defining it to lcms. -Screen colorspace: -Load the screen .icc profile to convert the canvas output from internal colorspace to screen colorspace. If user doesn't have a custom .icc screen profile, use sRGB profile by default. -Imported image colorspace: At import, convert the pictures to internal colorspace (so one can properly import either 8bit sRGB, 16bit sRGB, 16bit linear scRGB or whatever lcms can handle ;) ) -Export colorspace: For the render, convert the output to selected color depth and colorspace profile. (so one can use the full power of the internal renderer and export some 16bit png or some 16bit float .exr if that's supported, in whatever colorspace needed..) Another option is to (also) use OpenColorIO color management system. It's used exclusively in cinema production workflow (in big FX softwares, arrived in Blender recently, and even in Krita is an option plugin too now..) From what I know, most end-user wil use only "simple" .icc based color management system. Only big cinema/FX companies use opencolorIO color management. So I'd say most user may better benefit from icc based color management support, while having also OpenColorIO option may be useful for big studios, which could open some unexpected doors to synfig usage... For this all I can say is check the OCIO website, and the blender and Krita integration of it. http://opencolorio.org/