Today I installed Krita’s latest beta version from the site - 4.2.9-beta1 x64. It allows to set passthrough mode separately from blending mode, but thankfully one disables another (I cannot imagine how they’d work at once). Also it disables masks but not partial opacity, so if I disable it and restore inherit-alpha where the clipping was, example file above looks not as much broken, but some blending is still different.
I tested standard src-atop versus my non-standard clipping group, and it seems that the difference amounts to arithmetic precision of rounding in 8-bit calculations. I am not used to drawing in Krita, so excuse me for a not so fancy example this time:
Also for some reason “Addition” blending mode (same operation as “Linear Dodge”, “svg:plus”, etc.) in Krita looks different from my JS renderer (using “lighter” blending mode or custom-written asm.js addition, which both show the same result). “Screen” mode looks the same everywhere, so I added this variant to comparison.
Yes. After all, clip mode + blend mode looks like a good solution. I’d suggest to add “
alpha-composite-op” and “
color-composite-op” attributes, let applications make sense of possible combinations, and keep old combined “
composite-op” for backward compatibility, but there may be better ideas.
By the way, JS canvas API suffers from the same issue, only one operation at a time - with alpha or with colors, so I do it in two or more steps, stripping alpha mask for one step and returning it for another. Maybe this is intended, but surely not convenient.
As written on its official site, SAI developer is a one-man-company and does user support via email. There is no public mailing list or forum, any roadmap or request-FAQ (like table of “planned”, “won’t do”, etc.). He only ever responded to me on some bug reports (including one not-a-bug), never on suggestions and feature requests, so I don’t know what he thinks about supporting OpenRaster. At least he read it, because I wrote something about inconsistent blending modes along the way, and in some next version blending modes were reconsidered and fixed to align closer to Photoshop.
Yes, more or less. SAI’s native format can contain editable objects like text, vectors, rulers, etc. If I export it to PSD and load back the result, everything is rasterized, but looks as it should. I can continue to draw in PSD without problems if I don’t need to keep any SAI-specific things as objects. It also looks as it should in my custom renderer, to the extent covered by my rendering implementation (PSD.js library does not have it):
- For some blending modes, which I never used, I have wrong or even missing formulas, as web search turned up nothing good at the time.
- Passthrough ignored in non-trivial cases, as mentioned before.
- Lower precision of calculations yields more banding in smooth gradients. I am planning to fully rewrite my renderer to 16-bit calculation later, to have closer results to SAI and not suffer from Firefox JS canvas implementation that stores colors with premultiplied-alpha, degrading precision even more.
My files also look as intended in Photopea online editor, and load much faster there than on my page, but it’s closed-source. Probably WebAssembly, maybe possible to disassemble and find some clues, but I did not try yet. Maybe I won’t even need to when the time comes.
Surprisingly, some PSD files from SAI looked broken in CSP and Photoshop itself last time I asked someone else to test, because they support clipping-group property only on layers, but not on folders for some reason. Photoshop even shows a misplaced checkbox when it’s enabled on a folder, but ignores it for rendering purposes. Maybe it’s fixed in some later version, but I would not count on it.
IIRC Photoshop had some option to save a project in compatibility mode. Maybe SAI sticks to that as a common ground.