ðòïåëôù 


  áòèé÷ 


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: Newish Digital Tech



> From: David J. Littleboy
>
> That's exactly the oppposite of my conclusion. The X3 in the SD9 is used
> without an anti-aliasing filter, and a quick glance at the
> resolution charts
> shows that while it resolves nicely up to about 1000 lph, above that its a
> mass of aliasing artifacts. It shows a lovely strong response to
> a 1550 lph
> pattern, but it gives exactly the same response at higher frequencies as
> well, and fails to resolve patterns between 1100 and 1550 lph. I
> doubt that
> people will find it acceptable for serious work since you simply
> can't trust
> any detail it reports.

But _any_ pixelated sensor will alias if it doesn't have a diffuser in front
of it. The point of the Foveon chip is that the aliases are the same for all
colors, so you don't get color moire from a monochrome texture.

> There's no speed problem that I've ever heard about with Bayer sensors.
> Speed problems in digital cameras are always due to handling the
> large files
> after capture. If anything, X3 will be worse, since raw files
> will be three
> times larger than Bayer raw files.

It's certainly true that digicams are slowed down by the limited speed of
the storage medium, and this is exacerbated by increasing the file size.
However, the really good Bayer decoding algorithms, like Variable Number of
Gradients, are very CPU intensive. When I decode the raw files from my
Minolta DiMage 7 using their PC utility, or a couple other PC-based programs
I have for this purpose, it takes several seconds to decode them on a 1.7GHz
P4. The camera itself is capable of doing the conversion, plus JPEG
compression, in much less time, so I suspect the camera's using a simpler,
inferior algorithm (although I haven't noticed any artifacts). Not having to
mess with the conversion will save some CPU time in the camera, and as long
as the images are compressed, the writing time will be kept to a manageable
level. I'd rather spend the CPU time on JPEG2000 compression than on Bayer
decoding.

> Color rendition is problematic in the SD9...

That may just be an implementation problem with that particular camera. It
seems to me that any sensor that has has three filters with overlapping
bell-shaped spectral responses, centered on red, green and blue, is capable
of resolving all colors visible to the eye, given an appropriate profile.
After all, any color of perfectly saturated (i.e., laser) light will produce
a different combination of three numbers from the sensor, so suitable
arithmetic can turn these into perfectly saturated RGB values. The wider the
bandwidth of each filter, the more the colors will mix, requiring a larger
apparent gamut in the profile to compensate, but it can still be compensated
for.

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

----------------------------------------------------------------------------------------
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.