On 4/15/06, Jon A. Cruz <jon@...18...> wrote:
LittleCMS lets you do much of that color changing, and if the source and destination buffer types are the same, you can even do it in-place.
But I'm not working on buffers - unless my selection happens to include a bitmap. Most of the time I need to transform single color points (fills, gradient stops etc).
cmsDoTransform( transf, currLine, currLine, imagewidth );
And even apart from that, I know the formulas I need, they are pretty simple. Why would I want the trouble of creating a profile that implements these formulas and then apply the profile, if I can just apply the formulas directly?
Also... if you only want to change a given RGB color, then you just use that as a tiny "buffer" and change a single color. I've done that in code also.
Why on Earth?
However... if you need to change the actual source values of fills and gradients and such of items, then using LittleCMS is the best solution if those happen to have icc-color() set on them (which is getting added now).
Why is this a best solution? I work in sRGB. I convert one sRGB color to another. I don't want to even think about any kinds of profiles applied on top of my drawing. Let them do their job (prepare my image for printing), and please let me do mine (be creative with colors). I don't see why these two areas need to ever touch each other.
So for that point, the question is whether or not you need to change the paint specifications on the SVG items themselves, rather than only tweaking placed bitmap images.
Of course what I need is universal vector color adjuster, as I explained in that thread. I'm not interested in bitmap-only tweaks.
If it's the former, then I think you'd *have* to use LittleCMS to do those changes, otherwise you'll have to recreate the entire sourcebase for dealing with colorspaces other than sRGB.
I still don't see why. Just as we don't need no CMS for adjusting the HSL of a single object in Fill&Stroke now, we won't need it for my adjuster either. The only difference between them is that one affects single object and the other multiple objects!
Just ponder what "desaturate" might mean for an SVG drawing targeting a specific CMYK printer.
I must admit I don't understand this kind of reasoning. "Desaturate" has a perfectly intuitive meaning for everyone, and I don't see how the fact that I'm going to print it on some kind of printer might ever affect that meaning. Desaturate is a _creative_ thing, see? I don't want no stinkin' CMYK interfering with my creative choices. If that particular printer can't print my design adequately, it's a problem with the printer, not with my image.
Of course I'm exaggerating a bit for the sake of argument. But you get the idea. I don't like the sound of a narrow-purpose, hardware-tied code, with its CMYKish mindset, encroaching onto the land of pure vector creativity. If SVG forces this kind of issues on us (instead of letting the operating system do all of this CMYK stuff at low level), let's use littleCMS, but only when we must.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org