(Was Re: Macs vs PCs; 16-bit apps -- subject changed to protect the
intolerant... :-)
>From: Joe Gwinn <joegwinn@xxxxxxxxxxx>
>
>> From: Jan Steinman
>>Photshop use (memory intensive) benches at 2.2 times faster than a dual 3GHz
>>Wintel box...
>
>I'll wait for the benchmarks on actual computers.
I'm not sure what you mean -- those benchmarks WERE on actual computers, run by
an independent testing lab.
Or perhaps you meant waiting until you can run your own benchmarks?
>...Important but hard to quantify things like build quality, ease of use,
>suitability of the design for a specified purpose, et al, tend to get lost in
>the barrage of numerical noise. One mark of experience in a field is the use
>of such non-numerical qualities as a major consideration when choosing what to
>buy.
Thus we are all sophisticated, discerning folks for using OM cameras, no?
(Oops, accidental on-topic slip there... :-)
>I think there is a simpler reason for a Wintel user to be so reluctant to
>change: fear of the consequences of failed change... The risk incurred when
>making a change to a Wintel box far exceeds that incurred when making the same
>change in a Mac (or a UNIX box for that matter), so those fearful users are
>being perfectly rational.
I agree. However (food for Mac-haters here) I just got a Cinema HD display, and
can't get the damn thing to work! It displays the boot screen for a while, then
goes blank. I could ssh into the machine, and shut it down gracefully, but was
impatient, and so was turning it off and on, plugging and unplugging things,
trying to "shotgun" the problem.
The result of all this power cycling was a corrupted directory that fsck
couldn't fix. This isn't supposed to happen on a Mac! I spent ~$90 on Alsoft
DiskWarrior, and was able to fully recover the disk, but the whole experience
made me more sensitive to what my Windows-using friends and relatives go
through on a regular basis.
So perhaps I would not have been so hasty and impatient if I had had Windows
"frustration training." :-) (At least I've never had to completely re-install
MacOS, which seems to be a frequent event among Windows users.)
>I don't think images will go floating-point anytime soon, because FP is too
>space-inefficient a format, and FP arguably solves the wrong problem (as
>discussed later).
I appreciate your argument, but I can see another path.
>Ansel Adams, in his book on available-light photography, commented about the
>2500:1 illumination range he saw in a scene near his house, from white paint
>in direct sunlight to black dirt in shadow, and he used 13 zones (~stops) in
>that book, so we can conclude that a 2^13= 8,192 to one range of brightnesses
>is sufficient for all photographic purposes.
No, it was sufficient for THAT photographic scene. Scene contrast is not
absolute contrast!
>The minimum discernable difference in brightness is about 1% at the finest,
>varying with brightness. So, if one can express... 819,200 different
>brightness levels, one can in theory achieve practical perfection. This
>requires... call it 20 bits (per color)... In practice, 16 bits per color
>would be very difficult to distinguish from perfection.
But you are still talking about scene contrast, no?
I'm talking about the difference between staring at the sun, and shooting
during a new moon. It seems to me that SOME form of delta coding is going to be
more efficient than integers here, and since processors are already handling
floating point, it seems like a good match.
>The practical (instantaneous) range observed by Ansel is more like 13 stops...
Again, that's scene contrast. I think with falling memory prices and rising
processor speed, there may well be an opening for a delta coded format for
imagery, much as there is for audio. Such images would inherently be
"normalized," since they would encompass all the values one would ever need.
It's just a matter of selecting the proper mantissa and exponent, no?
The problem with binary is that light is exponential in nature. So let's say we
have a integer standard that encompasses the dynamic range you propose. Call it
24 bits per color, to fit byte boundaries.
You cite 1% as the minimum discernable brightness change. This fits in 7 bits.
So at the high end in a 24 bit-per-color image, aren't 17 bits being wasted? If
the most significant bit is set, the bottom 17 bits are "indiscernable" since
any combination of them results in less than the 1 hange you cite.
On the other hand, a delta code with a 7 bit mantissa and a 3 bit exponent can
express the same dynamic range as a 24 bit integer, no? This would preserve the
minimum discernable brightness change over a 21 octave dynamic range, while
requiring no more space than today's 8-bits-per-color images.
(I'm not actually advocating 8-bit floating point for images; just playing with
numbers to make my point.)
I think I follow your argument against decimal floating point. But binary
notation cuts short some of that argument:
>Now I want to code these numbers, to save storage space, so I allot a fixed
>number of decimal digits to the mantissa and also to the exponent, and assume
>that the decimal point is just after the first mantissa digit.
Don't use decimal digits, use bits! :-)
Perhaps I'm missing something, but I don't follow that an argument against
decimal floating point notation also holds true for binary floating point.
Things in binary floating point are not gridded to powers of ten, they're
gridded to powers of two.
>>All in all, it's an interesting time to be around. Whether one prefers
>>Windows or not, I think most people are glad Apple is out there, nipping at
>>Wintel's heels... :-)
>
>Yes.
Cool -- something we can agree upon!
Thanks for your insight and flame-less discussion, Joe. I also have a signal
processing background, but it is getting old, so I may have missed something
important...
--
: Jan Steinman -- nature Transography(TM): <http://www.Bytesmiths.com>
: Bytesmiths -- artists' services: <http://www.Bytesmiths.com/Services>
: HTML email goes right in the trash! Turn off HTML if you want to email me.
< This message was delivered via the Olympus Mailing List >
< For questions, mailto:owner-olympus@xxxxxxxxxxxxxxx >
< Web Page: http://Zuiko.sls.bc.ca/swright/olympuslist.html >
|