I got my Steam Deck almost a year ago. I got the cheapest 64 GB model fully expecting that I would need to upgrade its internal M.2 2230 NVMe SSD to something with more capacity down the road. Well, the day finally came. In this post I report the quick and painless process I followed to successfully upgrade the Steam Deck 64 GB SSD to a more than respectable 1 TB M.
MangoHud is an overlay for monitoring frame rates, frame times, temperatures and CPU/GPU loads on Vulkan and OpenGL applications in Linux. It is also the default performance overlay used in the Steam Deck, and it is awesome. I know the amount of people using Java for high performance graphics is not very high, but they are there, of that I’m sure. I’m actually one of them. Gaia Sky is written in Java, and even though it has its own rudimentary debug overlay, MangoHud goesfar beyond it.
A while ago I published this post about a better figure shortcode for Hugo that enabled lazy loading. Today, I bring you yet another update on the same shortcode. This time around, the focus is on leveraging the HTML picture element, which enables alternative versions of the same image in different formats, leaving the browser to decide which one to use. You can serve the same image in, for instance, JPEG-XL and plain old JPEG at the same time.
Gaia Sky has been using the OpenVR API from SteamVR for the last few years to power its Virtual Reality mode. However, the API is notoriously poorly documented, and it only works with the SteamVR runtime.1 That leaves out most of the existing VR headsets. Luckily, the main vendors and the community at large joined efforts to come up with an API that would be adopted by all and backed by the Khronos Group: OpenXR.
Edit (2023-03-30): Added a couple extra images to test for high-quality encoding and illustrations. Introduce SSIM and MSE measures.
Edit (2023-03-03): Fixed mistake, as AVIF does in fact NOT support progressive decoding.
Edit (2024-01-24): Following a comment on Mastodon, I have added a reference on the good performance of lossless WebP.
This is a subjective look at JPEG XL and AVIF. All comparisons in this post (except the ones using SSIM and MSE) are perceptual and based on my own opinion only. This is not a scientific study! I just grabbed a bunch of images, encoded them and looked at the results. For a more careful and methodical comparison between these formats (and more), have a look at CID22.
JPEG XL and AVIF are arguably the two main contenders in the battle to replace JPEG as the next-generation image format. There are other formats in the race, like HEIC and WebP 2, but the former is subject to licensing patents (and possibly not royalty-free), and the second is still in development and seems that it may never see the light of day as a production-ready image format anyway. The original WebP is not even a contender as it is inferior to AVIF in almost all aspects1 (although it may be ok in lossless compression2), and you should probably never use it for photography anyway3, or at all if you are not ok with mediocre image quality.4
First, a quick browser support test:
If you are browsing this page around 2023, chances are that your browser supports AVIF but does not support JPEG XL. This is mainly due to the Chrome team dropping support for JPEGL XL against the opinion the community at large. In this post, I hope to convince you why this is a bad move. Below, I perform a quick analysis of lossless and lossy compression with JPEG XL and AVIF, and evaluate how they fare in terms of file size and visual quality.
After the acquisition of Twitter by the South African con-man and billionaire the free and open source social network world is generating a lot of heat. The number of users and nodes of Mastodon in particular and the Fediverse at large has been climbing steadily for months now. However, there is no shortage of people who voice their concerns about the federated nature of such services, which rely on centralized instances governed by small dictators with absolute power.