ðòïåëôù 


  áòèé÷ 


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: Digital Darkroom Computer Builders?



Thank you for your responses.  They helped me clarify waht was being said
and understand the two positions better.  Technically, it is beyond my
understanding and ability to deal with the engineering and physics specifics
of the arguments; but theoretically, I get the gist of the arguments being
made by both you and Anthony, which is helping me develop my position on the
subject.

>That reminds me of a question I sometimes ask myself -- how many
>people still use CMYK? I can't see the point of using a colourspace
>like that that has nothing in common with either input or output
>devices.

Here I do agree with Anthony.  CYMK is a fundamental element in almost the
entire printing process - even if in some areas it goes seen but unnoticed.
You do not directly deal with CYMK when outputing to inkjet; but the printer
converts to it and prints in that space as limited by the media and the
inks.  It is the CYMK output that one is trying to match in WYSIWYG.
Monitor displays are RGB but they make up only a small portion of the final
finished outputs both in terms of images and in terms of textual materials.
The Web may rely in RBG displays but most materials found on the web at some
point is downloaded and printed to hardcover by a goodly number of people.
Most bureaucrates and business people demand hardcopies of everything for
safety reasons and as backup which is why the "paperless society never
happened.

-----Original Message-----
From: filmscanners_owner@halftone.co.uk
[mailto:filmscanners_owner@halftone.co.uk]On Behalf Of Major A
Sent: Tuesday, October 22, 2002 9:43 PM
To: laurie@advancenet.net
Subject: [filmscanners] Re: Digital Darkroom Computer Builders?



> >You're joking? I think M$ are trying to make big money to such an
> >extent that they are seriously harming their long-term future
>
> Microsoft whichmay come back to bite it; however, if Amthony is not
correct,
> then your conclusion is unsupported.

I fully agree. It wouldn't be the first time they tried to cripple
their lower-priced products so as to force many desktop users to
upgrade to a more expensive alternative.

> >PowerMacs have had 64-bit address registers from the beginning, so no
> >practical limits there.
>
> But the architecture of the PowerMacs while different from the other
> architecture does establish parametric boundaries of its own just
different
> from those of a different architecture; am I not correct?  You are not

Absolutely. The limit there is 2^64 bytes, which, however, is so large
that I don't believe we will ever have to worry about getting close to
it. My argument for this is that 2^64 is a 20-digit number and thus
comparable to the number of silicon atoms in a complex electronic
device like a CPU or a memory chip. Unless something about electronics
changes drastically at some stage, we are never going to reach that
limit. By the time we reach only just 40 bits of actually used address
space in a desktop computer, all modern computers including PowerMac
and new architectures like IA64 will be in a museum anyway.

> greater limit is not as efficiently achieved.  In otherwords, you can
access
> more than 4 GB of RAM with the 32-bit architecture, practically speaking,
> but not as efficiently or effectively as you can access up to 4 GB of RAM.
> Whereas, the 64-bit architecture permits one to more effectively and
> effiicently access more than 4GB practically speaking; but at some point
one
> will again run into a wall where greater access may be achieved but at a
> price of efficiency and effectiveness until the theroetical limit is hit.

A fully agree. The inefficiency of using >4GB on x86 is not
significant, however, because most of the workaround is done by the
memory management unit, which doesn't introduce any delays at all. It
does, however, limit the memory space allocated to any one process to
4GB, that is a real limit of the x86 platform that is very hard or
impossible to get around without radically changing the concept of
linear address space inherent in all modern desktop operating systems.

> unacceptible for graphic uses.  However, on the matter of sRGB, I am
> inclined to agree with Anthony that this is the one-size fits all standard
> and not the most optimium standard possible and not one I would be using

That's right, sRGB was made as a universal compromise, not a panacea
for all colour problems. For critical work, a properly calibrated CMS
is still necessary, but in this respect LCDs and CRTs are no
different.

> either for my Photoshop working space, my monitor, or output device.  For
> now, I have geared everything around Adobe RGB 98 which for the present
> seems to be the best compromise for my purposes and uses.

That reminds me of a question I sometimes ask myself -- how many
people still use CMYK? I can't see the point of using a colourspace
like that that has nothing in common with either input or output
devices.

  Andras

===========================================================================
Major Andras
    e-mail: andras@users.sourceforge.net
    www:    http://andras.webhop.org/
===========================================================================

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