go-gitea
[Feature Request] next gen image previews
I don't see any mention of them so throwing it out there since browser support is coming faster than any other formats that ever existed. When you view a jxl or avif it currently says: Binary file not shown. For now a setting in the app.ini file would make sense I guess to allow them to be previews for whoever has it enabled.
All major browsers can now be enabled / already ship with it enabled. Jpeg XL thumbs (.jxl) Mime type: image/jxl https://caniuse.com/jpegxl
AVIF (AV1's image from the Alliance for Open Media)
Mime type: image/avif
https://caniuse.com/avif
~~This probably won't be fixed in upstream dependencies as we use a patched version of https://pkg.go.dev/net/http#DetectContentType, which only implements an unmaintained spec.~~
~~Scratch that, it should be supported in upcoming go 1.17~~
Scratch that too, this detection is based on file extension, which we currently ignore.
Here's some go code that (incorrectly) adds avif support: https://github.com/gabriel-vasile/mimetype/pull/160 Maybe we could just use that lib
You're opening each file to read it's type for how you treat in the browser?
animated.avif: ISO Media, AVIF Image Sequence
still.avif: ISO Media, AVIF Image
AVIF support was added in https://github.com/gabriel-vasile/mimetype/pull/210
I am eagerly awaiting JPEG-XL support. I have migrated all other image formats (excluding RAW (DNG)) to JPEG XL, yet they still cannot be shown as other file-formats can. This file format is a game-changer and really should be supported.
While Chromium-based web browsers and Firefox have JPEG-XL support behind a flag, Safari already enables JPEG-XL in production.
- JPEG-XL: https://caniuse.com/jpegxl It still lacks enough support (default enabled)
- Maybel JPEG-XL won't win the game: JPEG XL competes with AVIF which has similar compression quality but fewer features overall.
- AVIF: it is supported now: Add avif image file support #32508
While Chromium-based web browsers and Firefox have JPEG-XL support behind a flag, Safari already enables JPEG-XL in production.
due to one of the leads of AVIF also being one of the leads on chromium, he removed jpeg xl entirely. Some forks like thorium have rewritten it and compiled it in, but nearly all of them do not have it at all (maybe brave does too?) And several firefox forks enable it by default, which is pretty poor support population wise.
So Edge and chrome do NOT have jpeg xl at all, even behind flags.
All in all he effectively killed it for web.
AVIF already wins, and Gitea added support for it. So I think this issue can be closed?
which is pretty poor support population wise
@G2G2G2G Support for JPEG XL has exploded despite it being created in only 2019 and standardised in 2022. A non-exhaustive list of software supporting JPEG XL (JXL) images is as follows:
- ffmpeg
- MPV
- GIMP
- Krita
- ImageMagick
- GraphicsMagick
- tinydng
- Photoshop
- Image Toolbox
- Safari
Firefox is planning to add JPEG-XL support and are working with Google Research to develop a Rust-based decoder[1]. Do you expect everyone to use a Chromium-based web browser?
AVIF already wins
@wxiaoguang If you're talking in terms of image quality and compression, this is false. AVIF wins only in high-compression scenarios. You can see such results on the many tests done both online and by yourself via the many available tools. When using medium-to-low compression, or lossless, JPEG XL is superior. This is not an opinion, it is a fact.
Most people are pushing for JPEG XL due to this, whether 2 holdout web browsers support it or not, which is likely to be reduced to 1 when the aforementioned decoder is released.
[1]https://github.com/mozilla/standards-positions/pull/1064
I already posted to correct you, why do you post more, it is clear you do not know about this subject All of the software you posted also supports jpeg2000 and no mozilla isn't working with anyone to get jpeg xl support. They straight said "we won't implement it unless there is a rust version" so Jon Sneyers the creator of FLIF (which is pretty much what jpeg xl is) is getting that done. Either by himself or community I do not know. Your list is software that supports tons of formats that are not supported on web. It is good to support jxl, but this is a web software so the browsers need to support it first. Support for jxl hasn't changed at all in 5 years for web. 90% of the web doesn't support it and unless you convince the idiot leading chromium, it never will. So go complain to him.
AVIF wins only in high-compression scenarios.
this is wrong, AVIF wins in animated images as it has look-ahead (among other features) since it's a video codec. Making it vastly more efficient for that. It isn't necessarily greater at anything else. Elsewhere most of its benefit is in thumbnails though... So the opposite of what you said is true
I agree that gitea should just add it and have an option to enable it and disabled by default since most people can't view it. You'll probably have far better luck at forgejo to do such an option. I was in your position 4 years ago - 10 years ago as you can see by this thread date, you're not going to teach me anything new about these formats.
I already posted to correct you, why do you post more, it is clear you do not know about this subject
@G2G2G2G It would be smart of you to not make assumptions about people, particularly when they are incorrect. I am a software developer. I am a photographer. I work in transcoding and in file standards. You don't know me, so it's clear to me that you are the one who talks without knowing about what they are talking about. Your arrogance is clear.
In fact, I'd like an apology for it.
All of the software you posted also supports jpeg2000
JPEG 2000 is not a comparable format in any way. Neither is AVIF or HEIC. JPEG XL has substantial advantages over them.
and no mozilla isn't working with anyone to get jpeg xl support. They straight said "we won't implement it unless there is a rust version"
Working with someone doesn't mean they are writing the code. It can quite literally mean they have asked for it as a partnership. Google Research agreeing to do it makes it a partnership.
It is good to support jxl, but this is a web software so the browsers need to support it first
I agree, but Safari already supports it, and Mozilla clearly have intention to. Projects like this not supporting it aren't helping get such great standards pushed into web browsers.
Support for jxl hasn't changed at all in 5 years for web
Apple added support for JPEG XL on iPhone 16 and Safari. Mozilla also increased their stance by stating they will support it under the condition of a Rust-based decoder becoming available.
90% of the web doesn't support it and unless you convince the idiot leading chromium, it never will. So go complain to him
Projects like Gitea not supporting it won't promote inclusion into web browsers. See above.
this is wrong, AVIF wins in animated images as it has look-ahead (among other features) since it's a video codec. Making it vastly more efficient for that. It isn't necessarily greater at anything else. Elsewhere most of its benefit is in thumbnails though... So the opposite of what you said is true
You are correct for the animation, and I was correct in high-compression comparison. I won't even argue about this because it's as clear-as-day that AVIF causes softening and detail loss when compared to JPEG XL at medium-to-low compression; the official JPEG XL article by Cloudinary shows that.
I am a software developer. I am a photographer. I work in transcoding and in file standards.
so is and does everyone else, so what? You obviously don't do much in any of the fields Jpeg2000 is a perfect comparison https://caniuse.com/jpeg2000 safari was the only thing supporting it on web for 20 years and now it is dead and off web, virtually every editing program supported it It is nearly identical to how jxl is being treated now. And that is the only context we're comparing it in. If you want to push away from the subject to flex your lack of knowledge you can all you want. And supporting it in gitea takes maybe 30 minutes to add, so since you're so great, add it. I already embed it in my forgejo instance. Keep practicing, you sure need it. Consider learning to read next time instead of trying to complain about unrelated things
Yep, quite heated 😄 Thank you all for the discussions and opinions.
To be clear, I said "AVIF already wins", I meant that "in browsers ecosystem": it is widely supported, but JPEG-XL isn't. As long as Gitea is a web-application, it fully depends on browser's supports. It's impossible to make Gitea embed a special image codec and convert a browser-unsupported format and render it in a browser-supported format.
So in the future, if major browsers all support JPEG-XL (or some new formats), Gitea can also support in that day.
🙏
Google have announced their intention to bring back JPEG XL support to Chromium[1], while the format will also be used in the PDF format[2]. This feature is going to be necessary over time as the format continues to explode in adoption and usability.
[1] https://www.phoronix.com/news/JPEG-XL-Possible-Chrome-Back [2] https://www.theregister.com/2025/11/10/another_chance_for_jpeg_xl/
It seems that Google have decided on jxl-rs, have integrated it into Blink, and it is indeed happening[1]. I don't think I need to say more on the matter. It's clearly happening.
[1] https://chromium-review.googlesource.com/c/chromium/src/+/7184969