Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rgbgfx -c png to specify palette specs as visible images #1123

Open
Rangi42 opened this issue Jan 3, 2023 · 11 comments
Open

Add rgbgfx -c png to specify palette specs as visible images #1123

Rangi42 opened this issue Jan 3, 2023 · 11 comments
Labels
enhancement Typically new features; lesser priority than bugs rgbgfx This affects RGBGFX

Comments

@Rangi42
Copy link
Contributor

Rangi42 commented Jan 3, 2023

Each color would be a single pixel, read top to bottom, left to right. (So for two palettes a user might supply a 1x8 png, or 8x1, or 4x2, or even 2x4.) The png's encoding wouldn't matter, only the individual pixels' colors.

@Rangi42 Rangi42 added enhancement Typically new features; lesser priority than bugs rgbgfx This affects RGBGFX labels Jan 3, 2023
@evie-calico
Copy link
Contributor

Why top to bottom? Left to right first seems more intuitive

@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 3, 2023

I mean the standard row-by-row order of English reading, electron gun scanning, etc.

@aaaaaa123456789
Copy link
Member

If we're going to do this, it might be worthwhile to also allow something like -c png42 to indicate that each color is represented by a 42×42 box instead of 1×1 (for any value of 42, of course). The reason for this is that many visualization tools will only reduce large images, but not expand small ones (or what's worse, use some sort of bilinear filtering when expanding small ones, creating lots of blur), which makes small images very hard to visualize outside of editing tools.

@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 3, 2023

That sounds useful too, although it could be a follow-up issue once this one is resolved.

@evie-calico
Copy link
Contributor

On second thought, i still think it would be worth being able to embed the palette in the first or last row of the image. For images which have unique palettes, I don’t see the point in creating a separate file with the palette definitions only for it to be used once. It only makes it more cumbersome to modify the palette, needing to do so in two files rather than one.

@ISSOtm
Copy link
Member

ISSOtm commented Jan 7, 2023

I would make -c png:image.png determine the box size automatically (inferring it from the amount of identical consecutive pixels on the first row), and -c png,42:image.png/-c png@42:image.png (not : to avoid parsing ambiguities) to enforce a specific size.

For images which have unique palettes, I don’t see the point in creating a separate file with the palette definitions only for it to be used once. It only makes it more cumbersome to modify the palette, needing to do so in two files rather than one.

It's for consistency: if you are using -c png generically, it's okay; if you aren't using it for specific images, you might as well use at-files.

@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 7, 2023

For images which have unique palettes, I don’t see the point in creating a separate file with the palette definitions only for it to be used once. It only makes it more cumbersome to modify the palette, needing to do so in two files rather than one.

Also you don't have to create a separate file; you should be able to pass rgbgfx -c input.png -o output.2bpp input.png.

@evie-calico
Copy link
Contributor

evie-calico commented Jan 7, 2023

But then it’ll read the image as a palette… that doesn’t make sense. if you make the first line of the image the palette you want to use, that line will show up in the output

@Rangi42
Copy link
Contributor Author

Rangi42 commented Jan 7, 2023

Ah, you're right, I was thinking in terms of an indexed palette, but that's what embedded is already for.

@aaaaaa123456789
Copy link
Member

I think what you're describing is some imaginary mode -c from:foo.png where the palette is taking from another file's indexed palette.

@Rangi42 Rangi42 added this to the v0.6.2 milestone Feb 8, 2023
@Rangi42 Rangi42 modified the milestones: v0.7.0, v0.8.0 Oct 31, 2023
@Rangi42 Rangi42 removed this from the v0.9.0 milestone Aug 6, 2024
@ISSOtm
Copy link
Member

ISSOtm commented Aug 14, 2024

At the very least, this should be compatible with the PNGs generated by contrib/view_palettes.sh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Typically new features; lesser priority than bugs rgbgfx This affects RGBGFX
Projects
None yet
Development

No branches or pull requests

4 participants