Dan Margulis Applied Color Theory - "I Switched to Adobe RGB!"

From: jacob glazer
Date: Fri, Jun 2, 2000, 9:13 AM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Bob,
this interests me. could you elaborate?

>1.8 gamma seems quite heavily favored toward lighter tones which is the main
>reason I shifted to Adobe RGB from ColorMatch. I seem to encounter more
>situations where heavy tone edits are required in shadows than in lighter
>tones. A 2.2 gamma working space seems a little less prone to hitting
>posterization problems in such circumstances.

>Bob Smith


From: Bob Smith
Date: Fri, Jun 2, 2000, 6:35 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

the closer the possible data points are, the more heavily you can shift the tonal scale without causing banding in areas of gradation. That's why you can edit the hell out of a 16bit image compared to what will get you in trouble with an 8 bit image (something like 65,000 steps from black to white vs 256). The close spacing of steps in 8bit sRGB means it can be edited much more than 8bit Wide Gamut RGB before problems are encountered.

ColorMatch RGB (1.8 gamma) has only about 100 steps from black to middle gray. Adobe RGB (2.2 gamma) has something like 118 in an 8bit per channel file. Not a huge difference... but like I said, for some reason I seem to find myself doing more extreme editing to shadows than lighter tones so why not go for any advantage I can get. Given that I'd prefer to stick to built in spaces Adobe RGB seems to be the most logical choice. I also do enough output to wide gamut devices...Lambda or LVT... to appreciate the slightly wider gamut of Adobe RGB.

Bob Smith


From: jacob glazer, jglazer@after-image.com
Date: Sat, Jun 3, 2000, 12:22 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

you said you output to wide gamut devices. yet you are limiting your gamut before output. makes sense in terms of banding-- which is one of my biggest concerns. I was given recommendations from the developer of my drum scanning software (Aztek Digital Photo Lab) not to limit my gamut to colormatch-- to specifically use Wide Gamut RGB, with a gamma of 1.8 and white point D55 and CIE RGB Primaries. HIs point is that the scans come in with the full gamut, so why compress them? Still, Colormatch has worked well for me. I know some answers to that-- one is so you can *see* the colors on the monitor, another is the preferable CMYK resulting from a conversion of ColormatchRGN to ColormatchCMYK, a third is the gamut of my output device ( a fujix 4000)

Your argument regarding banding is a strong one-- one which I will look into.

jacob


From: Chris Murphy
Date: Sat, Jun 3, 2000, 4:53 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch

>I was given recommendations from the developer of my drum scanning
>software (Aztek Digital Photo Lab)
>not to limit my gamut to colormatch-- to specifically use Wide Gamut
>RGB, with a gamma of 1.8 and white point D55 and CIE RGB Primaries.

Well then they don't know what they're talking about. Gamma 1.8, white point D55 and CIE RGB primaries is NOT defined as Wide Gamut RGB.

There are three things that determine what working space you are using. Gamma, white point, and primaries. Wide Gamut RGB is defined by a gamma of 2.2, a white point of D50 and 700/525/450nm primaries. If you change ANY one of these, you are no longer in Wide Gamut RGB. By changing primaries to CIE RGB, you are in a much smaller working space than Wide Gamut RGB. Notice that as soon as you change ANY of these settings, that the RGB: pop-up changes to Custom. This is because you have created your own custom color space. Unless it has been heavily tested, I wouldn't even consider using it for production quality work.

The RGB: pop-up is serves only to hold "pre-sets" of information for gamma, white point, and primaries. If I start with sRGB, and change gamma to 1.8 and white point to D55 and primaries to CIE RGB - i end up with the EXACT same space you have.

>HIs point is that the scans come in with the full gamut, so why compress >them?

If you don't convert data when importing, or opening a scan - you aren't compressing them at all. You're simply saying "my scanner behaves like Adobe RGB - or Wide Gamut RGB" or whatever space you have set in RGB Setup. You're asking Photoshop to make an assumption about the scanner that likely isn't true.

For compression to occur, you need to either convert on open, or use the profile to profile command to actually bring the image the working space. Alternatively you can make an incorrect assumption (as above) and simply color correct on your calibrated/profiled monitor until you like what you see.

The biggest reason to compress data is when you don't have more than 8-bits/channel information, and the editing space is large, and when you are going to color correct the image with more than minor edits. In a large space with only 8-bit/channel of information, you can run into banding/posterization when making medium to heavy edits. So if you don't have high bit scans, then it makes sense to compress to a space that supports the maximum amount of editing you will be doing, without compromising the image integrity; as well as being reasonably large enough for the destination.

This is why Adobe RGB is popular. It's gamut is large enough to contain most press CMYK spaces, with only a little clipping; slightly larger than the monitor's gamut; but small enough to tolerate significant edits without causing posterization to 8-bit/channel data.

Chris Murphy


From: Dan Margulis
Date: Sat, Jun 3, 2000, 8:34 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Bob Smith writes:

>>the closer the possible data points are, the more heavily you can shift the tonal scale without causing banding in areas of gradation. That's why you can edit the hell out of a 16bit image compared to what will get you in trouble with an 8 bit image (something like 65,000 steps from black to white vs 256). >>

This is one of these statements that gets repeated over and over and has never been demonstrated to be true. I've seen one article where the author applied around 10 curves to an image and then blew it up 400%, and you could see the difference. That accords with my own tests--if you apply a series of non-real world changes to the image and then put it in a setting for which it doesn't have enough resolution, 16-bit is better. Certainly in my tests a more economical way to increase quality would be to start with, say, 5% more resolution.

Anyhow, while I accept that theoretically the extra bits are better, I have yet to see any image where a realistic edit in 16-bit caused any discernible quality difference as opposed to converting the file to 8-bit first and doing the same edit. If anybody has an image that they think would show this is not so, I'd be happy to take a look at it.

Dan Margulis


From: Andrew Rodney
Date: Sun, Jun 4, 2000, 2:07 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

on 6/3/00 10:07 AM, jacob glazer wrote:

> I was given recommendations from the developer of my drum scanning
> software (Aztek Digital Photo Lab)
> not to limit my gamut to colormatch-- to specifically use Wide Gamut
> RGB, with a gamma of 1.8 and white point D55 and CIE RGB Primaries.

You absolutely don't want to fool with that space. It's too wide for just about any use and for 8 bit files is suicide for the file. If you must use a space that is wider then Adobe RGB 1998, at least try the Kodak ProPhoto RGB space which is much more logically created.

