Here's the most recent version of the draft: https://drive.google.com/file/d/19pjtxUgChAOmy5mi4sQBite4xgGa4iaA/view?usp=sharing
Google Docs
1 messages · Page 1 of 1 (latest)
Here's the most recent version of the draft: https://drive.google.com/file/d/19pjtxUgChAOmy5mi4sQBite4xgGa4iaA/view?usp=sharing
Well my first critique is that it's a google drive link 😹
A friendship indicator with contributors from Google 🤔
It's too large for discord, final version will go on arXiv
What kind of paper would this be called? White paper? A technical report?
Whatever you wanna call it :)
Not everything needs to be christened with an officially ordained name of officialness
;)
I'd call it a technical report
Technical breakdown
A review
Or you can just call it... le holy, royal official paper of certified absolute authority and global domination of human obedience
I could go see if I can get a USB stick knighted next time I'm in London
Making an official JPEG committee White Paper is a tedious process. We have one now, but it takes lots of meetings to get consensus so it's a bit of a pain to update it.
I was considering making an academic paper but most conferences have a low page limit, and even most journals have limits on the number of words and/or figures.
So this paper will just be uploaded on arXiv - which is officially meant to share preprints of what will become an official academic publication, but I think it kind of works similar to an open-access journal. Sure, there's no peer review but I don't really believe the academic peer review process really works with the current incentives (huge publication pressure for academics, no rewards for spending time on peer review), there is no guarantee that peer review rejects bad quality papers or accepts great ones.
In a different layout, the same material could be a 150-page book. Maybe it would make sense to publish it like that too.
I'm trying to think if there's any more out-of-the-box ideas with JPEG XL that could be added... Things like the modular bit-packing, the... Actually, I'm surprised you didn't add this image to the Splines section #jxl message https://cdn.discordapp.com/attachments/794206170445119489/1217510081239978084/image.png?ex=67ce6adf&is=67cd195f&hm=5e65689ff434aa1a8a8e81662ffe5ba6bf433a526ec91219af50a935b1590871&
Unfortunately, I think that screenshot is all that survives of the demo
So in other words science is dead and welcome to the new dark ages
That's an exaggeration, but yes I do think that the past few decades of applying "business logic" to university management worldwide (including a very quantitative view in terms of measuring output KPIs on which public funding then is directly based) has caused the quality of the peer review process and of academic papers in general to deteriorate, since every incentive is favoring quantity over quality.
I suppose my next critique is that it's 70 pages long.
Brevity is a virtue
70ish pages is fine for something that's supposed to be comprehensive
If you want brevity there are other JXL articles Jon wrote that serve that purpose
I'll try to provide more specific critique next.
going to add this
also reworking the introduction to start with a TL;DR overview of JPEG XL highlighting the main features and advantages of the format, before going into the paper structure (overview of sections) etc. Otherwise a casual reader basically had to wait until section 2 to get an overview of what jxl can do, which is far away.
My critique is that the graph should have the colors that are more distinct. When it comes to human perception, aren't we least sensitive to Blue? Anyways, I feel like vibrant colors should represent important milestones.
For example, "universally supported" could be gold 🥇
"One major browser" could be silver 🥈
"Standardized" could just be a plain old blue 🔵
Makes sense to use more distinct colors, not sure I like the silver/gold thing
better?
Much easier to see changes at a glance
The original can be even converted to greyscale
Isn't TIFF supported by Safari?
you're right, it is, I just checked. But I think I'm going to pretend it isn't, since it's very unsuitable for the web and in practice nobody will actually use it on a web page. It's like BMP in that sense.
Too many colors...
@stoic sinew it's been ages since I've used LaTeX. Do you have good control over what it's doing to the images when you convert to PDF?
I'm making sure that all the vector stuff in the figures remain vectors, and for the raster images I took a pragmatic approach to avoid a huge PDF filesize: where it matters (since compression artifacts are compared), I use lossless, but where it doesn't matter too much, I use high-quality JPEG instead so the PDF doesn't get huge.
Jpegli?
I'm so used to using the crappy Adobe products where you can't control from image to image.
It's ironic. Adobe add things to specs, then make such poor attempts at implementing them, they don't seem like an improvement (DNG using 700 pixel tiles, so it's hardly better than JPEG-LS. Lossy quality being so high, lossless at half the effort is actually smaller)
Just had a thought for a spin-off of this graph.
Chrome adoption compared to OS and other browser support.
You'd see WebP and AVIF get adopted long before the encoders are even finished, then a big hole where JXL is already on everything else
"Premature adoption graph"
Speaking of which, is WebP/Avif supproted in Google slides or Google docs? Nope
"Supported Image files (.JPEG, .PNG, .GIF, .BMP, .TIFF, .SVG)"
That's great, the google work suite doesn't even support 15 year old WebP
Why would it? There's not enough ecosystem interest to support webp, and it's not a significant incremental improvement enough to justify yet another new format that has to be supported forever.
Oh wait. That's the argument the webp creator said about jxl! How ironic.
It's true
It would be interesting to do that, or maybe Windows and macOS support compared to Firefox, Chrome, Safari, and IE/Edge support. I just don't have the patience to do the historical research to find the dates.
Having both macos, ios, and now finally even windows support so quickly is amazing
I'm not sure if the paper puts enough emphasis on all the "alien artifacts" left for the future to use. Or the potential for scanners and cameras and other sensors to encode jxl in hardware in the future. Or the potential to be used in document scans djvu-style with a high res bitonal text foreground layer and a softer, more compressed background layer? Although I guess it's not really a true replacement for djvu since djvu also has a selectable-text layer and good support for multi-page docs.
I agree, there should be a mention in "Future" (section 11) how patches could be majorly improved and how splines are not used at all.
Also I think larger DCT blocks are still not used yet
Yeah basically the full potential is largely untapped
And libjxl is not even close to being a good example of what the format is capable of. It's more like a token first attempt to demonstrating some of its main features, with barely any optimization or tuning
It's able to accomplish a lot with just a basic token effort but new encoders could go muck farther
Both in speed and compression factor
a few years ago, you couldn't do a webp photo search and add webp to the cover of a YouTube video
This guy literally wants to just keep on doing this pump and dump of low-effort junk formats he's spearheading like webp and avif and soon "avif 2" and forcing everyone to adopt all these new image codec standards forever, rather than thoughtfully designing a format that's intended to be used long into the future like jxl.
Let's stick to criticism of the paper and not criticism of Chrome
Something I discovered is that \includegraphics supports PDF input
and it preserves vectors
Yes, that's what I do in most figures.
@stoic sinew How is the paper coming along? It has been awhile since the last update.