Convert16to8 uses a short for count?!?

I'm trying to use the Color Space suite to convert 16-bit image data to 8-bit so that I can draw it. First, why in hell can't Photoshop plugins draw 16-bit image data, when Photoshop itself clearly can? Grrr...



OK, so much for the ranting. Now, can anyone tell me whose genius idea it was to make the ''count'' parameter to Convert16to8 a short? What good does it do to restrict us to 32768 pixels? That's a very small image! Am I misunderstanding the use of this parameter?



Also, this function seems to divide the 16-bit pixel values by 128 in order to get the 8-bit values. Anybody know why it's 128 and not 256? Are 16-bit pixel values signed?



Thanks,

Aaron
Convert16to8 uses a short for count?!?
1. Photoshop images and the plugin API has historically been limited to 30,000 pixels. There is now an extended API (and PSB file format) that raises this.



2. Photoshop really stores only 15 bits (plus one value) for 16 bit data. Plugins will see values from 0 to 0x8000 inclusive, which correspond to the 0-0xffff range you were probably expecting.



I hope that clarifies ... something.
Convert16to8 uses a short for count?!?
Isn't it 30,000 pixels on a side? 30,000 pixels total would be a *very* small image, unrealistically so (VGA is over 10 times that!)



Thanks for the clarification about the 15-bit limit.



Aaron

On a side, yes.

Unfortunately, the count in Convert16to8 is the actual number of pixels. That means that it's totally useless for converting an image buffer of any size.

Is there a major obstacle to calling it in a loop convering 32K chunks

then the remainder?



Aandi Inston

No, it just complicates the code unnecessarily and introduces a potential perfomance hit. It's easier to write the thing myself in that case, which in fact is what I've done. It just seems to be a foolish interface decision, unless there is some other factor that I'm not aware of that's constraining the size of the buffer being passed in.



Thanks,

Aaron