Add rgbgfx -c modulo to accept embedded palettes with extra used colors
#1067
Comments
|
Isn't it sufficient to generate the palette with $ rgbgfx -c embedded -p >(dd of=testcase1.pal bs=8 count=1 status=none) -o testcase1.2bpp testcase1.png |
|
Most tiles in the test case contain both pixels of color 0 and pixels of color 4. I had planned to try the command line snippet in ISSOtm's reply to observe how rgbgfx master reacts to
|
The first result for Ctrl+F'ing
Yes, I had a brainfart. Edited the line to be correct. |
|
It is not sufficient, at least with this particular test case. I have made an additional
|
|
Two additional test cases:
|
|
I think the errors are caused by |
Rangi42
added
enhancement
|
This is why: Lines 567 to 569 in a47da5f So if I'm understanding correctly, this should instead be: if (embPalSize > options.maxOpaqueColors() * options.nbPalettes) {
fatal("Too many colors");
}, right? |
|
I think my rationale for this condition was that it's unclear what should be done with more than 4 colours but the number cannot be divided by 4. |
|
If there are 7 colors 0-6, then colors 4-6 should become colors 0-2 in the output. |
|
Or to put it another way: |
|
The problem is that we don't know where the colours are being used at this point, so "0–3 and 5–7" is a non-starter. |
|
The three test cases, for reference:
|
|
|
|
I am using Thus I don't understand "closed this as completed". |
|
@pinobatch Okay, looking at this again I see what the intended goal is. I think " This would require PNG pixels to initially be read as their palette indexes, collapsed with That's possible to add of course, but nontrivial since currently indexed PNGs are entirely converted with libpng's |
|
This is further rendered difficult by the palette being determined before any image processing is done. Doing so being inherent to RGBGFX's processing structure (how do you even read pixel indices if you don't even have palettes yet?), this is not something that can be changed. |
|
A preprocessing script could modulo all the PNG's palette indexes by 4 before applying #!/usr/bin/env python
import sys, png # PyPNG
if len(sys.argv) != 3:
print('Usage:', sys.argv[0], 'in.png out.png', file=sys.stderr)
sys.exit(1)
with open(sys.argv[1], 'rb') as file:
reader = png.Reader(file)
width, height, rows, info = reader.read()
rows = list(rows)
if 'palette' not in info:
print(sys.argv[1], 'does not have an indexed palette!', file=sys.stderr)
sys.exit(1)
rows = [[idx % 4 for idx in row] for row in rows]
writer = png.Writer(width, height,
palette=info['palette'], bitdepth=info['bitdepth'], compression=9)
with open(sys.argv[2], 'wb') as file:
writer.write(file, rows)Then in your Makefile: %.mod.png: %.png
python modulo.py $< $@
%.mod.2bpp: %.mod.png
rgbgfx -c embedded -o $@ $< |
Say I have an indexed image with 16 input colors, and I want each input color to be reduced modulo
2**bit_depthin the output. For example, input colors 1, 5, 9, and 13 would become 1 in the output. I have relied on this behavior of a different tool in a previous project targeting an 8-bit console with 2bpp character graphics. Would it be reasonable to add-c modulo, which is-c embeddedwithout the fatal error on an out-of-bounds color value?If there's no serious objection, I plan to attempt the PR myself.
Test case:
testcase1.pnghas 8 colors and uses all 8.testcase2.pnghas 8 colors and uses the first 4; all color index values have been reduced modulo 4.testcase3.pnghas 4 colors. Converting them with-c moduloshould produce the same character data as convertingtestcase3.pngwith-c embedded. (I've used two of them as test cases for #1064 as well.)The text was updated successfully, but these errors were encountered: