A Photography forum. PhotoBanter.com

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PhotoBanter.com forum » Digital Photography » Digital Photography
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

"16-bit" mode.



 
 
Thread Tools Display Modes
  #71  
Old November 21st 04, 05:19 AM
David J. Littleboy
external usenet poster
 
Posts: n/a
Default


"Matt Austern" wrote:
Chris Cox writes:

I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.


Which is correct (for 0..32768 representation versus 0..65535
representation).


Perhaps this is offtopic, and perhaps you can't answer it without
revealing proprietary information, but can you explain why 15-bit
computation should be so much faster than 16-bit?


Here's my guess: Correctly testing boundary conditions for unsigned
arithmentic is tricky, since (0 - 1) is the largest value there is. Ouch. So
if you use signed arithmetic you can catch problems much easier. It would be
the additional testing code that makes full 16-bit calculations slower.

Just a guess.

David J. Littleboy
Tokyo, Japan



  #72  
Old November 21st 04, 05:26 AM
Bill Hilton
external usenet poster
 
Posts: n/a
Default

The color mode doesn't matter - it's still 16 bit data (0..32768).

From: Ken Weitzel

0..32767 or 1..32768

You just can't have it both ways


You can if you have 16 bits instead of 15


  #73  
Old November 21st 04, 05:26 AM
Bill Hilton
external usenet poster
 
Posts: n/a
Default

The color mode doesn't matter - it's still 16 bit data (0..32768).

From: Ken Weitzel

0..32767 or 1..32768

You just can't have it both ways


You can if you have 16 bits instead of 15


  #74  
Old November 21st 04, 05:36 AM
Ken Weitzel
external usenet poster
 
Posts: n/a
Default



Matt Austern wrote:

Ken Weitzel writes:


Matt Austern wrote:


Chris Cox writes:


I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

Which is correct (for 0..32768 representation versus 0..65535
representation).

Perhaps this is offtopic, and perhaps you can't answer it without
revealing proprietary information, but can you explain why 15-bit
computation should be so much faster than 16-bit? (If there's a
publication somewhere you could point me to, that would be great.)
I've thought about this for a few minutes, I haven't been able to
think of an obvious reason, and now I'm curious.
Feel free to email me if you think this wouldn't be interesting to
anyone else.



Hi Matt...

Nor can I see even the slightest difference. None at all.

So - I suspect that we're looking at it from the wrong
end. Suspect it's the a/d converter that could be the
bottleneck?



Nope. If Chris says 16-bit image processing in Photoshop would be much
slower than 15, I have no doubt that he's right. I just don't know
why. I can easily believe there's some subtle algorithmic issue that
I haven't thought of. For that matter, I can easily believe there's
some glaringly obvious algorithmic issue I haven't thought of. I'm
just curious what it might be.


Hi...

Perhaps you're right... throw a little more fuel on
the fire for whatever enlightenment it may be worth.

When I first got my ati aiw card, I read the manual(s).

They claimed that they were going to do 32 bit color...
sort of. They explained that they were going to do
3 x 10, but not "waste" the remaining 2 bits; they were
using them for additional green levels.

I'll see if I can't somehow find those manuals,
and share the detail if/when I do.

Ken

  #75  
Old November 21st 04, 05:36 AM
Ken Weitzel
external usenet poster
 
Posts: n/a
Default



Matt Austern wrote:

Ken Weitzel writes:


Matt Austern wrote:


Chris Cox writes:


I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

Which is correct (for 0..32768 representation versus 0..65535
representation).

Perhaps this is offtopic, and perhaps you can't answer it without
revealing proprietary information, but can you explain why 15-bit
computation should be so much faster than 16-bit? (If there's a
publication somewhere you could point me to, that would be great.)
I've thought about this for a few minutes, I haven't been able to
think of an obvious reason, and now I'm curious.
Feel free to email me if you think this wouldn't be interesting to
anyone else.



Hi Matt...

Nor can I see even the slightest difference. None at all.

So - I suspect that we're looking at it from the wrong
end. Suspect it's the a/d converter that could be the
bottleneck?



Nope. If Chris says 16-bit image processing in Photoshop would be much
slower than 15, I have no doubt that he's right. I just don't know
why. I can easily believe there's some subtle algorithmic issue that
I haven't thought of. For that matter, I can easily believe there's
some glaringly obvious algorithmic issue I haven't thought of. I'm
just curious what it might be.


Hi...

Perhaps you're right... throw a little more fuel on
the fire for whatever enlightenment it may be worth.

When I first got my ati aiw card, I read the manual(s).

They claimed that they were going to do 32 bit color...
sort of. They explained that they were going to do
3 x 10, but not "waste" the remaining 2 bits; they were
using them for additional green levels.

I'll see if I can't somehow find those manuals,
and share the detail if/when I do.

Ken

  #76  
Old November 21st 04, 09:43 AM
Dave Martindale
external usenet poster
 
Posts: n/a
Default

Matt Austern writes:

Nope. If Chris says 16-bit image processing in Photoshop would be much
slower than 15, I have no doubt that he's right. I just don't know
why. I can easily believe there's some subtle algorithmic issue that
I haven't thought of. For that matter, I can easily believe there's
some glaringly obvious algorithmic issue I haven't thought of. I'm
just curious what it might be.


One guess: checking for overflow in filtering. Many filter operations
can generate output values that are outside the range occupied by the
input image under some circumstances. If you use a range of 0-65535
for storage and computation, you have to check for overflow after each
operation that could possibly overflow in 16 bits, or you risk having
white overflow and turn into black. Conditional branches are expensive
on a Pentium 4.