Andrew Rodney


From: Chris Murphy
Date: Sun, Jun 4, 2000, 10:53 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

>Anyhow, while I accept that theoretically the extra bits are better, I have
>yet to see any image where a realistic edit in 16-bit caused any discernible
>quality difference as opposed to converting the file to 8-bit first and doing
>the same edit.

The effect of applying ICC profiles is less global than applying curves; yet can have the same effect (as well). That is, ICC profiles can be as generic as curves, but more often are more selective in nature (e.g., the ability to raise cyan in blue, but reduce cyan in lavender).

Given this nature of ICC profiles, why do you think Adobe uses 20-bit/channel transforms when using ICC profiles, but only 16-bit/channel transforms with separation tables? The difference between 20-bits/channel & 16-bits/channel is significant (each additional increase in bit-depth doubles the previous number of levels).

I think, Dan, the reason why you may not have come across a real world scenario yet is because it's only recently that we have support in Photoshop for RGB spaces that are SIGNIFICANTLY larger than our monitor spaces. I would agree that with monitor RGB it would take quite a bit of maneuvering. However, I have seen posterization occur when making heavy edits in a large space such as wide gamut RGB (and since proPhoto RGB is even bigger I would suspect it's more susceptible - we'll see); the heavy edits would be consistent with an image that wasn't very good to begin with. Also certain output devices are more prone to showing banding/posterization if they are wide gamut devices themselves but only support 8-bit/channel input; this makes them very dependent on those mere 256 levels per channel that are available.

This is certainly an important question, to know whether high-bit data, in the REAL WORLD actually makes a difference. I suspect it is extremely image specific as well as output device specific when it does occur.

Chris Murphy


From: Dan Margulis
Date: Mon, Jun 5, 2000, 1:22 AM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Chris writes:

>>Given this nature of ICC profiles, why do you think Adobe uses 20-bit/channel transforms when using ICC profiles, but only 16-bit/channel transforms with separation tables?>>

It doesn't hurt them to use those extra bits, but it doesn't make the conversion any more valid; all it's doing is introducing random data.

A better question might be, why do the scanner manufacturers, who have vastly more color experience than Adobe, content themselves with only 12 bits, even on their top-of-the-line models?

What you really need to ask is, is a thermometer that reports the temperature as 72.79378957 degrees better than one that merely reports it as 72.794 degrees? To know whether it is, you have to know whether the second and third digits after the decimal point mean anything or are they just random noise that the instrument is throwing in for want of anything better.

Like you say, with every additional bit you double the theoretical precision. The real-world precision is another story. It's clear that at least the ninth bit is often valid; otherwise there wouldn't be even the slight improvement in results seen by both Bob and me. Maybe even the tenth bit is valid sometimes. I seriously doubt that bits 11-16 mean anything under any circumstances. If that is true, it doesn't matter whether one uses 16-bit, 20-bit, or 20,000-bit transforms later on.

>>I think, Dan, the reason why you may not have come across a real world scenario yet is because it's only recently that we have support in Photoshop for RGB spaces that are SIGNIFICANTLY larger than our monitor spaces. I would agree that with monitor RGB it would take quite a bit of maneuvering. However, I have seen posterization occur when making heavy edits in a large space such as wide gamut RGB (and since proPhoto RGB is even bigger I would suspect it's more susceptible - we'll see); the heavy edits would be consistent with an image that wasn't very good to begin with. Also certain output devices are more prone to showing banding/posterization if they are wide gamut devices themselves but only support 8-bit/channel input; this makes them very dependent on those mere 256 levels per channel that are available.>>

Theoretically this is all true. To me, it's like asking how many angels can dance on the head of a pin. Nobody to speak of is using wide-gamut RGB. There are a lot better uses of our time than to investigate the question of whether it needs 16 bits. I *have* looked at the issue in Adobe RGB and don't see that the extra bits are useful there. As I mentioned earlier I would be anxious to see images from anyone that might contradict this.

>>This is certainly an important question, to know whether high-bit data, in the REAL WORLD actually makes a difference. I suspect it is extremely image specific as well as output device specific when it does occur.>>

I agree completely.

Dan Margulis


From: Dennis Dunbar
Date: Mon, Jun 5, 2000, 10:56 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch

Regarding the High bit space question I think it all comes down to just what you're doing with the image.

Most of the imaging I do is for Movie Posters and the like. It's very common for jobs to call for me to whack the colors and we're always looking out for bandng. If an Art Director has colorized the image using a Hue Sat adjustment then when I recreate the image for the finished version I have to be especially careful.

Another area where I see a distinct advantage to High Bit images is that airbrushing can be a bit smoother. I did a poster for the Blair Witch Project and in trying to vignette the face to shadow I was only able to achieve the smooth rollover we wanted in Live Picture. I attribute the smoother rollover to the fact that LP's paint layers were in 16 bit.

These cases may not be typical, but they are "Real World". It's just a case of what world you're in.

Dennis Dunbar
Phaedrus Productions


From: Chris Murphy
Date: Mon, Jun 5, 2000, 11:50 PM
RE: RE: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

> Perhaps you missed the post which created this thread ... but the
>logic of ProPhoto RGB space (ROMM RGB) was questioned. That is, how
>did Kodak "logically" arrive at gamma=1.8 and whitepoint=5000K??? I
>might want to try it for slide scans, but I'd be very tempted to
>"redefine" it for 2.2 and 6500K.

You cannot redefine it, just like you cannot redefine Wide Gamut RGB. If you change ANYTHING, you are no longer in that space, you have created a totally different space. These settings are not arbitrary. I hope to have an explanation on ProPhoto RGB in a couple of days.

