jdev - 2023-07-30

Hey, mates. I know that XMPP standard supports user to use avatar in any kind of formats. But I wonder the formats that most of developers approve. Personally, I love WebP＞SVG＞PNG; JPEG and AVIF are mediocre in my view; others like jpx, gif, I will not consider them. But, for client software, bad SVG consumes much RAM, and AVIF always consumes much CPU, so they may be inconvenient or even dangerous, I guess? Others mentioned above would be safe unless some pictures being loaded are too large (either in resolution or file size). What are your opinions?

Picture too large is not an issue with the max stanza size currently

☭民兵, for avatars explicitly, XEP-0084 requires it to be present in PNG, with additional nodes in different formats if this is wanted.

I would say SVG rendering is more CPU bound than AVIF or other bitmap formats, especially when using filters.

But it has the very useful property of being a vector format, so it can be rendered at any size.

Also AVIF usually uses the video decoder hardware for decoding, thus completely freeing the CPU while decoding happens.

Thank you for telling me that.

I've never seen avif in the wild yet, do clients support that?

I do not care about this situation. I guess very less people know and use AVIF.

me too. I suppose coz it use hardware to decode which is not widely available ?

Almost no xmpp client supports svg for anything. It's something I'm slowly adding to mine

singpolyma: it's mostly not up to clients

Jpeg and PNG are well supported of course, and webp support is pretty good

You have a gui framework or lib that loads pictures

And necessary deps just need to be installed

In gajim we use gtk pixbuf and pillow

So we probably support everything under the moon. But user needs to install those libs

Yes, gajim supports webp fine these days because of that. So long as OS is new enough to have pixbuf webp

Yes. I hope clients support SVG too. By the way, I guess clients should not draw it as the file specified inside then resize, draw it in a small size directly would be safe?

Link Mauve has had a SVG avatar for a long time, I expect it to work fine

SVG it would be nice to have consideration in some of the XEPs as well since base64 encoding xml to put back into XML is sad

But I'd take just better support

Once I created a bad SVG which made the display size too large, it made my web browser consume too much RAM. ✏

> Link Mauve has had a SVG avatar for a long time, I expect it to work fine It works well, though Conversations does not support it for now.

singpolyma, on the desktop, AVIF and SVG are very well supported.

> me too. I suppose coz it use hardware to decode which is not widely available ? AVIF can be decoded by CPU too, as a fallback. ✏

Link Mauve: good to know. More reason for me to finish integration in my app

And there is an excellent CPU implementation called libdav1d.

Zash, I still have an SVG avatar. :)

singpolyma, base64 XML isn’t much of an issue, the operation of de-base64-ing text is extremely cheap in comparison to the parsing and rendering process.

Big waste of space though, which is at a premium in a stanza

I believe AVIF and SVG are well supported on the web as well

lissine: yes of course, everything gets good support on web first

☭民兵, in resvg, which I use in some unrelated project lately, there are two different steps in the API: first it parses it into some internal representation which is still vector-based, and then there is another function to actually transform that into a bitmap.

The benefits are that you can re-render it at a different size much cheaper than if you had to redo the whole process.

singpolyma, the lack of compression is a much bigger waste of space, and we don’t use that at all since there is no MIME type for svgz.

SVG, especially as generated by Inkscape or similar tools, is very redundant at times.

Inkscape will include the same CSS snippet on every single element, even when it doesn’t differ from the defaults.

I doubt compress then b64 will be smaller than uncompressed

I recommend using a tool like svgcleaner before upload if you care about the stanza size.

Oh sure, optimized SVG is a thing

singpolyma, yesterday I had a look at a SVG icon for some software, it was 17 KiB at first, 7 KiB compressed, 5 KiB uncompressed but after svgcleaner, and 3 KiB compressed after svgcleaner.

That was a random Inkscape output.

A dataset of one, but common in my experience.

After base64 that would be 23 KiB.

Note that this is still around the median of the avatar sizes of my contacts.

to me svg is the source from author and png is for publish and consuming

Trung, it depends what you want to do.

it much less headache to open the svg, hit export to png for wherever you want to publish. Allow me to adjust the design appropiately too

Which adjustments do you make?

depends

https://trung.fun/logo.png is my main logo. The space around it is intentional. But if you look at my avatar, it is punched in quite a bit. And my favicon is broken on purpose.

depends on brand and design and etc

> to me svg is the source from author and png is for publish and consuming No. PNG is always bigger and lower quality than SVG ↺

For vector stuff of course I mean

yes correct. the source file is always bigger

