El mié, 12-03-2014 a las 02:19 -0400, Liam R E Quin escribió:
> On Tue, 2014-03-11 at 15:45 -0300, Gez wrote:
> Note that the case I mentioned the other day as seeming to be out of
> scope is when you *are* the print shop, and you (sometimes) receive the
> cmyk files, or need to edit them. E.g. remove an impression number from
> the imprint page and then send to imposition... but it seems it's in
> scope and just not there yet.
You're right, there's no free software tool fully capable for that
purpose.
The Separate+ plugin offers a rudimentary solution for that.
The resulting layered composite is far from ideal ("ugly" would be a
better description) but it kind of works.
Krita, although has native CMYK "mode", it doesn't offer the tools (at
least not yet) for that kind of job.
Early binding is still here. I can live without it, but of course that
it wouldn't be the case if I was a print-shop.
I'm curious to know how many print shops would consider using GIMP if it
had native CMYK. I suspect that the majority of people ranting about the
lack of CMYK are mostly designers who know just one way to send stuff to
print shops, not print shops.
> > From a user point of view having all the imported stuff converted
> > automatically to a high quality internal model (high bit depth linear
> > scRGB?) and having per-image output/proof settings seems more
> > straightforward and less error prone than the current mixture of
> > profiles.
>
> Are you going to pay for the extra memory I'll need? I only have 32G and
> already with 2.9 I sometimes am swapping.
No, but I can make you some coffee while you wait :-p
Ok, good point. I missed the segment of users who work with huge scans
completely.
On the other hand, is 8-bit enough for the type of work you do? Although
I'm still using 8 bpc for my work because I do it with GIMP 2.8, I have
a really hard time trying to keep good quality after a few rounds of
edits.
Maybe defaulting to 32bpc is too resource-intensive for a lot of works,
but wouldn't make more sense to have a higher quality default for
editing and keeping 8 bpc just as an output bit depth?
Anyway, rather than bitdepth, my comment was about giving the artists a
framework to create freely without worrying (much) about the constraints
of input/output colorspaces.
It's impossible to have that with 8 bpc. And correct me if I'm wrong,
but I suspect that using proofing filters on non-linear 8bpc carries a
lot of problems and the result can't be completely reliable.
Maybe we can have the flexibility and power just keeping two modes: 16
bit integer for memory-conservative tasks and 32 bit float for high
quality stuff.
Economy of system resources is important, but I'm sure that image
quality is far more important in a image manipulation program.
> > It may or may not be a problem for keeping legacy compatibility, but I
> > can imagine how simplified the UI and common workflows would be (no
> > bit-depth "modes", no assign/convert to profile, no profile-mismatch
> > warnings, simplified CM preferences, etc).
>
> You might not always be able to do round-tripping, because a colour in
> the input image's colour model might be out of gamut for the working
> profile. I don't know how big an issue that would be. Similarly you'd
> end up using colours that wouldn't come out at all right on your output
> device. The warnings are there for a reason...
scRGB exceeds the gamut of the usual profiles, following what I proposed
in the previous message, if you go -for instance- AdobeRGB -> scRGB ->
AdobeRGB with enough precision that shouldn't be a problem and RGB <->
CMYK roundrip is impossible anyway.
I'm not an expert by any means and I might be wrong, but that doesn't
seem to contradict what I said.
And regarding "you'd end up using colours that wouldn't come out at all
right on your output device", that's exactly what soft-proofing (the
topic of this thread) would prevent.
If you have in the workflow I presented, say an AdobeRGB image as input,
it would be converted to scRGB. All its colours would fall inside the
scRGB gamut, so no problem. If you save back to AdobeRGB without
changing anything, color shouldn't change.
If you save to sRGB, colors would have to be converted using a rendering
intent, because the output gamut is smaller. You could soft-proof your
editing against sRGB to see how colors would be affected with the
selected rendering intent.
The good thing about this is that your XCF file would store unmodified
color information, and that would allow to save later to AdobeRGB,
Prophoto or whatever you want.
Now, if you were obligated to convert your imported image to a working
profile (like you are now), and that profile has a smaller gamut than
the original image, your imported image is hopelessly degraded. You're
always tied to the color gamut of your working RGB profile.
Anyway, this is just an idea. It's not a small change and I'm not
suggesting that it has to be done the way I said. I think this is an
interesting topic to discuss since seems more suitable for
non-destructive editing than the current approach.
Gez.
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