D50 vs. D65 likely has to do with fewer errors in hue shift when transforming between two different white points through Lab (which the ICC specifies as being D50 Lab for the purposes of ICC profiles, which is what we're using here). The monitor being D65 has clear benefits but is NOT related to the working space white point. As for gamma, again I hope to have an understanding of why gamma 1.8 was selected over 2.2 and if it's even relevant.

I do know that Kodak was intending ProPhoto to be used (by and large, not exclusively) with high-bit data, so the gamma issue isn't related to bit-depth. 12-bits/channel data (let alone 16-bits/channel) is more than sufficient depth for whatever gamma you want to use to not be a problem. So the gamma 1.8 must have to do with something else.

Chris Murphy


From: Dave Badger
Date: Tue, Jun 6, 2000, 9:39 AM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Chris Murphy Wrote:

> If you don't convert data when importing, or opening a scan - you aren't
> compressing them at all. You're simply saying "my scanner behaves like
> Adobe RGB - or Wide Gamut RGB" or whatever space you have set in RGB
> Setup. You're asking Photoshop to make an assumption about the scanner
> that likely isn't true.

> For compression to occur, you need to either convert on open, or use the
> profile to profile command to actually bring the image the working space.
> Alternatively you can make an incorrect assumption (as above) and simply
> color correct on your calibrated/profiled monitor until you like what you
> see.

My drum scanner profiles bring the images in too blue. Am I better off coverting, and correcting this, then saving into my ColorMatch RGB working space, or hitting "Dont Covert" and correcting to the monitor?

If I do the latter, is my image now compressed into the ColorMatch space correctly? In other words, what happens to the color space when scans are brought into Photoshop with "Don't Convert"

Also, is an image more likely to suffer from 8 bit edits in "ColorMatch" vs "Adobe RGB" due to its smaller gamut?

-DB


From: jacob glazer
Date: Tue, Jun 6, 2000, 10:25 AM
RE: [ColorTheory] rgb working spaces

now that i have heard it all, I'm still uncertain as to which is the best working space for me-- since I have very high quality, full-range scans coming out of my scanner I don't want to 'convert' to a rgb space, but isn't photoshop still converting it when it brings it into a space? It displays the same, but it is not left alone anymore is it?

jacob


From: Dan Margulis
Date: Tue, Jun 6, 2000, 12:27 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Dave writes:

>>My drum scanner profiles bring the images in too blue. Am I better off coverting, and correcting this, then saving into my ColorMatch RGB working space, or hitting "Dont Covert" and correcting to the monitor?>>

If the images are always coming in too blue the problem should be attacked before going into Photoshop. If the scanner settings and/or profile can't be changed you should probably write a Photoshop Action that knocks the blue cast out automatically.

>>If I do the latter, is my image now compressed into the ColorMatch space correctly? In other words, what happens to the color space when scans are brought into Photoshop with "Don't Convert">>

A pixel comes in with a value of, say, 200R150G100B. If you convert, the idea is you get that same color, even if that color is constructed with different numbers in ColorMatch. If you don't convert, the idea is you get those same numbers, even if that would result in a different color in ColorMatch. It may or may not make a lot of difference depending on how different your profile is from ColorMatch.

So, if you know your incoming color is exactly what you want and that your profile is perfect, you convert, otherwise you have to recorrect the image every time.

Here, you know that your incoming data is *not* perfect. Converting is going to change that data, but whether for the better or the worse we don't know. Therefore, the answer to your question is: if you can't do anything at the scanner end, then get yourself two sets of half a dozen sample images, bring one set into Photoshop without converting and one set with, and then decide which method looks like it'll be easier to work with.

>>Also, is an image more likely to suffer from 8 bit edits in "ColorMatch" vs "Adobe RGB" due to its smaller gamut?>>

If anything, it would be the other way around. Those who favor using more bits believe that the wider the gamut is the more necessary the extra bits are.

Dan Margulis


From: Andrew Rodney
Date: Tue, Jun 6, 2000, 12:55 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

on 6/6/00 6:45 AM, Dave Badger wrote:

> My drum scanner profiles bring the images in too blue. Am I better off
> coverting, and correcting this, then saving into my ColorMatch RGB working
> space, or hitting "Dont Covert" and correcting to the monitor?

Do you have a good profile of that scanner? Ideally you'll have software in the scanner driver that takes into account the scanner profile, the display profile (for a soft proof) and an output profile (again for a soft proof and for scanning into that space). This output space could certainly be an RGB Working Space. In fact that's the preferred way to work unless you are supplying scans to others and want to give them the option of opening your raw scans in any Working or output space they wish. In that case you'd embed the scanner profile for conversion.

If you don't have software that can do this, the blue issue could be coming from several areas and the fix is based on this. Is the blue coming about from the inability to see what you are doing in the scanner software due to the lack of ICC support? Is the scanner profile causing this blue problem indicating that the input profile isn't a good one?

Correcting at the scan stage on high bit data is preferred. It saves time and produces superior files. Converting on open into your RGB Working Space and correcting (again on high bit would be preferable) can work but seems like a kludge to have to do this with every scan.

Simply opening a raw scan in your Working Space doesn't come close to insuring you are actually in that space. You have to do a specific conversion meaning you need a good input profile that describes the RGB the scanner is creating. It could be that the profile is fine and somehow you are introducing this blue with other scanner controls and maybe not seeing it. A lot depends on how you generated the scanner profile. If you don't have scanner software that fully takes advantage of the profile, I'd lock the scanner down in the exact same condition used to generate the profile. Then just make it a "dumb scanner" and scan away, convert on open using the scanner profile that describes that "dumb state" and go from there.

Seems overly complicated. The real issues are that most scanners simply don't have a clue how to deal with a necessary robust ICC workflow. There are a few (the scanners from Imacon, Heidelberg, the old ScanMate's etc). The key is having software that can soft proof the process just as Photoshop does.

Andrew Rodney
www.digitaldog.net


From: Andrew Rodney
Date: Tue, Jun 6, 2000, 2:15 PM
RE: Re: Dan-[ColorTheory] rgb working spaces

on 6/6/00 6:35 AM, jacob glazer wrote:

> since I have very high quality,
> full-range scans coming out of my scanner I don't want to 'convert'
> to a rgb space, but isn't photoshop still converting it when it
> brings it into a space?

Only if you specifically tell it to (convert on open) AND you specify a source profile (the profile of the scan). Otherwise you are simply opening the scan in a Working Space but the file isn't in that space. Previews are inaccurate and you are tagging the file as your Working Space when it's not. It's also questionable what kinds of editing you'd want to do in a scanner space as opposed to an editing space.

You probably DO want to convert into a Working Space or at the very least tag the file with a scanner profile to give the option to others down the line how they wish to convert into a editing space of their choice.

Andrew Rodney


From: Michael Shaffer
Date: Tue, Jun 6, 2000, 2:21 PM
RE: RE: [ColorTheory] rgb working spaces

jacob writes ...

> now that i have heard it all, I'm still uncertain as to
> which is the best working space for me--
> since I have very high quality, full-range scans coming
> out of my scanner I don't want to 'convert' to a rgb space,

why not? ... or is the problem "which space?" ...

