Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

   


   


   















      :: Filmscanners
Filmscanners mailing list archive (filmscanners@halftone.co.uk)

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

[filmscanners] Re: Channel alignment test for B&W scanned as RGB



Art

If it was a difference in the different focal points of different colours I
would have thought it would be apparent in all scans, even colour
transparency, and I have not seen it in transparency scans thus far.  This
has been noted consistently in black and white being scanned as RGB,
although as I said, I cannot reproduce the problem on the SS120.
Apparently, Imacon stated that the misalignment occurs in all scans,
whatever stock, but you can only see it on monochromatic stock because it is
a tri-colour scanner trying to produce completely neutral tones in RGB.  The
indications are that it is within what they regard as acceptable limits.

As someone who has worked closely with scanners and the technology, do you
know if there are normally vendor defined limits for the accuracy of the
scanning equipment, such as in the case of the alignment of the channels
where, as you stated, the tri-line sensor is actually recording a different
part of the film for each color at any one point in time.

Simon

----- Original Message -----
From: "Arthur Entlich" <artistic-1@shaw.ca>
To: <simon@sclamb.com>
Sent: Thursday, May 23, 2002 11:44 AM
Subject: [filmscanners] Re: Channel alignment test for B&W scanned as RGB


> Are you sure this isn't a result of the different focal points of
> different colors?
>
> You've probably noted that infrared, for instance, has a fairly large
> difference in focal point than the visible spectrum (the offset is
> indicated on most lenses as a red line or dot).  This holds true for the
> visible spectrum as well, but it is not usually that noticeable until
> you  look pretty closely.
>
> However, it is true that the film could shift, wobble or change
> dimensionally enough that the difference at scanning times/location
> could show up as well, since the tri-line sensor is actually recording a
> different part of the film for each color at any one point in time.
>
>
>  >>>=================================>>>> film
>             \|/    \|/    \|/
>          ---RRR----GGG----BBB---
>         |_______________________|
>               CCD    SENSOR
>
>
> Art
>
> Simon Lamb wrote:
>
> > There is a debate on-going on the Imacon users list regarding channel
> > misalignment when scanning black and white stock as RGB.  If anyone has
the
> > time to undertake a smal test could you do the following:
> >
> > 1. Scan a black and white negative as Positive and save at max
resolution as
> > 16-bit RGB.
> > 2.  Open the file in Photoshop and view at 100%.  Using the channels
> > palette, skip between the R, G & B channels (Control 1, 2 & 3) and look
to
> > see if the image moves (sometimes by between 2 and 4 pixels) between
each
> > channel.
> > 3.  If it moves then it shows other scanners have the same problem
aligning
> > channels when scanning monochrome stock using RGB sensors, which in some
> > cases causes the image to show stretching across the grain.
> >
> > Useful scanners to try this on would be those competing in the Imacon
Photo
> > arena (Nikon 8000, Sprintscan 120, Multi Pro etc.).
> >
> > Thanks to anyone who can do this test and post their findings.
> >
> > Simon
> >
> >
> >
>
>
> --------------------------------------------------------------------------
--------------
> Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe
filmscanners'
> or 'unsubscribe filmscanners_digest' (as appropriate) in the message title
or body
>

----------------------------------------------------------------------------------------
Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe 
filmscanners'
or 'unsubscribe filmscanners_digest' (as appropriate) in the message title or 
body



 




Copyright © Lexa Software, 1996-2009.