Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google unkills JPEG XL?

tonisagrista.com

Post reply on HN
Print view View original

121–130 of 283 posts

Re: Google unkills JPEG XL?

#121

Post by magicalist »

aleph_minus_one wrote: post #103
dpark wrote: post #60

Earlier quoted context omitted.

Saying web users should define web standards is like saying laptop users should design CPUs. They lack the expertise to do this meaningfully. Web authors? Maybe. WHATWG was created specifically because W3C wasn’t really listening to web authors though. I don’t think there are a lot of scenarios where standards aren’t driven by implementers, though. USB, DRAM, WiFi, all this stuff is defined by implementers.

> WHATWG was created specifically because W3C wasn’t really listening to web authors though. Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.

> Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.

Mozilla, Opera and Apple. Google didn't have a browser then, hadn't even made the main hires who would start developing Chrome yet and hixie was still at Opera.

Re: Google unkills JPEG XL?

#123

Post by palmotea »

aw1621107 wrote: post #84
tensegrist wrote: post #63

Earlier quoted context omitted.

100M+ is a bit more than i would expect for an image format. have i not been paying attention

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/…

>> 100M+ is a bit more than i would expect for an image format. have i not been paying attention

> So at least if GP was talking about libjxl "100K+" would be more accurate.

M can mean thousands and I think it's common to use it used that way in finance and finance-adjacent areas: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/A...:

> A. You’ve identified two commonly used conventions in finance, one derived from Greek and the other from Latin, but neither one is standard.

Starting with the second convention, M is used for amounts in the thousands and MM for amounts in the millions (usually without a space between the number and the abbreviation—e.g., $150M for $150,000 and $150MM for $150 million). This convention overlaps with the conventions for writing roman numerals, according to which a thousand is represented by M (from mille, the Latin word for “thousand”). Any similarity with roman numerals ends there, however, because MM in roman numerals means two thousand, not a thousand thousands, or one million, as in financial contexts...

https://www.accountingcoach.com/blog/what-does-m-and-mm-stan...:

> An expense of $60,000 could be written as $60M. Internet advertisers are familiar with CPM which is the cost per thousand impressions.

> The letter k is also used represent one thousand. For example, an annual salary of $60,000 might appear as $60k instead of $60M.

Re: Google unkills JPEG XL?

#125

Post by Magnap »

yread wrote: post #29
m348e912 wrote: post #13

A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image

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.

Re: Google unkills JPEG XL?

#126

Post by ocdtrekkie »

dpark wrote: post #96
ocdtrekkie wrote: post #86

Earlier quoted context omitted.

We have the legal force to do this. Google has already been determined to be abusing their illegal monopoly they have with Chrome. The penalty phase is ongoing, but consider that even forcing Google to sell Chrome was originally considered as a possible penalty. Requiring Google implement the standards as agreed by Apple, Mozilla, and Microsoft is not remotely outside the realm of the legal force that could be applie…

There’s something not quite right about saying one member of an oligopoly should be forced to follow the dictates of the other members of an oligopoly. I don’t feel like this actually solves anything. I feel like Mozilla would end up being a Google proxy in this case as they fear losing their funding and Apple and Microsoft would be incentivized to abuse their position to force Google not to do the best thing for the…

I agree there's already a significant proxy risk with Mozilla (though Mozilla does consider many Google web proposals harmful today), but that is also no less true today, and in fact, today that means Google holds two votes not one.

I would again agree Microsoft and Apple will heavily endorse their own interests, Microsoft much more so in terms of enterprise requirements and Apple much more so in terms of privacy-concerned consumers. The advertising firm influence will be significantly dimished and that is a darn shame.

Re: Google unkills JPEG XL?

#127

Post by josefx »

jsheard wrote: post #101
scheme271 wrote: post #71

Earlier quoted context omitted.

The PDF association apparently recently added jpeg xl to the pdf spec and indicated that it's the preferred solution for HDR content.

Then again PDF also technically supports embedded audio, video, 3D graphics, and arbitrary Javascript. If Flash hadn't died it would probably still support that too. It's a clown car format where everyone besides Adobe just tacitly agrees to ignore huge chunks of the spec.

> It's a clown car format

As is the destiny of any document format in wide spread use, PDF had flash, doc had ActiveX.

Also this text is formatted using a mark down language fully capable of embedding entire applications.

Re: Google unkills JPEG XL?

#129

Post by dgacmu »

MaxBarraclough wrote: post #106
EMM_386 wrote: post #37

Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface? I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we'…

> I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.

99% safe with 1% unsafe mixed in is far, far better than 100k loc of c++ -- look at Google's experience with rust in Android. It's not perfect and they had one "almost vulnerability" but the rate of vulnerabilities is much, much lower even with a bit of unsafe mixed in.

Re: Google unkills JPEG XL?

#130

Post by CharlesW »

JXL's war is not with AVIF, which is already a de-facto standard which has near-universal browser support, is enshrined as an Apple image default, will only become more popular as AV1 video does, etc. It's not going anywhere.

That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.

To address selected claims made in the post:

• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).

• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.

• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).

So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.

Post reply on HN