Possibly one of the more knowledgeable subscribers will point us to an URL which lists an accepted breakdown of advantages vs disadvantages. Personally, I don't believe there is anything wrong with scanning with highbit depth into AdobeRGB. I've been exploring PhotoPro (ROMM) RGB, but I'd rather the keep control over shadows when I do convert to 8bit/channel provided by gamma=2.2. I always scan with highbits into PS5, and I continue to work with it while I develop the final 24bit color image. If I want my 24bit work editted in AdobeRGB, then it doesn't make much sense my highbit file is in PhotoPro, especially while presented with such a different gamma and whitepoint. It would be a different workflow if I scanned, finalized changes with highbits and then converted to 24bits, but I continue to work with and copy from the highbit file.

> but isn't photoshop still converting it when it
> brings it into a space? It displays the same,
> but it is not leftalone anymore is it?

PS5 will not convert if that is your preference ... it instead leaves the RGB data alone, but presents the data in your preferred working color space, which may of course be the wrong color space for RGB data from your scanner. If the "device dependent" profile for your scanner (and film) were accurate, then you should be comfortable having PS convert from "device dependent" into your "preferred working" color space. A question I have and wish answered is "should P-to-P conversions be done in one direction only? ... that is, wide-to-narrow and avoiding narrow-to-wide?" (... 'cept I imagine this is difficult to avoid sometimes, e.g., when your printer gamut is wider than your monitor in some respects. I also imagine the subscribers here are heavily weighted towards using working color spaces when the target IS hardcopy ...)

Lastly, be aware if you save your scanned image, not having converted it, it is still embedded with your working space profile ... it would be nice if at least it were the appropriate profile.

=shAf= :o)


From: Chris Murphy
Date: Wed, Jun 7, 2000, 2:33 AM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

>My drum scanner profiles bring the images in too blue. Am I better off
>coverting, and correcting this, then saving into my ColorMatch RGB working
>space, or hitting "Dont Covert" and correcting to the monitor?

In any event the monitor must be calibrated and profiled first or you don't know if the blue is coming from the scanner, or it's coming from the monitor. Once the monitor is calibrated and profiled - you have the option of color correcting based on what you SEE and make it look like you want and trust that's the basis for Photoshop's conversion to CMYK.

It can save a good deal of time to have a scanner profile to compensate for device behavior as *WELL* as dealing with tonal mapping of the image into the RGB working space. This tonal mapping allows you to bring as much data as possible into the working space before converting to CMYK; so in other words you maximize scanner behavior.

> In other words, what happens to the color space when scans are
>brought into Photoshop with "Don't Convert"

Photoshop assumes they are images with the RGB behavior defined in RGB Setup. If this is an incorrect assumption then you're not getting ideal results when you ask Photoshop to convert the image to CMYK (or use Profile to Profile to convert to an RGB output method).

>Also, is an image more likely to suffer from 8 bit edits in "ColorMatch" vs
>"Adobe RGB" due to its smaller gamut?

It is LESS likely to suffer from heavy editing because ColorMatch RGB is a smaller space than Adobe RGB. This isn't a reason to select ColorMatch RGB however, because Adobe RGB's larger gamut makes it more versatile for a wide assortment of final destinations for images; but at the same time it isn't SO large of a space that 8-bits/channel images are going to have banding/posterization when heavy edits are made to the RGB data.

Chris Murphy


From: Chris Murphy
Date: Wed, Jun 7, 2000, 4:52 AM
RE: Re: [ColorTheory] rgb working spaces

>now that i have heard it all, I'm still uncertain as to which is the
>best working space for me-- since I have very high quality,
>full-range scans coming out of my scanner I don't want to 'convert'
>to a rgb space, but isn't photoshop still converting it when it
>brings it into a space?

You have three choices:

1.) Do nothing. This means that Photoshop assumes your images behave per what's selected in RGB Setup. This is a bad assumption for images coming from digital cameras or scanners because they don't have behavior like the RGB spaces in Photoshop. You cannot turn this assumption off - Photoshop assumes what is set in RGB Setup for the behavior of RGB images. When you convert to CMYK, RGB Setup information is used for the basis of that conversion (in conjunction with information in CMYK Setup). So CMYK Setup can be right, RGB Setup can be wrong, and you can get a less than ideal separation just by choosing to ignore the problem.

2.) Don't convert; color correct the image on screen until you like it. If you have a calibrated & profiled monitor, you're seeing the image accurately as Photoshop perceives it (in terms of the color meaning of RGB values in the image); so that when the file is converted to CMYK, the CMYK version is substantially like the RGB image (within the limits of the devices).

3.) Convert the data from scannerRGB to working space RGB, apply tweaks/edits/selective color/replace color/sharpening/filters, convert to CMYK. This is ideal because it compensates for the scanner so you don't have to do unnecessary color correction to compensate for the peculiarities of your scanner.

In other words, the concept of turning color management OFF is a delusion. You can't do it. Photoshop makes some assumptions whenever viewing or doing a mode change on an image.

> It displays the same, but it is not left
>alone anymore is it?

I don't understand this part of the question.

Chris Murphy


From: "Dave Badger"
Date: Wed, Jun 7, 2000, 2:21 PM
RE: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Andrew Rodney Writes

> A lot depends on how you generated the scanner profile. If you don't
> have scanner software that fully takes advantage of the profile, I'd lock
> the scanner down in the exact same condition used to generate the profile.
> Then just make it a "dumb scanner" and scan away, convert on open using the
> scanner profile that describes that "dumb state" and go from there.

The profiles come from the Howtek web site for an older non-ICC aware scanner. It's definently the profiles as the results change whether I use the "Fuji" or "Kodak" files. Can you suggest custom profiling software to use on older drum scanners? We use Scitex Profile Wizard on our Iris proofer and ther're supposed to come out with an expanded version to use on everything. Any experience with this?

My second more important question is, when a scanner profile is created, then don't you have to always lock down the scanner in that "dumb state" for all scans? My flatbed is fully ICC and Photoshop compliant, but we still use the "Auto Levels" button (in the scanner software) to set highlight and shadow. It seems to me that would invalidate the scanner profile, but I'm confused on this issue. If we don't set Auto Levels, then we have heavy editing in Photoshop.

-DB


From: Andrew Rodney
Date: Wed, Jun 7, 2000, 3:30 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

on 6/7/00 6:04 AM, Dave Badger wrote:

> The profiles come from the Howtek web site for an older non-ICC aware
> scanner.

