ðòïåëôù 


  áòèé÷ 


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: 8 bit versus 16



Art,
I concur with everything you have said except the last paragraph which
concerns something I have no knowledge about and no concern with, given that
I am not into gaming.  As I have noted in several of my posts, I see as a
potential positive for hi-bit scanning the fact that it furnishes more raw
data than a low bit scan and therefore provides for potential future
flexibility when creating archive master raw image files as ones final
output, which are to be used at a later date to generate working files for
specific purposes and output devices and  products( which in the future may
support high-bit files but not currently).  Otherwise, for general purposes,
high-bit scans as working files typically offer little added value overf an
8-bit file - except in a few rare (if not extreme) cases.

-----Original Message-----
From: filmscanners_owner@halftone.co.uk
[mailto:filmscanners_owner@halftone.co.uk]On Behalf Of Arthur Entlich
Sent: Wednesday, September 10, 2003 9:01 PM
To: laurie@advancenet.net
Subject: [filmscanners] Re: 8 bit versus 16


Hi Laurie,

This isn't about minutia, this is about belief systems and religion ;-)

The only real solution to deal with the zealotry would be a carefully
controlled double blind experiment.  Otherwise, we are indeed the blind
leading the blind, because simply, we shall see what we expect to see.

I am willing at accept that just like people's ability to hear musical
tones (AKA being "tone deaf" or not) some people are gifted with greater
color perception, and abilities to distinguish between them.  I happen
to have quite good color perception and color memory (i wish my event
memory was as good!), however, I "believe" tests would tend to show that
the vast majority within the bell curve cannot see the difference. I do
believe there is a small advantage to 16  bit files due to data getting
fractionated and pushed around slightly (although there really isn't a
very large step for it to go in either direction). But, if a great deal
of multiple manipulation is going to be accomplished a color could get
pushed a fraction of a 1/256th step in error. However, in terms of
printing, viewing on screen, etc, I think 16 bit files are of little to
no value, and that's even concluding that the scanner is really
capturing the full 16 bit depth, which many do not.

Regarding the matter of banding in 3D rendering, the as was mentioned by
another poster, that problem is due to use of unnatural restricted
pallets, and limited or no use of dithering, because random dithering in
a moving 3d object shows up as moving noise and it slows the rendering
process down, also.

Art


LAURIE SOLOMON wrote:

> On the face of it, this does seem to be another silly debate.  In his
> responses Austin covered his ass bymaking of point of sayin 16-bit is not
> necessary in most color scans as contrasted to all, which means that nay
> exception you bring up will be considered by his as an exception and not
the
> rule.  You on the other hand seem to have focused in on the needs of your
> own personal work flow and needs and not a general workflow or needs and
> come off as having an agenda of convincing others that your workflow is
the
> only good and acceptible one for everyone.
>
> If your work flow works for you and is something that requires you to
employ
> 16-bit scans as you perceive it, then you have to satisfy yourself and
> should stick to 16-bit scans.  If others think that 8-bit suffices for
their
> work than they should use that.  Neither has any need to convince the
other
> that what they are doing is justified much less the best and only proper
way
> to accomplish the goals at hand for each.
>
> Sometimes we become fanatical over trivial minutia which is not
significant
> to most and can not be dscerned by most even when they perform the
empirical
> experiments suggested.  Thus, for them this discussion becomes of as much
> practical relevance to their needs and work as knowing the number of
angles
> that can fit on the head of a pin.  If there is a key practical
significance
> to doing 16-bit color scans, it is to generate as complete a quasi-raw
data
> file as is currently possible from a scan for purposes of archiving as a
> master file off of which specific working files will be generated both now
> and in the future.  By doing a 16-bit scan of a color image, you capture
as
> much data as is now possible which may be of potential use in the future
as
> the software and hardware changes and approves to accomodate the use of
the
> additional data in a 16-bit file.  However, in many cases, the need and
> usefulness of a refined and tonally enhanced, extended 16-bit image file
as
> a working file that one is going to produce finished products from is of
> little practical use given today's software and hardware.
>
> If you or anyone thinks they see a difference in the final product when
> producing their work by using 16-bit as opposed to 8-bit scans, then by
all
> means they should use 16-bit scans and not worry about what anyone else
> thinks or says should be done.  If 8-bit is good enough for them, then
they
> should follow theirown light and disregard the opinions of those that push
> for 16-bit scans as the gospel.
>


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