Profiling Colorbyte and the Colorgetter
Profiling Colorbyte and the Colorgetter
- Subject: Profiling Colorbyte and the Colorgetter
- From: Nick Wheeler <email@hidden>
- Date: Mon, 04 Feb 2002 11:08:22 -0500
John:
I have just recently been observing some good results with scanner profiles
created using Don Hutcheson's scanner target along with "the scanner
application formerly know as Colorbyte" and Gretag's Profilemaker Pro on two
Colorgetters here in Massachusetts. I was able to accomplish this by
creating an RGB scan of Don's target that returned LAB numbers in Photoshop
that were very close to Don's measured values.
It is an iterative process. Scan Don's target with all colorsync stuff
turned off in your app, then use Profilemaker to create a profile from the
resultant target data file so I could get Lab numbers in Photoshop.
Obviously the first attempt was pretty far off, but a few passes and I was
able to create a target scan that returned Lab numbers with it's associated
profile applied in Photoshop that were very close to the numbers in Don's
measurement file.
Once the proper scanner settings were in place this left very little "work"
for the final scanner profile to do when drawing to the screen, just some
minor hue rotation and saturation adjustments. The results when converting
to an RGB workingspace are the best I have seen to date by a significant
order of magnitude. Before doing some final tweaking I thought it would be
nice to know how your application is actually returning the raw RGB numbers
I am seeing.
If I turn all the colorsync stuff off and leave LAB correction turned off is
the data I ask for in "tone and curves" exactly what I will get in the raw
TIFF file as RGB numbers. I assume it is and I am actually able to "tell"
the Colorgetter what I want for RGB values of a given scanner target color
patch without any further intervention. Can we call it setting the exposure?
Sort of like an operator at the controls of the "Scan" side of an old
Crosfield scanner.
What is the data the Colorgetter is sending to your app anyway. RGB Density.
Or is it actually a three channel file. Or a four channel file you have to
strip to get 3 channels?
Is this data being referenced to CIELAB or the monitor or am I in control in
the curves window. How is the data being displayed on the monitor? How is
the application able to display the data in both RGB and LAB without any
reference color space defined (obviously there is some type of assumed
defaults). And why is the L* axis defined as 0-255 in your app?
BTW I feel that this is what a basic scanner app should do, manage cropping,
file name and size, and return three channel TIFF values (an exposure? to
make a photo analogy) I can control and that's it. Congratulations on a
great application. Leave colorsync transforms, editing etc to other modules
in the workflow. At this point I also feel that the notion that the scanner
"exposure" can be left in some raw default state which a colorsync profile
can then correct will return only mediocre results with the
Colorgetter/Colorbyte, maybe other combinations as well.
Thank you,
Nick Wheeler