Pixly

[zed9h]

First try at implementing the Pixly file format, just loading for now and I tested with only two files, but it could be useful to some people (for instance this guy), so I am pushing right away.

[dacap]

Hi @zed9h, could this use the same png encoder/decoder to avoid duplicating the whole code? I see that it opens an XML file and a png file, so to load the png file you might try to use the png decoder (or calling load_document() to load the png file as a temporal doc::Sprite/app::Document).

Also could you please sign our CLA?

[zed9h]

@dacap, maybe It would be cleaner if I create a helper to decode/encode the PNG for both file formats, but first I will work on the Pixly format save, which will add more value upfront.

PS: I will read the CLA.

[dacap]

I'll take a look at this on next Tuesday. At the moment I recommend you to use load_document() if it's possible, so we can avoid modifying the actual png encoder/decoder (the code review from my side would be too much work if you refactor the code).

You can use Document* tmpDoc = load_document(nullptr, pngfilename) to "subload" the png file, and save_document(nullptr, tmpDoc) to save the png file.

[zed9h]

I signed the CLA and finished the Pixly file save; the code ended up much simpler than the original PNG format, because it only handle RGBA, take a look if you think it worth the generalization of the codec. For me it was easier to handle a standard lib code than aseprite internal structure, even when I found the latter pretty clear and organized.

[dacap]

@zed9h Remember that there is an email required in the CLA signing process too.

[dacap]

As a side note, I'll need several .anim files to test these routines (original files generated with Pixly), because I don't have an Android device and cannot install Pixly. You can send me some test files at support@aseprite.org (I'll add them into an internal test suite I use for decoders/encoders)

[zed9h]

@dacap Great points, I placed many more check()s and improved the error messages. I will send some good files and some bad ones to test the exceptions.

[zed9h]

If I remove the FILE_SUPPORT_PALETTE_WITH_ALPHA and the auto-generated palette has some alpha on it, there will be a warning every time the file is saved, so I think I will need to keep this flag, even if the palette will not be saved. I also added FILE_SUPPORT_BIG_PALETTES for the same reason. (Not really sure if this is the right way to go.)

I cleaned up some includes that seemed unnecessary.

[dacap]

Mhh, I think it's a bug in the code that check conditions in file.cpp. I'll be working in a fix for this so FILE*PALETTE* flags are checked only for Indexed images. (But I've to think more about those situations.)

The FILE_SUPPORT_BIG_PALETTES is in case the file format can save a color palette with more than 256 colors.

You can leave the flags and I'll then modify when the fix is done. Don't worry about that.

[dacap]

Finally I got a crash saving this file:

Could you please check this issue?

[zed9h]

As I suspected when I saw the line of the error, the cel image can be smaller than the sprite size, I will compensate for that.

[dacap]

Returning to this one: I'll finally remove FILE_SUPPORT_BIG_PALETTES and FILE_SUPPORT_PALETTE_WITH_ALPHA flags from .anim format as this format doesn't support these features (and the user must be warned that the palette will be lost). I've added the new issue #1182 how to fix the issues commented here.

[zed9h]

Of course, if the palette is user created there should be a warning.

@dacap BTW, I didn't explain it properly here, the "collums" (sic) are on the official Pixly format, nothing I could do about it.

[dacap]

BTW, I didn't explain it properly here, the "collums" (sic) are on the official Pixly format, nothing I could do about it

👍 yeah, that's what I thought