RE: null conversion
RE: null conversion
- Subject: RE: null conversion
- From: "Michael Fox Photography News Account" <email@hidden>
- Date: Sat, 26 Nov 2005 20:03:27 -0800
- Organization: Michael Fox Photography
Thanks, Graeme. That's very clear.
> -----Original Message-----
>
> >>Also consider that if you are dealing with CMYK profiles, then
> processing
> >>through
> >>the profiles will almost certainly be different from not, because the
> >>former
> >>causes the black to be regenerated, while the latter leaves the black
> >>levels
> >>unchanged. In some situations it might be desirable to do such a null-
> >>transform
> >>to enforce total ink limit on a file.
> >
> >
> > Hmmm. Can you describe such a situation?
>
> I'm not claiming it's likely, but theoretically a printer could
> receive a CMYK file that is in the colorspace of their
> press, but they are unhappy with the black generation curve
> or the TAC. One way of addressing this might be to run the
> file through their profile both as source and destination,
> thereby regenerating the black, and enforcing the TAC of
> their profile.
>
> > If it helps, in my case, yes the printer profile is a CMYK profile. So,
> in
> > the scenario above, the file is converted from the working space to the
> > printer profile, then saved. At that point, it should have the
> > desired/proper black levels. Later, the file is sent to the RIP. In
> what
> > situation would processing back to the PCS and back again to the output
> > space ever be a good thing?
>
> I wasn't passing a comment on whether this is a "good thing" or not,
> just that there are some technical reasons why identifying "same profile"
> can be difficult, and there are some scenarios where converting through
> the same profiles as source and destination may be desirable.
>
> If embedding the expected destination profile in a file is
> the workflow/systems mechanism for marking a file as "don't
> color process", then clearly color processing anyway is a "bad thing",
> and the RIP is being unhelpful.
>
> This mechanism (as I think I've pointed out a few times) has some
> drawbacks. It can be fragile (because of the profile matching issues
> I mentioned previously), and and it could occasionally be undesirable (if
> color processing is actually desirable, for reasons I outlined above.)
>
> As a mechanism for marking calibration/profiling files for instance, it's
> poor.
> Rather than being able to mark a file "calibration - don't process",
> you've
> got to somehow figure out what the current profile is on the printing
> system
> and embed it in the calibration file every time. You can never have a
> universal
> calibration file, it will always have to be modified to match the state of
> the printing system. This gets especially tricky if the printing system is
> remote.
>
> Alternative mechanisms that cope with these drawbacks are likely to be
> more
> complex, and haven't been standardized in any way (e.g. symbolic psudo-
> profiles
> that mark "calibration" or "characterization" data sets, or logical
> pseudo-profiles
> that will always match the current profile of the nominated device etc.)
>
> Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden