[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
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.