That would load the palette into the third subpalette and share the first two colors of all palettes. Default colors per subpalette is 4.
It would load the firts two colors of the given palette into the first two colors of the PNG palette and then the other two into 7th and 8th (3rd and 4th of the third subpalette). Every subpalette has two unique colors in this case.
The origin of shared colors is NES, which shares the first color of all palettes, but also the first sprite color being transparent on NES and Game Boy. Doing it like this instead of duplicating the color should improve PNG compression a bit, since especially sprites have sometimes complete rows filled with transparent.
I'm doing a lot with palettes right now since I try to create a tileset that works with black and white (Arduboy), four color grayscale (Game Boy), two colors per 8x8 (ZX Spectrum) and four colors per 8x8 (NES, MSX). That makes palettes even more complicated since now I'll also have duplicate subpalettes.
Next will probably be a tool to modify indexed PNGs:
check if tiles really only use one subpalette
autofix tiles if it's clear which palette shoud be used, which is the case when the colors are basically right but one was taken from the wrong subpalette
change subpalette of specified tile
swap positions of subpalettes and adjust the indices accordingly (maybe with multiple palettes)
merge duplicate subpalettes (maybe with multiple palettes loaded)
split images
merge images and their subpalettes (maybe with multiple palettes per image)
convert from/to subpalettes with shared colors (maybe with multiple palettes)
check if PNG's palette only uses colors that are in a .gpl palette
check if metatiles don't use more than N colors, even if they are from different subpalettes
Maybe even more simple changes like tile rearrangement, sprite frame duplication and stuff like that. Afaik there isn't really any tool that can do such stuff. Indexed images are quite niche and you'd usually do such stuff with imagemagick, but imagemagick always destroys palettes.
Edit:
A first version can check the subpalettes with specified tile dimensions, colors per subpalette and amount of shared colors between subpalettes.
It wil print stuff like "Tile 1x5 has 25 pixel(s) with colors from wrong subpalette(s)!"
Now it can also check if a metatile does not use too many colors. (RGB not palette indices)
NES can only have palettes per 16x16 metatile and not for every 8x8 tile ... unless a special chip is used. So far I ignored that restriction. I'm not sure if this could have any general use, since I mostly need it because my palette is more for switching systems. Maybe for checking that colors for metatiles don't get too out of hand.
Some of the Content made available for download on the Service is subject to and licensed under the Creative Commons Zero (CC0) license ("CC0 Content"). CC0 Content on the Service is any content which lists a "Published date" prior to January 9, 2019. This means that to the greatest extent permitted by applicable law, the authors of that work have dedicated the work to the public domain by waiving all of his or her rights to the CC0 Content worldwide under copyright law, including all related and neighboring rights. Subject to the CC0 License Terms, the CC0 Content can be used for all personal and commercial purposes without attributing the author/ content owner of the CC0 Content or Pixabay.
---
Luckily there are strong precedents against companies retroactively enforcing license agreement changes.
cc0 gives you the freedom to distribute it under more restrictive terms
"Please be aware that while all Images and Videos on Pixabay are free to use for commercial and non-commercial purposes, depicted items in the Images or Videos, such as identifiable people, logos, brands, etc. may be subject to additional copyrights, property rights, privacy rights, trademarks etc. and may require the consent of a third party or the license of these rights - particularly for commercial applications."
That is generally the case, maybe not the "additional copyrights", but the rest definitely. Creative commons is based on copyright and gives you only freedoms regarding copyright.
If you use something commercially you also have to follow commercial property protections (patents, trademarks …)
The right of one's own picture is a personal right derived from human dignity. If you allow somebody to photograph you that permission is always in a certain context. You can put images into a different context via captions and modifications (especially porn captions, fake nudes and deep fakes). In the worst case that can be defamition, which is a crime in some countries.
You can neither do anything else that constitutes a crime.
I did not notice at first, that this json format encodes a color mapping and not palettes.
switchpalette.sh actually takes two palettes and maps every color in the first one to the color with the same index in the second one, that works with RGBA. I wrote loadgpl becaus I worked with a lot of subpalettes who shared colors at that time. The implementation of switchpalette.sh also has problems, because one color is mapped after another, this leads to errors when source and target palettes share colors. This also leads to errors, you sometimes do not immediately notice, when the source image has some wrong color values. That's one of the main reasons why I hated that I had to do such a translation in javascript, but I think I replaced all colors at the same time there.
GitHub has nice tools for visual diffs between binary images. I'm happy to consider other alternatives if you have ideas, but git/GitHub still seems like the most obvious solution for the time being...
gitg and such tools also have image diffs integrated
I don't think size itself will be much of an issue with 64x64/32x32 pixelart.
Edit regarding size:
Indexed PNGs can be smaller.
On example "Bascinet, Raised, Plumage.png":
Original size: 54.2KiB (8bit RGBA)
Just running optipng: 12.3KiB (4bit indexed)
Filling all transparent colors with black in GIMP and then making black transparent, then saving with maximum compression and minimal additional data: 31.6KiB (8bit RGBA)
Just saving it again with mtPaint makes it grow to 32.4KiB (8bit RGBA), that's the difference in PNG compresison different tools do with highest level (9) compression.
Running optipng on this: 10.5KiB (4bit indexed)
Just making the gimp image into 8bit paletted with mtPaint: 11.5KiB (8bit indexed)
mtPaint does not support <8bit. It can be seen that cleaning up transparent colors can also make quite a different. The first run of optipng actually created an indexed image with an alpha channel, there is no index marked as transparent, I'm not sure whether that's a non-standard thing to do or not.
Color values make a difference because of the RLE, which is part of the DEFLATE algorithm, which again PNG uses for compression.
So that's a different thing we should/could take into account. All transparent area should have the same color. Original LPC spritesheets already do that wrong. If you use paletted PNG with just one index being transparent, you are guaranteed to not do that. But disabling alpha in the editor (that's different from removing it from the image) should be the same, it allows you to see what colors are transparent.
edit2:
The automated way with Image Macick + pngcrush + optipng would be:
file=Bascinet,\ Raised,\ Plumage.png; magick "${file}" -background black -flatten -transparent black "${file}_im.png"; pngcrush -rem alla -rem text "${file}_im.png" "${file}_cru.png"; optipng "${file}_cru.png" -out "${file}_opti.png"
Optipng only saves 10 bytes in this example, since pngcrush already compressed it well.
Is pyxeledit capable of opening indexed PNG? Does it only restrict saving to RGBA?
Sorry, what I was thinking about was taking one index/shape image and making say 10 different recolors with 10 different palettes.
You can just call it multiple times for that. There is a bit more overhead, because the image has to be read multiple times, but that's about it.
I'd prefere to focus on subpalettes
I haven't figured out how we should handle objects with multiple "materials" (e.g. several independent color palettes). For instance, the base bodies and their eyes, or the helmets that ElizaWy just posted and their red plumes. I suppose an advantage of the JSON palettes here is that different materials could have different standard palettes, which could be concatenated unambiguously.
You basically can do that with gpl too, it's a color per row and the readers just ignored any lines which werent RGB values. I don't know if that's standard conform and I have to test if pillow is capable of reading that. But you can also properly concatenate them with something like cp whatever.gpl whatever_new.gpl; tail whatever2.gpl -n+5 >> whatever_new.gpl or you can filter them out with something like sed "/^\(#\|GIMP\|Name\|Columns\)/d" whatever2.gpl >> whatever_new.gpl
I'd like to allow to feed multiple palettes into my tool, as well as an offset if you just wanna change one subpalette. It should keep the other colors in the palette untouched and also keep the transparent index.
I always place subpalettes one after another and sort them darkest to lightest color.
I should try to switch to pillow, it's more likely to be already installed and it should be doable. It does come with it's own .gpl reader, but my code size will very likely grow.
Next issue would be a duplimap written with pillow, since I really hate what Image Magick does to the palette. Currently I have to do palette swapping before I feed things into Image Magick.
GitLFS has the same centralization issues like SVN, the images are all stored at one place. I don't know how strongly they are connected to domains, but that could make it hard to preserve or fork hard.
If you have an image, grayscale and a palette ... you can as well have an image and a paletted version, which just lacks the alpha data. You can also RGBA images and palettes, like I do in javascript, but that will give you trouble for shared colors, which you can indeed manually fix in your approach. But I imagine it's harder to fix manually, since you do not directly see the colors you assign in the greyscale image. Your additional data can be lost more easily than an embedded palette, when somebody makes a remix without using the tools.
I think I chose PyPNG because all methods of PIL.ImagePalette.ImagePalette are marked as experimental and badly documented
You forgot https://opengameart.org/content/tiny-16-basic-add-ons
I'm back to this and updated https://github.com/basxto/loadgpl. I now support subpalettes and shared colors:
"./loadgpl.py src/tileset/zxtileset_cblack.png src/palette/dmg_basic.gpl tileset/zxtileset_cblack_dmg.png -u3 -s2"
That would load the palette into the third subpalette and share the first two colors of all palettes. Default colors per subpalette is 4.
It would load the firts two colors of the given palette into the first two colors of the PNG palette and then the other two into 7th and 8th (3rd and 4th of the third subpalette). Every subpalette has two unique colors in this case.
The origin of shared colors is NES, which shares the first color of all palettes, but also the first sprite color being transparent on NES and Game Boy. Doing it like this instead of duplicating the color should improve PNG compression a bit, since especially sprites have sometimes complete rows filled with transparent.
I'm doing a lot with palettes right now since I try to create a tileset that works with black and white (Arduboy), four color grayscale (Game Boy), two colors per 8x8 (ZX Spectrum) and four colors per 8x8 (NES, MSX). That makes palettes even more complicated since now I'll also have duplicate subpalettes.
Next will probably be a tool to modify indexed PNGs:
Maybe even more simple changes like tile rearrangement, sprite frame duplication and stuff like that. Afaik there isn't really any tool that can do such stuff. Indexed images are quite niche and you'd usually do such stuff with imagemagick, but imagemagick always destroys palettes.
Edit:
A first version can check the subpalettes with specified tile dimensions, colors per subpalette and amount of shared colors between subpalettes.
It wil print stuff like "Tile 1x5 has 25 pixel(s) with colors from wrong subpalette(s)!"
https://codeberg.org/basxto/palgic
Edit2:
Now it can also check if a metatile does not use too many colors. (RGB not palette indices)
NES can only have palettes per 16x16 metatile and not for every 8x8 tile ... unless a special chip is used. So far I ignored that restriction. I'm not sure if this could have any general use, since I mostly need it because my palette is more for switching systems. Maybe for checking that colors for metatiles don't get too out of hand.
They updated their terms April 4, 2023 https://pixabay.com/service/terms/:
3. CC0 License
Some of the Content made available for download on the Service is subject to and licensed under the Creative Commons Zero (CC0) license ("CC0 Content"). CC0 Content on the Service is any content which lists a "Published date" prior to January 9, 2019. This means that to the greatest extent permitted by applicable law, the authors of that work have dedicated the work to the public domain by waiving all of his or her rights to the CC0 Content worldwide under copyright law, including all related and neighboring rights. Subject to the CC0 License Terms, the CC0 Content can be used for all personal and commercial purposes without attributing the author/ content owner of the CC0 Content or Pixabay.
---
cc0 gives you the freedom to distribute it under more restrictive terms
That is generally the case, maybe not the "additional copyrights", but the rest definitely. Creative commons is based on copyright and gives you only freedoms regarding copyright.
If you use something commercially you also have to follow commercial property protections (patents, trademarks …)
The right of one's own picture is a personal right derived from human dignity. If you allow somebody to photograph you that permission is always in a certain context. You can put images into a different context via captions and modifications (especially porn captions, fake nudes and deep fakes). In the worst case that can be defamition, which is a crime in some countries.
You can neither do anything else that constitutes a crime.
Beta of Wayback Machine is over, so here are some updated links:
https://web.archive.org/web/20150920020628/http://open.commonly.cc/unlocked
https://web.archive.org/web/20131113144333/http://garage.commonly.cc/#download
"Tannenbaum" works, but "Baum" doesn't. Maybe they tried to find parts of the compound words.
I basically always Ctrl-A Ctrl-C before I reply.
Occurs always when I use tripple dots, correct quotes and correct apostrophe. (edit: each single one of them breaks it)
https://n0paste.tk/WmI04lg/
Hehe, I fixed the character order.
But be warned, the alignment is also off.
I did not notice at first, that this json format encodes a color mapping and not palettes.
switchpalette.sh actually takes two palettes and maps every color in the first one to the color with the same index in the second one, that works with RGBA. I wrote loadgpl becaus I worked with a lot of subpalettes who shared colors at that time. The implementation of switchpalette.sh also has problems, because one color is mapped after another, this leads to errors when source and target palettes share colors. This also leads to errors, you sometimes do not immediately notice, when the source image has some wrong color values. That's one of the main reasons why I hated that I had to do such a translation in javascript, but I think I replaced all colors at the same time there.
gitg and such tools also have image diffs integrated
I don't think size itself will be much of an issue with 64x64/32x32 pixelart.
Edit regarding size:
Indexed PNGs can be smaller.
On example "Bascinet, Raised, Plumage.png":
Original size: 54.2KiB (8bit RGBA)
Just running optipng: 12.3KiB (4bit indexed)
Filling all transparent colors with black in GIMP and then making black transparent, then saving with maximum compression and minimal additional data: 31.6KiB (8bit RGBA)
Just saving it again with mtPaint makes it grow to 32.4KiB (8bit RGBA), that's the difference in PNG compresison different tools do with highest level (9) compression.
Running optipng on this: 10.5KiB (4bit indexed)
Just making the gimp image into 8bit paletted with mtPaint: 11.5KiB (8bit indexed)
mtPaint does not support <8bit. It can be seen that cleaning up transparent colors can also make quite a different. The first run of optipng actually created an indexed image with an alpha channel, there is no index marked as transparent, I'm not sure whether that's a non-standard thing to do or not.
Color values make a difference because of the RLE, which is part of the DEFLATE algorithm, which again PNG uses for compression.
So that's a different thing we should/could take into account. All transparent area should have the same color. Original LPC spritesheets already do that wrong. If you use paletted PNG with just one index being transparent, you are guaranteed to not do that. But disabling alpha in the editor (that's different from removing it from the image) should be the same, it allows you to see what colors are transparent.
edit2:
The automated way with Image Macick + pngcrush + optipng would be:
file=Bascinet,\ Raised,\ Plumage.png; magick "${file}" -background black -flatten -transparent black "${file}_im.png"; pngcrush -rem alla -rem text "${file}_im.png" "${file}_cru.png"; optipng "${file}_cru.png" -out "${file}_opti.png"
Optipng only saves 10 bytes in this example, since pngcrush already compressed it well.
Are the grayscale images grayscale with alpha?
Is pyxeledit capable of opening indexed PNG? Does it only restrict saving to RGBA?
You can just call it multiple times for that. There is a bit more overhead, because the image has to be read multiple times, but that's about it.
I'd prefere to focus on subpalettes
You basically can do that with gpl too, it's a color per row and the readers just ignored any lines which werent RGB values. I don't know if that's standard conform and I have to test if pillow is capable of reading that. But you can also properly concatenate them with something like cp whatever.gpl whatever_new.gpl; tail whatever2.gpl -n+5 >> whatever_new.gpl or you can filter them out with something like sed "/^\(#\|GIMP\|Name\|Columns\)/d" whatever2.gpl >> whatever_new.gpl
I'd like to allow to feed multiple palettes into my tool, as well as an offset if you just wanna change one subpalette. It should keep the other colors in the palette untouched and also keep the transparent index.
I always place subpalettes one after another and sort them darkest to lightest color.
I should try to switch to pillow, it's more likely to be already installed and it should be doable. It does come with it's own .gpl reader, but my code size will very likely grow.
Next issue would be a duplimap written with pillow, since I really hate what Image Magick does to the palette. Currently I have to do palette swapping before I feed things into Image Magick.
GitLFS has the same centralization issues like SVN, the images are all stored at one place. I don't know how strongly they are connected to domains, but that could make it hard to preserve or fork hard.
If you have an image, grayscale and a palette ... you can as well have an image and a paletted version, which just lacks the alpha data. You can also RGBA images and palettes, like I do in javascript, but that will give you trouble for shared colors, which you can indeed manually fix in your approach. But I imagine it's harder to fix manually, since you do not directly see the colors you assign in the greyscale image. Your additional data can be lost more easily than an embedded palette, when somebody makes a remix without using the tools.
I think I chose PyPNG because all methods of PIL.ImagePalette.ImagePalette are marked as experimental and badly documented
Pages