Then it's likely not very good unless we can assume that ALL such scanners operate identically (not likely) nor do we know how good the profiling package that generated the profile was. Bottom line, profile the scanner yourself so you have a custom description of that unit.

> We use Scitex Profile Wizard on our Iris proofer
> and ther're supposed to come out with an expanded version to use on
> everything. Any experience with this?

I haven't played with Profile Wizard in some time but I was pretty sure it made scanner profiles. If not, I'm quite happy with Praxisoft's products. WiziWYG Deluxe with a nice 4x5 IT8 should do the job for under $500.

> My second more important question is, when a scanner profile is created,
> then don't you have to always lock down the scanner in that "dumb state" for
> all scans?

Depends on the scanner software. In far too many cases, yes. That's because the software is stupid and hasn't a clue about using a profile within the rest of it's controls. Better, more modern scanner drivers like those from Imacon, Heidelberg, LaserSoft (which may have a driver for your Howtek) allow one to load the input profile, define the display profile for viewing and also define where the scan is going (the output profile). It then allows the user to control all aspects of the software while using all 3 profiles. That's the ideal way to work. Otherwise you have to find the best settings for a raw scan, profile to that and scan that way every time. Then apply the profile. It does speed up scanning to some degree but also takes away some control at that stage. Of course you can now do all the same work in Photoshop assuming you have a nice high bit file.

> My flatbed is fully ICC and Photoshop compliant, but we still use
> the "Auto Levels" button (in the scanner software) to set highlight and
> shadow. It seems to me that would invalidate the scanner profile, but I'm
> confused on this issue. If we don't set Auto Levels, then we have heavy
> editing in Photoshop.

As you can see, the scanner software is ICC compliant so you can feel free to use the auto controls (or others) and reap the benefits of the profile workflow and the scanner software designed to use it.

Andrew Rodney


From: Dan Margulis,
Date: Thu, Jun 8, 2000, 12:24 AM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Dave writes:

>>My second more important question is, when a scanner profile is created, then don't you have to always lock down the scanner in that "dumb state" for all scans? My flatbed is fully ICC and Photoshop compliant, but we still use the "Auto Levels" button (in the scanner software) to set hightlight and shadow. It seems to me that would invalidate the scanner profile, but I'm confused on this issue. If we don't set Auto Levels, then we have heavy editing in Photoshop.>>

Correct on all counts. If the input is variable the profile loses most of its utility. If you're using the drum scanner properly, an accurate profile is an oxymoron.

That said, as with any other calibration method, if you see a consistent pattern developing, you should fix it. You indicated that almost all of your scans were too blue. This would suggest a simple fix to the profile, if you happen to have a profile editor or if Photoshop 6 winds up including one. Alternatively, you could just bag the profile and set up to scan directly into your Photoshop RGB.

Dan Margulis


From: Chris Murphy
Date: Thu, Jun 8, 2000, 3:55 AM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

>Correct on all counts. If the input is variable the profile loses most of
>its utility.

This is not true. An ideal scanner profile allows conversions of raw scanner data to suitable editing space with reduced contrast. Thus all of the information in the original (that the scanner can see) is in the scan when you scan raw. Converting reduced contrast into the working space retains all of the data without any clipping at either end giving the user the flexibility of deciding what to do with the image while at the same time the profile has eliminated device specific color casts and tonal irregularities.

There is nothing contradictory setting levels after applying an ICC profile, and the profile absolutely does not lose its utility. This workflow method is actually the strongest reason for using a scanner or digital camera ICC profile.

>If you're using the drum scanner properly, an accurate profile
>is an oxymoron.

Where'd you get that one, Dan? Most drum scanners have a means to compensate for excessive magenta in blues, but not enough magenta in reds. Arguably most scanners don't have this capability unless they support ICC profiles. This is impossible to do without table based compensation of some kind.

Profiling a scanner has plenty of value, and several packages allow you the option of reproducing an original as closely as possible without any intervention (which means some images will have one end or the other, or both, clipped) for consumer level "hands free" profiles, or more absolute rendering, or reduced contrast for professionals. The idea is that profiles don't eliminate the human aspect, but it significantly reduces color matching and tonal irregularities that will take a human some fussing to fix; it also necessitates they are going to need to make a decision about setting white, black and gamma in levels on a per image basis which is the idea in a professional environment anyway (that a pro is going to be making these decisions).

Chris Murphy


From: Chris Murphy, lists@colorremedies.com
Date: Thu, Jun 8, 2000, 3:53 AM
Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

>My second more important question is, when a scanner profile is created,
>then don't you have to always lock down the scanner in that "dumb state" for
>all scans? My flatbed is fully ICC and Photoshop compliant, but we still use
>the "Auto Levels" button (in the scanner software) to set hightlight and
>shadow.

The scanner software, if fully ICC compliant, will have a means to set the scanner into raw mode so automatic correction isn't applied, and the scanner is set to maximum dynamic range. The profile is made with this in mind. Subsequent scans are made in raw, full range mode by the scanner software, which then applies the profile to the data before giving you access to it. So scanner peculiarities are removed by the time you get to the data. For each image, you will need to set the white point using either curves or levels, or autolevels. The profile isn't designed to set white and black because these are image specific (or more accurately, original specific); it's just designed to perform both a tonal mapping and color "matching" function.

> It seems to me that would invalidate the scanner profile, but I'm
>confused on this issue. If we don't set Auto Levels, then we have heavy
>editing in Photoshop.

Setting levels does not invalidate the scanner profile when levels are set AFTER the profile has been applied - this is how ICC compliant scanner software will work. It will apply the profile with each scan (assuming you have an ICC profile selected within the scanner software) before you even have access to the data, so there is no problem with optimizing your scan once the profile has been applied.

Chris Murphy


From: Andrew Rodney
Date: Thu, Jun 8, 2000, 9:31 AM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

on 6/7/00 8:07 PM, Dan Margulis wrote:

> If the input is variable the profile loses most of
> its utility. If you're using the drum scanner properly, an accurate profile
> is an oxymoron.

That's absurd. There are drum scanners (ScanMate running ColorQuartet) that are fully ICC compliant and allows the use of ALL scanning tools with the ICC profiles. The profile only loses it's utility when scanner manufacturers don't understand how to write software to use them. Another drum scanner (a CCD drum) that gets it right is the Flextight running ColorFlex. A third example is the Heidelberg Tango running either NewColor or LinoColor. All scanners above allow the user to profile the scanner to describe the RGB and fully use all controls in the software with that profile (curves, levels, selective color etc).

