|
|
"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 |
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 :) |
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 :) |
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 |
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 |
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 |
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 |
wrote:
In message , Chris Cox wrote: Without your original data to test, I can't even guess what went wrong. You don't need my original data. Any image in "16 bit greyscale" mode has all kinds of numbers between 0 and 32768 missing, and not possible no matter hown much you blur or interpolate. "16 bit greyscale" is about 13.5 bit greyscale. -- John P Sheehy Hello I don't know if this thread in the Photoshop forum has any bearing on this. http://www.adobeforums.com/cgi-bin/[email protected]/7 Mike Engles |
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 |
| All times are GMT +1. The time now is 04:00 PM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
PhotoBanter.com