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

271–280 of 283 posts

Re: Google unkills JPEG XL?

#271

Post by SquareWheel »

jfindper wrote: post #262
SquareWheel wrote: post #243

Earlier quoted context omitted.

I made no such implication. Mozilla is certainly an other party, and their positions on standards hold water. They successfully argued for Web Assembly over Native Client, and have blocked other proposals such as HTML Import in the Web Components API. They are still a key member of the WHATWG. The fact that Mozilla aligns with Google on both of these deprecations suggests the reasons are valid. I personally see no re…

>> "[...] support the web standards as determined by other parties. " > "Which other parties? Because Mozilla's stance on JPEG XL and XSLT are identical to Google's" If this isn't an implication that Mozilla isn't an other party, than I'm not sure what you were trying to say with " Which other parties? ". Whatever you meant to say, it read as an implication that Mozilla just does what Google does so Mozilla isn't rea…

It means exactly what it says: "What other parties do you mean?". Key players are already in lockstep on this decision, so insisting that Google must submit to the other WHATWG members doesn't make any sense in an argument for restoring XSLT or JPEG XL.

You seem to be reading subtext into a statement that was put plainly.

Re: Google unkills JPEG XL?

#272

Post by danhau »

egorfine wrote: post #124

A little bit related: RAW files from iPhone 17 Pro are compressed using JPEG-XL.

How‘s that possible? JPEG-XL stores image files, right? But RAW files are not images in the same sense. They haven‘t even been demosaiced. Or are Apple RAWs different?

Edit: I should have googled. apple‘s ProRAW does this, which isn‘t a RAW file in the classic sense.

Re: Google unkills JPEG XL?

#273

Post by jfindper »

SquareWheel wrote: post #271
jfindper wrote: post #262

Earlier quoted context omitted.

>> "[...] support the web standards as determined by other parties. " > "Which other parties? Because Mozilla's stance on JPEG XL and XSLT are identical to Google's" If this isn't an implication that Mozilla isn't an other party, than I'm not sure what you were trying to say with " Which other parties? ". Whatever you meant to say, it read as an implication that Mozilla just does what Google does so Mozilla isn't rea…

It means exactly what it says: "What other parties do you mean?". Key players are already in lockstep on this decision, so insisting that Google must submit to the other WHATWG members doesn't make any sense in an argument for restoring XSLT or JPEG XL. You seem to be reading subtext into a statement that was put plainly.

>Google must submit to the other WHATWG members doesn't make any sense in an argument for restoring XSLT or JPEG XL.

The comment you replied to was speaking generally, not specifically to XSLT or JPEG XL. They obviously didn't say "Google should be barred from having standards positions" just in context of XSLT/JPEG XL, but they're totally cool with the Google monopoly with every other standard.

>You seem to be reading subtext into a statement that was put plainly.

Nah, I'm really not.

But I'm just farming downvotes, apparently, so nevermind. You win! yay

(It's fun that people are coming to a conversation over 24 hours old, however many levels deep, to downvote!)

Re: Google unkills JPEG XL?

#274

Post by EMM_386 »

tensegrist wrote: post #63
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'…

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

You are correct, "K" not "M" in my typo.

Re: Google unkills JPEG XL?

#276

Post by alphatodder »

greenavocado wrote: post #250
goku12 wrote: post #156

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…

I have been relentlessly shilling JPEG-XL's technological superiority especially against their joke of an alternative and a stain on the Internet they call WebP https://www.reddit.com/r/DataHoarder/comments/1b30f8h/image_... https://youtu.be/w7UDJUCMTng

Some of the same people developed both. Pretty sure Jyrki Alakuijala for example led the development of lossless mode for both WebP and JPEG-XL.

Re: Google unkills JPEG XL?

#277

Post by swiftcoder »

majora2007 wrote: post #269
swiftcoder wrote: post #45

Earlier quoted context omitted.

> Lack of metadata for collecting PDFs have pretty excellent support for metadata. If the collection software doesn't support at least Dublin Core, that may be kind of their own fault...

I haven't seen this in the real world or the tooling to back it up. Currently, Calibre is the only software that writes metadata that pulls from online sources. I'm sure Adobe Acrobat also supports, but that's not used in the scene.

Feels like a very big gap in the OSS world then. The PDF spec supports multiple standards for metadata, Acrobat has workflows for all of them, and Adobe sells into a bunch of verticals (such as public libraries) that rely on this functionality heavily.

Re: Google unkills JPEG XL?

#278

Post by tkfoss »

jiggawatts wrote: post #213
tkfoss wrote: post #189

Earlier quoted context omitted.

Interesting approach

It comes from the "intelligence is a form of compression" hypothesis that has been floating around in the ML space. Also, with a good compression algorithm it is a fairly direct measure of entropy, which is quite well correlated with what a developer might consider code size and/or complexity.

I'm familiar with the concept[1], but I'm unsure if it's a good showcase of code complexity. I've tested some internal microservices I'm deeply familiar with and found no correlation...

[1] for the past ~15 years actually, got introduced to the concept through works of mr. Hutter, after becoming aware of his Prize, and I'm dabbling in compression to this day (right now trying to improve on Bellard's nncp)

Re: Google unkills JPEG XL?

#279

Post by aidenn0 »

flir wrote: post #253
aidenn0 wrote: post #207

Earlier quoted context omitted.

Each pixel would represent roughly 16cm^2 using a cylindrical equal-area projection. They would only be square at the equator though (representing less distance E-W and more distance N-S as you move away from the equator). No projection of a sphere on a rectangle can preserve both direction and area.

I admit it, I was applying Cunningham’s Law. Disappointingly(?), you came to the same answer.

I admit I trusted your math; you seem to be off by a factor of 4:

  You have: 510.1e6km^2/1073741824/1073741824
  You want: cm^2
   * 4.4244122
   / 0.22601872
Strangely enough, units lacks area_earth, so I used the number from https://iere.org/what-is-the-area-of-the-earth/

Re: Google unkills JPEG XL?

#280

Post by otabdeveloper4 »

UltraSane wrote: post #266
otabdeveloper4 wrote: post #241

Earlier quoted context omitted.

If this was a real problem then you could have just `s/[]/at()/g` across your codebase and called it a day. But you all don't even bother to do that, so I guess it's not actually a problem in practice.

C doesn't have any protection for accessing out of bounds. It does zero bounds checking behind the scenes. Which is actually really, REALLY stupid. And when all computers are connected to the internet this is disastrous.

> It does zero bounds checking behind the scenes.

Thankfully you can fix that with one sed command. Why don't you?

Post reply on HN