> Alternatively, you could just bag the profile and set up to scan > directly into your Photoshop RGB.

How would he handle a conversion into a Photoshop RGB space without a source? Oh he could make the scan look good and call it monitor RGB. That's a pretty low tech solution with plenty of restrictions on the color. OK you don't mind working in AppleRGB or sRGB (actually approximations of those spaces).

Andrew Rodney


From: Chris Murphy
Date: Thu, Jun 8, 2000, 1:29 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Andrew writes:

>The profile only loses it's utility when scanner manufacturers
>don't understand how to write software to use them.

I would say it still has utility, it's just that the scanner's software loses it's utility since I'm going to have to lock down the software to get consistent raw scans time after time; and apply the profile in Photoshop and use Photoshop tools instead of scanner tools. This isn't a bad workflow actually. If you have a lot of scanning to do, you can get the scanning done a lot faster by dumbing the scanner process, capturing full range high-bit data, and sending images off onto skilled Photoshop users for manipulation (instead of doing that on the scanner itself).

If the scanner doesn't support high-bit mode, then I would recommend dumbing down the scanner, then I would use scanner software to select a white point and black point for each image (of course this would have been done on the IT8 as well for making the scanner's profile); then bring into Photoshop and apply the profile.

The only time a profile loses it's utility is when:

1.) The software automatically color corrects each image and you can't turn this feature off (newer Polaroid scanners come to mind)

2.) The software has proprietary calibration/characterization process that creates tables that compensate for scanner behavior.

Chris Murphy


From: Dan Margulis
Date: Thu, Jun 8, 2000, 2:46 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Chris writes:

>>There is nothing contradictory setting levels after applying an ICC profile, and the profile absolutely does not lose its utility.>>

Yes, but he was talking about applying it at the scanner level, BEFORE applying the profile, and the profile DOES lose its utility if he does that.

>> >If you're using the drum scanner properly, an accurate profile
>is an oxymoron.
Where'd you get that one, Dan? Most drum scanners have a means to compensate for excessive magenta in blues, but not enough magenta in reds. Arguably most scanners don't have this capability unless they support ICC profiles.>>

If I might suggest, if you read the phrase before pasting it in, your response will be more logical. What part of "drum scanner" don't you understand? Whether "most scanners" don't have this capability is off point. When I said drum scanner, I meant drum scanner, and I reiterate that if one is using a drum scanner properly a profile is a waste of time.

>>Profiling a scanner has plenty of value>>

So does profiling a can of anti-Newton spray, a camera bag, or a lunch at McDonald's. Unfortunately, the person it has value for is ordinarily not the user.

Dan Margulis


From: Andrew Rodney, andrew@digitaldog.net
Date: Thu, Jun 8, 2000, 3:15 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

on 6/8/00 9:49 AM, Chris Murphy wrote:

> I would say it still has utility, it's just that the scanner's software
> loses it's utility since I'm going to have to lock down the software to
> get consistent raw scans time after time; and apply the profile in
> Photoshop and use Photoshop tools instead of scanner tools. This isn't a
> bad workflow actually. If you have a lot of scanning to do, you can get
> the scanning done a lot faster by dumbing the scanner process, capturing
> full range high-bit data, and sending images off onto skilled Photoshop
> users for manipulation (instead of doing that on the scanner itself).

I agree that the Photoshop route has a lot of merit but we need to be sure we can save out high bit data from the scanner. But from a workflow perspective, either locking down the scanner and using a profile (or doing very minor tweaks) and saving out high bit really is a good move. You can get a relatively unskilled scanner operator and just pass the data over the network to multiple users to do the corrections. The scanner can produce a lot more scans per hour when you simply crop, set resolution and scan away. Plus there aren't many scanner drives that come close to the control you have in Photoshop.

Andrew Rodney


From: Andrew Rodney,
Date: Thu, Jun 8, 2000, 4:08 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Dan Margulis wrote:

> Yes, but he was talking about applying it at the scanner level, BEFORE
> applying the profile, and the profile DOES lose its utility if he does that.

And Chris is still correct. The scanner software is ICC compliant. You are supposed to load the scanner profile in the software before you do any work. How can the scanner provide the correct preview or numbers until you do this. Again, you CAN with the correct software, load (define) the scanner profile THEN use the software with that profile. Get yourself a copy of LinoColor and see.

> If I might suggest, if you read the phrase before pasting it in, your response
> will be more logical. What part of "drum scanner" don't you understand?
> Whether "most scanners" don't have this capability is off point. When I said
> drum scanner, I meant drum scanner, and I reiterate that if one is using a
> drum scanner properly a profile is a waste of time.

What the heck is the difference in a drum scanner or a CCD scanner in this case besides the sensor? Nothing. There are at least two drum scanners (yes real PMT drums) that operate with ICC profiles as I described above and the profile is anything but a waste of time. It's used no differently then any other CLUT. When you do an on the fly conversion into CMYK, what's the difference if you have a PMT drum or a CCD? Nothing. The CLUT (in this case an ICC profile) is used on the input side just like some CMYK CLUT is used for the output side. It's no more a waste of time on any kind of scanner on the input side as the output side. Dan, it's time you started working with scanners that were made AFTER Jimmy Carter was president!

> So does profiling a can of anti-Newton spray, a camera bag, or a lunch at
> McDonald's. Unfortunately, the person it has value for is ordinarily not the
> user.

Another cute sounding, completely illogical and incorrect statement that has nothing to do with the issue at hand; profiling a scanner.

Andrew Rodney


From: Chris Murphy
Date: Thu, Jun 8, 2000, 5:21 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

>Yes, but he was talking about applying it at the scanner level, BEFORE
>applying the profile, and the profile DOES lose its utility if he does that.

It's less than ideal; but you can do it without losing the benefit of the profile. If you set white & black on the IT8, make a profile - you can then set white and black for each image BEFORE applying the profile. I recommend this for 8-bits/channel scans. For high-bit I recommend bringing the image into Photoshop and applying the profile first, then set white and black in levels.

His scanner software is ICC savvy which means it will apply the profile first, and apply his levels adjustments afterward.

>Most drum scanners have a means to
>compensate for excessive magenta in blues, but not enough magenta in reds.
>Arguably most scanners don't have this capability unless they support ICC
>profiles.>>

