On 4/15/06, Jon A. Cruz <jon@...> 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 t=
> 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 tweaki=
> 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 enti=
> 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.
Inkscape. Draw Freely.