Is there any client-side technology able to convert sRGB to CMYK through an ICC color profile?

Asked 16/1, 2011 at 19:52 Answered 8/8, 2011 at 19:59

Is there any technology available in a browser (client-side) able to convert sRGB colors to CMYK and vice versa using a specified ICC color profile?

I'm currently using a hidden Java applet for the conversions (Java has a built-in class for this), but I'm trying to find an alternative, since java applets are slow and outdated.

SVG would be ideal if browsers supported ICC colors in SVG, but no-one does. Flash or Silverlight would also be good, but I can't find anything relevant.

Streamline answered 16/1, 2011 at 19:52 Comment(4)

My suggestion is that you stick with the Java solution, since there is nothing wrong with it. I do not understand why you want to replace it, or why you assume Flash or Silverlight would be better. – Pantechnicon 10/10, 2011 at 2:10

Just performance. The whole interaction of JavaScript and Java applet is a bit slow since it's done many times per second while you fiddle around changing colors. – Streamline 12/10, 2011 at 9:18

If the bottleneck is in passing messages between JavaScript and the applet then I suspect that replacing Java with Flash or Silverlight will make no difference. But if you are currently using ColorSpace.fromCIEXYZ and related methods on individual pixels - Well that is slow. There are faster implementations in Java (which may still be faster than JS or Flash.) – Pantechnicon 13/10, 2011 at 18:59

No, the bottleneck is passing messages from/to JS and the applet. No image manipulation involved, just converting colors. It's for a color picker. – Streamline 14/10, 2011 at 18:40

Am I correct in thinking you want use the ICC profile of the display device?

I am fairly certain there is no facility to determine the display device ICC profile using javascript. At best it may be possible in a third party environment like Flash. The math itself would be no problem.

Of course, this is all really the responsibility of the web browser. Firefox has reasonably good support for colour management. If I'm not mistaken, Microsoft are going to be addressing colour management in IE9.

Lytle answered 27/1, 2011 at 12:14 Comment(4)

Providing the color profile for RGB through a file is fine too. I'm already using a file for CMYK. I don't need it for full images, just particular colors (for a color picker). Flash would be fine, considering I'm using a hidden Java applet now, which is much worse. – Streamline 28/1, 2011 at 2:42

@Lea: That may change things. Can you point me to an example of how you are actually using the applet? Code is also ok. – Addictive 28/1, 2011 at 7:33

coloratum.com It's still a bit buggy and slow as I haven't released it yet. View with a modern browser. – Streamline 28/1, 2011 at 16:19

Nice neat code. I have a professional deadline right now, but I'd like to look at this a bit more later in the week. – Addictive 31/1, 2011 at 12:29

After reading your question, I can't decide if:

a. you're trying to do a soft-proof operation, or

b. you're building a color picker type of app, and you want to provide your users with the names of certain colors (from e.g. pantone or NCS or somesuch) when you display their sRGB-value approximations, or

c. something else entirely.

What is the CMYK space you are concerned with? If you're doing option (a) -- soft proofing -- you can probably fit curves to the LUTs in the CMYK profile, and use them to figure out a 'shortcut' transform that you can then run in the non-ICC-aware javascript runtime you're working in. Most CMYK profiles do their conversion with LUTs, and many use ICC4 NamedColor2 values (which you may know as the value in 'ncl2' ICC tags).

If this is the case, I can point you to some resources on how to do that -- I am doing it myself using SciPy in the python django color-management image-analysis app platform thing I am working on.

If you're doing option (b), and you need color names, you can extract the names you need from your CMYK profile (most likely NamedColor2 values) and build a lookup table, which you can then serialize it to JSON so you can load it in your app. If your app needs to have some knowledge of the display space, you can probably have the user 'calibrate' your app for their display -- feed them some questions that will allow you to calculate the white-point offset (and possibly the RGB XYZ tristimulii) and then maybe create a quickie transform (which could be as simple as one chromatic adaptation transform I am guessing) which you then apply to color values you want to 'color manage' before you display them.

