• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Is this a scum dot?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is this a scum dot?


  • Subject: Re: Is this a scum dot?
  • From: bruce fraser <email@hidden>
  • Date: Tue, 19 Nov 2002 10:40:33 -0800

At 2:53 PM +1100 11/19/02, Graeme Gill wrote:
bruce fraser wrote:
My compromise is a bit different from the one you suggested, and it's
one that's well-supported by most profiling tools, which generally
don't map the A16 patch to L*100 -- they do in fact look at the RGB
values and make sure that RGB 255 maps to L*100.

Profiling software that does this is seriously broken. In general
no scanner will exactly read RGB 255 given a (not practically realizable)
Absolute L*100 reflective sample. I can imagine scanner makers
aspiring for their scanners to behave that way (although they might
get themselves in to trouble with fluorescent samples reflecting
more than 100% light at certain wavelengths), but the whole purpose
of characterizing a scanner is to compensate for how it actually
behaves, as opposed to how it ideally behaves.

Mostly I scan film, which fortunately doesn't fluoresce. I can't get an ideal diffuser to fit in the film holder.


If the scanner is manually calibrated of course, then you
can get whatever behaviour you like out of it in this regard
(including getting RGB 255 to whatever relative L*100 you like).

I profile the scanner's wide-open 16-bit/channel behavior, and scan
everything wide open. I experiment to find the tone curve that will
produce the best agreement between the actual values in the target
and the predicted ones I get by assigning the profile to the scan,
converting to LAB, and comparing with the target values.

By "wide open" you mean running in its uncalibrated, "raw" RGB mode ?

With CCD scanners, there's generally no calibration to be done other than the scanner's internal one which is always done and can't be defeated. So raw in this context simply means not making any adjustments to black and white points.

By "tone curve", you mean a per channel calibration curve applied to
the raw RGB data before it hits the CMM ?

More likely a single output gamma value on a CCD scanner and a master RGB curve on a drum.

I'm not sure I understand where the profile comes from, that you
are using to get Lab values, to set up your tone curves. Seems
like a chicken and egg problem. You can't create the scanner
profile until you've decided on tone curves, yet you're using
some profile to choose your tone curves. Can you clarify how
this works ?

I scan the capture target at different gamma settings, and build a profile from each one. Then I assign the corresponding profile to each captured target and convert it to Lab. I compare these Lab values with those in the target description file, and choose the one that gives the lowest delta-e values, and use that gamma setting (or tone curve in a drum scanner) for all subsequent scans.

> I always want RGB 255 to map to L*100 -- it's the only way I know to
let me decide where my highlights go from specular to diffuse while
using all the bits.

If you are calibrating the scanner, then you can do anything you want.
I'm a bit puzzled about "what" L*100 you are getting RGB 255 to map
to. Absolute L*100 (how do you test it ?). If a Relative L*100, which
media - the IT8 chart white (I presume not, from your comments), the
white of the particular item being scanned ?

It's L*100 in the PCS. It's not a media white. It's the brightest white that the scanner can capture. In practice, I never capture this value during the scan.

If the latter, doesn't this imply calibrating the scanner to
each print you are scanning (viable for high value work, not
viable for more casual scanning).

No, I scan everything at the same setting. I edit the images. The reason for mapping specular white to L*100, which I do manually, image by image, is to ensure that on output, it translates to paper white via relative colorimetric rendering. Outside of proofing scenarios, the question of the absolute value of white in the image may be academically interesting, but if it gets translated literally to output it makes for ugly output, since the viewer's eye generally adapts to the paper white and judges all other colors in that context.

For any decent-quality work, scans need editing. The traditional prepress workflow did that by changing the response of the scanner to each original. I prefer to wait until I can see all the pixels and make the edits in Photoshop instead, knowing that I'm capturing everything the scanner can deliver.

The profile's role is simply to convert the raw scanner RGBs into a more friendly editing environment like a gray-balanced RGB working space, where I can optimize contrast and, to a lesser degree, saturation.

If someone can show me a more effective approach, I'm always willing to learn, but it's important to realise that when we scan E6 transparencies, the goal is hardly ever to reproduce exactly what's on the film, partly because in most output scenarios it's physically impossible to do so.

Bruce
--
email@hidden
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Is this a scum dot?
      • From: Graeme Gill <email@hidden>
References: 
 >Re: Is this a scum dot? (From: "Bruce J. Lindbloom" <email@hidden>)
 >Re: Is this a scum dot? (From: bruce fraser <email@hidden>)
 >Re: Is this a scum dot? (From: Graeme Gill <email@hidden>)

  • Prev by Date: Re: Black'n'White for Newspapers
  • Next by Date: Re: Is this a scum dot?
  • Previous by thread: Re: Is this a scum dot?
  • Next by thread: Re: Is this a scum dot?
  • Index(es):
    • Date
    • Thread