chore(color): helper script to convert SVG firmware graphics to PNG

[pfeerick]

Summary of changes:

• work in progress helper script that will convert SVG graphics for menus, etc as used in colorlcd radio firmware to PNG files.

Supersedes #6762, may replace #6768.

TODO:

• [x] --validate like option that checks for PNGs without SVGs, SVGs without PNGs
• [ ] --clean-slate like option that deletes all PNGs in the image folders and regenerates from SVG
• [ ] consider version locking resvg version used for consistency... might be easier if switch to python + uv instead if that is worth pursuing

[JimB40]

for considereration resvg produces better quality PNG (less jagged edges, bettter gradients) but cost is PNG size -> splash_logo is 90kB vs 55kB for 800x480 size

I'm reading that resvg is recommended for accurate rendering for web/illustrations while rsvg-convert for system integration (e.g., GTK apps)

[pfeerick]

resvg is more about performance (i.e. it's faster) and standards compliance, as well as better at handing more complex SVGs than what rsvg-convert (librsvg) is. But you don't get anything for free... given we're still talking about PNGs (rather than a complete change of format) ... improved quality is usually going to be at the expense of file size/usage... so if rsvg-convert is still making good enough quality images (to be honest, I don't think you'd tell the difference given the screens currently in use) and doesn't choke on the SVG source files ... I'd vote for smaller sizes over quality. I simply avoided it due to cairo (which rsvg-convert uses for rendering) having a history of issues with "complex" SVGs.

[JimB40]

Differences are minimal, with resolution like 800x480 and less jagged edges is not an issue because all edges are jagged anyway :) I can't spot any quirks even in complex SVG like logo above. It should be rather as rule of thumb that while designing SVG is downgraded to simplest format > that means converting everythnig to shapes.

[3djc]

Just for consideration, higher DPI displays are likely

[JimB40]

@pfeerick Peter I've submitted #6781 that also includes changes to helper SVG > PNG because I was using it to cleanup gfx source images, we need to sync it somehow. I'm rookie with Github so better ask you twice before screw something. Bear in mind that CSV now holds new graphics names so it is not copy-paste to your draft.

In this PR:

1. changed script name to convert-gfx.sh I don't know why but VScode didn't allow me in new PR to use the same name conver-icons.sh, besides we convert graphichs.

2. added --resvg param to force using resvg insted of rsvg-convert (testing) New script uses rsvg-convert as default. based on my test PNG are smaller, but added option to use resvg engine for testing

3. updating only changed files

As long as the tool generates the same content each time, a new generation pass should only result in the new files being >wanting to be committed anyway... when you try to add them, git will ignore the unchanged files. i.e. I just ran this on my >system, and it didn't propose any new files to be checked in... which is how things should be with a reproducible >conversion process.

Somehow while generating all gfx Github claimed all are new files. So added --update flag and "modified" field to CSV Script compares actual SVG file modificitation date with the one stored in CSV then generates only those that are newer and updates CSV with actual SVG modification date.

4. CSV placement May be in img-src folder as @philmoz suggested as we keep "business" in this folder

5. CSV separator As noted I used to use semicolon not to run into issues with decimal place symbol just a habit. only integers in data but you never know :) VSCode uses colon ad default so had to changed it to semi-colon to get proper visual preview. If you prefer colon we change.

Now How do we sync both #6772 and #6781 Should I manual fix comma separator, CSV file placement in #6781?