Oh hey that's a good idea! Probably calculating the lightness, hue and chroma for the source CMYK color is going to be faster than searching for it in the DB. Also I'm using the DB because it provides mappings for all the CMYK colors. If I just work with CIECAM02, and run the math in reverse to get a CMYK color, there's no guarantee that the numbers that come out will actually be valid CMYK values: they might be greater than 100 or less than 0 and either case is not a valid CMYK value. This happens because CIECAM02 tries to model all the colors that exist in the visible spectrum and CMYK only represents all the colors which can be made by mixing cyan, magenta, yellow and black inks and thus there are fewer colors in CMYK than CIECAM02. Still I might be able to try "looking around" in the case that the computer calculates invalid CMYK and that might be faster than using the DB.
Yeah, you could maybe still create all the CIECAM02 values related to your input (within some granularity limit) and discard those producing values outside the CMYK gamut.
Or you can try "gamut mapping", on them: this is through algorithms to get the closest "narrow gamut color" in CMYK from a color in a "wider gamut color space" like CIECAM02.
Search for "gamut mapping algorithms" or "gamut compression".
Thanks! It turns out "gamut mapping" was the special keyword I needed to be searching for. Immediately I was able to find the coloraide library which does everything I need it to: convert colors from CMYK to CAM16-UCS, adjust the CAM16-UCS value by some perceptual attribute, map the new CAM16-UCS value back to CMYK and adjust it again if the new value does not fit in the CMYK gamut.
Comments
Oh hey that's a good idea! Probably calculating the lightness, hue and chroma for the source CMYK color is going to be faster than searching for it in the DB. Also I'm using the DB because it provides mappings for all the CMYK colors. If I just work with CIECAM02, and run the math in reverse to get a CMYK color, there's no guarantee that the numbers that come out will actually be valid CMYK values: they might be greater than 100 or less than 0 and either case is not a valid CMYK value. This happens because CIECAM02 tries to model all the colors that exist in the visible spectrum and CMYK only represents all the colors which can be made by mixing cyan, magenta, yellow and black inks and thus there are fewer colors in CMYK than CIECAM02. Still I might be able to try "looking around" in the case that the computer calculates invalid CMYK and that might be faster than using the DB.
Yeah, you could maybe still create all the CIECAM02 values related to your input (within some granularity limit) and discard those producing values outside the CMYK gamut.
Or you can try "gamut mapping", on them: this is through algorithms to get the closest "narrow gamut color" in CMYK from a color in a "wider gamut color space" like CIECAM02.
Search for "gamut mapping algorithms" or "gamut compression".
Thanks! It turns out "gamut mapping" was the special keyword I needed to be searching for. Immediately I was able to find the coloraide library which does everything I need it to: convert colors from CMYK to CAM16-UCS, adjust the CAM16-UCS value by some perceptual attribute, map the new CAM16-UCS value back to CMYK and adjust it again if the new value does not fit in the CMYK gamut.
https://facelessuser.github.io/coloraide