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

Feature request: More flexible "reverse mode" in rgbgfx #1096

Open
Rangi42 opened this issue Oct 14, 2022 · 6 comments
Open

Feature request: More flexible "reverse mode" in rgbgfx #1096

Rangi42 opened this issue Oct 14, 2022 · 6 comments
Labels
enhancement Typically new features; lesser priority than bugs rgbgfx This affects RGBGFX

Comments

@Rangi42
Copy link
Contributor

Rangi42 commented Oct 14, 2022

I'd like to remove bpp2png.c from our projects and recommend rgbgfx -r, but bpp2png has two conveniences:

  • It can guess a width based on the 2bpp size, or default to 128px, so you don't have to specify one.
  • It can pad an image with blank tiles if the specified width doesn't perfectly divide it, which is not uncommon for images that have had some trailing tiles removed with rgbgfx -x (or gfx.c's --trim-whitespace).

(I also think it's more intuitive to not have to specify -o as the input file, but it arguably makes sense for rgbgfx since -t, -a, and -p all become inputs instead of outputs too.)

@Rangi42 Rangi42 added enhancement Typically new features; lesser priority than bugs rgbgfx This affects RGBGFX labels Oct 14, 2022
@eievui5
Copy link
Contributor

eievui5 commented Oct 14, 2022

I also think it's more intuitive to not have to specify -o as the input file

The main rationale behind this was that you could simply add -r to a command to reverse it.

@ISSOtm
Copy link
Member

ISSOtm commented Oct 15, 2022

Doesn't -x already add blank tiles to the end of the input? If not, maybe that should be added.

As for guessing the input size, unless the image is perfectly square, the guess is at best 50/50. A default width is not appropriate in general, only for a single project. (And even then, you can just specify the flag instead. No?)

@Rangi42
Copy link
Contributor Author

Rangi42 commented Oct 15, 2022

-x has to specify how many tiles to pad, which you may not know offhand; -r N could just add however many tiles are necessary to make a rectangular image.

Regarding a default width, it could just use "any PNG width that can be re-generated the same way". For example, if you have 4x6-tile PNG and convert it to 2BPP, and you reverse-generate a PNG with "-r auto", it could end up as 4x6, 6x4, 12x2, 1x24, etc; any of those would be accurate to the original data.

@ISSOtm
Copy link
Member

ISSOtm commented Oct 15, 2022

Yes, but my point is that if you specified -x as input, you can also specify the same in "reverse mode".

Those wouldn't be accurate to the original data, since they wouldn't even be the same width.

@Rangi42
Copy link
Contributor Author

Rangi42 commented Oct 16, 2022

The use case is for when you have a .2bpp from somewhere, and want to view it as a png, without having to check its filesize, divide by 16, and calculate a valid width. (Or use the always-valid but hard-to-view -r 1.) The result is accurate in that it can get the exact same .2bpp back, so for example, you can take a project full of .2bpp files and replace them all with .pngs without breaking the build.

@ISSOtm
Copy link
Member

ISSOtm commented Oct 16, 2022

Then the best guess to take is 1, which is equivalent to -r 1. Is it not sufficient to view the file, press up in the terminal, change the argument to -r, and pick something else?

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

3 participants