Ask HN: Where do I go to talk to people about color matching? | Hacker News Reader

Ask HN: Where do I go to talk to people about color matching?

So at work I wrote some python to match colors in photoshop. Basically it takes a CMYK color, an attribute (lightness, hue, chroma) a direction (-1 or +1) and a scale factor between 0 and 1 and it picks a certain number of colors from a database for which only that attribute is modified. The good news is that it works, but there are two problems: 1) it's really slow taking around 2-3 minutes and 2) it produces a lot of garbage which right now I work around by just increasing the number of colors for it to pick, which does not make it go slower. I figure it's time to ask for help. Where do I go to talk to people about this? Is there like an IRC channel or a forum for graphic design? I know Onyx Graphics has a product that does a similar thing and it's a lot smaller and faster than my solution but it doesn't work in every case.

View on HN

How does "it works" go together with "it produces a lot of garbage"?

I understand that it also produces some correct (or correct looking) results, but the code sounds like it has lots of false positives from what you're saying, so it's probably not the correct algorithm.

As for the time it takes, it doesn't sound like something that should take so much time, but not sure how it's in the code.

I'd look for these things:

Is the DB storing the color info as CMYK? If so, maybe go through your existing table and add another table or extra columns with pre-computed columns for lightness, hue and chroma.

Then you can get a CMYK value as input, translate it to lightness, hue and chroma, and select only the rows where the query attribute (e.g. lightness) is different to the one you got. You can even apply the scale factor in the SQL query directly (e.g.

  WHERE 
  CASE 
    WHEN $direction = 1 THEN lightness > $lightness + ($scale_ratio * $lightness)
    ELSE lightness < $lightness - ($scale_ratio * $lightness)
  END

Is the DB the slow part? Do you even need the DB? Perhaps you can loop through the colors (creating each in memory), and if you need to lookup some unrelated attribute like an assigned per-row id, you could query the DB for that after you found the N "matching" colors, and only for those.

Can you express the distance algorithm in SQL (or a PL/SQL function)? Is it faster?

A row in the DB has 7 columns: c,m,y,k,lightness,chroma,hue. I used the colorspacious python library to create the DB which took about 24 hours. I wanted to map all the colors in the CMYK gamut (about 10^8) over to the CIECAM02 model but I changed some of the math to make it populate the database faster and that DID introduce some error but the errors were on the order of 10^-6 and I don't know enough about CIECAM02 to tell if that's significant or not. Also I don't really have the time or the compute resources to test 10^8 colors. But I would make the DB again if I had some assurances that the math I was using was accurate and also I need to figure out how to parrallelize python because that would speed things up significantly.

I think a row in the DB is 7 floats, it should be 4 ints (c,m,y,k) and 3 floats (lightness, chroma, hue) but I don't know how to fix 10^8 rows in a reasonable amount of time.

The reason it takes so long is because first it searches for the source CMYK color. Then because of how floats work I can't just tell it to pick all the colors with the same hue, I have to specify some delta and pick all the colors where the absolute value of the hue minus the hue of the source color is less than the delta. That's the part that takes a lot of time but I can't really think of a way to speed it up beside changing the data types of the columns.

>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.

https://facelessuser.github.io/coloraide

What happens if there is no match in the database?

My guess is that you are replacing each pixel in an image with the "best" color in the database. Is this correct? Can you post a good and a bad sample image?

At the moment, I think the program just crashes if there's no match in the DB. It should be impossible for the initial lookup to fail because the DB has a row for every possible CMYK color but in the second lookup has crashed the program because for example it'll narrow the options down to 10 colors and I'll ask it to select 11 colors. I have actually done something similar before for testing purposes and the program just crashed.

Also, everything is on my computer at work but I can share everything when I go back on Monday (in 31 hours), the code, the DB, some sample images it made.

Because I work in a textile mill we make colors by printing images on paper with a CMYK process and then we use heat to sublimate the ink off of the paper onto the textile. In this process there are so many variables affecting the color of the ink that it's basically a black box where CMYK numbers go in and very often the wrong color comes out. The only way to match colors is to pick a lot of them, and see which one is the most accurate after transfer and use that one. The process of picking those colors is what I'm working on.

I'm still not sure what you want to do. Is it "posterize" or "dither" or something else? Why do you want to pick exactly 10 colors?

Posterize: https://docs.gimp.org/2.10/en/gimp-filter-posterize.html https://www.google.com/search?q=Posterize&tbm=isch Last year my wife wanted to posterize some photos to make street graffiti. She tried like 5 online and offline versions and got bad results. I tried a few more and also got bad results. So she pick the best one and made a lot of manual corrections. It looks like a hard problem.

Dither: https://docs.gimp.org/2.10/en/gimp-filter-dither.html https://www.google.com/search?q=Dither&tbm=isch I used this a long time ago and got good results, but it was a long time ago so I may be misremembering.

---

A long time ago someone told me about how to calibrate a printer system . IIRC yuo get an image in the computer and a printer version with a bunch of colors. Then you print the image and scan the original and the new version. Then the software compare both, and make some corrections. Now you repeat the process a few times, until the image you print is equal to the image you got initially. I'm not sure if the systems assumes to many details that are specific for the printer.

---

IIUC one of the problems is that the CMYK in the computer is very different from the CMYK you get in the fabric. Perhaps you can print in paper using normal ink a version of https://www.google.com/search?q=color+tv+calibration&tbm=isc... and then print the same image in the fabric using sublimation. Then scan both and compare them. Perhaps make a custom image with a lot of small squares to cover all the CMYK space, like

{00, 40, 80, C0, FF} x {00, 40, 80, C0, FF} x {00, 40, 80, C0, FF} x {00, 40, 80, C0, FF}

because I remember that FFFFFF00 is a horrible dark brown color and 000000FF is a nice black color, but TV doesn't care about that detail.

Perhaps print multiple images, to sample more points in the the CYMK space. As many as possible without making everyone hate you.

So now you have two functions, F and G:

F(CMYK_computer) = CMYK_paper

G(CMYK_computer) = CMYK_fabic

and you want a third function H that convert the initial CMYK color into a fake CMYK color that printed in the fabric is equal to the result of the initial one in paper.

H(CMYK_computer) = CMYK_fake

G(CMYK_fake) = CMYK_paper

G(H(CMYK_computer) = F(CMYK_computer)

so H is defined as

H(CMYK_computer)=invG(F(CMYK_computer))

Calculating the inverse of G may be difficult, but my guess is that interpolation or machine learning should solve the problem. Also, the inverse of G may not be defined in some cases, so you should add some clipping to avoid raising an error.

It looks like an interesting problem (not easy, but not impossible).

The database is 8 gigabytes so it will take a minute to upload, but I put one of the output images on imgur:

https://imgur.com/a/oMtVDYO

The source color is in the top left corner and below it are colors darker than it ordered by lightness descending from top left to bottom right. The hue of all the colors is supposed to be similar but there is so much variance in the hue that really only 20% of these colors are usable.

This image would be printed out and if one of the colors is more accurate after printing, then the source color in the original art would be replaced with that other more accurate color.

I think you have too much samples in your databas. I think it's better to sample a much smaller range like 4x4x4x4 in the CYMK space, and interpolate the other values. (Perhaps 4x4x4x4 is too low, and you should use 16x16x16x16, or sample using an uneven grid because the easy grid will probably be full of dark brown versions.)

Anyway, it looks like someone else gave a better hint and you were able to solve your problem :) https://news.ycombinator.com/item?id=37643761

---

If some day you have some free time, it would be nice to read a blog post explaining the problem and the solution. If you add some photos it could get some traction here (or not, nobody is sure what gets traction).

Reply on news.ycombinator.com