I'm writing a format plug-in and am having some difficulty getting the pixel data from photoshop in the format I want. From what I gather from the documentation in the SDK I need to specify the following to tell photoshop what format to deliver my pixels in:
theRect
loPlane
hiPlane
data
colBytes
rowBytes
planeBytes
planeMap
I specify all of these appropriately for a 32 bit rgba8888 uncompresssed image and it works just fine... but ONLY if the image I load in the first place matches the format I am requesting. If the image I load is some other format, like a 256 color image with a palette, gFormatRecord->advanceState() just fails with a nebulous -30500 error code (formatBadParameters) instead of delivering pixel data.
So my big question is this: Is Photoshop capable of doing the conversion and delivering the pixels to my format plug-in in my requested format? If it CAN do it, what might I be doing wrong? Please help! Thanks!!
Let me rephrase this question in a different manner.
Is there a sample anywhere that converts from the various image modes to ARGB? Even the SDK docs acknowledge the following:
"For example, Photoshop stores RGB
images with an alpha channel in the order
RGBA, whereas most frame buffers store the
data in ARGB order."
Why not help out most people porting code from "most frame buffers" type designs by providing code to bridge the gap? This note provides a hint to get you going on RGB, but this doesn't help out with indexed, CMYK, etc. It seems silly to have everyone writing the same code over and over again.
No, there is no such sample code. You should be processing the image in it's own mode, preferably in it's own depth. If you can't handle a particular mode or depth - indicate that in the EnableInfo PIPL field.
You noticed you can use the planeMap[] array to permute the channels. It's not so obvious that Photoshop should offer generalised bit depth/colour space/palette processing. It can be argued that's the role of the plugin itself: to mediate between Photoshop's native image data (which it does offer conveniently) and whatever arbitrary image format the user requires. At least, that's what most of
my plugins do.
Sure, there are a few obvious conversions, but you have to stop somewhere... Sooner or later you'll be implementing stuff on the Photoshop side that
should be in a plugin. I don't have a big problem with the line drawn in the current API.
> You should be processing the image in it's[sic] own mode...
Photoshop is not the center of the universe. If Photoshop was the only graphics app in existence, then coding directly to the Photoshop format would make sense. There is a lot of code out there that started out in environments other than Photoshop.
I _could_ process the image in its own mode, but the word "should" is too strong in this case.
Why not make the Windows Bitmap file filter a sample in the SDK?
>>Why not make the Windows Bitmap file filter a sample in the SDK?
>
>Windows bitmaps can be 1- 2- 4- or 8-bit paletted or 24 bit color...
And the export sample doesn't handle CMYK or Lab. In the general
principle of Photoshop, color conversions should never be implicit,
the user needs to be in control, so they can choose suitable ICC
profiles and rendering intent, and confirm the result.
Even if the sample isn't perfect, it would help out a great deal.
Also, why couldn't this kind of interaction be added as well in the sample? If it's a best practice and in line with the principles of the API, why not provide a complete sample of a well known, widely documented format that demonstrates what should be automatic and what should require user interaction?
I have now written all of the necessary code myself. It would have saved a great deal of time if such an example had existed. I can imagine that many developers have and will go through the same process over and over again.
8
Replies
AdChoices