I should have written "most drum scanners do NOT have a means to compensate for excessive magenta in blues, but not enough magenta in reds." Most of them do not support table based conversions; those that do support them RGB to CMYK. Few support RGB - RGB table based conversions in order to compensate for scanner behavior, as well as to properly map tonal data into the working space.

>If I might suggest, if you read the phrase before pasting it in, your
>response will be more logical. What part of "drum scanner" don't you
>understand? Whether "most scanners" don't have this capability is off
>point.

I said "most drum scanners" not "most scanners".

>When I said drum scanner, I meant drum scanner, and I reiterate
>that if one is using a drum scanner properly a profile is a waste of time.

I totally disagree, Imacon disagrees, Heidelberg disagrees, those who use profiles on their drum scanners will disagree. I have a customer with an old Howtek scanner that will not let him compensate for the quartz based light source, and he consistently cannot get good blues without creating an overall cyan cast in his images. Howtek has no solution. Creating a profile for this DRUM scanner solved the problem by allowing cyan to be raised only in blue and no where else in the image (actually we increase blue a bit, and decrease red and green more, since this is an RGB scanner). This flexibility doesn't exist in a majority of scanners of any kind, drum or flatbed.

>>>Profiling a scanner has plenty of value>>

>So does profiling a can of anti-Newton spray, a camera bag, or a lunch at
>McDonald's. Unfortunately, the person it has value for is ordinarily not
>the user.

Oh whatever Dan - lets try to come up with a more tangent analogy next time. It's as bad as if I were to say, "If you don't use profiles, you're color is going to suck, and you're going out of business." It's inflammatory as well as false.

The value is as much for the operator, as the customer, as the business performing the scan in the first place. It absolutely saves time and the more advanced tonal mapping strategies in newer profiling packages allows for more flexibility on the part of the person who will be color correcting the image. It lets them choose what parts of the image are important by giving them a scan with all of the data in it.

Chris Murphy


From: Peter Figen
Date: Thu, Jun 8, 2000, 6:02 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Dave Badger wrote:

> The profiles come from the Howtek web site for an older non-ICC aware
> scanner. It's definently the profiles as the results change whether I use
> the "Fuji" or "Kodak" files. Can you suggest custom profiling software to
> use on older drum scanners?

No one bothered to ask you which of the older Howtek's you're using, and what interface you're using with it? It's possible that all you need to do is upgrade to the latest software.

If the profiles were ICC profiles that you got from the Howtek website, how could they be for "an older non-ICC aware scanner"? I've used several of the profiles from the Howtek ftp site with great success. I don't know if they are the same profiles that you got. I've used those profiles on more than one scanner with very similar results. I know there was some discussion recently about the validity of these sort of profiles on different machines. I think, but I'm not sure, that once the scanner goes through its log density calibrations on the clear and white strips of the drum, that different scanners of the same model, may react very similarly. That has been my experience. I seem to remember that Imacon ships some sort of generic input profile with ColorFlex.

I also just purchased the hand measured Fuji Provia IT8 transparency target ($530)and made several different input profiles with it on my Howtek 4500 using CompassProfile. So far, it appears to working extremely well, with absolutely none of the crossover, gradation, or shadow detail problems that I had making similar profiles with the Kodak IT8. It's not an easy item to find and seems like it's overpriced (it comes in a handsome binder), but now that I have it and have used it, it seems like a bargain, especially when you consider how many friends want to borrow it.

To that end, and I'm using the pre-release beta version of Trident 4.0, I'm able to load the input and monitor profile and embed the profile in the file. I'm also able to make endpoint and color adjustments in the software and have the screen match exactly what I subsequently open in Photoshop. Maybe because this is a beta version, there is still a problem converting to an RGB workspace, but I just do that on opening the file in Photoshop, which gives you far more options anyway.

Peter Figen


From: Chris Murphy
Date: Thu, Jun 8, 2000, 11:12 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Dave Badger wrote:

> The profiles come from the Howtek web site for an older non-ICC aware
> scanner. It's definently the profiles as the results change whether I use
> the "Fuji" or "Kodak" files. Can you suggest custom profiling software to
> use on older drum scanners?

I've had very good success with Kodak's ColorFlow suite of products, in particular Profile Tools (also known as profile editor) which will create all kinds of profiles (monitor, scanner, output, abstract, and device link) plus allows you to edit profiles including scanner profiles. It's one of the only packages that allows you to edit scanner and monitor profiles. Catch is that this is their high-end package and comes with a high-end price, about $2500.

Alternatively, their Input Profile Builder has a fantastic Reduced Contrast option (and I think they will have a few new tonal mapping strategies posted on their web site soon) that I really like. It's definitely worth the efffort, cost is $395. It has a wizard style interface and you can make a profile in a matter of minutes.

Chris Murphy


From: Dan Margulis
Date: Fri, Jun 9, 2000, 6:45 AM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Chris writes:

>>I should have written "most drum scanners do NOT have a means to compensate for excessive magenta in blues, but not enough magenta in reds.">>

Well, one can understand how the sentence can be misunderstood if "not" is missing.

In fact, almost all drum scanners have exactly this capability and have had it for more than 20 years. Every Hell, Crosfield, and Screen model made from around 1978 on has had this. Reduce magenta in blues and add it in reds? Just twist the magenta-in-blue dial one way and the magenta-in-red dial the other. Many models can even do it in a specific tonal range. The Photoshop Adjust: Selective Color command is (and was identified in its initial documentation) an attempt to mimic drum scanner functionality.

If you see a picture of an older model of such a scanner you will usually see an array of 24 dials somewhat removed from the main panel. That is the function of these dials.

It's hard to imagine how a high-end scanner could be effective without a selective color function. It's hard to imagine how someone who doesn't understand this can feel impelled to instruct drum scanner users on how to reinvent this particular wheel.

This thread should come to an end. While one can sympathize your frustration at the lack of adoption, surely you have made your views unmistakably clear on this point, and further discussion amounts to mere mailbombing. Perhaps you might be able to persuade Andrew to sell you a profile that might compress the volume of such posts into a gamut more appropriate for the group.

Dan Margulis


From: Chris Murphy, lists@colorremedies.com
Date: Fri, Jun 9, 2000, 2:31 PM
RE: Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

>In fact, almost all drum scanners have exactly this capability and have had
>it for more than 20 years.

Sure, on a manual basis that needs to adjust on an image by image basis; the knobs are for adusting image content, not for adjusting the scanner itself, although plenty have no choice but to chase these problems manually because there is no other way to do so without the automatic application of some form of table to do it for you.

