The reason it takes so long is because first it searches for the source CMYK color
Why does it need to find the source CMYK color in the DB? All the information from that row you either have or you can calculate without hitting the db, no? I mean, since your input is a CMYK color, you can just run the same mapping function on it and get the lightness/chroma/hue values corresponding to it - without touching the database.
Actually, do you even need the db for anything? If I understand correctly, it can go like this:
You are given an input CMYK values, a hue OR lightness OR chroma value and a scale factor,. Say you're given C,M,Y,K, attribute = "lightness" and scale_factor = 0.2 and direction = 1.
(a) convert the CMYK value you were given to H/L/C (running the mapping function).
(b) given a desired "smallest granularity" (e.g. one matching the precision you already have on the db), just run a loop on the H/L/C value you got in (a), incrementing L from its original value up to the max value you can go given the scale factor. For each step you have a new L value, say L' value, and you can combine it with H and C, to get: H, L', C. Convert that back to CMYK using a reverse mapping, and that's one of your answers. Increase L' another step and repeat.
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
Why does it need to find the source CMYK color in the DB? All the information from that row you either have or you can calculate without hitting the db, no? I mean, since your input is a CMYK color, you can just run the same mapping function on it and get the lightness/chroma/hue values corresponding to it - without touching the database.
Actually, do you even need the db for anything? If I understand correctly, it can go like this:
You are given an input CMYK values, a hue OR lightness OR chroma value and a scale factor,. Say you're given C,M,Y,K, attribute = "lightness" and scale_factor = 0.2 and direction = 1.
(a) convert the CMYK value you were given to H/L/C (running the mapping function).
(b) given a desired "smallest granularity" (e.g. one matching the precision you already have on the db), just run a loop on the H/L/C value you got in (a), incrementing L from its original value up to the max value you can go given the scale factor. For each step you have a new L value, say L' value, and you can combine it with H and C, to get: H, L', C. Convert that back to CMYK using a reverse mapping, and that's one of your answers. Increase L' another step and repeat.
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