Re: null conversion
Re: null conversion
- Subject: Re: null conversion
- From: Graeme Gill <email@hidden>
- Date: Sat, 26 Nov 2005 16:56:47 +1100
Michael Fox Photography News Account wrote:
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