Best image file format for designing custom GUI & animations ?

[amiga500]

Hello & greetings ! What is the "JUCE recommended" image format for creating custom GUI graphics such as sliders, knobs, and buttons that can be moved or rotated? Specifically, we are looking for advice on which file format is optimal among JPG, PNG, SVG, or X. We haven't been able to find any official guidance from JUCE on this topic.

Moreover, should these images be prepared as a filmstrip or as separate images for each position of the component? How should we communicate to our graphic designer friend about the required format and specifications for creating these graphics?"

Thanks

[yetkin]

Hi there! I was also searching for an answer to the same question. I am currently trying to determine which format is more commonly used and which one is better overall.

[T-CM11]

PNG, SVG

I'm no programmer (desktop publisher), but you should read up on the difference between pixels and vectors.

[Cyforce]

Most developers use PNG for their UI/Skin files, probably for a reason. Even if e.g. JPG looks smaller in filesize than PNG sometimes - most of the time (I think in NI Kontakt UI it`s the case) the graphics (only PNG can be used) will be transformed into binary format anyway to process the UI interface. So maybe PNG is there more efficient or it`s because PNG is open-source while JPG is not (so far as I know).

It also depends on the subject, like Knob/Slider strips with transparency - PNG is the better choice.

[otristan]

PNG is lossless while JPG are not

[matt42]

JUCE supports the PNG (which as mentioned is lossless and handles transparency) format, but the built in controls use vector graphics. You'd need to inherit from a control class and implement the loading and displaying of the images yourself. Typically you'd use a filmstrip, but the formatting details you give to your designer would depend on your implementation of course.

[amiga500]

JUCE supports the PNG (which as mentioned is lossless and handles transparency) format, but the built in controls use vector graphics. You'd need to inherit from a control class and implement the loading and displaying of the images yourself. Typically you'd use a filmstrip, but the formatting details you give to your designer would depend on your implementation of course.

Thank You

[BrutusMagnus]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

From what I've gathered, JUCE doesn't have a strict rule on image formats, but a lot of folks seem to prefer PNG for its lossless quality, especially when dealing with elements like sliders and buttons that might need transparency.
Regarding filmstrip vs. separate images, it depends on your animation approach. If you're going for smoother transitions, a filmstrip might be handy.

As for communicating with your designer friend, just let them know PNG works well, and if animation's in the mix, a filmstrip could be useful.

Speaking of image compression, you could use a JPEG optimizer. It can help you compress image (https://jpeg-optimizer.com/) without losing too much quality. It's been a game-changer for me when trying to find that sweet spot between file size and visual clarity.

[Music Engineer]

For pixel graphics, I would use .png filmstrips and for vector graphics, I would use .svg and do the rotation or translation or whatever transformation is needed in the code. But then, I have not yet used any graphics files for GUI stuff so far (I render my GUIs programmatically), so I have no idea, if that advice is any good. ...and if you want to go with vector or with pixel graphics (or a mix of both) - that's a design decision, you'll have to make. Both have pros and cons. Vector graphics are freely scalable without quality loss, pixel graphics are guaranteed to look the same everywhere because no renderer is involved to display them (because you already deliver them pre-rendered) and the graphic designer has more freedom to do more advanced stuff - like, say, 3D raytraced stuff and/or post-processing with sophisticated image processing algorithms or whatever. With svg, you are restricted to what svg can do - and perhaps even more so by the renderer, if it doesn't implement the full feature set of the svg specification. I don't really know, how feature complete JUCE's svg-rendering capabilities are - but a quick search brought up this:

https://forum.juce.com/t/i-figured-out- ... juce/52953

which seems to imply that it is not complete, so your graphic designer would be further restricted to use only those features of svg, that JUCE supports

[whyterabbyt]

PNG is lossless while JPG are not

that.

[S0lo]

Another crucial difference between JPG and PNG is that JPG doesn't support an alpha blend channel or even just a transparency color. Which is a major difference if you want to layer UI components code wise.

Edit: There is this JPEG 2000 format which seam to support transparency. But I'm not knowledgeable of any further details about that.

[Urs]

PNG is not only lossless, it also has an alpha channel for transparency.

[diroxe7660]

If you're considering venturing outside of JUCE, QOI (lossless with alpha) is worth a look.

A couple notes on SVG vs PNG vs QOI:

- SVG has the advantage of being vector based - free infinite scaling and 'free' ultra basic font rendering!
- Adding lots of fine detail to SVGs is artistically very difficult and quickly increases rendering time.
- There are no SVG libraries that are fast, complete AND small - you only get to pick between two.
- A complete and fast SVG library with support for compressed SVGs will add a MiB or even more to your plugin.
- PNG is fairly slow to decode and mature decoders are fairly large (but very small compared to SVG).
- The QOI reference decoder is tiny (<15 KiB).
- QOI is exceptionally fast to decode.
- QOI images are usually 0% - 25% larger than optimised PNGs.
- Pre-filtered (visually lossless) QOI images are competitive with PNGs for size.
- PNGs encoded and decoded with richgel999's fpng are competitive for speed with QOI images, but PNG's size advantage is lost in the process - and the decoder is still much more complex (iirc the fpng decoder uses SSE intrinsics, so not trivially portable)

[mystran]

Besides the fact that PNG is lossless, supports alpha and offers reasonable compression, it also comes with a killer feature: if works just about everywhere. It's all good to have a fancy format, but it becomes a pain the moment you need to convert formats just to open the image in another piece of software.

That's why you use SVG for vectors, PNG for lossless rasters, JPEG for photos, PDF for printing, DXF for laser cutting and Gerber for etching PCBs.. not because they are the "best" formats, but rather because they are what everyone else is using and therefore you can expect them to work with minimum fuzz.

Something like stb_image is almost trivial to put into a project, doesn't add any ridiculous weight into your binary and will load most common (raster) formats. That means if you end up with a file that is something other than PNG/JPEG, it'll probably load it anyway... but it still makes sense to use PNG just because there are much better ways to spend your time than to figure out why some obscure format loads wrong in some random piece of software.

[Guillaume Piolat]

Using a combination of JPEG, PNG, and a custom codec QOIX which always beat QOI (and does 10-bit, greyscale...). Vanilla QOI only beats PNG that is output by stb_image_write.h, who has a rather bad zlib encode. libpng beats vanilla QOI hence better QOI variants appeared quickly in the last 2 years, such as QOIP, QOIX and QOIR. All the variants beat QOI at least 15%. In particular QOIR would be well suited to C++ audio plugins instead of shipping gigantic PNG that you then decode with the slow zlib in stb_image.h

From QOIR github:
https://github.com/nigeltao/qoir/blob/m ... pratio.png