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

171–180 of 283 posts

Re: Google unkills JPEG XL?

#171

Post by rottencupcakes »

lsecondario wrote: post #169
phatfish wrote: post #153

Earlier quoted context omitted.

German speakers usually have very good English, but this is one of their tells.

Another one I've noticed is using "I've" as a contraction in e.g. "I've a meeting to attend". Seems totally reasonable but for some reason native speakers just don't use it that way.

I’ve is only used when there is a verb to follow and the have is part of the verb’s construction.

As in “I’ve done it” or “I’ve seen it”

It would not be used before a noun, in the context of ownership, as in “I have a meeting”

Re: Google unkills JPEG XL?

#172

Post by jfindper »

johncolanduoni wrote: post #10
jfindper wrote: post #9

Earlier quoted context omitted.

> Because Mozilla's stance on JPEG XL and XSLT are identical to Google's. Okay, and do they align on every other web standard too?

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.

Re: Google unkills JPEG XL?

#173

Post by ragall »

Quick reminder that it's not "Google" that killed JXL before, it was the Chrome team. Jpeg XL was designed by a Google engineer (JyrkiAlakuijala here) who is not part of the Chrome team, but in Google Research in the Zurich office while the Chrome team, although it has offices all around the world, at its core is very insular and lives in the Mountain View bubble.

Re: Google unkills JPEG XL?

#174

Post by dpark »

Fileformat wrote: post #159
dpark wrote: post #80

Earlier quoted context omitted.

> all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc. What “community” is this? The typical consumer has no idea what any of this is.

I agree with you. But a typical consumer will already be using Chrome, and has no reason to use Firefox. If one of these advanced/niche technologies takes off, suddenly they will have a reason to use Firefox.

For Firefox to win back significant share, they need to do more than embrace fringe scenarios that normal people don’t care about. They need some compelling reason to switch.

IE lost the lead to Firefox when IE basically just stopped development and stagnated. Firefox lost to Chrome when Firefox became too bloated and slow. Firefox simply will not win back that market until either Chrome screws up majorly or Firefox delivers some significant value that Google cannot immediately copy.

Re: Google unkills JPEG XL?

#175

Post by uselesswords »

palmotea wrote: post #123
aw1621107 wrote: post #84

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

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

Technically right is the worst kind of right

Re: Google unkills JPEG XL?

#176

Post by Grosvenor »

phatfish wrote: post #153
senbrow wrote: post #97

Earlier quoted context omitted.

no one asked, but FYI in English it is more commmon to say "for several years" instead of "since some years" :)

German speakers usually have very good English, but this is one of their tells.

German speakers usually have very good English, but this is already one of their tells.

Fixed that for you.

Re: Google unkills JPEG XL?

#177

Post by [deleted] »

lsecondario wrote: post #169
phatfish wrote: post #153

Earlier quoted context omitted.

German speakers usually have very good English, but this is one of their tells.

Another one I've noticed is using "I've" as a contraction in e.g. "I've a meeting to attend". Seems totally reasonable but for some reason native speakers just don't use it that way.

[deleted]

Re: Google unkills JPEG XL?

#178

Post by inejge »

bmicraft wrote: post #164
zorgmonkey wrote: post #95

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 library had a hiatus with zero commits of over 1.5 years until recently iirc. That this is working out is a combination of wishful thinking and getting lucky.

"Code frequency" for jxl-rs shows no activity from Aug 2021 to Aug 2024, then steady work with a couple of spurts. That's both a longer hiatus and a longer period of subsequent activity (a year+ ago isn't "recently" in my book.) What data have you based your observation on?

Re: Google unkills JPEG XL?

#179

Post by Intralexical »

xnorswap wrote: post #51
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

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…

"Google's magic calculator" was probably just a wrapper to GNU Units [0], which produces:

  $ units
  You have: (1073741823/(600/inch))**2 / A4paper  
  You want:  
         Definition: 3.312752e+10
Equivalent tools: Qalc, Numbat

0: https://news.ycombinator.com/item?id=36994418

Re: Google unkills JPEG XL?

#180

Post by mrbluecoat »

rottencupcakes wrote: post #170
shevy-java wrote: post #93

"in favor of the homegrown and inferior AVIF" I am using .avif since some years; all my old .jpg and .png files have been pretty much replaced by .avif, in particular fotos. I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif. I could have gone .webp or perhaps jpeg-xl but at the end of the day, I am quite happy with .avif as it is. As for JPEG XL - I think the problem here is ... Google. G…

> I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif going crazy reading this sentence

recursive logic is recursive logic is
Post reply on HN