Hacker News Reader

Comment by firefoxd | Hacker News Reader

Recently I made a small game at work called JPEG or PNG, for the front end team. Bootcamps tend to not focus on image formats at all, the results is all Figma images gets exported as PNGs and bloat the website. Devs often argue that the format is "sharper".

Anyway, my game consisted of a slide of images and we vote what's the most appropriate format. When when people got a hang of it, I threw in WebP and SVG. I talk about those last, because they can easily abused: i.e an SVG with an embedded png.

View on HN

My favorite real world example of this was adding a bunch of 2-tone graphics to a website that looked like hand-drawn sketches. The designer insisted they have to be SVG because vector graphics scale better.

The SVG was 20MB. The PNG version at huge resolution was 20kB.

PNG is really good when you have a few flat colors. SVG is really bad when you have lots of fine detail.

I wonder how much you could have compressed that SVG if you stored the broad strokes and added the perturbations with javascript, after loading.

Client side JS will always be slower than letting the browser render the PNG.

Have to wonder what those 20 MB SVGs were like and whether they could've been optimized as SVG still. Doesn't seem to add up that at "huge" resolution that PNG would be that small either.

> Doesn't seem to add up that at "huge" resolution that PNG would be that small either.

Well maybe not huge huge. Like 1000px wide so they look nice on retina screens.

The key is that these images were just 2 contiguous color areas. Black and transparent. PNG is really good for that because the compression algorithm works on the basis of contiguous color areas.

Was there any attempt to optimize SVG? If it was just a single object/path, it'd be pretty small (if it was optimized/simplified for curves/node count, it could be even smaller), and then it could be harder matching that size with PNG or it wouldn't be that much of a difference.

PNG keeps a count of sequentially-same color pixels (not really but roughly speaking) instead of keeping pixels themselves. So scaling a monocrome png image means just changing the count entry (very roughly speaking), so it'll be nearly zero cost.

What I mean is, if you have a million pixels of the same color (0xDEADBEEF maybe), then PNG will call that 1,000,000 x OxDEADBEEF. So, it scales very nicely for few-color, sparse or "blocky" images.

Fine detail isn’t really the metric to use when thinking of SVG size. 20MB just sounds like a catastrophic degenerate export from shitty software

They said halftone, so I imagine every pixel became a circle.

I’ve worked with various graphic formats for web… for over 20 years at this stage.

It’s incompetence to blame rather than file-size, maybe designers or someone in the briefing process that is uninformed that confuses the requirements for everyone else.

Also… I don’t trust Figmas quality with exported SVG. Just type some text, export it and see how it degrades…

Unless Figma is embedding a raster image of the text in the SVG, how is that possible?

When I was looking at it a few months ago, vector lettering (an outlined name in a logo) when exported the curves were goofy. I brought them into Illustrator and overlaid it on the actual logo and there was a clear difference.

Couldn’t find the source of the issue so could only assume the SVG data was being compressed on export.

We decided to only use it to share graphic across the team, in any instance we were working with type we used illustrator.

> results is all Figma images gets exported as PNGs and bloat the website

It's not just size but also decompression time. JPEG is way faster to decode which is also on the critical path towards time-to-display

> Devs often argue that the format is "sharper".

And they’re correct.

PNGs use lossless compression.

JPEGs use lossy compression. (JPEG XL allows for lossless.)

> Bootcamps tend to not focus on image formats

Can you tell me which university class you took that did?

I did a course on them at university. I can't remember what it was called.

https://web.stanford.edu/class/cs148/ would be a class that covers raster vs vector graphics, which should be covered in every computer science degree.

Which got me thinking, may be there should be a tool that shows results of compression and allow devs to choose which one to use?

JPEG, PNG, WebP, JPEG XL and SVG. Even though I am pretty sure JPEG XL will win 95% of times.

The huge SVGs are probably a side effect of Figmas export to svg and people not knowing what to look for. I have seen some crazy inefficient exports from that.

> Devs often argue that the format is "sharper".

You can also use lossless WebP in place of PNG these days.

You can get your code to list PNG or JPG and then get your server to serve webp. Browsers don't care about file extensions, they read the image headers.

To implement this you can get nginx to generate the webp from the JPG or PNG. Then you get that cached by your CDN.

If you need to change your compression levels then you can delete the cache on the CDN.

You can use the varies header to see if webp is accepted. If not, serve the original. In this way people can save the hires JPG with a right click.

You can also amp up the compression just for when the data saving flag is set.

The best thing is that you can do all this with hardly any lines of code and the VIPS library to optimise it.

And what were the results?

Bad at first until the pattern emerged. Solid colors, sharp lines, is PNG. Photo, 3d, landscape, is JPEG. I'm still trying to hammer it down for juniors who default to JPEG now.

Huh, don't you learn these at school? I learned this in 5-6th grade in my country. Even learned basic HTML and how to create websites with tables... which was when floats were all the rage.

Same here. It's not so hard, if your image isn't flat colours and has any "noise" use jpg.

As an American that grew up in a rural area, this definitely isn't something that would've been taught in a public school here. At best, we had typing classes in middle school, and the (quite old) teacher insisted on two spaces after the end of a sentence, something that disappeared after we stopped using typewriters.

More to the point, the two spaces after the end of a sentence is a consequence of the typographic style at the time that the typewriter was introduced where additional space at the end of a sentence was employed (this is most common in books typeset in the 18th and 19th centuries, although earlier and later examples exist). Despite what people will tell you, it has nothing to do with legibility for monospace printing, and an awful lot with 19th century compositors getting paid by the line and padding their paychecks by increasing spacing wherever possible. William Morris and his followers, direct and indirect, led to a contraction of word spacing and the elimination of the additional space at the end of sentences in emulation of the best printing examples of the 15th and 16th centuries.

I learned.. how to type.

Oh, this is a great idea. I love it.

Reply on news.ycombinator.com