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 Test.zip (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!!
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
We'll fix this in the next update.