John said:
I am sure that you are correct. However, this is a bizzare concept, don't
you think? A standard which allows you to be non-standard, so to speak
Not really, it is a standard which permits profiles to be tied to
specific products, and that is a strength intended to prevent problems
not cause them. For example, what use would there be in applying a
profile developed for, say, a Canon scanner to be used with a Nikon
scanner? Or worse, apply the profile for a certain monitor or printer to
the Nikon scanner? Not only would it not have any useful purpose, it
would actually cause potential problems if it was permitted since, as
Don frequently points out, the profile changes the data and, without an
inverse profile and to some extent even with one, there is no way back.
The point is that if the profile is correct in its mapping from the
scanner colour space into the abstract normalised output colour space
then there should be no need ever to go back to the original raw data.
Seriously though, even though I accept what you say, it doesn't really
detract from my original point, which is that Nikon CMS is essentially a
'sealed system'.
That is the intention - to exploit the capability of the standard to
permit only profiles intended for the specific unit to be used. You are
correct that the software should enable other profiles to be used,
especially profiles that have been created for particular hardware
setups including the scanner in question. However, it would appear that
Nikonscan is specifically looking for the flag in the file which
identifies the profile as Nikon specific. Obviously, as a scanner
specific application it should do that, otherwise the protection that
the standard permits could not be utilised.
So, the question you should be asking is why the system used to create
the profile in the first place did not include the Nikon specific
identifier in the file when it was created. To blame this on Nikonscan
is a bit like the guy who, having bought a new lock for his front door
having some new keys made and, upon discovering they don't open the
lock, blames the lock manufacturer rather than the key cutter. Why
isn't the key cut with the correct shape to open the lock?
The answer is quite simple really. The software used to create the
profiles *expects* them to be used in image editing applications, such
as Photoshop, not scanner interfaces. In other words, you would have
more success directing your complaints to the writers of the profile
creation software to persuade them to include hardware identifiers in
their profiles so that they can be used on hardware specific drivers
instead of forcing you to use generic image processing packages to
implement something which is clearly hardware specific.
Nikonscan is not only operating correctly but is implementing the locks
and protection measures that were built into the CM standards exactly as
they were intended to be used.
It comes natural to me, if something does not work properly, to investigate
it. If Nikon CMS does a poor job on an image, it could be a duff profile or
it could be a defective CM engine (or a combination of the two). It is
therefore reasonable to want to try Nikon's profile in a different CMS, or
more importantly, to replace the Nikon profile with a custom one.
I have the same urge when things don't work - and also when they do and
I am interested to find out why others appear to have problems with it.
This is what led me to investigate the Nikon profiles in the first place
and compare them with the published open standards.
It is, however, interesting to note that both Don and yourself are
slating NikonScan based on experiences with the LS-30 which, of course,
uses completely different profiles and files from any of the other
scanners where the users are perfectly satisfied with the results. It
would be useful to determine some hard evidence of whether the problem
is the intrinsic limitation of this older scanner or an actual error in
the specific profile itself.
