Layer opacity not working with certain blending modes

[f2d]

Hi.

I am developing a similar tool with different features, available here with my test files. It has no layer tree editing, only menu of presets loaded from the artwork file itself. It is still not finished for real use, especially rendering quality and speed, but I intend to continue development.

I stumbled upon PSDTool again recently, tried to throw in some of my files and found rendering problems.

For example, unit_base.psd is simpler and looks as intended. Note that the shading folder with linear-light mode was saved with 100% own opacity setting.

But unit.psd has more complex structure, and resulting shadows look too dark in PSDTool. Originally, shading layers with linear-burn mode were saved with around 23% opacity setting. I think, pass-through and clipping are unrelated and work as intended.

My guess:

When SAI2 saves PSD files, for certain blending modes (including linear-burn, linear-dodge, linear-light, etc.) it stores user-authored layer opacity into "Fill" opacity property, while storing normal "Opacity" property as 100%. SAI2 does not support editing Fill and normal opacity independently.

My suggestion:

Read both opacity properties and multiply them as normalized to [0-1] before using. I do this myself for now. SAI2 probably does the same, but I don't know exactly.

Related:

https://github.com/meltingice/psd.js/issues/153

[f2d]

I just remembered that there is more to this problem. The reason SAI2 does this in the first place is some “Transparency Shapes Layer” setting in Photoshop.

Long story short, blending operations in Krita match TS mode versions of SAI2, while my JS code matches non-TS mode versions, at least for the modes used in my files.

I never completely solved this problem and just used workaround (multiply both opacity properties) to have something workable. I planned to look at the source code of Krita to reproduce TS mode behavior when "Fill" opacity is 100%.

Some details here, but not solution: https://krita-artists.org/t/call-for-help-assist-development-of-ora-format-providing-kra-psd-or-other-source-files/3482/15

[oov]

Hi, f2d! Thank you for your report.

Yes, currently, PSDTool does not support the "iOpa" section in Additional Layer Information. As you know, PSD format have a lot of parameters, so it's not easy to render them correctly. This fact is a source of trouble not only for PSDTool, but for all software that draws PSD files.

PSDTool treats PSD as a file format for exchanging data between multiple software. Therefore, I do not actively implementing features that do not supported by many software.

For example, the "iOpa" section is not supported by GIMP or FireAlpaca. Both of these are freeware, so many people will try to use them to open PSD files. I am deliberately not implementing this feature to make the similar results across these softwares(including PSDTool). For the same reason I have not implemented an adjustment layer.

If I am going to build a web application like PhotoPea, I would have to actively implement it.

[f2d]

Thank you for response.

There is a workaround for artwork authors - using 100% opacity setting directly on a folder with offending blend mode and modify layers inside it instead. I did this for testing, until I found a way to read Fill opacity.

As a side note, Photoshop itself and maybe some other programs did not support clipping group setting on a folder. Maybe they changed in years while I did not check. Clip Studio Paint finally does for example (but shading mode in my file looks different from SAI, matching its TS mode instead). SAI does since ages ago, same as PSDTool and my own tool, and there is no real reason not to. I use folder clipping a lot in SAI and my files looked totally broken in those popular "industry-standard" programs. Some this year's version of Krita completely ignores clipping settings from PSD (and ORA). I'm going to recheck latest versions of Krita and GIMP now, but the point still stands. I think, we do not have to settle for the worst common case.