bzt 2b5485f438 Added rc file | %!s(int64=2) %!d(string=hai) anos | |
---|---|---|
src | %!s(int64=2) %!d(string=hai) anos | |
LICENSE | %!s(int64=3) %!d(string=hai) anos | |
README.md | %!s(int64=2) %!d(string=hai) anos | |
pngpal | %!s(int64=2) %!d(string=hai) anos | |
pngpal.exe | %!s(int64=2) %!d(string=hai) anos |
Little command line tool that replaces colours in images according to a specified palette.
pngpal by bzt Copyright (C) 2021 MIT license
https://gitlab.com/bztsrc/pngpal
./pngpal [-m <num>] [-p <palfile>] [-c] [-t] [-g] <input image> <output png>
-m <num> set the maximum number of colours
-p <palfile> load palette (aco, ase, jasc-pal, gpl, paint.net, any image)
-c use CIE76 method instead of sRGB distance
-t make the output a truecolor image
-g generate palette ramps
<input image> input image (png, jpg, gif, tga, bmp, pnm, psd)
<output png> output image, always png (truecolor or indexed if possible)
Just download, no dependencies, no install, portable executables.
Just run make
in the src directory. No configure, no dependencies, suckless as it should be.
You can read the palette from various formats. If the -m
option is given, then it will read
that many colours (up to 256).
In theory multiple colourspaces supported in palette files (grayscale, HSV, CMYK, LAB, RGB), but only RGB was tested. With images for the best results, you should use an indexed image (gif or quantized png), or a true-color image that has no more than 256 different colors in it. Dimensions and number of pixels doesn't matter, only how many different pixels there are.
Alpha values never read from the palettes, instead the original image's alpha channel is preserved.
For the colour conversion, by default sRGB distance is used. It is fast and provides very good results most of
the time. However in some edge cases it might choose bad colours, so you can use the -c
flag to use the CIE76
method (which converts both the palette and the image to CIELAB colourspace and then calculates distances there.)
Input can be in any format that stb_image understands:
For animated gifs, the frames are extracted vertically (first frame on the top, last frame at the bottom).
The converted image is saved as a PNG with alpha channel. No .so nor .dll needed, libpng included. If possible, then the
output is going to be indexed (8 bit per pixel plus 24+8 bit palette, much smaller file size), unless -t
given, in which
case output is always saved as a 32 bit per pixel image, even if it contains less than 256 different colours.
If -g
given, then the output won't be a converted image, rather it will contain the palette ramps of the input image,
vertically sorted by color (hue) and horizontally by decreasing luminance (not perfect, but good enough).
Licensed under the terms of MIT license.
Cheers,
bzt