ðòïåëôù 


  áòèé÷ 


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?




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



 




Copyright © Lexa Software, 1996-2009.