I fully understand (and appreciate!) that this is exposed as a site setting for administrators to toggle, but I find this “feature” to be very misguided in the first place.
There are two hugely important features of PNGs: its lossless (and readable!) representation of text and support for transparency. Both of these are important reasons to use PNGs. As a user of a discourse site, I uploaded an image (of text with transparency) to my board and was highly disappointed to see it auto-convert to a JPG. No matter, I’ll just host it elsewhere. Well, that worked great until @system came along and downloaded and converted my image and edited my post out from underneath me, breaking the transparency and making it look worse. Thankfully I’m also an admin and was able to search the web to find one of the threads below that guided me to the png to jpg quality setting that I could change.
At a minimum, it seems prudent to turn off this feature if there is transparency in the GIF.
Do folks actually like this feature on their boards? It’s been brought up twice before, both times with folks confused/frustrated that PNGs were getting converted. It seems worthwhile to reconsider this default.
This means the image was much smaller as a JPG. I believe there are site settings to tweak this threshold. Have a look, search through your site settings.
In Settings/Files, scroll down to the 3rd item from the bottom. Uncheck Strip image metadata. Just above that is the png to jpg quality. Adjust setting as necessary.
Yes, I totally get that this is configurable (I’ve already disabled it on my site) and I understand the motivation. I still think that the feature is misguided in the first place and that it’d make sense to change the default.
Here’s an example — PNGs are the default file format for screenshots and rightfully so. If I just take a screenshot of this window and try to upload it, it gets converted to a JPG.
The original file was 361KB, your compressed JPG is 218KB. Sure, it’s smaller, but we’ve also lost the transparency — it looks awful for folks using a dark theme — and there’s artifacting around the text.
If, instead, I use optipng locally to optimize the PNG, I end up with a file that has transparency and sharp text that’s only 219KB. This will now remain a PNG when I upload it:
Converting PNG to JPG is a very lossy conversion. It’s one thing to do this on upload; it’s yet another to edit posts to do it automatically to external images after posting. There are other ways to save on bandwidth and storage, including PNG optimizers and even resizing (with the click-to-view-full-size feature it seems sensible to embed the smaller image in the post and only show the full-size image on click).
There are a bunch of topics of people trying to host their forums for as cheap as possible and complaining that images are taking too much space. This type of admin doesn’t care about quality of the images, all they want is to cut every corner and reduce costs.
On the other side of the spectrum you have people who are really invested on their communities and will leverage object storage and be able to provide a good quality with reasonable costs.
The discussion here is about defaults right? Or maybe we could try to measure the jpg size against the png post optimization? If I remember correctly the png optimization can be quite expensive…
Eliminating this feature isn’t happening. But this post seems interesting:
What would it take to have Discourse try using optipng first, and then use the resulting “optimized” size to determine whether it wants to go to JPG? Or would that be too slow?
Try running optipng on a 6000x6000 png and see what happens. We already do a form of this but it falls off an algorithmic cliff quickly. And real badly.
I’m not at all after eliminating the feature — sorry if I was overly bombastic in calling it a misfeature. It’s about the defaults. I just found the behavior surprising and unhelpful (especially after I had worked around it with an external link and had it automatically edited back). So I came here because I thought it’d be beneficial to others if the default were different… but as with all default choices subjective preferences on the tradeoffs rapidly come into play.
Thanks for the well-reasoned post, Rafael. I appreciate the discussion — as I initially said, I was earnestly asking if folks liked this feature.
It’s worth saying that the current default to optimized JPEG is not a misguided decision! I love PNG and abhor JPG for graphics but for this issue I totally support the current regime (both meanings: authority and system).
The Discourse team have made a realistic assessment of what will make Discourse successful out of the box:
The average site owner-administrator will not be looking for image quality options. They don’t have image quality as a goal and they will not be consider the default image file format to be an issue. So defaulting to optimised JPG produces the least grief and the greatest benefit for the most people.
PNG-ophiles like myself are always looking for site options to preserve image quality and information. Likewise photo- and image-driven sites will have image quality as a central decision.
A practical consequence of the current approach is likely to be a seamless transition to lossy WebP. Then the issue of lossy vs lossless WebP will probably arise in further topics here.
One thing, that we will eventually have is the ability for users to optimize their image before uploading.
By spawning the compression work into another thread (using web workers) and using the same algorithms we use on the server (using WASM) the user experience isn’t bad.
If you tell your screenshot program to stop inserting drop shadows, Discourse will probably stop converting it because it’ll actually be text and solid colors.
I was looking into this today for a site that wants all uploaded PNG files to be kept in the PNG format. What I was finding is that after setting png to jpg quality to 100, Discourse will still convert large PNGs to JPGs unless the recompress original jpg quality setting is also set to 100. Is this the expected behaviour? If so, the description for the recompress original jpg quality setting needs to be updated to describe how it affects PNG uploads.