I don't see why this is such a big deal. The result is the same, the scanner behavior (if consistent) can be compensated for in an automatic way without penalty. So why not do it so long as it saves time?

>It's hard to imagine how someone who doesn't
>understand this can feel impelled to instruct drum scanner users on how to
>reinvent this particular wheel.

It's hard to imagine how someone who claims to understand the benefits of table based profiles (ICC or otherwise) says they have no utility if the scanner is properly configured. Properly configured does not mean automatic compensation of device specific anomalies; properly configured to does guarantee match colors that can be match; properly configure does not mean inherent maximizing of dynamic range of the scanner to capture maximum tonal information in a given image; properly configured 20 years ago does not mean there isn't a better way today.

>This thread should come to an end.
Fine - last post.

>While one can sympathize your
>frustration at the lack of adoption, surely you have made your views
>unmistakably clear on this point,

While one can empathize your frustration with 7 in 10 posts over the last two months originating with some form of color management in mind, you have made your views unmistakably clear on this point. It works both ways, Dan.

>Perhaps you might be able to persuade Andrew to sell you a
>profile that might compress the volume of such posts into a gamut more
>appropriate for the group.

An extremely high number of my posts and Andrew's posts are answering questions on the topic originated by others. I don't think you're seeing either one of us originating posts on the topic of color management.

Chris Murphy


From: "Dave Badger", dbadge@worldnet.att.net
Date: Sun, Jun 11, 2000, 2:03 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

Peter Figen Wrote:

>No one bothered to ask you which of the older Howtek's you're using, and what
>interface you're using with it? It's possible that all you need to do is
>upgrade to the latest software.

I'm afraid I've fueled this debate by not being clear enough on my equipment configurations.

I'm using a Howtek 7500 with Aurora 3.0 software which is non-ICC compliant. (I tried the Trident 3.5 for 90 days and found the interface clunky, confusing, and the scans superior to Aurora only part of time, so I sent it back.)

The question is: when doing RGB scans is it *worth* using profiles on older scanners. The profiles I downloaded are for the 7500, but I see no improvement over not using them. Here, Dan's point makes sense. The software has no clue how the profile was made (canned nor custom). The scan is already done before applying the profile, so if the highlight-shadow was properly set for the image, then it inevitably is different from when the target was scanned and therefore the profile is inaccurate.

However, a previous post suggested there are still benefits from mapping tonal values from the scanner space to Photoshop RGB. IF, this is true, I should use the canned Howtek profiles and just correct them in Photoshop (i.e. subtract blue from the highlights).I hesitate to "dumb down" the scanner as even though its a 12 bit scanner, I believe it's delivering 8 bits to Photoshop.

Fortunately, most of my work is still CMYK from the scanner and as Adobe recommends against transforming in the CMYK space I know of no reason to use profiling with this workflow.

My other scanner is an Epson 836XL flatbed with Silverfast 4.x. I now understand that it applies the scanner to input profile before any adjustments in the Silverfast software and therefore maintains it validity. Thank you all for clearing that up.

-DB


From: Chris Murphy
Date: Mon, Jun 12, 2000, 1:31 PM
RE: Re: Dan-Re: [ColorTheory] "I shifted to Adobe RGB from ColorMatch"

>The question is: when doing RGB scans is it *worth* using profiles on older
>scanners. The profiles I downloaded are for the 7500, but I see no
>improvement over not using them.

It is extremely debatable how helpful a canned profile is. Unless Howtek publishes the expected scanner behavior the profile was made, I would find the helpfulness of such a profile dubious. In fact, it's possible for a canned profile to make matters worse, although this is more common for monitor profiles than scanner profiles. Your specific scanner is going to have different behavior even at the same settings as another 7500, let alone the one used to make the canned profile which was likely a brand new scanner. Even scanner software versions can make a difference.

>The scan is
>already done before applying the profile, so if the highlight-shadow was
>properly set for the image, then it inevitably is different from when the
>target was scanned and therefore the profile is inaccurate.

This is not as big of a problem as it would seem. The key is consistency. You are not changing the color behavior of the scanner. You're only telling it about the dynamic range of the image you're scanning. You're "normalizing" the scan to have a set white and black that is consistent with the white/black point settings used to make the profile in the first place. This method is recommended when you can only export 8-bits/channel. This is because setting white/black in the scanner software allows more than 8-bits/channel to be used for the stretching of the histogram; then downsampling occurs to 8-bits/channel after the fact.

When you can export high-bit scans, then there isn't a need to set white and black in the scanner software because you have access to high-bit data even in Photoshop. There you can apply the profile, then go into levels and maximize the existing data as you see fit.

>However, a previous post suggested there are still benefits from mapping
>tonal values from the scanner space to Photoshop RGB. IF, this is true, I
>should use the canned Howtek profiles and just correct them in Photoshop

As I mentioned earlier, I wouldn't judge scanner profile performance based on a single profile let alone a canned profile. Everyone has their own preferences. I could build a number of profiles, all of which would have slightly different behavior with your scanner on the same settings. Scanner profiles don't really say "this is how this scanner behaves" universally. You *can* make such a profile, and it can be helpful for certain tasks, but there will be a trade off. Usually scanner profiles have some kind of tonal mapping function to go from scanner RGB to the PCS (that enigmatic term again) and there are reasons to have slightly different tonal mapping functions for different scanners, sometimes images, and definitely personal preferences. Usually most people do not have more than four or five profiles for a scanner or digital camera. Many of my customers have two or three.

I would suspect this canned profile simply does not suit your scanner, and just as possible does not suit your personal requirements.

>I hesitate to "dumb down" the
>scanner as even though its a 12 bit scanner, I believe it's delivering 8
>bits to Photoshop.

Yes exactly; that's why you don't want to dumb down the dynamic range. That's why it's OK to set white and black, to maximize the scanner's ability to capture as much information as possible with each image.

>Fortunately, most of my work is still CMYK from the scanner and as Adobe
>recommends against transforming in the CMYK space I know of no reason to use
>profiling with this workflow.

Ultimately you should use what works, regardless. I'm not sure I understand this Adobe recommendation against transforming in the CMYK space. I don't know what that refers to.

In any event, some profile is being used. Howtek must make some assumption of RGB in order to convert scans on the fly to CMYK. So either it's built-in permanently, or it's a proprietary file of some kind; but it's still there.

Chris Murphy

Adobe Photoshop training classes are taught in the US by Sterling Ledet & Associates, Inc.