If the inputs are in the range 0-32768, many of the same filtering
operations can guarantee that their output, though it may be larger than
32768, will never reach 65535. So the code can sit there doing
multiplies and adds at maximum rate, and only has to check for possible
overflow at the end of the whole process. (Underflow is a similar
issue, except that underflow generates a large value in unsigned
arithmetic. As long as the maximum overflow value can't get as large as
the minimum underflow value, you can straighten it out later).

Another possibility: suppose you have both colour components and alpha
encoded so that 1.0 is 65535 and 0.0 is 0. When you multiply colour by
alpha, you get a 32-bit result. To convert that back into 16-bit form,
you need to divide by 65535 if you want the best accuracy. Just doing a
right shift by 16 bits is not good enough if you want to be able to test
for exactly 1.0. (If you do a 16-bit right shift, you're essentially
scaling the result by 65535/65536, enough to change 65535 to 65534 when
multiplying by the representation for 1.0).

But if 1.0 is represented by 32768, that's an exact power of 2, and you
can get the exact result of the multiply by doing a right-shift of 15
bits.

The Pixar Image Computer used tricks like this many years ago. The
memory was 12 bits per component, with 2048 representing a value of 1.0.
Values up to 3071 were brighter than white, up to 1.5. The range
3072-4095 represented negative values in [-0.5, 0]. When a 12-bit value
was loaded into the processor, it was automatically extended to 16 bits
in a way that preserved the positive or negative meaning, then the
arithmetic was all 16/32 bit.

Dave
  #77  
Old November 21st 04, 09:43 AM
Dave Martindale
external usenet poster
 
Posts: n/a
Default

Matt Austern writes:

Nope. If Chris says 16-bit image processing in Photoshop would be much
slower than 15, I have no doubt that he's right. I just don't know
why. I can easily believe there's some subtle algorithmic issue that
I haven't thought of. For that matter, I can easily believe there's
some glaringly obvious algorithmic issue I haven't thought of. I'm
just curious what it might be.


One guess: checking for overflow in filtering. Many filter operations
can generate output values that are outside the range occupied by the
input image under some circumstances. If you use a range of 0-65535
for storage and computation, you have to check for overflow after each
operation that could possibly overflow in 16 bits, or you risk having
white overflow and turn into black. Conditional branches are expensive
on a Pentium 4.

If the inputs are in the range 0-32768, many of the same filtering
operations can guarantee that their output, though it may be larger than
32768, will never reach 65535. So the code can sit there doing
multiplies and adds at maximum rate, and only has to check for possible
overflow at the end of the whole process. (Underflow is a similar
issue, except that underflow generates a large value in unsigned
arithmetic. As long as the maximum overflow value can't get as large as
the minimum underflow value, you can straighten it out later).

Another possibility: suppose you have both colour components and alpha
encoded so that 1.0 is 65535 and 0.0 is 0. When you multiply colour by
alpha, you get a 32-bit result. To convert that back into 16-bit form,
you need to divide by 65535 if you want the best accuracy. Just doing a
right shift by 16 bits is not good enough if you want to be able to test
for exactly 1.0. (If you do a 16-bit right shift, you're essentially
scaling the result by 65535/65536, enough to change 65535 to 65534 when
multiplying by the representation for 1.0).

But if 1.0 is represented by 32768, that's an exact power of 2, and you
can get the exact result of the multiply by doing a right-shift of 15
bits.

The Pixar Image Computer used tricks like this many years ago. The
memory was 12 bits per component, with 2048 representing a value of 1.0.
Values up to 3071 were brighter than white, up to 1.5. The range
3072-4095 represented negative values in [-0.5, 0]. When a 12-bit value
was loaded into the processor, it was automatically extended to 16 bits
in a way that preserved the positive or negative meaning, then the
arithmetic was all 16/32 bit.

Dave
  #80  
Old November 21st 04, 02:32 PM
Mike Engles
external usenet poster
 
Posts: n/a
Default

Kennedy McEwen wrote:

In article , Mike Engles
writes

Hello

Is astronomical image processing done in a linear space or a gamma
space?

Normally in linear space, Mike - because you are primarily interested in
physical quantities and their quantitative results.

After that has been achieved, the representation for human consumption
is created - either from the source data or the processed data depending
on the objective required.
--
Kennedy
Yes, Socrates himself is particularly missed;
A lovely little thinker, but a bugger when he's ****ed.
Python Philosophers (replace 'nospam' with 'kennedym' when replying)



Hello

Is the same true for imaging from spacecraft, interplanetary or
otherwise or is gamma encoding done before transmission?

Mike Engles
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Sony Cybershot P100 VX '640x480' movie mode is fake Mark Elkington Digital Photography 17 November 2nd 04 02:24 AM
What's the D300's "Close-up mode" for? Darryl Digital Photography 10 September 23rd 04 05:11 PM
Q-Confused about which picture record mode to use in a digital camera. Mr. Rather B. Beachen Digital Photography 1 July 13th 04 01:50 AM
What image quality mode to use? Mr. Rather B. Beachen Digital Photography 2 July 13th 04 01:21 AM
wireless 550EX in manual mode with 420EX danny Other Photographic Equipment 1 February 15th 04 04:35 PM


All times are GMT +1. The time now is 11:05 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PhotoBanter.com.
The comments are property of their posters.