I think that's the opposite of what I said

sorry more flexible i meant

don't let that stop you doing svg for avatar tho. i can see you adding effects into it which can open new creative doors. why not

Although for animations, no renderer besides web ones support that. :(

Trung, with SVG you can reference external elements with the <use/> element and draw them wherever you want at whichever size you want, with as many or as few borders as you want.

This isn’t a feature of any bitmap format in wide usage (that I know of).

AVIF comes close with invisible frames, but that’s in a single file, you can’t reference frames in a different file.

singpolyma, it really depends on the size at which you render, very small PNGs are almost always smaller than the source SVG.

But with the trend of having very high DPI in screens, some icon which used to be small like 32×32 can now be 128×128 on some screens and now you have to ship all of the intermediate sizes.

> Although for animations, no renderer besides web ones support that. :( Yes, this is true of the one I'm currently using also ☹️ ↺

Even without going that way, people like to zoom in and now you have to re-render at a different scale even if they didn’t change screens, or it will look blurry and bad. ✏

Not all designer like to work with code... 🙂

Not sure how that's related :)

> Trung, with SVG you can reference external elements with the <use/> element and draw them wherever you want at whichever size you want, or as few borders as you want. `<use/>` is code rite? are there a gui buttons to do that in inkscape and the like?

conditional branching is second nature when you're familiar with programing but if you grap 10 graphic designers and ask them to do such thing, i bet you all 12 of them will surrender

Trung, yes there is, right click > Clone.

In object mode.

>> Trung, with SVG you can reference external elements with the <use/> element and draw them wherever you want at whichever size you want, or as few borders as you want. > `<use/>` is code rite? are there a gui buttons to do that in inkscape and the like? Yes of course. No one* writes thier SVG by hand as code ↺

Conditional rendering in SVG is <switch/>.

yeah … i don't think people use the features very often. they would rather render png. it's less headache

Trung, on my system, only 55 out of 1220 SVG icons use a <use/> element.

It is a common feature, even if you didn’t know it existed until now. :)

Some of these SVGs are created by Illustrator too, so I assume this software also knows how to use <use/>.

thank you Link Mauve. I'd still render to png tho. I like to reserve my brain for other things when doing graphics

😁

What I am trying to say is, know your tools, it’s always useful to not feel limited by them.

limit is mother of all creation

Yeah, PNG can't help but look ugly since it can't be safely rendered at any size but the one it was created with. So it's really a desperate last resort kind of format IMO. Unless it's a painting or photo and was raster to begin with of course

I think webm ist better then png for nearly everything

Menel: you mean webp? For the purposes of this raster vs vector discussion it's identical :) but yes it's got better compression than PNG usually

Yes 🙂 too muc stuff out there ✏

Not even, WebP has the annoying property (inherited from VP8) of only supporting 4:2:0 chroma subsampling, which means any schema or image using sharp colour changes will look extremely ugly.

If you go for lossless WebP you won’t get this issue, but it is a completely different format actually.

And it doesn’t have much benefit over PNG.

It also can’t use hardware video decoders VP8 WebP uses.

If you want an image format based on a video codec, AVIF is better in every way.

heh didnt know it was that bad

It does support 4:4:4 subsampling at almost no additional cost, 10-bit for nicer gradients, and the usual animations, transparency, etc.

And it has hardware decoding support.

For a much smaller file size for an equivalent quality to VP8. ✏

At a much smaller file size for an equivalent quality to VP8. ✏

> If you go for lossless WebP you won’t get this issue, but it is a completely different format actually. Yes, when I talk about webp in the same conversation as PNG I mean lossless of course ↺

Most people mean VP8 and not lossless when they talk about WebP. ✏

That's not useful to compare to png though since PNG is lossless. Lossy webp one compares to jpeg

Not even, JPEG is usually nicer at still images.

Sure, you can prefer jpeg, but it's a fair comparison at least

Whats wrong with gif?

Trung: palletized colour

No alpha

pallettes are cool tho

subsample? ...how many screens are there that display 444 10bit?

and color calibrated every week by professional

singpolyma, GIF actually supports more than 256 colours, but still 1-bit alpha.

Trung, 4:4:4, almost every screen which isn’t a shitty TV.

10-bit, high end screens, but that is still useful for gradients, and especially in dark areas where the difference between two adjacent colours is huge.

Programs which display 10-bit images on 8-bit or 6-bit panels will usually dither them, a technique which costs a lot in bitrate but is free when you do rendering.

Trung, also GIF compresses much less than PNG for an equivalent image.

(With some exceptions.)

Does your phone display 444? How big is the screen ?

Trung, phone displays use RGB LEDs, so each pixel can independently set each component in the colour.

They don’t depend on the colour of the pixels on the sides.

4:2:0 is where groups of 2×2 pixels share the same chroma value, but still have different luma intensities.

the only time i ever need 444 10bit is when i still need to push color of the image and do vfx. After the render it almost always down to 422 coz no one needs all that fancy thing with gigantic size

420

Trung, as I said, with modern codecs like AV1 the difference between 4:2:0 and 4:4:4 is around 5% of the bitrate.

And even with JPEG it’s pretty common to use 4:4:4, when you don’t want to destroy the quality too much.

4:2:0 is more common in videos, not so much for still images.

Yeah gif is not still tho

> 10-bit, high end screens, but that is still useful for gradients, and especially in dark areas where the difference between two adjacent colours is huge. You can't see the gradient details from consumer screen i think. The colors they display are off aniway.

Trung, GIF doesn’t do 4:2:0.

Also no, gradient banding is totally visible on consumer screens, and don’t depend on calibration.

Yeah i agree

Here is one exagerated example:

https://upload.wikimedia.org/wikipedia/commons/9/9a/Colour_banding_example01.png

I wasnt agaisnt u lol i need bed

Ừ đúng rồi

Oh no wrong window sorry

Ok now do 24-bit gradient, dithered and animated

or, heck, 8bit animated dithering will beat your 24 bits every day!

Zash, this one is a wrong example because it is a single component, so 24-bit actually means 8-bit for the previous discussion.

24-bit is actually 3×8-bit, one for each of red, green and blue, so for a black to red gradient we only use one component, the red one.

Link Mauve, remember/seen the thing where someone squeees insane quality out of a friggin 1-bit monochrome screen?

I can’t find a good example right now, but take any video shot in a very dark environment, if it’s encoded in 8-bit (per component, so 24-bit) it will have very visible banding artifacts, if it’s encoded in 8-bit but with dithering the file size will be huge, if it’s encoded in 10-bit (per component, so 30-bit) it will look great and have a small bitrate.

Zash, sure, I even have a video player on the GameBoy. :p

The quality isn’t great, especially the audio quality at 3-bit. :D

> I can’t find a good example right now, but take any video shot in a very dark environment, if it’s encoded in 8-bit (per component, so 24-bit) it will have very visible banding artifacts, if it’s encoded in 8-bit but with dithering the file size will be huge, if it’s encoded in 10-bit (per component, so 30-bit) it will look great and have a small bitrate. Yeaah thats rite. Bitrate and siza aint evryth

Web centric comparison :https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types

> Link Mauve has had a SVG avatar for a long time, I expect it to work fine Link Mauve ever had an avatar? 🫣

I only see him as 'L'.

I bet that L is a svg tho!

Hmm.

Martin, Android still doesn’t support SVG…

What year is this???

🤦

It will probably only take me a couple hours to fix this once I get back to my house, so I should just do it

> Not even, WebP has the annoying property (inherited from VP8) of only supporting 4:2:0 chroma subsampling, which means any schema or image using sharp colour changes will look extremely ugly. Comrade Link Mauve, you are an expert of picture formats! That is my experience too. WebP encoder provides a mode called “near-lossless”, which deals little damage to sharp colour. How do you think about that? It looks like it is causing damage before using lossless encode.

I think WebP is far better than PNG in all ways except the resolution is limited in 16383×16383. But that resolution is far enough for me. ✏

> I bet that L is a svg tho! Yes. Now it is.

I do not know any advantage of GIF when comparing it with WebP.

If somebody really cares about sharp colour, they must use lossless but not lossy, I think. If they still want to use lossy for the pictures they care about colour, they could use the “near-lossless” mode and set the parameter as they like.

>WebP encoder provides a mode called “near-lossless”, which deals little damage to sharp colour. It could produce a better quality in both visual and file size than the lossy mode of WebP when being used for simple screenshot. ✏

That would produce an amazing effect if you use the near-lossless mode to an picture with all of extremely random colour pixels, obviously better than JPEG.

> I do not know any advantage of GIF when comparing it with WebP. Gif is probably still more widely supported ↺

Well... I hope it will be abandoned in the future, if not, then this world is too conservative.

Web browser older than 2 weeks? Sorry can't run this website. Image format 15 years old? Sorry still not supported

It's not like that... Unless the ternary computer is newly invented in the future...

Yeah it's actulaly 6 weeks that's the treshold.

and SVG is 22 years old?