Lossless JPEG XL is in the DNG spec since three years (v1.7). So, you can convert your proprietary camera raw files to smaller ISO standard compliant JPEG XL compressed DNG raw files (mosaiced, not linearized).
PureRAW can now output linear DNG's compressed with JXL. It's amazing the first time you use it seeing 25mb RAW files go in, get made linear, and pop out 8mb or 9mb, then toss them in your RAW developer of choice and still find all the dynamic range and such you'd expect from the original RAW. I'd been doing that on my own with a script that called Adobe's DNG Converter, which has the same capability, to convert older versions of PureRAW's linear DNG to JXL-based DNG files, but that's no longer necessary.
Unfortunately, at least as of perhaps a year ago, I couldn't find any other actively maintained software tooling that could reliably do what Adobe's DNG Converter was doing, and there's so much nuance to the world of RAW files that's not at all just a trivial one-shot prompt to Claude/Codex to roll your own.
Not linearized as in samples do not represent linear color space? I think that's untrue, as all sensor work I've done (a decent amount across many projects) are linear: double light = double photon count = 1 bit of sensor space. There are technically often some bends from physical and engineering effects (photon interaction with substrate has some variability, temperature affects things a bit).
Or is there some other meaning of "not linear" you mean?
> PNG, the lossless format is great for diagrams and stuff with sharp edges.
But also, like GIF, it's pointless when lossless WebP exists and is supported everywhere. It's more efficient. Lossy WebP does not make as much sense though since jpegli entered the game.
OP has made https://halide.cx/iris/ which could make lossy WebP make sense, but it's not open source or generally available.
> The new formats are interesting webp, avif, JXL and so on.
WebP was introduced 15 years ago. New relative to JPEG perhaps, but certainly not new.
PNGs will persist because I know that they're lossless by looking at the filename. When I hit File > Save as .png, I don't have to inspect output metadata (that image viewers don't expose) or play around with exporter settings.
It's unfortunate that we didn't give lossless webps a separate extension. Frankly I think even saving them as .png would've better than what we have now - people roughly understand that a .png is an image without artifacts, and any self-respecting image viewer will inspect magic bytes before opening a file anyways.
Being lossless is a function of the whole pipeline from an input image to an output image. The last step being encode to PNG doesn't guarantee anything about losslessness.
I do not know whether this has anything to do with any limitation in the WebP format, because it is more likely that this is some kind of bias in the kind of authors of Web pages who choose the WebP image format, who might also choose more aggressive compression settings, but for me WebP is a synonym for "low-quality image".
This means, that at least for the Web sites that I happen to access frequently, whenever I see PNG or JPEG images they typically have a better quality than when I see WebP images.
I do not know whether when browsing the Web I see frequently any AVIF images. They are either rare or they have a similar quality with JPEG images, so they did not stand out like WebP, where I perceived a degradation, so I noticed that the image format was different.
I do not care much about the speed of decoding Web images, because the speed of loading Web pages is determined mostly by the amount of junk JS that is included and not by the loading and decoding of the included images. So for me the quality of the included images is more important, thus WebP is something that I dislike, while JPEG is far too limited, so I would prefer JPEG XL images.
The arguments in TFA do not seem entirely honest, because the presented data confirms the low quality of WebP in comparison with JPEG XL, and because the 2 compared JPEG XL implementations differ in their performance by a factor more than 2, so it is likely that they are both immature and one could still accelerate the decoding of JPEG XL by at least 2 or 3 times in comparison with the best of them.
The only claim of TFA that seems valid, is that if AVIF is really as good as claimed, it could be sufficient for Web pages that want to show only highly-compressed images and good for replacing JPEG for such a use, while JPEG XL might be strictly required only for applications that need higher quality, i.e. for the processing and storing of photographic images.
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
> Where do you draw the line between system packages and user facing apps?
If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.
I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
> I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
Digression, but I’m curious since you brought it up: Are you saying that Silverblue-based distros are noticeably more stable than Fedora? Or is it more a theoretical benefit, that you believe more in the long-term stability of that architecture?
> Are you saying that Silverblue-based distros are noticeably more stable than Fedora?
TBH, I can only say it's far more stable than openSUSE, Ubuntu and Manjaro which are the non-atomic distros I've used for a long time.
Aurora has never broken and I've never had any major problems that I can recall in over two years. I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).
It's Linux for those who have work to do and don't want to be a sysadmin for their desktop.
> I never initiate updates of the system, my Flatpaks or Homebrew. That happens in the background and whenever i restart (without me noticing).
Two follow-up questions on this:
- How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.)
- Does Aurora sometimes reboot multiple times when doing updates? On normal Fedora I usually end up running dnf update manually to avoid doing updates in batches; when it updates on reboot, it can reboot 2-4 times… I have full-disk encryption on my laptop and it’s painful to have to wait for all the password prompts during updates. If this could happen be done in one reboot on atomic distros that would certainly be a benefit.
> How does Homebrew auto-update on Linux? Do you have a daemon, cron job, or similar? Or a plugin for GNOME Software, Discover, or similar? (I’ve used Homebrew on Mac and Linux, but not with auto-updates.)
I don't know, and I don't want to have know, how it works. :) It just does. You can force updates by running "ujust update". It updates Homebrew, Flatpaks, the system image and all Distroboxes in one go. You can also turn auto updates off.
> Does Aurora sometimes reboot multiple times when doing updates?
I doesn't reboot at all. I never notice updates, they happen in the background. System image upgrades are applied that time I turn off my computer and turn it on again. No extra reboots then. It's just a boot like any other.
Unless doing something esoteric like updating firmware that requires manual intervention, Fedora Atomic distros should never need to reboot multiple times to update, as updates are staged as side-by-side replacements of the entire base system, which includes essentially everything that would be installed through the system package manager in a traditional distro, so it's effectively like booting into an upgrade install of the OS (so preserving configuration files, user data, containers Flatpaks, etc.), except the old version remains available as a bootable option (which is possible because the atomic distros carefully separate OS and user directories, with the former typically mounted read-only).
The only times I've (very rarely) run into trouble is when adding additional RPMs to the base install, which, while frowned upon for this reason, generally poses no more problems than installing the same packages in a traditional Fedora installation, so worst-case you can simply uninstall the layered packages and re-run the update if something isn't working.
Again, without a reboot, because incompatible updates generally while staging, not after rebooting the system into the new OS, e.g., a package, possibly from an external repo, which does not exist, or depends on packages that do not exist, in the version you're updating to.
Aside from major version upgrades where packages you've layered might simply have been removed, this occasionally happens if you're installing packages from an external repo like RPM Fusion that's closely integrated with the base OS, because there are times when the base image (or even loose package mirrors) might lag a bit behind released loose packages which updates of external packages may depend on, and while you can override base image packages to resolve this, it's a bit of a hassle and probably not worth the trouble vs simply waiting until the base image catches up. Unless you have specific needs that can't be resolved by, e.g., running applications that require proprietary video codecs as Flatpaks or in containers, I'd recommend sidestepping this whole mess by not layering anything from RPM Fusion or similar (layering to pick up third-party packages that don't depend on very specific versions of distro packages works fine).
Generally speaking, nothing in the update / RPM install / RPM uninstall process touches the running OS unless you specifically request that it does, and nothing changes the on-disk copy of the running OS period. So, e.g., you can add new RPMs to the running install without rebooting, but how this works is that it first adds them to a new staged install, then creates transient filesystem overlays to activate the packages within the running OS. In other words, the on-disk copy of the current running OS remains unchanged and available in case anything goes wrong.
It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc.
But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".
I use `lima` and `llvm` every day with brew. It works great there's no reason to use distro specific tooling when you can use what everyone else is using.
"Conflict" is maybe a strong word? Homebrew installs stuff into its own directory tree so it should in theory not have issues coexisting with native packages.
Then again I use versioned AppDirs on Linux since +20 years anyway, so I am
not really into any arbitrary disctinction random linux distributions try
to push down onto the (downstream) userbase. Besides, if you compile from source, why
would you want to rely on the distribution package manager to begin with?
None of them allow for versioned AppDirs by default as far as I know; NixOS
uses a hashed name, so that is the only exception I can think of (and GoboLinux
of course), but as far as I know if you are on e. g. a debian system, you can
not use it for a versioned AppDir layout.
> NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course)
Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?
I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.
An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.
Check out MacPorts. It was the original package manager, still going strong, and it supports Macs going all the way back to the Leopard era. It also always used /opt instead of taking over /usr/bin like Homebrew.
I always found it much slower when compared to brew and sometimes would just hang and get stuck when installing something. Plus the lack of casks does make it less of a direct replacement.
> There’s a reason Apple displays are still the gold standard.
Apple is not the gold standard, Eizo's ColorEdge monitors are. Built-in hardware calibration is non-negotiable for color critical work. Monitors drift over time.
> Built-in hardware calibration is non-negotiable for color critical work
No it is mostly a convenience gimmick. Support for external hardware calibration is important though. But far more important feature, implemented properly only by Eizo and no one else I am aware of - is uniformity compensation. Benq has it, so does Dell, but they all come with sever limitations compared to Eizo.
> No it is mostly a convenience gimmick. Support for external hardware calibration is important though.
Until you decide to use Linux and all the distros you're interested in force you to use Wayland (which is a color management trainwreck).
Also, I find that for actual work the calibration actually gets done if the display does it by itself during night at set intervals. Perhaps I'm just lazy.
Many important security updates will end much earlier. The table is based on how long Fairphone will provide incomplete security updates, not how long the device will truly receive security support.
Fairphone 5 and earlier have end-of-life Linux kernel branches without security support. Fairphone's more recent devices are headed to the same situation. In practice, the same thing happens with other components beyond the Linux kernel.
You always have the right to a minimum 2-year guarantee from the moment you received the goods. However, national rules in your country may give you extra protection.[1]
"Die" is a common singular form of "dice". The relative prevalence of "die" vs "dice" for this is regionally dependent. In general, English can't make up its mind with a lot of things involving words which end in a "sss" sound.
Die is singular, dice is plural. 1 die, 2 dice, 3 dice, …
It used to be something people were corrected on, but these days dice is accepted as the singular too and die is starting to be seen as a little antiquated.
So, they've realized podcasters and vloggers are a large part of their target audience. Then I believe they have to implement some models for speech restoration.
These days most people just Adobe Podcast Enhance and forget and, from what I've seen there isn't an open source GUI based tool for automated voice processing out there.
Must add that it's so awesome to have an open source Qt based audio editor on KDE Plasma that does not look like shit!
> Additionally, with Vib (Vanilla Image Builder), anyone can customize their own system image, or even create their own distro with minimal effort.
This sounds very intriguing! Been using Aurora (Universal Blue) for years, but there's always a package or two you need to layer. Updates have crapped out more than once because of these packages. Been thinking that an easier way of creating custom images is the solution.
uBlue images are not effortless to create and maintain. Just installed plain Fedora two days ago for this reason.
Vanilla being GNOME by default has kept me from trying it. Plasma is so darn good these days.
Lossless JPEG XL is in the DNG spec since three years (v1.7). So, you can convert your proprietary camera raw files to smaller ISO standard compliant JPEG XL compressed DNG raw files (mosaiced, not linearized).
reply