patterns not processed - Ae: at ye.decodePattern

[alexspevak]

when processing patterns, @webtoon can throw an error because of inadequate ColorMode or missing color channel. Question is should we catch such error in octopus-psd or not? psd-tools does process such patttern without crashing

In kraken, the error is:

Ae:
at ye.decodePattern (file:///var/task/node_modules/@webtoon/psd-ts/src/classes/Psd.ts:127:13)

[alexspevak]

files found with this issue: https://kraken-dev.pc.avocode.com/admin/designs/designversion/5be7d9c4-5cf8-43ce-8441-84e89a600774/change/

[rychlis]

isn't this same as https://github.com/opendesigndev/octopus/issues/46 ?

Yes, I will close 46 and paste your comment which you copied from Lucas's slack message here Info from Lucas:

https://ceros.slack.com/archives/C02K0QW3RHC/p1676482972560599?thread_ts=1676449018.387359&cid=C02K0QW3RHC

Ok, I think I found out exactly what we are missing; this innocently-looking piece of Python code: https://gitlab.avcd.cz/avocode/psd-tools/-/blob/master/src/psd_tools/user_api/pil_support.py#L124-141 is missing in webtoon/psd and, even worse, the structure around it is hardcoded to take into account only rgba and grayscale byte patterns (more on that later). There's also no helper like Pillow currently used in webtoon/psd. So we'd need to either: 1) write this byte-wrangling by ourselves in Rust, 2) find a Rust library that does roughly that and ensure it works in WASM, or 3) find JS library, makes sure it works in Node and Browser, and convince webtoon to use it (or hard fork at this point). I can't really estimate 2) or 3) - it would require first a spike to even take a look into ecosystem. As for 1) it seems like we'd need to rewrite https://github.com/webtoon/psd/blob/main/packages/decoder/src/lib.rs to split decompression from output generation and then add each color mode in turn. A week for the first part and then a couple of days per color mode, I guess? I did something similar in the other Rust psd library, but it's untested - https://github.com/chinedufn/psd/pull/38 @alexander spevak should probably add an estimation from his point of view, depends on his Rust knowledge :) And in either case the structure of the JS library has to be updated to recognize the option of non-RGB images. The intended API (https://developer.mozilla.org/en-US/docs/Web/API/ImageData) is quite restrictive (only 8-bit RGBA), which dictated most of the parser structure. So we'd need to somehow reconcile two output formats? LittleCMS takes part of this code: https://gitlab.avcd.cz/avocode/psd-tools/-/blob/master/src/psd_tools/user_api/pil_support.py#L145-152 - and can even convert CMYK to RGB. But it's not a dependency of webtoon parser, so we can't use it during parsing step. We probably could hard-fork webtoon parser and lean more heavily on littlecms... At this point it looks like we are looking at quite heavy options for less than 1% of designs? Maybe adding the images which fail due to only 8-bit pixel width would account for larger percentage, since they require changes to the same part of code.

[alexspevak]

when processing 1000 designs we get 7 of these errors. All of them are working in psd-tools. We can process only RGB ColorMode, all other throw. Out of these 7 failing desings 6 these are Indexed and 1 Multichannel

you can find failing designs here

[alexspevak]

After processing new set of 1000 files from https://kraken-dev.pc.avocode.com/admin/designs/processingcollection/137/change/?_changelist_filters=design_collection%3D21 we found 9 errors of this type. Errors can be found here: https://kraken-dev.pc.avocode.com/admin/designs/octopustask/?design_version__design__processing_collection=137&error__isempty=0

[rychlis]

Here is a link to just tasks with this error Ae: at ye.decodePattern: https://kraken-dev.pc.avocode.com/admin/designs/octopustask/?q=decodePattern&design_version__design__processing_collection=137&error__isempty=0