To do the transforms without a CMS system, Bruce Lindbloom's math is a good place to start:

http://www.brucelindbloom.com/

if it's c) I am very curious as to what it is.

is any of that helpful? I can elaborate and/or provide example code, &c, if you supplement your question (I'm doing work in a similar problem-domain, so we could both win on this).

Poulter answered 8/8, 2011 at 19:59 Comment(11)

It's for a color picker. I want the CMYK <-> RGB conversion to be the same most users are accustomed to from Photoshop, when using its default color profile (which is also closer to any printed reality than the naive CMYK<->RGB conversion algorithms that are done without a color profile at all). – Streamline 8/8, 2011 at 21:38

Default, as in US Web Coated SWOP v2? That's my CMYK default working space; I think it's been the default since at least the first "Creative Suite" release. It may have been before that but I didn't use color management before the CS advent so I don't know. – Poulter 9/8, 2011 at 5:1

... I agree that most naive CMYK-to-RGB conversion functions you'll find are horribly blunt instruments but (at risk of sounding pedantic) printed reality, for many people, isn't necessarily SWOP... when printing on inkjet paper, most contemporary inkjets have gamuts that are much closer to sRGB than a CMYK web press, for example. – Poulter 9/8, 2011 at 5:8

... But so, it's a color picker that uses soft-proofing for value conversion (but not for its display in general? – Poulter 9/8, 2011 at 5:9

Even on inkjet, I don't think #0ff is anywhere close CMYK cyan for example. Yes, I mean US Web Coated SWOP v2. As for the color picker, you can see a rough draft here: coloratum.com It's kinda slow, mostly due to the hidden Java Applet. – Streamline 10/8, 2011 at 18:35

@Poulter you seems very good in this arguments. I need to make something like this for a soft-proof system but based only on html(5) without any java or flash plugin. Can you give me some indications? – Crump 3/9, 2013 at 11:1

@Crump you mean to say, your system has to work client-side in a browser, like using only JavaScript to do the math? ... if so, that's a serious 80/20 problem. You can find the algoithic basis of most sRGB-based matrix color transforms online with ease – e.g. brucelindbloom.com/… – but the hard part of a soft-proof app would be writing a parser for the ICC binary format in JavaScript. There are a ton of edge-cases: proprietary tags, common invalid values, etc. Using a server-based environment (e.g. python) puts you ahead of much of that. – Poulter 13/9, 2013 at 9:7

@Poulter For having the wanted color profile on image a server side process can be used to return the image with that profile. I know it is almost impossible to read profiles with javascript and parse them. The modern browsers can actually read incorporated profiles inside an image. The real problem for me is getting with javascript the CMYK real values of a pixel of images. So knowing the color profile of the image in the browser, how can I give to Javascript the correct math instruction (returned from server), in that way that I can calculate the color of the pixel in CMKY? – Crump 13/9, 2013 at 13:31

@Poulter so in final words: knowing (and parsing) the color profiles from server can I deduce (or find) any math calculation to make javascript to return the real color info of a pixel? – Crump 13/9, 2013 at 13:34

@Crump Aha, yes! It's not trivial but it's doable. The hard part is still reading the source ICCs – but the metadata should be enough for you in 98% of cases – and prepare your algorithm(s) for your specific CMYK medium simulation(s). But with a straight-shot conversion, vs. a full soft-proof implementation, your convert code can do an end-run around the CMS math stuff (e.g. gamma un/companding, PCS transforms, screwy reference whites &c). You'll likely need the right GCR function in JS, to get your values right*, and not skimp on float conversion – neither of which rocket-science. Good luck! – Poulter 14/9, 2013 at 15:8

* here's my own GCR hack-job: github.com/fish2000/django-instakit/blob/master/django_instakit/… – based on this StackOverflow ICC-related Q: https://mcmap.net/q/891553/-how-to-create-cmyk-halftone-images-from-a-color-image – Poulter 14/9, 2013 at 15:10

Recommended topics

Hot tags