GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Photoshop PSD Transparency

I dont use a third party tool for thumbnails or view images.

Do you have a sample psd file so I can have a look?

It's possible 16bit PSDs have embedded TIFF thumbnails with (unmarked) alpha, which Opus then decodes if it's set to assume unmarked alpha is transparency data.

If I remember correctly, 8bit PSD files use JPEG for their thumbnails, and JPEG does not support transparency. The transparency data obviously exists elsewhere in the PSD file, along with all the other layers and effects data, but is not built into the embedded thumbnail data (unless there's some augment to it which I am not aware of).

Checking my own 16bpp PSD saved with the latest version of Photoshop, transparency works as long as Opus is set to use the embedded preview image, not the embedded thumbnail, for thumbnails.

The tiff_assume_alpha option does not seem to be needed here. (Maybe it is with files saved in older versions of Photoshop.)

Summarising everything:

[ul][li]Opus has built-in PSD thumbnail and viewer support.[/li]
[li]It works by showing whatever image data Photoshop embedded into the file.[/li]
[li]Photoshop can embed both a full-size preview and a smaller thumbnail (or neither, depending on its configuration). Opus lets you choose which to use.[/li]
[li]Opus supports transparency, but Photoshop only seems to save transparency data into 16bpp preview images, not thumbnails and not 8bpp (AFAIK).[/li]
[li]Some 3rd party cools can extract the transparency data from 8bpp PSD files via some method (which could be parsing the actual layers etc.).[/li]
[li]Opus won't currently let you call 3rd party code for thumbnails if it has built-in code for the file format (unless the code is packaged as an Opus-specific plugin).[/li]
[li]We can change that in 12.2.[/li][/ul]

Many thanks, Leo for succinct explanation, which fits exactly with what I have discovered through much experimenting. Why on earth Adobe should choose to use JPEG previews on 8bit PSD files is beyond me when one of the main reasons for using the format is to create transparency masks.

Your plans to make changes to DOpus in 12.2 will be very welcome to those who make extensive use of PSD files.

I had a look at the code to understand why there was alpha there for 16bpp and not for 8bpp, and it turns out the PSD files do have alpha for 8bpp as well, we just weren't always using it. So transparency should work with both 8bpp and 16bpp without needing any third party add-ons, or the extra option (similar to viewer_disable_internal) I was talking about before.

It will still require setting PSD thumbnails to use the embedded preview image instead of the embedded thumbnail image (since the latter does't include alpha data), but we may make that the default anyway as the thumbnails aren't large enough for high DPI on top of having no alpha.

(Also, the tiff_assume_alpha setting should not affect things at all when it comes to PSD files.)

The change that enables alpha for 8bpp image previews is in beta 14 which was released today.

You guys are amazing and a credit to the software industry. I spent twenty odd years dealing with software companies around the world in my work in the graphics and print industry, but I have never witnessed service like this. To bring up a problem and have a solution within a couple of days - and at a weekend - is above and beyond. Thank you for your efforts.

I hope this does not scupper the 12.2 plans to allow external programs to produce thumbs for DOpus, as they do bring other goodies to the party

Thanks guys. Really appreciated.

On a side note though. I found this. When the composite preview image of the psd file has transparent pixels and there is an alpha channel, the background becomes white instead of transparent.

It doesn't if the alpha channel is available and decoded.

More info is needed. Which Opus version? What type of PSD file (e.g. color mode and it depth)? Viewer or thumbnails? What's psd_image_preference set to?

I can confirm what OpelOpus is saying.

The images I am using are 8 bit RGB PSDs. I am using the very latest DOPus Beta ie 14 and have set the psd-image-preference to the setting recommended.

If I re-save the image in Photoshop (CC 2015.5) after deleting the alpha channel, transparency is restored.

Are we talking about alpha channels distinct from transparency/opacity?

Does anything else preview the files differently?

Could an example file be zipped for us to try?

My understanding of alpha channels is that they are only of practical use if your are passing the image to another program like Quark or In Design and want the image as a cut-out. I have simply deleted the alpha channel in the few PSDs that appear with a white background in Opus to get around the problem. Of course that solution may not suit everyone.

I attach a zip of a PSD with a saved Alpha channel that appears with a white background on my system
Alpha (16.2 MB)

It turns out Photoshop writes not just RGBA into the preview bitmap but all of the alpha channels.

On the plus side, it's easy to make this particular example work.

On the down side, this has revealed a problem with interpreting channels beyond RGB in PSD files. There is no way to know that the 4th channel in the file is actually opacity data. If it is some other kind of alpha channel, the results will be wrong when it's interpreted as opacity.

You can see this already if you put a solid background layer behind your test image, so it has no non-opaque pixels, and re-save it, while keeping the alpha channel. You then get a file with the 3 RGB channels + 1 extra channel that isn't opacity (in this case it it's inverted opacity, but it could be any 8bpp data). That channel is interpreted as opacity, since it's 4th in the list. Since it's inverted opacity in this case, we end up with the whole foreground of the image cut out, and the only thing visible is the background forming a silhouette around where the foreground used to be.

We'll probably add a psd_assume_alpha option similar to the tiff_assume_alpha one for people whose workflows involve images with no opacity channel and some other kind of alpha channel. That will have to be in 12.2 though.

I've worked out a way to tell if the first alpha channel is opacity data or something else (excluding extremely pathological cases), so that should no longer be a problem in the next update, and a psd_assume_alpha shouldn't be needed after all.

Great news Leo. You guys are awesome!!

This is in beta 15, let us know how you get on with it.

I think the inverted appearance of the alpha channel is more to do with how programs like Quark Xpress and In Design treat imported images. i.e. the image behind the white part of the mask is what shows up in the pagination program, the black part does not. It seems to be the equivalent of a clipping path.

As far as I can tell, if you do not import into pagination type programs, there is little point in saving the alpha channel from Photoshop.

But, hey, well done on the workaround. I will let you know how I get on.

Looks like a fix. Many thanks.

Works like a charm. Thank you very much!

Sorry to bring this one up again. Just wanted to mention that transparency doens't work for CMYK psd documents. Even the viewer doesn't open the psd if the file is save in CMYK and has transparent pixels. Viewer gives unable to load picture error.

You can test this failry easily with converting your psd to CMYK