From: Stacy Cates, INTERNET:scates@berry.edu
Date: Fri, Mar 1, 2002, 12:19 PM
RE: [colortheory] Color correction by numbers/batch scanning
HelloI'm Stacy Cates, Creative Services Designer at Berry College near Rome, Georgia.
I've started reading Dan's book Professional Photoshop 6, and I'm trying the color correction by numbers. I'm having some trouble, and I have a few questions.COLOR CORRECTION BY NUMBERS
1. I've tried applying the numbers c5m2y2m2 highlight and the c80m70y70k70 shadow to images by:a. using threshold command to help me find the highlight and shadow and/or deciding for myself what should be highlight or shadow,
b. and (altering the cmyk curves, one at a time, to apply these values) or (setting the curves highlight eyedropper to those values for the highlight, then clicking on the highlight area of the image with the curves highlight eyedropper tool; same for shadow),
c. and finally trying to find what I think should be a neutral area and applying appropriate neutral values to that area by assigning the values as I described above for the hi's and lo's.
I was a little confused about how to determine what values I should use for the neutral point. I noted the RGB values in my cmyk image for what I chose for the neutral area (with the eyedropper tool set to 3x3 average), I chose one of the 3 values. I then went to the color picker, typed that same value into the R and G and B. I then noted what the cmyk values were; I assumed typing an RGB neutral value in the color picker would cause a neutral cmyk value to be displayed in the color picker. I then applied those cmyk neutral values to the neutral point I chose using the methods described above for applying the hi's and lo's.
I've also tried this method using only RGB values starting with RGB images instead of cmyk mode images.
While it seems to work sometimes, more often I get a bad color cast.
Am I doing something wrong, or does it take experience to learn how to choose appropriate highlight and shadow areas? Could I just be choosing the wrong areas?
BATCH SCANNING
2. Our office, which produces publications for the college, is developing an image database using Filemaker Pro Server Version, which will allow the database to be accessible over the internet. We also use Filemaker Pro for our work flow/job ticket database, so we chose Filemaker with the idea that the 2 databases could be integrated if we wanted and because of the internet-accessibility. We want to put thumbnail images (only) of many of our originals in the image database (hundreds and eventually thousands). The originals include slides and 35mm negatives. We have a Sprintscan 4000 film scanner and an AGFA Duoscan T2500 reflective and film scanner. I don't have a way (that I know of) to batch scan on the Sprintscan, and while the AGFA does allow batch scanning, I can't get it to skip the preview for each scan, which takes too much time.
Does anyone know of a scanner that will allow us to batch scan, for thumbnail image quality, slides and negatives?Thanks
Stacy Cates.
From: INTERNET:rproulx@r2p2.com, INTERNET:rproulx@r2p2.com
Date: Fri, Mar 1, 2002, 3:37 PM
RE: Re: [colortheory] Color correction by numbers/batch scanning
On 1 Mar 2002 at 11:22, Stacy Cates wrote:> I was a little confused about how to determine what values I should use for the
> neutral point.Stacy,
A neutral tone is any gray tone that falls between white and black. When doing colour photo printing it's always in the neutral tones that one can see if there's an overall colourcast or not. It's the same with digital images.
The key to interpreting any CMYK tone that 'should be neutral' is to inspect the corresponding CMYK numbers (forget RGB) and find out if it is indeed a neutral colour value or not. Generally all neutral CMYK values (grayscale from white to black) will have equal MY and about 5% higher Cyan. The exact 'higher % of Cyan' varies a bit depending if we're checking a highlight or a shadow (the highlight's Cyan is higher than 5% and lowers as the tone gets darker). Since Black is already neutral we can ignore it altogether.
The "by the numbers" method essentially has us set the white (5,2,2,0) and deepest shadow (80,70,70,70) (deepest value will change if the press allows more ink = "total ink"). We then check any neutral tones or skintones in the image to try and see if there's a colourcast and then fix it (if we want to).
YOU have to figure out what should be neutral in the scene and go for it. There's no numerical 'RGB or otherwise' way of looking at the image. If you see a white wall then it's probably neutral. If everything goes nuts when you try and fix it then it probably wasn't yellow afterall. If you see some black pavement - it's probably neutral. See a humanoid - there's probably an appropriate skintone on it. If there's no neutral nor skin tone available then we really have no clue what the "right" colour should be unless we have access to the original subject. In this situation you just make up something that looks ok on your "calibrated monitor" (one still does look at the monitor) and hope the client buys your interpretation.
Russell.
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Fri, Mar 1, 2002, 6:25 PM
RE: Re: [colortheory] Color correction by numbers/batch scanning
on 3/1/02 11:03 AM, Russell Proulx wrote:
>
> The key to interpreting any CMYK tone that 'should be neutral' is to inspect
> the corresponding CMYK numbers (forget RGB) and find out if it is indeed a neutral
> colour value or not. Generally all neutral CMYK values (grayscale from white
> to black) will have equal MY and about 5% higher Cyan.ANY well behaved RGB editing space is easy to peg for neutrals. R=G=B! Input and output spaces can vary of course. For CMYK, there is no fixed rule for what values constitute a neutral. Your recipe above is best guess/good luck since any output device (be it RGB and especially CMYK) can have a multitude of values that may create a neutral. RGB is a piece of cake. All neutrals are R=G=B (54/54/54, 233/233/233 and so on). That1s the beauty of RGB.
Andrew Rodney.
From: "Stephen Marsh", INTERNET:samarsh@ozemail.com.au
Date: Fri, Mar 1, 2002, 9:56 PM
RE: [colortheory] Re: Color correction by numbers/batch scanning
Russell wrote:> > The key to interpreting any CMYK tone that 'should be neutral' is to inspect
> > the
> > corresponding CMYK numbers (forget RGB) and find out if it is indeed a neutral
> > colour value or not. Generally all neutral CMYK values (grayscale from white
> > to
> black) will have equal MY and about 5% higher Cyan.Andrew replies:
> ANY well behaved RGB editing space is easy to peg for neutrals. R=G=B! Input
> and output spaces can vary of course. For CMYK, there is no fixed rule for
> what values constitute a neutral. Your recipe above is best guess/good luck
> since any output device (be it RGB and especially CMYK) can have a multitude
> of values that may create a neutral. RGB is a piece of cake. All neutrals
> are R=G=B (54/54/54, 233/233/233 and so on). That1s the beauty of RGB.I agree, a RGB working space (not device) such as Adobe RGB or ColorMatch RGB is safe and neutral. It is very easy to judge neutrals if the file is in RGB.
If the file is in CMYK - then the profile which describes the file or the assumed work space has to be correct, otherwise any RGB or LAB evaluations off the numbers in the file will not match the profile, and neutrals and other colours will not be translated correctly. CMYK without a profile which describes the separation or final device numbers will need to be evaluated using traditional output condition aimpoints and eyeball, if there is no other way to judge things.
As mentioned, device RGB or CMYK is not linear for neutrals - the amount of light or ink may vary over the tonal range. When you get to know how one process works (such as what we loosly call 'SWOP' printing) - you may get to know what values equate to neutral over the tonal range without the benefit of the correct profile which describes those numbers (neutral aimpoints).
I agree with Andrew that working space RGB is easier to evaluate, and if you are working in RGB then the numbers for white/black or gray make sense. I personally find RGB harder and less intuitive for evaluating non neutrals, and when in RGB I will use CMYK info display for known memory colours (skin, sky, grass etc) - but endpoints and neutrals are still judged via RGB numbers (using CMYK endpoints and neutral display when in RGB is dangerous and should be avoided, since the RGB working space file will no longer be balanced or neutral).
And coming from the device independent point of view - LAB will demonstrate whether the RGB or CMYK is in fact neutral - based on the assigned or assumed profile for the files RGB or CMYK space (which needs to be correct). They can also be described in LAB values, where L is meaningless for colour and zero readings in AB are the key.
If Dan's book and methods have taught me anything - it is not to discount any colour mode, when it comes to correcting/editing or even just evaluating a colour or tone. Grayscale, HSB, LAB, RGB and CMYK info palette readings can be a very important tool - no matter what colour mode you are currently working in or going to.
Regards,
Stephen Marsh..
From: INTERNET:rproulx@r2p2.com, INTERNET:rproulx@r2p2.com Date: Sat, Mar 2, 2002, 12:30 AM RE: Re: [colortheory] Re: Color correction by numbers/batch scanning
On 2 Mar 2002 at 13:05, Stephen Marsh wrote:> CMYK without a profile which describes the separation or final device
> numbers will need to be evaluated using traditional output condition
> aimpoints and eyeball, if there is no other way to judge things.Stephen,
Some would argue that THAT is the 'tried and proven' method of achieving predictable results more often than not. A printing press is not a photocopier and there is a human being controlling that part of the process. Learning the appropriate values required to help them best do their job is there I put my efforts. As some offset press profile proponents say "you can't profile a moving target". A press controlled by imperfect (and often more interesting) humans is just that.
Russell.
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Sat, Mar 2, 2002, 12:16 PM
RE: [colortheory] Color correction by numbers/batch scanning
Stacy writes,>>I was a little confused about how to determine what values I should use for the neutral point. I noted the RGB values in my cmyk image for what I chose for the neutral area (with the eyedropper tool set to 3x3 average), I chose one of the 3 values...While it seems to work sometimes, more often I get a bad color cast. Am I doing something wrong, or does it take experience to learn how to choose appropriate highlight and shadow areas? Could I just be choosing the wrong areas?>>
There are obviously many things that could cause an unsatisfactory result. However, I suspect that your continued use of the phrase "*the* neutral point" is the likely problem.
When you force an object to become neutral you are betting the image that you're right. If you take something that's naturally brown and force it to be gray the image will take on a blue cast.
If you have nothing in the image that you can guarantee is supposed to be neutral, don't take matters into your own hands. Similarly, if you've found one thing that you can guarantee should be neutral, look for another. There is no "*the* neutral". There can be one neutral point, twelve, or zero. Your job is to identify them and correct them as necessary.
If several known neutral objects are reading as neutral, that's just about the definition of an image that has no cast.
Dan Margulis.
From: "Stephen Marsh", INTERNET:samarsh@ozemail.com.au
Date: Sat, Mar 2, 2002, 12:15 PM
RE: [colortheory] Re: Color correction by numbers/batch scanning
> Some would argue that THAT is the 'tried and proven' method of achieving
>predictable results more often than not.Very true Russell, I agree. My point was that old 'aimpoint' systems do not work with ICC methods - and when you use all methods available to do what works, it can be a PITA to come over a part which bucks the rest of the system. I have learned to live with this (one foot in ICC, one foot out), but when you move out of your comfort zone then those profiles and LAB readings can really help. When you have no other info to go on and conditions are unknown, you have to start somewhere. For example, I have not had consistent newsprint experience to gain any real opinions on gray balance for these wildly shifting conditions, so I still trust the profile to provide neutral aimpoints (for what this is worth). It would be nice if everyone was confident in their aimpoints, but many people who need to present separations to print providers do not have a good place to start from - be it ICC or 'old fashioned' numbers to aim for.
All methods try to supply 'true' seps for neutrals to the press - and the press operator usually seems to have some leeway to move, if the basic seps are there in the first place.
I find the problem is not just trying to hit a moving target (this implies one is known) - but knowing what, if and where the target is in the first place.
Regards,
Stephen Marsh.
From: INTERNET:citizenray@aol.com, INTERNET:citizenray@aol.com
Date: Mon, Mar 4, 2002, 3:13 AM
RE: Re: [colortheory] Color correction by numbers/batch scanning
Dear Stacy,Regarding your posted questions under the "Color correction by numbers/batch scanning" head, you mention first, trying to correct CMYK scans with finding/fixing neutrals, and then latter mention you have access to a scanner(s) and wish to make files accessible via the Internet using a FileMaker database.
I can offer the following...
1. I suggest color correcting RGB files as this presents easy-to-see neutral colors on screen and in the eye dropper readout. Neutrals are even numbers of RGB as 0,0,0 is black, 128,128,128, is a medium gray, and 255,255,255 is white. Follow all the standard rules; don't clip the end points, make good contrast without losing shadows or hilights, remove incorrect color casts, etc. Do all this and save your working space profile into the file upon save. The profile tells your user's and service provider's computers how to interpret the colors.
For you to color correct in CMYK with particular CMYK values is more laborious than RGB work and restricting the file to a certain CMYK condition. For example, the CMYK values required for a photo could be very different for a traditional high volume print publication, a short-run digital printer, and a large format vinyl banner print. The CMYK neutral values for these different devices are not the same. Those certain values are not your responsibility, however a file with reproductive detail and color does need to come from you, and not just for CMYK use. RGB files can be used for WWW, PowerPoint presentations, 35mm slides, desktop printers, small and large format photo printers, the list goes on. You may as well be proficient with RGB color and files, digital cameras and scanners deliver RGB files and this is the direction we're headed.
2. Unfortunately, batch scanning from the two scanners you mention will probably never save any time for you. They can enable you and your department to get scans but not in any volume that is economical compared to the time involved, especially from film negatives. I can suggest finding an outside source that provides Photo-CD, Fuji Frontier scans, or contract volume. Kodak also has desktop high-volume scanners for volume work that may be with in your budget.
3.
>We want to put thumbnail images (only) of many of our originals
>image database (hundreds and eventually thousands).Look into Extensis Porfolio and/or Cumulus graphics archiving software that will provide more features, speed, and power than FileMaker at this time. Both options will communicate completely with your FileMaker database(s) but are far more tuned to web publishing graphics than FileMaker.
I hope this helps,
Stephen Ray.
From: INTERNET:varis@varis.com, INTERNET:varis@varis.com
Date: Wed, Mar 6, 2002, 1:03 PM
RE: Re: [colortheory] Color correction by numbers-RGB
Hi all,Regarding Dan's post about RGB vs CMYK editing. I must admit that I am from the half who grew up working in RGB. I did ALL of my color correcting in RGB and then simply converted, in the best way I knew how, to CMYK. I almost never did any post conversion editing of the CMYK because my images "seemed" to be fine and in no particular need of CMYK tweaking.
After taking Dan's class however, I can tell you that now I find plenty of excuses to actually convert into CMYK to do some special color/tone editing that IS easier to accomplish in CMYK. Most often this involves editing the black plate to enhance shadow detail but there are plenty of other tweaks that one can do in CMYK easier than RGB.
Sometimes, it is worth doing black plate editing on a duplicate of your RGB, converted to CMYK - then convert back to RGB and apply the luminosity of the edited file to the original RGB color to retrieve the full gamut color and gain the benefit of greater shadow detailing. Once you start to think more fluidly about RGB, CMYK and LAB a whole world of possibility opens up and images can be enhanced way beyond what you've accepted as good in the past.
Regarding Daniel Rubinstein's post:
> I wonder if > there are any numeric guidelines for skin tones in RGB, as I would like to > make my advanced students work in the info palette rather then in the > colour. Does anyone has suggestions regarding RGB numbers for skin tones?
I have taken to looking at CMYK numbers (as the secondary color) in the info palette when editing RGB for skin tone. With a little practice it has become easy to adjust RGB to hit certain CMYK values that I use as a guide only.
-- Regards,
Lee Varis
varis@varis.com
http://www.varis.com
888-964-0024.
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Wed, Mar 6, 2002, 2:09 AM
RE: Re: [colortheory] Color correction by numbers/batch scanning
With respect to the statement about the relative ease of correcting in RGB vs. CMYK, I will add the following. Of the people I meet in various locations who have not taken my seminars, about half grew up working in RGB and the other half in CMYK. The people who grew up with RGB echo Steven's view almost unanimously, feeling that CMYK is obviously more difficult and that anyone who doesn't see this is brain-dead. This differentiates them from those who grew up with CMYK, who with even greater unanimity assert that RGB is obviously more difficult and that anyone who doesn't see this is brain-dead.Dan Margulis.
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Tue, Mar 12, 2002, 8:39 PM
RE: Re: [colortheory] Color correction by numbers-RGB
Lee writes,
>>After taking Dan's class however, I can tell you that now I find plenty of excuses to actually convert into CMYK to do some special color/tone editing that IS easier to accomplish in CMYK. Most often this involves editing the black plate to enhance shadow detail but there are plenty of other tweaks that one can do in CMYK easier than RGB.>>
I was sorry not to get a chance to respond this past week. The above is exactly right. It should be added, however, that there are many things that *can't* be done well in CMYK. Generally speaking, curves work better in CMYK, blending in RGB, and color spikes in LAB, but it's quite a bit deeper than that.
Lee posted on his site a couple of RGB images on which he used some highly nonstandard tactics, not in CMYK, but in LAB. One of them is
http://www.varis.com/ColorTheorySuccess2/index.htm
>>Once you start to think more fluidly about RGB, CMYK and LAB a whole world of possibility opens up and images can be enhanced way beyond what you've accepted as good in the past.>>
Amen. Unfortunately for the forces of colorspace chauvinism, there are more people like Lee around. For those who restrict themselves to working in one space, they are formidable competitors.
Dan Margulis.
From: thi lamaire, INTERNET:bobineinc@yahoo.com
Date: Tue, Mar 12, 2002, 9:44 PM
RE: Re: [colortheory] Color correction by numbers-RGB
Hi everyone I been toggling the uncorrected Coyote Buttes-J-PEG with the color corrected final ,the difference between the two J-PEG is contrast and saturation. In this case why go into so much blending and look up table playing when one could easily use contrast and saturation in RGB for the same result in less time? Non the less I did appreciate the demonstration very much
Respect
Thierry Lamaire> http://www.varis.com/ColorTheorySuccess2/index.htm
>
> >>Once you start to think more fluidly about RGB,
> CMYK and LAB a whole
> world of possibility opens up and images can be
> enhanced way beyond what
> you've accepted as good in the past.>>.
From: INTERNET:dangster@harbornet.com, INTERNET:dangster@harbornet.com
Date: Tue, Mar 12, 2002, 9:17 PM
RE: RE: [colortheory] Color correction by numbers-RGB
Thanks Lee (and of course Dan for the writing the book)!This is a very helpful exercise. -easier way for me to grasp with the images mixed right in on the page. I'm good on this until 05; then it gets a little hard to follow the three quick lines of what was applied using which blend mode and how much :)... That must be the part that comes with practice. I will work through it a few times! Yes, I'm only as far as chapter 9. Have already used quite a few techniques. Why can't a bright colored fruit image come across my workstation?
There's really no question in this message - yet, I want to get through the book at least once.
Dan McCormack>>Lee posted on his site a couple of RGB images on which he used some highly nonstandard tactics, not in CMYK, but in LAB. One of them is
From: "Lewis Levin", INTERNET:lewis_levin@hotmail.com
Date: Wed, Mar 13, 2002, 6:46 PM
RE: Re: [colortheory] Color correction by numbers-RGB
But, keep in mind there are still costs in terms of data loss to repeated color space conversions. While effective image rendering may seldom require 16 bits of color data per channel, having it would certainly eliminate most artifacts introduced by repeated conversions. A final conversion to 8 bit could be done to reduce the data that is sent to final rendering, while the archived image could be kept in 16 bit. Storage space, memory, and cpu speed are no longer impediments..
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Thu, Mar 14, 2002, 10:50 AM
RE: Re: [colortheory] Color correction by numbers-RGB
Lewis writes,>>But, keep in mind there are still costs in terms of data loss to repeated color space conversions.>>
This has come up several times on this list. Basically, the idea that going RGB>LAB>RGB with a photograph causes significant damage is an old wives' tale, even when the conversion is made fifty, a hundred, two hundred times to the same image.
>> While effective image rendering may seldom require 16 bits of color data per channel, having it would certainly eliminate most artifacts introduced by repeated conversions. A final conversion to 8 bit could be done to reduce the data that is sent to final rendering, while the archived image could be kept in 16 bit. Storage space, memory, and cpu speed are no longer impediments.>>
Irrelevant, since 16-bit is not available for the moves Lee made. The test is whether the image looked better than before, using the tools at hand.
Dan Margulis.
From: "Renard A. DellaFave", INTERNET:radellaf@4pi.com
Date: Thu, Mar 14, 2002, 12:37 PM
RE: Re: [colortheory] Color correction by numbers-RGB
>This has come up several times on this list. Basically, the idea that going
>RGB>LAB>RGB with a photograph causes significant damage is an old wives'
>taleWhile I've seen LAB conversions tear up a histogram, whether it does so in any given case is easy to determine. With the CoyoteButtes photo there's no question, I see no degradation.
From what I've seen, it's gamma adjustments, or any un-subtle curves, that benefit most from high-bit editing.
>, even when the conversion is made fifty, a hundred, two hundred times
>to the same image.Assuming the routines are consistent, and that no edits are made in between, repetition should have no effect.
>Irrelevant, since 16-bit is not available for the moves Lee made. The test
>is whether the image looked better than before, using the tools at hand.Well, irrelevant in an immediate sense. No reason not to ask Adobe for high-bit image apply commands, or better yet, the improved Calculations box talked about in Photoshop Channel Chops.
---
BTW, this is my first post to the list, and I'm delighted to be on it. I've been voraciously reading Photoshop books and playing with the program, and Professional Photoshop really stands out. Dan, you've got a gift for writing as well as being a color correction genius. Reading your book has made me a fan. OTOH, Channel Chops has opened my eyes to further uses of RGB. No book seems to adequately cover inkjet printing, though Real World Photoshop comes close. I think the problem is that it is so hard to characterize, at least with the low-end printers.
Well, I'll shaddup now. I may know a lot of technical stuff, but it's clear that to really "know" color correction requires a ton of experience I don't yet have. Working on it, though. But for now it seems my curves mess things up more than they improve them, at least when going beyond the by-the-numbers basics. Mostly, faces seem to look really BAD when I increase their contrast, and flat areas on curves make these ugly greyish areas on the picture. Also, the bezier curve points on curves drive me nuts. I adjust one thing up and the stupid program makes a u-shaped dip on the other side of the adjacent control point. What I really want is a line fit through my points, not this bezier "junk".
Oh, also, I'm curious about the origin of color correction terms. Where did we get "write curves" and "moves"? Granted it's shorter than "apply an image transform", but why not {use, come up with, shape, sculpt, specify, develop, make} curves, or make color {changes, shifts, transforms}? Guess it's just the lingo of the field. Nothing wrong with it, just takes some getting used to..
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Fri, Mar 15, 2002, 11:37 AM
RE: Re: [colortheory] Color correction by numbers-RGB
Renard writes,>>While I've seen LAB conversions tear up a histogram, whether it does so in any given case is easy to determine. With the CoyoteButtes photo there's no question, I see no degradation.>>
It is unfathomable how people have so little confidence in their own eyesight and judgment that they have to talk about "data integrity" and histograms to figure out whether a picture looks good. Suppose that the histogram looks bad, but the picture looks good. Are we going to throw it out?
The interesting thing about this is (and I'm not talking about Renard's post here) how people who hold themselves up as experts in these matters have so little clue about what the histogram does. They preach that one shouldn't change colorspaces during a correction, because it may harm the histogram. In actuality, if one converts from colorspace A to colorspace B, corrects there, then reconverts to colorspace A, the histogram will invariably look better than if the correction had been done in colorspace A from the get-go.
With respect to Lee's image, the description of what he did makes it screamingly plain that the histogram would have to be relatively smooth. Anyone who, after reading that description, needed to look at the histogram, shouldn't be looking at histograms in the first place, because it was obvious what the histogram would show.
>>Oh, also, I'm curious about the origin of color correction terms. Where did we get "write curves" and "moves"? Granted it's shorter than "apply an image transform", but why not {use, come up with, shape, sculpt, specify, develop, make} curves, or make color {changes, shifts, transforms}? >>
This probably dates from 1980s electronic color correction. When it takes 20 minutes for a workstation to execute a curve, and the workstation costs a quarter of a million dollars, one can't afford much experimentation. The sensible workflow at that time was for a production planner to script every move that the operator would make, to avoid the catastrophe of applying curves and then having to cancel them, and to eliminate very expensive thinking time while the operator was deciding what to do next. Thus, the curve was in fact written down, as were any other "moves" that the planner thought should be executed at the same time.
Dan Margulis.
From: "Renard A. DellaFave", INTERNET:radellaf@4pi.com
Date: Mon, Mar 18, 2002, 2:21 AM
RE: Re: [colortheory] Color correction by numbers-RGB
Quoting Mr. Margulis:
>It is unfathomable how people have so little confidence in their own
>eyesight and judgment that they have to talk about "data integrity" and
>histograms to figure out whether a picture looks good.Agreed in general, but in specific, esp. as regards the authors of Real World Photoshop, the concern seems not to be so much of whether the image looks good in its present form, regardless of "holes" in the histogram, but how editing that introduces such holes will eventually enlarge them to the point that the image shows posterization.
e.g., since more than one edit may be applied, editing that throws data away is less useful in a general sense. Or, must be used more cautiously, lest the effects accumulate and become visible.
>Suppose that the
>histogram looks bad, but the picture looks good. Are we going to throw it
>out?No, but we might try harder to find a less edited original if we needed to "repurpose" it or otherwise edit it for effect.
But sure, the image is fine as it stands.
>They preach that one shouldn't change colorspaces during a >correction, because it may harm the
>histogram.I'd just say, esp. if you're changing gamma by the conversion, change colorspaces in high bit mode if possible. I thought Photoshop did that automatically, but the few times I've tried it that doesn't seem to be the case. i.e., 8-convert-8 looks worse than 8-16-convert-16-8.
> In actuality, if one converts from colorspace A to colorspace B,
>corrects there, then reconverts to colorspace A, the histogram will
>invariably look better than if the correction had been done in colorspace A
>from the get-go.Well, yeah, tripping over yourself to do an edit in a colorspace that makes it a more complicated edit is, well, foolhardy. It's like trying to integrate the area of a sphere in rectangular or cylindrical coordinates, or do frequency domain filtering operations with time domain functions. It can be done, but it's simpler to tack a transform on one end, do something simple, then the reverse transform.
I do wish Photoshop displayed all 10 channels rather than having modes. Barring round-off errors, modes are all just math, and what model the data are stored as is inconsequential. The faster our computers get, the more this can be made evident in real time in Photoshop. Ideally, some operations would benefit from a 3-D "histogram" of one of the tristimulus modes and the ability to mark off arbitrarily shaped regions within it. (c.f. Image Processing Handbook by John Russ, and his son's plug-ins at http://members.aol.com/ImagProcTK/).
Now if only such complex tools would more quickly imbue the operator with the knowledge of what to do with them to improve images...
>With respect to Lee's image, the description of what he did makes it
>screamingly plain that the histogram would have to be relatively smooth.
>>While I've seen LAB conversions tear up a histogram...I do wish I remembered what kind of image the LAB conversion noticeably "combed" the histogram of. The theory is pretty clear, that of representing a wide gamut in 24 bits throwing away subtleties that a narrow gamut stored in the same 24 bits can maintain, but I'll be damned if I can get it to happen. Maybe I was converting between Adobe RGB and Apple, in which case I was seeing the effect of the gamma change, not the gamut change, knocking out levels in the channel histograms.
>Thus, the curve was in fact written down, as were any other "moves"
>that the planner
>thought should be executed at the same time.Hmm, interesting. In general, I find the way people used to do what Photoshop does a fascinating subject. I'd love to see a "stat camera" for instance.
FWIW, I probably should write down, or save, curves more often. Their shapes are rather ephemeral the way Photoshop works right now..
From: "Stephen Marsh", INTERNET:samarsh@ozemail.com.au
Date: Wed, Mar 13, 2002, 10:20 AM
RE: [colortheory] Re: Color correction by numbers-RGB
> Hi everyone
> I been toggling the uncorrected Coyote Buttes-J-PEG
> with the color corrected final ,the difference between
> the two J-PEG is contrast and saturation.Simple concept. Getting there is different.
> In this case
> why go into so much blending and look up table playing
> when one could easily use contrast and saturation in
> RGB for the same result in less time?Thierry, are you sure the result is the same? I tried some of the quicker methods - and they all fall short. None of them put the colour or luminosity variation of the blending moves posted. Even when you add luminosity curves maximizing each channel - the image could still use some CMYK mode targeted CK sharpening and luminosity blending into the RGB to make things better, but not as good. And the image in question has not had these sharpening and curve moves applied yet, and is close to ideal as things stand...
> Non the less I did appreciate the demonstration very
> much
> Respect
> Thierry LamaireAlthough images are chosen for their relevance to the demo - it is more about grasping the deeper concepts and then learning how to apply them in similar or different cases. For example, I would have considered the LAB AB moves to pop colour - but probably would not have used the apply image command and used curves instead. This is because there is no major detail in the AB, and I generally think of blends to increase luminosity type detail. But the AB apply image steps demonstrate an alternative that I will have to explore further. Cheers Lee (and Dan).
Repeat of link in question: www.varis.com/ColorTheorySuccess2/index.htm
Sincerely,
Stephen Marsh.
From: Mike Russell, INTERNET:mgr@zocalo.net
Date: Tue, Mar 19, 2002, 6:21 PM
Re: Color correction by numbers-RGB
The issue Dan and others have raised is how any verbal argument can be more compelling than what our own eyes see. And I think the answer does lie in the some of the material presented to beginners in books, like Bruce Fraser's.The authors of these books are content to state that more bits is better, illustrate this with a histogram with gaps in it, and move on. No examples are presented. So beginners may well conclude that it is either irrelevant what the image actually looks like, or that the image in question looks so bad that it is not worthy of being looked at.
Both conclusions are, of course, false. Effective training in graphic arts must focus first on the what the final observer will see. Failure to do so results in a practitioner with theoretical knowledge, but little or no confidence in his ability to see for himself.
I do wish I remembered what kind of image the LAB conversion noticeably "combed" the histogram of.
The original image was a splined gradient. But, taking the opportunity to illustrate the previous point, why not wonder about the phase of the moon, since it is equally relevant to the quality of your images?
(BTW - there are two Mike Russell's, of which I am one. Since the other Mike Russell seems to contributing only very thoughtful and correct material
to this group, I for one see no reason to distinguish the two of us. He, of course, may feel differently :-)Mike Russell
http://www.zocalo.net/~mgr
http://geigy.2y.net
From: Dave Balderstone, INTERNET:dave.balderstone@producer.com
Date: Tue, Mar 19, 2002, 10:10 PM
RE: Re: [colortheory] Digest Number 380
At 11:05 AM -0800 3/19/02, Mike Russell wrote:
>The authors of these books are content to state that more bits is better,
>illustrate this with a histogram with gaps in it, and move on. No examples
>are presented. So beginners may well conclude that it is either irrelevant
>what the image actually looks like, or that the image in question looks so
>bad that it is not worthy of being looked at.
>
>Both conclusions are, of course, false. Effective training in graphic arts
>must focus first on the what the final observer will see. Failure to do so
>results in a practitioner with theoretical knowledge, but little or no
>confidence in his ability to see for himself.Interesting and insightful comments, Mike. Color in theory exists in the histogram and other technical details of a computer file, or transparency, or a printed image. But color in practice exists in the minds of the observer, so that is what we need to target.
I had opportunity to share a couple of drinks with a photog and image guru in NYC recently. His (admittedly paraphrased here) stand seemed to me to be "The fact that you can't see any difference in the final image has no bearing on the *reality* that 16 bit is a far superior editing space than 8-bit."
I had no response to that at the time and still don't. I'm only concerned with what an image *looks like*, not the theoretical and technical details of the bits and bytes. If people want to edit in 16-bit more power to them, but personally I can't see the difference.
djb
Adobe Photoshop training classes are taught in the US by Sterling Ledet & Associates, Inc.