[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Color Spaces, Part Two of Two (Long!)



Humongous Post, Part II (of two)

5) Device gamuts:  Some printers have much more saturated greens and cyans
than Ektachrome, e.g. see the gamut plotted at Chromix that Steve Upton
referred to.  Also note the recent collaborative effort between Kodak and
Bruce Fraser to create an RGB space called ROMM RGB (the profile is
actually named "rgbMaster.pf" and is available on Kodak's web site, along
with a white paper about it) which was intended not to correlate with the
gamut of any family of color films, rather with a collection of digital
output devices, including, most notably (I gather from looking at the
space) inkjet printers using saturated inksets like Epson's, or Encad's
standard indoor set, or the like, as well as film recorders.  The claim is
not made that this gamut includes all current output devices, but if it
doesn't, it sure doesn't leave out much.  It is huge.

There are a lot of gamuts in the world.  When you scan your film, you may
think you know all that you will ever do with a given scan, and indeed you
may, but if you do your scan with the intent of doing it only once, you
would probably be well advised to store your scanned image in a space which
will do no harm to the data by clipping it or by arbitrarily mapping it in
any way to fit into some smaller space, or by stretching out the data too
far horizontally if there is any realistic chance that the stretching will
posterize the image.

If your original is an Ektachrome or a Fujichrome, "Ekta Space PS 5, J.
Holmes" (which I spent a great deal of time creating a couple of years ago,
for my own use, basically) fits the requirement perfectly, unless your
images consistently do not utilize most of the film gamut.  If you should
want to print to a device that has colors outside of your original gamut
and would like to juice the colors in the image to get those colors in a
print, you would simply convert your image data from Ekta Space into ROMM
RGB and there would be no harm done (to the quality of the color mapping
anyway, but a little harm to the tone scale vis-a-vis approaching the
threshold of visible tonal banding more closely, because the gamma of ROMM
RGB is 1.8 instead of 2.2, and you might also approach the threshold of
visible chroma banding, esp. in greens).  Then you would edit on screen in
a source simulation and/or an output simulation, albeit one that shows
monitor gamut clipping because your monitor can't show all the colors, use
an out-of-printer-gamut warning to show you which colors in the source
space are not going to fit into the printer space without being mapped
inward (printer gamut warnings are not meant to imply that your overall
saturation is too high, necessarily!), then make a print and the thing
would just be lovely (we hope).

If you want to print without ever making the image colors stronger than
what the film could hold (very likely), then you would never have to map
upward into a bigger space.  Most image colors (from original photographs)
will easily fit into most device gamuts, even the smaller ones, but some
will not, and often the out-of-printer-gamut colors will be ones that you
<will> miss, unless your printer gamut is among the better ones.  As I
mentioned, painted originals tend to be more challenging, vis-a-vis
out-of-printer-gamut colors.

BTW, Bruce RGB was intended to hold the colors of offset CMYK for
publishing workflows, and has little bearing on working with larger gamut
devices.  Nor will it protect against the clamping I mentioned (it's too
small to do that when saving scans of chromes), but it will protect against
outright loss of gamut in press prints, which is very important.


6) Banding with working/storage spaces of different sizes with 24-bit data:
So, one could just store images in a gamut the size of the anticipated
printer's gamut, but that would clamp out-of-printer gamut colors and harm
the quality of the final result while entering this, printer-sized RGB
storage space.

Or one could just store images in a gamut the size of the monitor (a la
ColorMatch RGB), but that will not only cause the clamping damage to
out-of-ColorMatch-RGB-gamut colors, as described above, but it will also
preclude you ever getting to utilize that part of your printer's gamut that
your monitor doesn't cover (e.g. brilliant yellows, several darker
saturated hues, and maximum greens and cyans), if those colors existed in
your original or if you wanted to create them by adjusting the chroma
upward during editing.

Or one could store the images in a color space the same size as the source
gamut (Ekta Space if you start with chromes).

Or one could store the images in a color space that most likely includes
all known output device gamuts (e.g. ROMM RGB).

At some point banding will theoretically begin to occur, as the 24-bit data
is spread out horizontally further and further.  Note that the overwhelming
source of actual banding in prints is a lack of steps in the vertical
direction, not the horizontal direction!  I have <never> been able to
detect the slightest chroma banding (horizontal banding), despite trying to
make it happen many times, in any image or torture test done with Ekta
Space.  Nor does Ekta Space aggravate banding in the vertical direction,
compared with other RGB spaces that can be used in Photoshop, if you save
directly into it from 48- or 36-bit scanner space, as you should.  Nor is
there any problem with shadow detail if it is used correctly, the same as
any other space I have tested.  There are issues with shadow detail that
are inherent in the choice of a tone curve for a storage space, but the
requirement of the tone curve being a simple, pure gamma curve in PS 5
limits the ideal solutions for most workflows to gamma 2.0 to 2.2 tone
curves, because such curves are a better match to the natural tonality of
most printing devices, than are gammas outside of that range.


7) Archiving considerations:  The more you want to be able to endlessly
re-purpose your image files, and the less you want to have to scan them all
over again, the more sense it makes to store them in a color space that can
be used as a working space, which also can hold all of the colors as they
were in the original (or in the original as adjusted during scanning)
without arbitrarily moving colors around and changing the color
relationships of the image.  I spend a great many hours on each master
file, so I have a serious need to avoid ever doing that work over again,
and one thing I can be certain of is that output systems will continue to
change, a lot.


In conclusion:

So far, banding has never been caused by either of the Ekta Space profiles
that I or anyone else that I know of has ever been able to detect, so I use
them with impunity when archiving my giant scans, regardless of how
un-saturated the image may be.

Also, I have never yet encounted any problem with the monitor's lack of
gamut causing me to have inaccurate soft proofs or forcing me to make image
edits because colors are being clamped entering monitor space which would
not be clamped entering printer space, though indeed, with a much larger
gamut printer and more saturated subject matter (scanned or photocopied and
scanned paintings), this could be a problem, as many people have discussed
at various times, and for which a variety of solutions have also been
proposed.  Note that I do all of my color correction in Live Picture, where
I utilize excellent (extremely accurate) source and output simulations,
both.  (Of course, I use Prove it! for my monitor calibration.)  Color
correction in Photoshop unfortunately still demands the use of another
application (such as ICC Viewer, $24.95 at www.colormall.com, sold by
download only), or fancy tricks, to get RGB output simulations (soft
proofs), without which, one's life is apt to be incomplete, regardless of
the printer, inks, and paper in use!

End of sermon/encyclopedia/gas bag/take your pick.


Joe Holmes

Natural Light Photography
Kensington, California


-
Turn off HTML mail features. Keep quoted material short. Use accurate
subject lines. http://www.leben.com/lists for list instructions.



[Photo]     [Photo Printers]    [Yosemite Photos]     [Scanner Discussion]     [Gimp]     [Gimp Users]

Powered by Linux