Despite the claim that CS does many function in 16 bit I have discovered that claim is false. CS uses 15 bits not 16. The difference is a factor of 2 which could be important. But even more important is the dishonesty of claiming one thing and supplying another. How many of you would accept your next V8 automobile if the factory decided to not include one cylinder? Now the question. Is there anything in CS that I can do to give it the 16 bits/channel that Adobe claims it has? If so I will be very happy to retract all my statements above.
For those who want to check this out simply put the eye dropper on a pure white area of an image. The value you read for L in the Lab system or for R or G or B in the RGB system (the values are all equal if the area is white) will be near 65000 for a 16 bit system (the maximum value is 2^16-1 or 65535 ) and near 32000 for a 15 bit system (the maximum value is 2^16-1 or 32767).
It’s 15 bit plus one precision in 16 bit space. Show Adobe a device that has full 16 bit precision and that might change, but at this point devices that capture "16 bit" are doing so at less than 16 bit of usable data plus noise.
It is 15 bits plus the sign bit. Many many many 16 bit computers can only access signed 16 bit integers (that is 15 bits of precision plus 1 sign bit). One of the more interesting examples would be an old HP concept which reserved the 16th bit to indicate indirection (that is the remaining 15 bits contain an address not a value).
Jim wrote in message
Despite the claim that CS does many function in 16 bit I have discovered
that claim is false. CS uses 15 bits not 16. The difference is a factor of 2 which could be important. But even more important is the dishonesty of claiming one thing and supplying another. How many of you would accept your next V8 automobile if the factory decided to not include one cylinder? Now the question. Is there anything in CS that I can do to give it the 16 bits/channel that Adobe claims it has? If so I will be very happy to retract all my statements above.
For those who want to check this out simply put the eye dropper on a pure
white area of an image. The value you read for L in the Lab system or for R or G or B in the RGB system (the values are all equal if the area is white) will be near 65000 for a 16 bit system (the maximum value is 2^16-1 or 65535 ) and near 32000 for a 15 bit system (the maximum value is 2^16-1 or 32767).
Following all these useless discussions in the past:
A linear relation between two number spaces is defined by the mapping of the minimal and the maximal numbers :
Zero for color R/G/B is mapped to zero in "16-bit-space". Max. for RGB is mapped to 2^15 in "16-bit space".
An unsigned number max. value could be mapped to 2^16-1 but it´s really up to the programmer how he/she is doing this.
2^15 + 1 (including zero) different values for R/G/B (each) or for gray are really enough. For simplicity this is called "16-bit". Reading this literally then it´s wrong. Practically it´s OK.
Confusion can be expected, because the users might think: max. R/G/B = 2^16-1.
For those who want to check this out simply put the eye dropper on a pure
white area of an image. The value you read for L in the Lab system or for R or G or B in the RGB system (the values are all equal if the area is white) will be near 65000 for a 16 bit system (the maximum value is 2^16-1 or 65535 ) and near 32000 for a 15 bit system (the maximum value is 2^16-1 or 32767).
So, the value you see is merely a signed integer. It still occupies 16 bits. Jim
It’s not a signed/unsigned issue; the problem is in fact that Photoshop stores only 15 bits per channel, not 16. One bit is silently discarded: Adobe’s dirty little secret which has long been known to plugin developers.
it’s to get 50% on an actual value rather than between values, right?
The technical cause of the problem is unclear, but Adobe has apparently taken some pains to conceal it (e.g. I’ve been told that noise is added in some situations). Perhaps it is a ‘legacy code’ issue like the 30,000 pixel limit.
John – Yes, that extra level gets you a true middle value, and makes lookup tables a lot faster and cleaner than they would be otherwise.
Toby – it’s not legacy, we don’t conceal it. And I’ve given the reasons several times before. The problems are: current common CPUs are still slow at 64 bit math, so overflowing 32 bits is a bad idea. Using 0..65535 representation would cause a lot of overflows and require the use of 64 bit math. 2^N – 1 representations are convenient for some things, but require more math in many other areas — thus they can be slower. Having a middle value is a very good thing for blending math. And the 0..32768 representation is cleaner for lookup tables (less math, better results).
Using 0..65535 representation would cause a lot of overflows and require the use of 64 bit math.
This is not technically credible. All 32 bit processors can do unsigned 32 bit math; some signed operations are actually slower; and AFAIK no current 32-bit runtime requires (or even offers) hardware or software exceptions on integer overflow.
It’s true that some calculations (not the basic operations) would need 64-bit arithmetic, but since you don’t offer layers in 16-bit mode last time I looked, the impact would not be very large.
Distorting 16 bit data in and out of 15 bit representation *does* have an impact; it’s a dealbreaker for many scientific image processing applications, and means that Photoshop cannot transparently edit 16 bit image formats (of which there are many).
Toby – it’s very credible, and technically true. And I said: 64 bit math, not 32.
Many of the operations done in Photoshop would overflow 32 bits (even unsigned) if we used the 0..65535 representation. And they’re common enough that the slowdown would be noticable. We did the research — we didn’t just pluck this out of the air.
Many of the operations done in Photoshop would overflow 32 bits (even unsigned) if we used the 0..65535 representation. And they’re common enough that the slowdown would be noticable. We did the research — we didn’t just pluck this out of the air.
To assert that operations on 16-bit unsigned values would be slow or difficult using 32-bit native arithmetic on 32-bit CPUs in 2004, 25 years after 32 bits went mainstream, is just absurd. It’s the craziest thing I’ve ever heard you say.
I have several 16-bit minicomputers around the house that would have no difficulty handling those quantities without resorting to the quasi-15-bit format.
Perhaps you should inform all those other developers who work with true 16-bit values – SGI, Lucasfilm, any serious image processing package, countless other companies – that they can gain "noticeable" speed by halving their arithmetic range. I suspect you might hear laughter in answer.
If you really did benchmark a full 16-bit image processing engine in Photoshop, presumably compared to the existing 8-bit engine, it would be easier to convince doubters if you would quantify this putative "arithmetic slowdown".
Right now I’ve got my hands full trying to improve Chris’ grasp of reality.
To address this "64-bit" thing: you say it would be necessary to use 64-bit arithmetic to work with 16-bit channels. Not so. Firstly because 32-bit headroom is demonstrably sufficient; and secondly because you’re already working with 16-bit values with the 0..+32768 range! You seem to insist that Photoshop’s internal operations on 8-bit (and quasi-15-bit!) channels currently use 32-bit arithmetic (which makes sense, being the optimal format on 32-bit hardware). It follows that 32-bit arithmetic on full 16-bit values would be no slower whatsoever.
Just confess that it’s an arbitrary limitation of Photoshop and we’ll forget you ever came out with the smoke’n’mirrors performance canard.
CS’s choice to use only 15 bit must be arbitary since Picture Window Pro uses the full 16 bits and has value ranges as expected (1 to 64535) and although I haven’t timed any of the identical operations I have not noticed any differences. Oh, by the way my machine is a 32 bit Intel Pentium running at 2 ghz and I run both Picture Window Pro and CS on it. It is interesting that CS saves the full 16 bit data (they must add a arbitary lowest bit) data. When Picture Window Pro loads a 15 bit file saved by CS it has the full 16 bit range. My conclusion is that the CS programmers were well aware of what they were doing and either didn’t inform management of the 15 bit nature of the CS system or management was dishonest in chosing to advertise CS as a 16 bit machine dispite the fact that it is a 15 bit machine.
Reading that sentence I inevitably heard the voice of my old school teacher when she "machine gun"-addressed us after one of us tried something innocent like burn down the school or so…
I wish ANY kind of impoliteness would be punished immediately by the old and the new hosts.
Chris wasn´t able to explain the strange internal data format. Not even for somebody with 20 years experience in assembly programming.
The data format is up to the company, as long as the program works as expected (if we exclude the poor software developers who don´t have the actual SDK).
But one shouldn´t try to tell everybody that the concept is the best without a proof or at least a plausible explanation.
It´s not surprising that Toby is angry.
I´m only an OBSERVER. For me it would be sufficient to read the high resolution data by decimal numbers, as already suggested (000.000 to 255.000).
A little OT here: InDesign 2.0 reads 32-bit BMPs by swapping the R and the B channel (therefore wrong). Nobody in other forums felt obliged to comment this severe bug.
probably you are referring to the nonsensical help menue in InDesign (…BMP for inferior applications …).
BMP is a well defined format. Only InDesign is wrong by interpretation. PhS is able to decipher BMP-32 correctly since version 7 (I´m remembering that I had sent Ch.C. some sample files for BMP-32).
I don´t need your suggestions because I´m relying 1. on file specifications 2. on experiences how other programs interpret BMP.
As a believer in Adobe Products one might say: If PhS decodes the file correctly then InDesign should do this as well.
Nowhere does it use the word inferior. From the help:
BMP is the standard Windows bitmap image format on DOS and Windows-compatible computers. However, BMP does not support CMYK, and its color support is limited to 1, 4, 8, or 24 bits. It is less than ideal for commercially printed or online documents, and it is not supported by Web browsers. BMP graphics can provide acceptable quality when printed on low-resolution or non-PostScript printers.
I’m not arguing that it doesn’t work, my point is that for most users, including myself, there’s no reason to even care.
My advice, if you haven’t done it already is to file a bug report and hope for the best.
Bob
May 7, 2004
BMP is a well defined format.
But not for professional print output nor for the web, the two primary target markets of Adobe products. I know I’m not alone in saying that whenever a client sends us BMPs they are immediately converted to TIFFs, no exceptions.
Toby – I’m sorry, but it’s not absurd, it’s the truth. And again – I’m not talking about 32 bit math, I’m talking about 64 bit math being slow. Remember – there are many places where you have to multiply values, and sum values (and many of those need to be signed).
It’s not a limitation of Photoshop, it’s a limitation of mathematics and the currently common CPUs.
You don’t have all the math or information at hand, so you’ll just have to take my word for it — using 0..65535 would require 64 bit math in many places and would slow Photoshop down significantly.
Gernot – I explained it adequately. The explanation should be sufficient for anyone with an image processing, signal processing background, or basic math background. I don’t know why Toby doesn’t understand the concepts – but he needs to stop ranting and TRY the math.
Even 65535 * 65535 doesn’t leave a lot of headroom in an unsigned 32 bit quantity. Now what happens when you need to sum a few multiplication results? An overflow.
And that’s a simple example.
Most of the math inside Photoshop isn’t that simple.
Oh, and I’m still working on higher precision value specification. I’m not sure if most people will understand 0 .. 255.000 or 0 .. 1.00000 better. The latter does have advantages (not tied to any representation, can do overranged values, etc.).
"BMP graphics can provide acceptable quality when printed on low-resolution or non-PostScript printers."
BMP defines raster images just like TIFF, but with less degrees of freedom. A TIFF can contain several images. A BMP is just one. And this one is accurate.
BMPs are printed on PS and non PS-printers just the same (surely, after printing more than 1200 pages of my printer test pages).
I don´t like Microsoft, but the BMP format is OK: nowhere any loss. Your quoted phrase is truly nonsense.
Back to my critics: the often&everywhere advertized InDesign interprets BMP-32 wrong whereas PhS reads the same file cor- rectly.
I realize that English is not your first language. I’m not blaming you for anything. I’m simply pointing out that BMP is a lousy format for print. For that reason, most InDesign users don’t care that there’s a problem.
My only suggestions stands. Report it as a bug to Adobe if you are that concerned.
Even 65535 * 65535 doesn’t leave a lot of headroom
But it can still be done in unsigned 32 bits. Anyway, you’re already multiplying 32768 * 32768… !
But WHERE in Photoshop’s common operations would you multiply two channel values? It’s not required in display; it’s not required in layer composition because you don’t offer 16-bit layers…
It seems like an expedient hack (and on the face of it, unnecessary) to me, but we won’t see that admitted around here.
One more time: because the calculations involve multiplying those quantities and summing those quantities which can lead to values which exceed the capacity of 32 bits.
64 bit math is slower.
Using 0..65535 would force us to use 64 bit math far more often. Using 0..32768 doesn’t make us use 64 bit math very often.
