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: film and scanning vs digital photography



Of course, things get even more complex than distinction between what we
often refer to as "grain" (which as the reference states is actually
different densities of grain clumps), in black and white, and that of
color films which have no actual "grain" but instead dye clouds which
either formulate around the grain clumps, or replace the grain clumps,
depending upon which color process was used.

The problem you discuss in regard to mpeg compression of cine film grain
(or dye clouds) is not different than what occurs with still frames of
film which get scanned.  The problem is while the grain lumps/dye clouds
define the image, their actual existence isn't image information in the
true sense of the word, but the "substance" the images is made from.
All that "noise" makes for a horrible amount of excess data.  It seems
we still haven't developed the complex algorithms to separate the grain
from the actual image data.  Some of the Applied Science Fiction (Kodak)
filters come closer than basic pass filters, but I'm not sure we yet
have the processing speed to really remove graininess without loss of
resolution.

Art

R. Jackson wrote:

>On Jul 4, 2007, at 11:28 PM, Arthur Entlich wrote:
>
>
>
>>However, if the same processing that is done to digital images in
>>camera were done to the film image, a lot of the grain could be
>>suppressed.
>>
>>
>
>Yeah, but would you want to suppress the grain? I did a test for a
>video camera manufacturer last year. They were interested in seeing
>if their mpeg encoder would be practical in a telecine situation. To
>the encoder the grain structure is just noise, so it ground away
>ruthlessly trying to suppress as much of the "noise" as possible. The
>up side was that 720p transfers of 8mm footage were possible and
>looked pretty decent. The down side was that if you stopped on a
>frame and examined it closely there was a sort of cross-hatch
>aliasing pattern all over the image where the mpeg encoder had tried
>to smooth out that hideous noise that seemed to be absolutely
>everywhere. At the end of the day the thoughts of the engineers were
>that to get close to an acceptable mpeg compromise would result in
>very large files and require a lot of processing power to encode
>them. The market was really too small for them to bother.
>Uncompressed video still seems to be the best format for capturing
>telecine passes.
>
>IMO, most "noise reduction" attempts at reducing grain in scanned
>film looks bad. I use ICE occasionally or Noise Ninja sometimes in
>selected problem areas and then fade it a bit to reduce the grain
>when something is particularly grainy, but it can look really bad if
>you aren't careful. The ideal situation, IMO, will arrive when
>scanning at resolutions sufficient to completely and accurately
>reproduce the grain structure exist and are practical for
>photographic use. Look here:
>
>http://www.imx.nl/photosite/technical/Filmbasics/filmbasics.html
>
>See the 400x magnification? If that level of capture detail existed
>in your film scans and you had no issues with aliasing I think it
>would be pretty significant. The files will be enormous, though, and
>you'd have to really enjoy the artifacts of the medium to even
>bother. I'd bother, though. I imagine it will be another decade
>before that kind of technology is accessible to people for fine arts
>use in any practical sense, but I'll be at the head of the line.
>
>-Rob
>
>
>
>

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