I have a little workflow that scales down images, alters metadata, sets the color profile to srgb, and exports as a jpeg. Super handy, I use it as a droplet for any photography I want to post to the web. Just now though I sent it a multilayer PSD that was 100% opaque, but which had an alpha channel left over from a selection I had saved. The resulting JPEG was white in the area where the alpha had been black. I confirmed that deleting the alpha makes the problem go away, but I don’t want to have to delete a channel to get this to work. Is there a way to make Retrobatch just ignore alpha channels in PSDs?
Can you share a sample PSD file with this in it?
Sure, here is a link to a zip file on dropbox which contains:
- Master photoshop file
- the Retrobatch workflow
- the resultant JPEG
Thanks, I got it! I’ll take a look at this in a bit.
So I took a look at it, and the problem is in the PSD loader RB uses - which is from the system libraries. Both Preview.app and QuickLook have the same problem (PSD parsing is crazy complicated).
Can I use your image to file a bug with Apple on this?
sure, go ahead.
it’s funny that the layer masks don’t get seen as alpha channels…
Actually, it’s not the frameworks problem, it’s a Photoshop bug (I’m about … 80% sure on this).
I was digging into this a bit more because something felt off, and it turns out that PS is using that alpha for the composite layer, which it really shouldn’t be doing. A PSD file’s data is ordered basically like this:
- Image info, bit depth, color profile.
- Layer information (width / height / name)
- Layer data. These are the bits which make up the RGB(A) pixels.
- At the very end, “composite” data, which is what the image is supposed to look like when all the layers are composited together. It’s basically a TIFF image stuffed at the end of a PSD. This is one of the things that the the “maximize compatibility” flag does when you save a PSD file. This is for programs that just want to know what the image looks like, but don’t have all the routines to mash the layer data together correctly.
It’s at this last composite image data where the alpha is being added for some reason. There’s no need for the composite to write out an alpha channel there, but it does. I have no idea why, so I don’t think this is really Apple’s or Retrobatch’s fault. It’s what Photoshop is giving other apps to use.
Interesting… I spent some time trying to come up with workarounds — turning off “maximize compatibility,” saving as a layered TIFF — those didn’t work. What did work was adding a first alpha channel that was solid black (aka 100% opacity across the whole image) and then saving any additional alphas I wanted to keep as Alpha 2, Alpha 3, etc… I don’t know if it’s the name of the channel or its position as channel #4 that matters, probably the latter. Anyway that’s the funny workaround for now. And hopefully a solid black channel compresses well so isn’t really adding a lot of overhead.