> I guess I wasn't aware that Wine pivoted from trying to be a general purpose, drop-in replacement for Windows to being a platform for games that only supports a subset of Windows functionality.
> I AM saying "people don't want ride trains that allow 5% of the riders to smoke cigarettes on enclosed train platforms and in enclosed train cars."
Just don't allow that then?
> Public transit advocates need to be honest with themselves that anti-social behavioral issues really matter to people. People are willing to pay more to have a more pleasant experience. When a transit system fails to meet that standard, then you'll suddenly find yourself with a transit system that people don't want to use.
"we can't have good transit because a few people who call themselves transit advocates have bad opinions" is very defeatist. Weak-spined politicians find it much easier to just set money on fire than actually solving problems, so even though most transit advocacy groups in the US emphasize quality and being less wasteful with budgets, your politicians usually prefer the worse options.
>> I AM saying "people don't want ride trains that allow 5% of the riders to smoke cigarettes on enclosed train platforms and in enclosed train cars."
>Just don't allow that then?
>"we can't have good transit because a few people who call themselves transit advocates have bad opinions" is very defeatist.
My point here is only that this is a hard problem, not a trivial one. When the transit advocates in my area just say "transit should be free" in response to "transit pricing is a complex problem that affects system fragility" and they say "stop hating homeless people" in response to "quality of life concerns matter to keeping the system functional long term" then we're in bad place, because the non-transit advocates literally want to get rid of the system. The last TWO Muni funding bills in SF failed.
We've built a system that can fail catastrophically, in large part, because transit advocates don't want to deal with the realities of running a functional transit system. This is why I get grumpy when people say "all this work is impressive, but I'd rather have better trains" when it's very clear why Waymo is succeeding as Muni is failing, but it is exactly because Muni is mostly disconnected from market forces that we've got to this place, and the "solution" being proposed by most transit advocates is to just completely remove all market forces which will very obviously be worse is the long run.
> That's not the reason, but the excuse. The reason firefox doesn't have jxl is that it is funded by Google, and someone at Google decided that it has to die.
So what, you think they were just lying when they said that they'll ship JXL when it has a Rust implementation? You think Mozilla devs were just bluffing when they were working directly with the JXL devs over the last year to make sure everything would work right?
See cousin comment, it accepts AVIF files. At least they would render on the app. Which would be enough for many. As it stands it accepts this format and renders nothing at all.
Also, just because there's a spec for using gainmaps with JPEG doesn't mean that it works well. With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding. JXL otoh is completely immune to banding, with or without gainmaps.
> With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding.
This is simply not true. In fact, you get less banding than you do with 10-bit bt2020 PQ.
> JXL otoh is completely immune to banding
Nonsense. It has a lossy mode (which is its primary mode so to speak), so of course it has banding. Only lossless codecs can plausibly be claimed to be "immune to banding".
> The JXL spec already has gainmaps...
Ah looks like they added that sometime last year but decided to call it "JHGM" and also made almost no mention of this in the issue tracker, and didn't bother updating the previous feature requests asking for this that are still open.
> Nonsense. It has a lossy mode (which is its primary mode so to speak), so of course it has banding. Only lossless codecs can plausibly be claimed to be "immune to banding".
color banding is not a result of lossy compression*, it results from not having enough precision in the color channels to represent slow gradients. VarDCT, JPEG XL's lossy mode, encodes values as 32-bit floats. in fact, image bit depth in VarDCT is just a single value that tells the decoder what bit depth it should output to, not what bit depth the image is encoded as internally. optionally, the decoder can even blue-noise dither it for you if your image wants to be displayed in a higher bit depth than your display or software supports
this is more than enough precision to prevent any color banding (assuming of course the source data that was encoded into a JXL didn't have any banding either). if you still want more precision for whatever reason, the spec just defines that the values in XYB color channels are a real number between 0 and 1, and the header supports signaling an internal depth up to 64 bit per channel
* technically color banding could result from "lossy compression" if high bit depth values are quantized to lower bit depth values, however with sophisticated compression, higher bit depths often compress better because transitions are less harsh and as such need fewer high-frequency coefficients to be represented. even in lossless images, slow gradients can be compressed better if they're high bit depth, because frequent consistent changes in pixel values can be predicted better than sudden occasional changes (like suddenly transitioning from one color band to another)
I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web.
> avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that.
And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.
> I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Did they actually say that? All the statements i've seen them have been much more guarded and vauge. More of a, maybe we will think about it if that happens.
> If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.
That's what they said a year ago. And a couple of Mozilla devs have been in regular contact with the JXL devs ever since then, helping with the integration. The patches to use jxl-rs with Firefox already exist, and will be merged as soon as a couple of prerequisite issues in Gecko are fixed.
Their standards position is still neutral; what switched a year ago was that they said they would be open to shipping an implementation that met their requirements. The tracking bug hasn't been updated[2] The patches you mention are still part of the intent to prototype (behind a flag), similar to the earlier implementation that was removed in Chrome.
They're looking at the same signals as Chrome of a format that's actually getting use, has a memory safe implementation, and that will stick around for decades to justify adding it to the web platform, all of which seem more and more positive since 2022.
It didn't.