241–250 of 283 posts
Earlier quoted context omitted.
> ...but now in le Rust!!1 I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.
Because a language happily letting you try to access an array index far past its end isn't stupid at all.
But you all don't even bother to do that, so I guess it's not actually a problem in practice.
Earlier quoted context omitted.
The only practical way to work with such large images is if they are tiled and pyramidal anyway
Which JXL supports, by the way. Tiling is mandatory for images bigger than 2048x2048, and you can construct images based on an 8x downscaled version, recursing that up to 4 times for up to 4096x downscaling.
Earlier quoted context omitted.
Usually it’s Mozilla not wanting to implement something Google wants to implement, not the other way around.
Indeed, you're making my point. SquareWheel implied that Mozilla doesn't count as an "other party" because they are aligned with Google on this specific topic. My comment was pointing out that just because they are aligned on this doesn't mean they are aligned on everything, so Mozilla is an "other party". And, as you have reinforced, Google and Mozilla are not always in alignment.
The fact that Mozilla aligns with Google on both of these deprecations suggests the reasons are valid.
I personally see no reason for XSLT today. Outside of the novelty of theming RSS feeds, it sees very little use. And JPEG XL carries a large security surface area which neither company was comfortable including in its current shape. That may change based on adoption and availability of memory-safe decoders.
Earlier quoted context omitted.
At 600DPI that's over a marathon in each dimension. I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space. I was going to work out how many A4 pages that was to print, but google's magic calculator that worked really well has been replaced by Gemini which produces this trash: Number of A4 pages=0.0625 square meters per A4 page * 784 squ…
Wolfram alpha is the better calculator for that sort of thing.
Prompt: “How many A4 pages would a 1073741823×1073741824 image printed at 600dpi be?”
Gemini Pro: “It would require approximately 33.1 billion (33,127,520,230) A4 pages to print that image.
To put that into perspective, the image would cover an area of 2,066 square kilometers […].
The Math
1. Image Dimensions: 1,073,741,823 × 1,073,741,824 pixels.
2. Physical Size: At 600 DPI, the image measures roughly 45.45 km wide by 45.45 km tall.
3. A4 Area: A single sheet of A4 paper (210 mm * 297 mm) covers approximately 0.06237 m².
4. Result: 2,066,163,436 m² / 0.06237 m² ≈ 33,127,520,230 pages.”
Alternatively, rink (https://rinkcalc.app/) :
> (1073741823 / (600/inch))**2 / A4paper
approx. 3.312752e10 (dimensionless)
Earlier quoted context omitted.
That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are. PS: I'm a bit too sle…
> The only thing I'm not sure about is why they decided to reopen it. It's almost certainly due to the PDF Association adding JPEG XL as a supported image format to the ISO standard for PDFs; considering Google's 180 on JPEG XL support came just a few days after the PDF Association's announcement.
Earlier quoted context omitted.
According to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header". So at least if GP was talking about libjxl "100K+" would be more accurate. [0]: https://github.com/…
One of the best ways to measure code complexity is to zip up the source code. This eliminates a lot of the redundancies and is a more direct measure of entropy/complexity than almost anything else. By that metric, jpeg-xl is about 4x the size of the jpeg or png codebase.
Earlier quoted context omitted.
It's Google, it's one of the biggest tech companies in the world making boatloads of money, in part off their browser. They're currently best known as one of the companies trying to create AI God. They really can't write an... image format parser?
Cool, but why does that mean they need to write a codec for you for free?
I don't think it's irrational to be upset when a (near-)monopoly browser holds back useful features. Even if said browser is provided for free.
One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched. Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG. Only know this because we have tens…
What's the point of transcoding? You still have to store the original DICOM right? That's probably the bulk of the cost
Losslessly meaning, with the same quality than the original JPEG received by the storage.
One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched. Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG. Only know this because we have tens…
It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence). [0] https://issues.chromium.org/issues/40168998#comment507
That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are. PS: I'm a bit too sle…
https://www.reddit.com/r/DataHoarder/comments/1b30f8h/image_...