Improve Code Export

[FiratUsta]

Currently the code generation algorithm is very barebones, and it doesn't allow for more complex palette types to be exported such as random palettes or palettes containing locked swatches.

A more robust algorithm that can export any palette would be useful.

I would normally do this by saving exported palettes in a central DB where they can be referenced, but it's important that the app works with full capacity offline so this solution is out.

Another solution is to just make the "code" a listing of all colors, or the generator parameters (as it is now) + locked swatches, but with larger palettes the resulting code would be way too long. Zipping the resulting text could make it smaller, but that also completely depends on the palette and would present very inconsistent results.

Another solution would be to list all colors, but instead somehow encode them into a binary file (1 color can be stored in 3 bytes as RGB values, so the resulting file size would be really small with 108 kb for 36000 colors) and replace "code" export with a "file" export. Honestly right now this looks like the best bet, but I feel like this is unnecessarily complex and with a little thinking a more elegant solution could be found.

All suggestions welcome.

[FiratUsta]

This is being pushed back, 2.0.0 release has been almost ready for too long and was mainly held back by this issue.

The best idea I've had about it is adding the ability to import/export .ase (or another common palette format) files. Although possible, this is too much work for little return (as this is mainly a personal project and I don't really use any palette files) while keeping with the philosophy of the project (that is, pure HTML, CSS & JS code with no external libraries or frameworks)

I want to go through with the 2.0.0 release while focusing on my other projects, so I'm moving this to the 2.x milestone instead.

[scout0773]

You mentioned encoding the colors into a binary file and I had the thought of serializing the palette by storing the number of colors as an unsigned integer, followed by each color's RGB value packed as three unsigned bytes. Then, during deserialization, it can read the number of colors and the RGB value of each color. I don't know if that's exactly how it could/would work, so correct me if I'm wrong.

[FiratUsta]

That's almost exactly what I've been thinking, only with the addition of a header that has more information than just the palette length (eg. format version, palette start position, palette end position, color chunk length, color chunk format) so that if I want to extend the generators capabilities in the future (custom color names, palette name etc.) I can reflect those in the export file as well.

I'm just not sure how smart it is to completely invent a new color palette file format when good, mature (and some even open) formats exist (.ase, .aco, .gpl etc.) with each having their own pros and cons.