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

JPEG XL Test Page

tildeweb.nl

Post reply on HN
Print view View original

161–170 of 170 posts

Re: JPEG XL Test Page

#161

Post by edflsafoiewq »

GuB-42 wrote: post #138
gcr wrote: post #110

One thing I like about JPEG-XL is that it supports all kinds of weird image formats. For example, I used to work with depth data a lot, which is best expressed as monochrome 16-bit floating point images. Previously, TIFF was the only format that supported this. Many shops would instead save depth images as UINT16 .PNG files, where the raw pixel intensity maps to the camera distance in mm. The problem with this is tha…

> One thing I like about JPEG-XL is that it supports all kinds of weird image formats. And it is probably the reason why browser vendors disliked it. Lots of complexity, it means a big library, which is high maintenance with a big attack surface. By comparison, webp is "free" if you have webm, as webp is essentially a single frame video.

AFAIK browsers do not reuse any VP8 codepath for WebP, they just use libwebp, which decodes lossy images in software. WebP has a non-VP8 lossless mode too. The concern about image format attack surface is also probably because of the recent exploit in libwebp.

Re: JPEG XL Test Page

#162

Post by illiac786 »

rkangel wrote: post #137
capitainenemo wrote: post #82

Earlier quoted context omitted.

Checking the Firefox bugs on this, it seems they decided to replace the C++ libjxl with a rust version which is a WIP, to address security concerns with the implementation. All this started a few months ago. Maybe the zen fork is a bit older and still using the C++ one?

Google Chrome is using a Rust implementation. The existence and sufficient maturity of it is the reason they were willing to merge support in the first place.

Hmmm, check the jxl-rs repository. I wouldn’t call it mature. Not to say it’s buggy, but most of its code is very fresh.

Re: JPEG XL Test Page

#163

Post by encrypted_bird »

Dylan16807 wrote: post #131
encrypted_bird wrote: post #120

Earlier quoted context omitted.

Have you tried KeePassXL with SyncThing? I've heard good things about that setup.

For what purpose? While it's a perfectly good password manager, when used with Gnome Web it also means copy/pasting passwords and losing passkeys. Doesn't it?

When I commented that, I did not realize Gnome Web was a web browser (I'd never heard of it frankly), let alone a non-Firefox-based browser. Lol.

Re: JPEG XL Test Page

#165

Post by awestroke »

nar001 wrote: post #142
awestroke wrote: post #104

Earlier quoted context omitted.

zen browser is pretty much vibe coded

Do you have any proof/more about this? I've never heard this claim and I'd like to know more

1. Zen Browser had remote debugging enabled by default and disabled the security prompt for it. Extreme incompetence or malice? https://github.com/zen-browser/desktop/pull/927

2. Social trackers are selectively allowed, unsigned extensions are enabled by default, and Enhanced Tracking Protection isn't fully implemented.

There's just a theme of incompetence, trying to cover it up and just in general being clueless about security.

Re: JPEG XL Test Page

#167

Post by mikae1 »

Santosh83 wrote: post #133
pkulak wrote: post #106

Earlier quoted context omitted.

And Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/

Wonderful. Allow an "unmonitored" extension from a random stranger on the Internet have access to "all data for all websites" just to support an image format for which Mozilla should have long built in native support...

This...

I would not install non-recommended Firefox addons for things that can be achieved in about:config.

Just do set image.jxl.enabled flag in about:config to true.

Re: JPEG XL Test Page

#168

Post by diroussel »

Dylan16807 wrote: post #156
p_ing wrote: post #151

Earlier quoted context omitted.

You're free to make such assumptions.

What are you calling an assumption? My first statement is an opinion/judgement, not an assumption. I'm confident my second statement is true. Note that any argument that says niche formats are a problem because color space might be ambiguous also applies to the formats they do accept.

Who should accept responsibility when a conversion is not as expected?

There are very few ‘lossless” conversions possible if you consider the loss of a data or metadata could affect the result. So if printer did accept a file that needed to be converted, and then during printing and converting they found conversion could lead to unexpected results should they cancel the print run? There is just too much to go wrong in printing already without these extra problems.

The print industry has a long and storied history, and for whatever set of reasons, printers only accept very specific profiles of specific formats.

Re: JPEG XL Test Page

#169

Post by Vinnl »

bmacho wrote: post #148
Vinnl wrote: post #139

Earlier quoted context omitted.

Security concerns are exactly the reason the format doesn't have native support yet. However: https://github.com/mozilla/standards-positions/pull/1064

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. Also the parent comment was about that you really shouldn't just let a random Russian guy run any javascript on any website you visit, that's stupid. Also also, am I missing something, or Firefox extensions are broken , there is no way to limit an extension to…

The link I posted shows that Jpeg-XL will come to Firefox, and that that same Google is the one making that possible by writing a secure implementation.

Re: JPEG XL Test Page

#170

Post by Dylan16807 »

diroussel wrote: post #168
Dylan16807 wrote: post #156

Earlier quoted context omitted.

What are you calling an assumption? My first statement is an opinion/judgement, not an assumption. I'm confident my second statement is true. Note that any argument that says niche formats are a problem because color space might be ambiguous also applies to the formats they do accept.

Who should accept responsibility when a conversion is not as expected? There are very few ‘lossless” conversions possible if you consider the loss of a data or metadata could affect the result. So if printer did accept a file that needed to be converted, and then during printing and converting they found conversion could lead to unexpected results should they cancel the print run? There is just too much to go wrong i…

> Who should accept responsibility when a conversion is not as expected?

Who does it already? The system already takes files that could have unexpected results.

It's likely that if they took some other reasonable file types while always pre-converting they could actually reduce the error rate.

Post reply on HN