|
jonnyawsom3
|
2025-06-13 03:16:18
|
IIRC butter doesn't like dithering, SSIMU2 isn't so bad because it scales the image internally so the dither gets blurred
|
|
|
Demiurge
|
2025-06-13 03:46:57
|
So high frequency distortion that averages out to look like the original signal would be, rightfully, favored then, supposedly
|
|
2025-06-13 03:54:35
|
Whereas distortion that can be seen from a distance or even in a downscaled version of the image, such as banding, would be super duper punished.
|
|
2025-06-13 03:54:49
|
Presumably?
|
|
|
Lumen
|
2025-06-13 03:55:22
|
I also wonder why butteraugli chose to have only 2 scales but well, at least it is faster this way
|
|
|
_wb_
|
|
Demiurge
Presumably?
|
|
2025-06-13 08:47:47
|
Yes, something like that. The weights for each scale and component were tuned based on subjective datasets like TID2013 and CID22, so it's not like I manually selected the weights to heavily punish banding, but they do seem to do that
|
|
|
|
paperboyo
|
|
_wb_
added a version of that gradient with adaptive LF smoothing disabled, it does show quite clearly that it makes a difference
|
|
2025-06-13 08:51:31
|
Oh, what a coincidence, I wouldnβt have asked otherwise, but looking at these in the paper, I wondered: what `speed` AVIF example was encoded at? Reason being, I see this blockiness much reduced or disappear at aom `speed` `5` (versus `6` Iβm using). Sadly, `5` took helluva longer to encode in my baby-tests, so felt (too) bad asking my encoding friends for itβ¦
|
|
|
|
_wb_
|
2025-06-13 08:52:54
|
I don't remember, I can check when I get the chance
|
|
|
Kupitman
|
|
_wb_
added a version of that gradient with adaptive LF smoothing disabled, it does show quite clearly that it makes a difference
|
|
2025-06-13 09:15:32
|
COOL
|
|
|
CrushedAsian255
|
|
_wb_
banding and macroblocking are artifacts that have a pretty low per-pixel error, but in smooth gradients we don't need large differences to see unnatural banding or blocking β there is no contrast masking whatsoever to hide the artifacts. But PSNR has no clue about contrast masking, it's just an average of per-pixel error.
|
|
2025-06-14 12:08:24
|
so its just
```python
def psnr(source, distorted):
total_pixels = 0
error = 0
for source_pixel, distorted_pixel in zip(source,distorted):
error = (distorted_pixel-source_pixel)**2
total_pixels += 1
return log(error/total_pixels)
```?
|
|
|
A homosapien
|
|
_wb_
uploading an updated version, will probably take until after the weekend for arXiv to process but it's in the pipeline
|
|
2025-06-14 12:11:30
|
If you do revise the paper, could you also update the codec comparison table (fig 52) to include libaom's new tune IQ?
|
|
|
Jyrki Alakuijala
|
|
Demiurge
In ssimu2 and butter and similar metrics, how is banding detected and punished worse than other less damaging types of distortion?
|
|
2025-06-14 10:22:46
|
Diffs relate to other diffs in proximity (masking/contrast sensitivity)
|
|
|
_Broken sΜΈyΜ΄mΜ΄mΜ΅ΜΏeΜ΄ΝΝtΜΈrΜ΅ΜΜΏyΜ΄Ν Ν
|
2025-06-15 10:19:00
|
I do got an question, in the djxl man-page it says's bout lossless:
> Lossless pixel compression only preserves the pixels losslessly, not the input bitstream.
What is meant by bitstream vs pixel-losslessness? is that a hint towards color-profiles or something? If not, where can I read up about it?
|
|
|
|
Demiurge
|
2025-06-15 10:37:23
|
Bitstream means the file bitstream is not the exact same file but the pixels are the same
|
|
|
|
_Broken sΜΈyΜ΄mΜ΄mΜ΅ΜΏeΜ΄ΝΝtΜΈrΜ΅ΜΜΏyΜ΄Ν Ν
|
2025-06-15 10:37:41
|
Ahh, okay. That makes sense.
|
|
2025-06-15 10:37:47
|
Thank you π¦¦
|
|
|
|
Demiurge
|
2025-06-15 10:38:40
|
Like for example metadata and headers or other things that don't affect the pixels themselves
|
|
|
|
jonnyawsom3
|
|
_Broken sΜΈyΜ΄mΜ΄mΜ΅ΜΏeΜ΄ΝΝtΜΈrΜ΅ΜΜΏyΜ΄Ν Ν
I do got an question, in the djxl man-page it says's bout lossless:
> Lossless pixel compression only preserves the pixels losslessly, not the input bitstream.
What is meant by bitstream vs pixel-losslessness? is that a hint towards color-profiles or something? If not, where can I read up about it?
|
|
2025-06-15 10:57:35
|
It says that because JPEG Transcoding does preserve the original bitstream/file, but it won't create bit matching PNGs, ect
|
|
|
|
_Broken sΜΈyΜ΄mΜ΄mΜ΅ΜΏeΜ΄ΝΝtΜΈrΜ΅ΜΜΏyΜ΄Ν Ν
|
|
It says that because JPEG Transcoding does preserve the original bitstream/file, but it won't create bit matching PNGs, ect
|
|
2025-06-15 11:07:38
|
Would it then make sense to reformulate it? like:
> Lossless pixel compression only preserves the input bitstream when recosntructing a transcoded JPEG, it otherwise losslessly preserves the input pixels.
Idk, maybe a bit plumb.
|
|
|
|
Demiurge
|
2025-06-15 08:35:36
|
That would probably be a better way to say it.
|
|
|
|
jonnyawsom3
|
|
_Broken sΜΈyΜ΄mΜ΄mΜ΅ΜΏeΜ΄ΝΝtΜΈrΜ΅ΜΜΏyΜ΄Ν Ν
I do got an question, in the djxl man-page it says's bout lossless:
> Lossless pixel compression only preserves the pixels losslessly, not the input bitstream.
What is meant by bitstream vs pixel-losslessness? is that a hint towards color-profiles or something? If not, where can I read up about it?
|
|
2025-06-15 09:38:27
|
Wait, where did you see that? It's not in the repo or djxl help
|
|
|
|
_Broken sΜΈyΜ΄mΜ΄mΜ΅ΜΏeΜ΄ΝΝtΜΈrΜ΅ΜΜΏyΜ΄Ν Ν
|
|
Wait, where did you see that? It's not in the repo or djxl help
|
|
2025-06-15 11:43:00
|
```man djxl```
Or are the man-pages created by someone else?
|
|
|
|
jonnyawsom3
|
2025-06-15 11:43:53
|
Yeah that's not ours https://github.com/libjxl/libjxl/blob/main/doc/man/djxl.txt
|
|
2025-06-15 11:44:46
|
Though the man files need to be updated at some point
|
|
|
|
_Broken sΜΈyΜ΄mΜ΄mΜ΅ΜΏeΜ΄ΝΝtΜΈrΜ΅ΜΜΏyΜ΄Ν Ν
|
2025-06-15 11:45:26
|
huh?
I did tho install it as it said there:
> apt install libjxl-tools
or does that then come from a different provider or smth?
|
|
2025-06-15 11:47:57
|
Anyway, thank you guys so far; π¦¦
I do need to nap now;
|
|
|
|
jonnyawsom3
|
|
_Broken sΜΈyΜ΄mΜ΄mΜ΅ΜΏeΜ΄ΝΝtΜΈrΜ΅ΜΜΏyΜ΄Ν Ν
huh?
I did tho install it as it said there:
> apt install libjxl-tools
or does that then come from a different provider or smth?
|
|
2025-06-15 11:55:43
|
<https://manpages.debian.org/bookworm/libjxl-tools/djxl.1.en.html>
|
|
2025-06-15 11:55:47
|
Hmm https://snapshot.debian.org/package/jpeg-xl/0.7.0-10/
|
|
|
|
_wb_
|
|
Nuk
It's a very nice paper, very thorough AND approachable. Some formatting nitpicks if you ever decide to update it: p10 fig4 misplaced caption "libjpeg-turbo -quality 10" should be moved to the right. p38 typo "contructed"? And maybe change "Legend:" to "Legend (Predictors):"
p41 "Adaptive LF smoothing" fig30: it'd be nice to have an example of JPEG XL without adaptive smoothing (also is that the best AVIF can do? I thought it had better LF filtering)
p55: "the dynamic approach is inherently slower, both for encoding and decoding": for (all) decoders and fast encoders yes, but some encoders that do RDO (or DP path search / optimal parsing for LZ, or Trellis quantization) iterate several times using the probabilities of the previous pass as cost estimations for the current one, and the (single-pass) dynamic approach ends up being faster. I don't think this currently applies to libjxl though.
p67 "slower encode speed settings lead to a lower image quality": it's the other way around, right?
|
|
2025-06-16 06:08:01
|
Updated version is up: https://arxiv.org/abs/2506.05987
|
|
|
Kane
|
2025-06-23 08:14:40
|
how to instal libjxl for Windows? No MS store version.
|
|
|
HCrikki
|
2025-06-23 08:44:22
|
use of as part of XL Converter https://github.com/JacobDev1/xl-converter
|
|
2025-06-23 08:47:45
|
just make sure to confirm the options are set as desired. iinm its set to wipe metadata by default and do full conversions from jpeg sources that do not even guarantee smaller filesize (ir, *not lossless reversible transcodes* - in doubt, theres a specific conversion target for that one)
|
|
|
|
jonnyawsom3
|
2025-06-24 07:21:09
|
<@179701849576833024> nightly builds seem to be stuck, probably needs some tweaks after the github artifacts got broken and then fixed https://artifacts.lucaversari.it/libjxl/libjxl/latest/
|
|
|
|
veluca
|
2025-06-24 07:21:36
|
let's see if there is something obvious
|
|
|
|
jonnyawsom3
|
2025-06-24 07:33:36
|
I was going to link to it so someone could use my progressive PR, then realised the builds are almost 2 months old xD
|
|
|
|
veluca
|
2025-06-24 07:43:12
|
should be fixed now?
|
|
2025-06-24 07:43:17
|
it was even _two_ problems
|
|
|
|
jonnyawsom3
|
2025-06-24 07:49:26
|
Dear god.... Working now at least
|
|
|
|
Demiurge
|
2025-06-24 11:57:21
|
Deer god? π¦
|
|
|
minecraft.client.rpx
|
2025-06-25 04:37:09
|
test
|
|
2025-06-25 04:37:39
|
orig join date nov 13 2023 (have to leave on my main because no server space)
|
|
|
|
jonnyawsom3
|
2025-06-26 06:50:14
|
Well that was a horrible CLA to sign... But finally fixed their docs in light of the Blender attention https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4812
|
|
|
Orum
|
2025-06-26 06:57:24
|
Blender was very indifferent to JXL last I checked
|
|
2025-06-26 06:57:30
|
has that finally changed?
|
|
|
|
jonnyawsom3
|
|
Orum
has that finally changed?
|
|
2025-06-26 07:10:20
|
https://devtalk.blender.org/t/2025-06-26-platforms-builds-module-meeting/41220
|
|
2025-06-26 07:10:42
|
> Support for JPEG XL may be added for 5.0, WIP pull request is available at https://projects.blender.org/blender/blender/pulls/140882. Technical discussion is happening on https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-format/41155.
|
|
|
|
Orum
|
2025-06-26 07:11:00
|
yeah, "may"
|
|
2025-06-26 07:11:08
|
not going to hold my breath
|
|
|
|
jonnyawsom3
|
2025-06-26 07:12:19
|
> I think JPEG XL makes sense as an image format to support, because we generally want to support reading most images that users will encounter or want to publish with. To me that seems non-controversial, just needs someone to do the work.
|
|
2025-06-26 07:13:13
|
The OIIO PR is seemingly nearly done, and a dependency update is ready for when it's merged
|
|
2025-06-26 07:15:31
|
<@736897074896830535> how near completion is the PR?
|
|
|
|
Orum
|
2025-06-26 07:18:24
|
yeah IIRC the work was already done a while ago and then never got merged
|
|
|
|
5peak
|
|
<@736897074896830535> how near completion is the PR?
|
|
2025-06-26 07:22:35
|
Depends on the definition of done. Initial support for R, G, B and Ξ± channels is there. Still need to add support for more channels, such as depth et cetera.
|
|
|
|
Orum
|
2025-06-26 07:31:03
|
Blender gives you channel separators though, and seeing as JXL has over 4000 possible channels per image, is that really necessary?
|
|
|
|
jonnyawsom3
|
|
Depends on the definition of done. Initial support for R, G, B and Ξ± channels is there. Still need to add support for more channels, such as depth et cetera.
|
|
2025-06-26 07:34:58
|
For now, I'd say just add Depth, since OIIO already supports it and JXL has the kDepth channel type for it
Other channels can come in a future PR, to make sure this is ready for 5.0. Unless of course it's easy to add the others once Depth is done
I also left a [comment](<https://projects.blender.org/blender/blender/pulls/139397#issuecomment-1586637>) with suggestions for the save menu. Namely `Compression`, `Effort` and `Speed`. Photon noise would be fun, but isn't important
|
|
|
username
|
2025-06-26 07:36:50
|
having Depth would be amazing \π
|
|
|
|
5peak
|
2025-06-26 07:47:26
|
Maybe this WE.
|
|
|
|
jonnyawsom3
|
2025-06-26 07:48:34
|
Thanks for picking it up again
|
|
2025-06-26 07:49:22
|
Deadline for new dependencies is in 1 month, so we have time, but the sooner it can merge the better in case there are problems to solve
|
|
|
lonjil
|
2025-06-26 09:09:41
|
when are we getting a jxl spec update to add per color alpha ? π
|
|
|
|
jonnyawsom3
|
2025-06-26 09:24:39
|
Just have R, G, B layers
|
|
|
|
_wb_
|
2025-06-26 09:28:40
|
Does that need a spec update? You can have three alpha channels and give them names if you don't want to go just by index
|
|
2025-06-26 09:29:27
|
I guess if you want frames to blend correctly with that, a spec update is needed
|
|
2025-06-26 09:32:10
|
But for the image itself, the way alpha blending is done is not in scope of the jxl spec. Sure there is the expectation that it will be done with the first alpha channel and with blend math according to the associated or not field. But nothing stops applications from doing it per-color if there happen to be 3 alpha channels with names RA, GA, BA or whatever
|
|
2025-06-26 09:33:28
|
Is there a situation where per-color alpha semantically makes sense?
|
|
|
|
jonnyawsom3
|
|
Well that was a horrible CLA to sign... But finally fixed their docs in light of the Blender attention https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4812
|
|
2025-06-26 10:08:20
|
They're being quite stubborn... <https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4812#discussion_r2170010379>
> `JXL_ENC_FRAME_SETTING_DECODING_SPEED`
> Is this really something that controls the decoding speed tier? Or encoding?
|
|
|
|
Orum
|
2025-06-26 10:21:47
|
well it might affect encoding speed too but there's `-e` for that
|
|
|
|
jonnyawsom3
|
2025-06-26 10:32:47
|
Until v0.12 releases, faster decoding would dump uncompressed JXLs, which unsurprisingly was quite fast. I already linked them to the PR that fixes it, twice, but they didn't bother to read it so I suck a new chart directly in the discussion
|
|
|
|
lonjil
|
|
_wb_
Is there a situation where per-color alpha semantically makes sense?
|
|
2025-06-26 11:21:46
|
yes, in VFX if you render out an element that's transparent in only one color and then want to composite it with another element, for example.
|
|
|
|
_wb_
|
2025-06-27 08:51:16
|
So something like green colored glass could be fully transparent in red and blue but semi-transparent in green? As opposed to being semi-transparent in all three, which would darken or dull the red and blue?
|
|
|
Aras PranckeviΔius
|
2025-06-27 09:31:54
|
To me this sounds less like an "alpha channel" and more like "transmittance" / "translucency" which is colored
|
|
|
|
_wb_
|
2025-06-27 09:54:29
|
I suppose there are different variants of what physical process alpha tries to model: mixing ink, adding light, filtering light, fuzzy selection for compositing, etc. Depending on what it is exactly that you want to do, the blending should be done in a particular color space and with a particular formula.
|
|
|
|
Jyrki Alakuijala
|
|
username
having Depth would be amazing \π
|
|
2025-07-01 01:26:07
|
I had a hobby effort to build a relief editor. It was like gimp but with 16 bit color component and 16 bit depth, and existed before gimp. I worked on it 1995-1999.
|
|
|
|
5peak
|
|
Jyrki Alakuijala
I had a hobby effort to build a relief editor. It was like gimp but with 16 bit color component and 16 bit depth, and existed before gimp. I worked on it 1995-1999.
|
|
2025-07-01 08:37:39
|
HyvÀÀ pÀivÀÀ Jyrki,
It would be great to finalize the OIIO JPEG XL I/O plug-in to support more channels w/o Xaos. Such as stereo and multiview. I would appreciate your insight and any hints.
|
|
|
|
jonnyawsom3
|
2025-07-01 11:05:29
|
What's Xaos? It just comes up as a fractal viewer
You'd want to figure out how to store the channels though. Since those are essentially separate images, multilayer or framed/paged JXL might be better than extra channels. It depends if you'd want to do differential storage between them using floats and offsets, ect
|
|
|
|
5peak
|
2025-07-01 12:45:31
|
I meant real chaos. IIRC the stereo 3D is such a big mess of various configurations. SGI got that right twenty plus years ago.
|
|
2025-07-01 12:48:48
|
4 the reference, just check https://3dtv.at
|
|
|
|
jonnyawsom3
|
2025-07-01 01:02:32
|
> Left and right view should be either encoded as single video stream in side-by-side format or over/under format, or each view should be encoded as separate video stream.
>
> In case separate streams are used, video stream numbers should be ordered from left to right. The most-left video streams has the lowest number, the most-right video stream the highest number. It is not required that video stream numbers are continuous. The number of video streams is limited by the ASF format only. Playback applications supporting only stereoscopic viewing methods (requiring two views only) should be able to decode just the first two video streams and ignore the remaining streams.
Yeah, that's what I've usually seen. Stream numbers could be layer/frame/channel names for JXL, the question is what would be best
|
|
|
|
5peak
|
|
> Left and right view should be either encoded as single video stream in side-by-side format or over/under format, or each view should be encoded as separate video stream.
>
> In case separate streams are used, video stream numbers should be ordered from left to right. The most-left video streams has the lowest number, the most-right video stream the highest number. It is not required that video stream numbers are continuous. The number of video streams is limited by the ASF format only. Playback applications supporting only stereoscopic viewing methods (requiring two views only) should be able to decode just the first two video streams and ignore the remaining streams.
Yeah, that's what I've usually seen. Stream numbers could be layer/frame/channel names for JXL, the question is what would be best
|
|
2025-07-01 02:39:55
|
https://github.com/AcademySoftwareFoundation/openexr-images/tree/main/MultiView for an inspiration.
|
|
|
|
jonnyawsom3
|
2025-07-01 02:46:10
|
Thanks but that doesn't help much, it just confirms that it's multiple normal images stored in the same file. So we still need to decide between layers, frames or pages, since channels would be wasteful for separate RGB views
|
|
|
https://github.com/AcademySoftwareFoundation/openexr-images/tree/main/MultiView for an inspiration.
|
|
2025-07-01 02:54:35
|
This is more useful https://openexr.com/en/latest/MultiViewOpenEXR.html#example-file-structures
|
|
|
|
_wb_
|
2025-07-01 02:56:20
|
So today we had a joint breakout session between JPEG and MPEG to discuss jxl as a payload codec for HEIF.
|
|
2025-07-01 02:57:30
|
This has been suggested in the past but I always resisted so far. This time I will cave in and help to make it a thing.
|
|
|
|
veluca
|
2025-07-01 02:58:04
|
jxif?
|
|
2025-07-01 02:58:05
|
π
|
|
|
|
jonnyawsom3
|
2025-07-01 02:58:19
|
What are the advantages? I know HEIF is meant to have other payloads but only HEIC is common
|
|
|
|
veluca
|
|
What are the advantages? I know HEIF is meant to have other payloads but only HEIC is common
|
|
2025-07-01 02:58:30
|
I mean, AVIF exists
|
|
|
|
_wb_
|
2025-07-01 02:59:34
|
I have resisted in the past because there is little that HEIF brings that plain jxl doesn't already have besides header overhead and potential patent issues.
|
|
|
|
jonnyawsom3
|
|
veluca
I mean, AVIF exists
|
|
2025-07-01 02:59:55
|
Eugh, right, the naming.... This is why everyone just uses `.avif`, `.heic` and `.jxl` xD
|
|
|
|
_wb_
|
2025-07-01 03:00:06
|
But both Apple and Adobe really seem to want this, so who am I to say they shouldn't do it.
|
|
|
|
veluca
|
2025-07-01 03:00:37
|
IMO it is mostly useful as a political move
|
|
|
|
5peak
|
|
_wb_
This has been suggested in the past but I always resisted so far. This time I will cave in and help to make it a thing.
|
|
2025-07-01 03:01:04
|
I recall BPG. Miss it badly. https://photo.reflexion.tv/BPG/
|
|
|
|
afed
|
2025-07-01 03:01:44
|
yeah, a double container isn't a good thing (just unnecessary, inefficient overhead)
and basically heif isn't needed for jxl, but maybe it'll help with wider adoption, which isn't bad
|
|
|
|
jonnyawsom3
|
2025-07-01 03:02:16
|
I'm very confused why they need or want it... Just to hide that it's really a JXL inside?
|
|
|
|
5peak
|
|
I'm very confused why they need or want it... Just to hide that it's really a JXL inside?
|
|
2025-07-01 03:03:03
|
NIH.?!
|
|
|
|
_wb_
|
2025-07-01 03:03:03
|
It's not that different from what happened with DNG and DICOM.
|
|
|
|
username
|
|
afed
yeah, a double container isn't a good thing (just unnecessary, inefficient overhead)
and basically heif isn't needed for jxl, but maybe it'll help with wider adoption, which isn't bad
|
|
2025-07-01 03:03:25
|
eh I could see it not really doing much for adoption considering that barely anything supports HEIC
|
|
|
|
jonnyawsom3
|
2025-07-01 03:03:37
|
True I suppose, even if I have my own gripes with the DNG implementation
|
|
|
|
_wb_
|
|
username
eh I could see it not really doing much for adoption considering that barely anything supports HEIC
|
|
2025-07-01 03:04:32
|
HEIC maybe not, but HEIF is very ubiquitous since AVIF is an instance of HEIF
|
|
|
|
jonnyawsom3
|
2025-07-01 03:05:33
|
We stick to our `.jxl`, and people complain that their `.heif` isn't opening. It'd certainly boost adoption, even if not for the right reason
|
|
|
|
afed
|
|
username
eh I could see it not really doing much for adoption considering that barely anything supports HEIC
|
|
2025-07-01 03:07:53
|
i mean, if heif is important for someone to accept jxl, then okay, since there are no other choices
|
|
|
|
username
|
2025-07-01 03:10:44
|
to be clear I'm not against JXL being a payload for HEIF but I just really don't see it as that big of a vector for adoption and I don't think AVIF's adoption was influenced much or at all from it being based on HEIF
|
|
|
|
jonnyawsom3
|
|
_wb_
HEIC maybe not, but HEIF is very ubiquitous since AVIF is an instance of HEIF
|
|
2025-07-01 03:16:25
|
I accidently proved my own point earlier, people know AVIF as AVIF and HEIC as HEIC. I don't think any of us have ever seen HEIF outside of Apple's ecosystem, and they already have OS level JPEG XL support
If it helps adoption then sure, but I just don't see how it could since anywhere using (Specifically) `.HEIF` already has JXL
|
|
|
|
afed
|
|
username
to be clear I'm not against JXL being a payload for HEIF but I just really don't see it as that big of a vector for adoption and I don't think AVIF's adoption was influenced much or at all from it being based on HEIF
|
|
2025-07-01 03:19:36
|
not for users, but perhaps for certain companies who consider HEIF to be more "influential" and "valuable"
HEIC is not as widely adopted because HEVC still has licensing issues and does not give significant advantages
|
|
|
|
5peak
|
|
afed
not for users, but perhaps for certain companies who consider HEIF to be more "influential" and "valuable"
HEIC is not as widely adopted because HEVC still has licensing issues and does not give significant advantages
|
|
2025-07-01 03:36:28
|
Check 0kia & π deal.
|
|
|
|
jonnyawsom3
|
|
HyvÀÀ pÀivÀÀ Jyrki,
It would be great to finalize the OIIO JPEG XL I/O plug-in to support more channels w/o Xaos. Such as stereo and multiview. I would appreciate your insight and any hints.
|
|
2025-07-01 03:39:53
|
I think I'd suggest pages for JXL multiview/stereo, as they're either RGB or greyscale images.
EXR suggests
```
Part 0: view: "right" ; name: "right"
channels: R G B diff.R diff.G diff.B spec.R spec.G spec.B
Part 1: view: "left" ; name: "left"
channels: R G B diff.R diff.G diff.B spec.R spec.G spec.B
```
JXL could be
```
Page 1: Frame Name: "right"
Main Channels: R G B
Extra Channels: diff.R diff.G diff.B spec.R spec.G spec.B
Page 2: Frame Name: "left"
Main Channels: R G B
Extra Channels: diff.R diff.G diff.B spec.R spec.G spec.B
```
> If frame duration has the value 0xFFFFFFFF, the decoder presents the next frame as the next page in a multi-page image.
|
|
|
|
5peak
|
|
I think I'd suggest pages for JXL multiview/stereo, as they're either RGB or greyscale images.
EXR suggests
```
Part 0: view: "right" ; name: "right"
channels: R G B diff.R diff.G diff.B spec.R spec.G spec.B
Part 1: view: "left" ; name: "left"
channels: R G B diff.R diff.G diff.B spec.R spec.G spec.B
```
JXL could be
```
Page 1: Frame Name: "right"
Main Channels: R G B
Extra Channels: diff.R diff.G diff.B spec.R spec.G spec.B
Page 2: Frame Name: "left"
Main Channels: R G B
Extra Channels: diff.R diff.G diff.B spec.R spec.G spec.B
```
> If frame duration has the value 0xFFFFFFFF, the decoder presents the next frame as the next page in a multi-page image.
|
|
2025-07-01 03:41:53
|
Lπks gπd 2 M.
|
|
|
|
jonnyawsom3
|
2025-07-01 03:42:25
|
Then simple decoders will only display the first view, like in EXR, but more complete ones would let you see every view too
|
|
|
|
5peak
|
|
Then simple decoders will only display the first view, like in EXR, but more complete ones would let you see every view too
|
|
2025-07-01 03:43:33
|
Cπ1!
|
|
|
|
jonnyawsom3
|
2025-07-01 03:43:34
|
The main color channels can all use VarDCT as they're separate frames instead of extra channels, and the extra channels can then make propper use of the RCTs too
|
|
2025-07-01 03:46:22
|
Depth channel would want the kDepth channel type but the rest should work with kOptional
|
|
2025-07-01 03:50:23
|
<@736897074896830535> I've said it before, but please try and get the current Blender PR merged before working on multiview and extra channels. If JPEG XL support is added for 5.0, then it can be improved much more easily in a future PR without having to wait a year to test.
|
|
|
|
username
|
2025-07-01 03:54:35
|
extra channel wise all that would really be needed/important for Blender is the Depth channel support and I'd hate for Depth channel support to be left out as it's one of the only things that would make JXL an enticing/interesting option for direct exporting from Blender
|
|
|
|
5peak
|
|
<@736897074896830535> I've said it before, but please try and get the current Blender PR merged before working on multiview and extra channels. If JPEG XL support is added for 5.0, then it can be improved much more easily in a future PR without having to wait a year to test.
|
|
2025-07-01 03:56:38
|
OK. WE was 2 busy. Now I have a bit of free(time_t now) to make.it.final
|
|
|
|
jonnyawsom3
|
2025-07-01 04:07:13
|
3 weeks left https://projects.blender.org/blender/blender/issues/138940
|
|
|
novomesk
|
2025-07-01 04:46:10
|
What will be the mime type of the JXL-in-HEIF ?
|
|
|
|
afed
|
2025-07-01 04:57:59
|
most likely the same as other JPEG formats, because HEIF can also contain JPEG1, J2K, JXR and JXS, with the same HEIF extension
|
|
|
|
jonnyawsom3
|
|
afed
most likely the same as other JPEG formats, because HEIF can also contain JPEG1, J2K, JXR and JXS, with the same HEIF extension
|
|
2025-07-01 04:59:33
|
The other JPEG formats have no mime type though
|
|
2025-07-01 04:59:44
|
https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format#JPEG_compression_formats_in_HEIF_files
|
|
2025-07-01 05:01:20
|
> Although Annex H to ISO/IEC 23008-12 specifies JPEG (and indirectly Motion JPEG) as a possible format for HEIF coded image data, it is used in HEIF only for thumbnails and other secondary images. Therefore, neither a dedicated MIME subtype nor a special file extension is available for storage of JPEG files in HEIF container files.
|
|
|
|
afed
|
2025-07-01 05:01:35
|
i mean, most likely jxl will be integrated in a similar way as other jpeg formats
|
|
|
|
jonnyawsom3
|
2025-07-01 05:02:18
|
Hmm, so just for thumbnails :P
|
|
|
|
afed
|
2025-07-01 05:07:03
|
at least JPEG1 can be used normally, not just for thumbnails
|
|
|
|
Jyrki Alakuijala
|
2025-07-01 05:14:46
|
competition: how many times can we put an image container inside an image container such as tiff, heif, iff, riff, matroska, av1, jpeg xl, Distinguished Encoding Rules, webp, zip, pdf, dng etc. and have a main stream image decoding system to still be able to view the image?
|
|
|
|
5peak
|
|
Jyrki Alakuijala
competition: how many times can we put an image container inside an image container such as tiff, heif, iff, riff, matroska, av1, jpeg xl, Distinguished Encoding Rules, webp, zip, pdf, dng etc. and have a main stream image decoding system to still be able to view the image?
|
|
2025-07-01 05:54:31
|
B$ingo!
|
|
|
AccessViolation_
|
|
Jyrki Alakuijala
competition: how many times can we put an image container inside an image container such as tiff, heif, iff, riff, matroska, av1, jpeg xl, Distinguished Encoding Rules, webp, zip, pdf, dng etc. and have a main stream image decoding system to still be able to view the image?
|
|
2025-07-01 06:59:02
|
now I wonder if there's a potential DOS vulnerability with that, just like how you can create a zip file that never finishes extracting
|
|
|
spider-mario
|
2025-07-01 09:39:02
|
maybe some form of quine is possible
|
|
|
|
Demiurge
|
2025-07-02 09:10:53
|
You know, if you devs are really thinking of a "bitstream format revision 2" for jpegxl, you really ought to hash out the details before commercial products with jxl decoders start being deployed.
|
|
2025-07-02 09:12:39
|
At this early stage in the life cycle, it would be easy to add decode support for a new, experimental "variant" bitstream format, where you can experiment with fixing any last minute regrets you might have when designing the standard.
|
|
2025-07-02 09:15:00
|
But once more commercial products start shipping, you will have less opportunity to do this, if there's more and more commercial products that include a jxl decoder that cannot or will not be updated to a newer decoder version.
|
|
2025-07-02 09:17:08
|
You could have "original" standard jxl files, plus "variant 2" jxl files
|
|
2025-07-02 09:18:48
|
The earlier you introduce it, before the format gets really popular beyond your control, the easier and less noticeable it will be. And the less likely people will be using an old enough decoder version to matter.
|
|
2025-07-02 09:19:08
|
You could even have a way to losslessly convert "variant 2" into "old" jxl
|
|
|
|
HCrikki
|
2025-07-02 12:42:11
|
any change would imo be harmful and fragment the jxl ecosystem. bitstream is fine, 'futureproof' wasnt a humblebrag. rest is a decoder's job, and many implementations being shallow integrations of libjxl will ensure any improvements from jxl authors trickle down (assuming correctly implemented naturally)
|
|
|
|
jonnyawsom3
|
|
Demiurge
You know, if you devs are really thinking of a "bitstream format revision 2" for jpegxl, you really ought to hash out the details before commercial products with jxl decoders start being deployed.
|
|
2025-07-02 03:33:35
|
When did they say that? All he said was that JXL can be inside a HEIF container
|
|
|
|
_wb_
|
2025-07-02 03:42:16
|
There are no plans to change the bitstream and certainly not in a backwards-incompatible way.
|
|
|
|
Demiurge
|
2025-07-02 03:55:47
|
Not changing it. But making a new bitstream format in addition to the existing one. A variant, maybe a superset with the existing bitsteam format defined as a special case.
|
|
|
|
jonnyawsom3
|
2025-07-02 03:56:49
|
So you already want to make JPEG XXL :P
|
|
|
|
Demiurge
|
2025-07-02 04:01:42
|
If you truly have some minor little regrets you wish you could change, you can make a minor little variant and make sure the decoder is ready to handle it, while the encoder sticks to the old format for the forseeable future until the decoder proliferates.
|
|
2025-07-02 04:02:38
|
The spec can define both variants, which will be similar enough to each other that it won't be burdensome.
|
|
|
|
username
|
2025-07-02 04:02:42
|
live service image format
|
|
|
|
jonnyawsom3
|
2025-07-02 04:02:45
|
'make a minor little variant'
So that any existing applications can no longer open the files and making it an untrustworthy format to adopt due to not maintaining a compatible format
|
|
2025-07-02 04:02:51
|
No.
|
|
|
|
Demiurge
|
|
So you already want to make JPEG XXL :P
|
|
2025-07-02 04:03:10
|
It will still be jpegxl, just like how there is raw vs containerized jxl
|
|
|
|
jonnyawsom3
|
2025-07-02 04:03:34
|
No, just like there is lossless JPEG and Baseline JPEG
|
|
|
|
Demiurge
|
|
'make a minor little variant'
So that any existing applications can no longer open the files and making it an untrustworthy format to adopt due to not maintaining a compatible format
|
|
2025-07-02 04:04:35
|
No, because the encoder will not produce "new variant" files. Not until older decoder versions are extinct.
|
|
|
|
afed
|
2025-07-02 04:04:45
|
why do we need new formats when we can just update jpeg1 every year <:Poggers:805392625934663710>
|
|
|
|
jonnyawsom3
|
2025-07-02 04:05:08
|
And when are old versions extinct? How do you know when every application has updated or is no longer used?
|
|
|
|
Demiurge
|
2025-07-02 04:06:11
|
It's still early enough in the lifecycle of jxl that it won't be disruptive to make minor bitstream improvements if it's done intelligently.
|
|
|
|
jonnyawsom3
|
2025-07-02 04:06:19
|
> will not produce "new variant" files. Not until
Those are very contradictory statements next to each other...
|
|
|
|
Demiurge
|
2025-07-02 04:09:42
|
The existing bitstream format will be forever supported. But it really, is not a big deal, to add an additional variant bitstream definition to the decoder at this point in time. As long as you wait a while before producing files in that new format.
|
|
|
|
jonnyawsom3
|
2025-07-02 04:09:52
|
'minor' bitstream improvements are bugfixes like the special distances, maybe metadata changes or new box additions. Not incompatible variants of the core encoding method
|
|
|
|
afed
|
2025-07-02 04:10:59
|
yeah, if the format isn't frozen and there's no full backward compatibility with any decoder, it'll be a total mess and won't be any different from just introducing a new format
unless it can be half-compatible and, say, show some image with worse quality or without animation, like it's compatible but downgraded if there's no support for some new extensions
|
|
|
|
jonnyawsom3
|
2025-07-02 04:11:15
|
You say this as if it isn't already shown to be a problem with AVIF. They added incompatible variants, and now different versions of Android can't open different AVIF files
|
|
|
|
Demiurge
|
2025-07-02 04:12:01
|
But avif is older and has already been incorporated into commercial products like android phones.
|
|
2025-07-02 04:12:13
|
Time is frankly running out then
|
|
|
|
jonnyawsom3
|
2025-07-02 04:12:18
|
It's doesn't matter if you 'wait a while', because in that time more people are adding support for that old version of the format
|
|
|
|
Demiurge
|
|
It's doesn't matter if you 'wait a while', because in that time more people are adding support for that old version of the format
|
|
2025-07-02 04:13:20
|
No, they are adding support for the decoding library... which will have support for the new format very early on.
|
|
|
|
jonnyawsom3
|
|
Demiurge
Time is frankly running out then
|
|
2025-07-02 04:13:25
|
Considering I'm running an 8 year old Android with no support for AVIF at all, I think you underestimate the average lifespan of a phone
|
|
|
|
Demiurge
|
2025-07-02 04:15:22
|
The only phones with jxl support are Apple phones. You will know when apple updates the decoder to a newer version when it's able to decode experimental files in the variant format.
|
|
2025-07-02 04:15:49
|
Hypothetically speaking
|
|
|
|
jonnyawsom3
|
2025-07-02 04:16:07
|
We already know when they update the decoder due to dithering and bugfixes that allow it to decode existing files correctly
|
|
|
|
Demiurge
|
2025-07-02 04:16:22
|
It's really not a big deal or as complicated as it sounds. There's no real basis for the hesitancy or fear
|
|
|
|
jonnyawsom3
|
2025-07-02 04:17:00
|
You say that when every other person is giving you reasons for hesitancy and fear
|
|
|
|
Demiurge
|
2025-07-02 04:17:32
|
Adding a minor variant to the decoder is a trivial thing
|
|
2025-07-02 04:18:32
|
It will have zero impact on anybody
|
|
2025-07-02 04:18:40
|
At this point in time
|
|
2025-07-02 04:19:03
|
If it's done too late in the future then it will have an impact
|
|
2025-07-02 04:22:45
|
The format is frozen. So you just define a new "variant 2" format and keep it very simple and elegant to define. You make sure decoders can ideally handle files in both formats.
|
|
2025-07-02 04:25:59
|
The only real potential problem is, decoders that support only 1 type
|
|
2025-07-02 04:26:57
|
But that's a hypothetical and unlikely problem since there aren't a whole bunch of jxl decoders floating around that aren't commonly known
|
|
|
'make a minor little variant'
So that any existing applications can no longer open the files and making it an untrustworthy format to adopt due to not maintaining a compatible format
|
|
2025-07-02 04:31:15
|
Like this for example are all purely imaginary and meritless concerns.
|
|
|
|
jonnyawsom3
|
2025-07-02 04:33:06
|
> The format is frozen. So you just define a new "variant 2" format
Again, those are very contradictory statements next to each other... It's frozen for a reason, and only recently so in the grand scheme of things
|
|
|
|
Demiurge
|
2025-07-02 04:33:23
|
By the time the new variant becomes switched on, you would have to be using a PC you dug up from a time capsule let's say, in order to encounter a file you can't decode. And then it's expected you have problems when you are using a machine like that.
|
|
|
|
jonnyawsom3
|
2025-07-02 04:34:01
|
Dedicated hardware has been in the works for a few years now already, you'd be throwing away all their work
|
|
|
|
Demiurge
|
|
> The format is frozen. So you just define a new "variant 2" format
Again, those are very contradictory statements next to each other... It's frozen for a reason, and only recently so in the grand scheme of things
|
|
2025-07-02 04:34:18
|
The existing frozen format still stands, parallel to the potential/hypothetical variant
|
|
|
|
jonnyawsom3
|
2025-07-02 04:34:43
|
Again, like Lossless JPEG, JPEG-XT, JPEG-XR......
|
|
|
|
Demiurge
|
|
Dedicated hardware has been in the works for a few years now already, you'd be throwing away all their work
|
|
2025-07-02 04:34:54
|
I mean that depends on what the hypothetical variant differences would be...
|
|
2025-07-02 04:37:40
|
jxlinfo would show you what type of file it is, just like it shows you whether it's raw or containerized. And you would be able to losslessly convert files back and forth between the two formats, since all the last-minute regrets were extremely minor if I recall
|
|
2025-07-02 04:38:47
|
I don't see why that would be anything to freak out about. Like I said, it sounds honestly really trivial.
|
|
2025-07-02 04:39:14
|
If you wait any later it won't be so trivial anymore
|
|
2025-07-02 04:39:48
|
Because then it gets harder to keep track of all of the different decoders out in the wild
|
|
2025-07-02 04:39:57
|
Right now it's easy to keep track of that
|
|
2025-07-02 04:40:18
|
That's my logic
|
|
2025-07-02 04:40:57
|
But there is an argument to be made that if all the regrets are really minor, why even bother at all
|
|
2025-07-02 04:42:25
|
It should be a judgement call but I don't think it should be written off completely just because of imaginary worries
|
|
2025-07-02 04:42:53
|
It could be done intelligently if there was a good enough reason
|
|
|
|
afed
|
2025-07-02 04:46:00
|
there is a reason why no one uses lossless or arithmetic coding for jpeg1, even if many decoders support it
the same for avc 10-bit and similar, for avc there is even another name with these extensions - xavc, which is essentially an extended avc, which already supports 10-bit and other improvements, but it is still 99.9% avc
it is just easier and more understandable to use it as some new format, than to try to improve the old one without full compatibility
|
|
|
|
5peak
|
|
<@736897074896830535> I've said it before, but please try and get the current Blender PR merged before working on multiview and extra channels. If JPEG XL support is added for 5.0, then it can be improved much more easily in a future PR without having to wait a year to test.
|
|
2025-07-02 07:38:09
|
Need lot of β++
|
|
|
|
jonnyawsom3
|
|
Need lot of β++
|
|
2025-07-02 07:47:28
|
What's left to do currently? It looks like Bitdepth, Quality, Int/Float, Greyscale, RGB and Alpha are all complete in your PR
I know I asked about setting Effort and (Decode) Speed too, but I think those should be quite easy
|
|
2025-07-02 07:51:25
|
Also this may be useful for Depth in future <https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4055#issuecomment-1986737766>
|
|
|
|
5peak
|
2025-07-02 07:54:55
|
I do hope it will be finished this summer.
|
|
2025-07-02 07:54:58
|
! 1 man show.
|
|
|
|
jonnyawsom3
|
|
I do hope it will be finished this summer.
|
|
2025-07-02 08:09:57
|
What's stopping the PR currently? More channels can be added in future, so I'd like to get it in 5.0 if we can help
|
|
|
|
HCrikki
|
2025-07-03 03:14:45
|
separate formats based on jxl and adding any special sauce or feature would suffice. ie, extending future PSD to be 'based on jxl' but now with a million layers and blending modes
|
|
|
|
jonnyawsom3
|
2025-07-03 03:16:27
|
I already have an open discussion with Krita devs about moving to JXL powered KRA files
|
|
|
|
HCrikki
|
2025-07-03 03:18:48
|
cool. software that used to have its own legacy limited inefficient file formats would win big adopting that way
|
|
|
|
jonnyawsom3
|
2025-07-03 03:21:10
|
https://bugs.kde.org/show_bug.cgi?id=500877
|
|
2025-07-03 03:21:54
|
Likely similar issues to Blender in <#803574970180829194> for exchange format use. Floats are unoptimized and decoding is quite slow
|
|
|
|
Demiurge
|
|
afed
there is a reason why no one uses lossless or arithmetic coding for jpeg1, even if many decoders support it
the same for avc 10-bit and similar, for avc there is even another name with these extensions - xavc, which is essentially an extended avc, which already supports 10-bit and other improvements, but it is still 99.9% avc
it is just easier and more understandable to use it as some new format, than to try to improve the old one without full compatibility
|
|
2025-07-03 07:19:21
|
But in the case of JXL, it's still very early on and there aren't that many decoders out there. So it's still pretty easy to keep track of and control what the decoders support.
|
|
|
|
5peak
|
|
What's stopping the PR currently? More channels can be added in future, so I'd like to get it in 5.0 if we can help
|
|
2025-07-03 11:39:34
|
Real time_t
|
|
|
|
_wb_
|
2025-07-04 11:55:43
|
Is anyone here familiar with the internals of ISOBMFF/HEIF/MIAF and wants to weigh in on the way we will define how to embed jxl into that container?
The main thing we need to deal with is that isobmff has its own header syntax (mostly mandatory) to signal stuff like image dimensions, orientation, color space, etc β which we already have in the jxl codestream.
I'm co-chairing a joint WG3 + WG1 ad-hoc group and we have to come up with a proposal before the next meeting in October.
|
|
|
|
Orum
|
2025-07-05 12:06:30
|
Why is this JXL's problem? Seems like something that needs to be sorted out on their end, not yours...
|
|
|
|
jonnyawsom3
|
2025-07-05 12:24:22
|
I'm still wondering why they need it...
|
|
|
|
_wb_
|
|
Orum
Why is this JXL's problem? Seems like something that needs to be sorted out on their end, not yours...
|
|
2025-07-05 12:43:37
|
It's better to be involved in sorting it out, then to let people do it who have limited understanding of the technical nuances, which leads to a poor solution.
|
|
|
|
Orum
|
2025-07-05 12:44:52
|
I guess... frankly I wouldn't care if BMFF/HEIF died a quick death though
|
|
|
|
_wb_
|
2025-07-05 12:54:01
|
Unlikely. It is backed by many big players. It is not only used by HEIC and AVIF either...
|
|
2025-07-05 12:56:31
|
When both MPEG and AOM use it, it's probably not just going to go away
|
|
|
|
jonnyawsom3
|
2025-07-05 01:04:22
|
It's not going to go away, but it's not always necessary either. Surely someone knows *why* they're doing all this work, other than "We want HEIF to have JXL"
|
|
|
|
CrushedAsian255
|
2025-07-05 01:05:03
|
Why does JXL even need to support ISOBMFF
|
|
2025-07-05 01:05:14
|
is anyone trying to stuff JXL code streams in there?
|
|
2025-07-05 01:05:27
|
If so, they really need to read 18181-2
|
|
|
Orum
I guess... frankly I wouldn't care if BMFF/HEIF died a quick death though
|
|
2025-07-05 01:05:43
|
Isnβt MP4 based on BMFF?
|
|
2025-07-05 01:06:30
|
MKV is better tho imo
|
|
|
Meow
|
2025-07-05 05:52:57
|
A JXL HEIF?π€
|
|
|
|
_wb_
|
2025-07-05 05:53:42
|
I suppose we could call it HEIL
|
|
|
|
spider-mario
|
2025-07-05 09:14:54
|
or maybe hej
|
|
2025-07-05 09:15:18
|
casual HEIF
|
|
|
|
_wb_
|
2025-07-05 09:44:41
|
HEXL?
|
|
|
|
novomesk
|
2025-07-05 10:02:09
|
hej2 = JPEG 2000 in HEIF
|
|
|
|
_wb_
|
2025-07-05 10:44:35
|
Is that the brand name they picked? I don't remember
|
|
|
|
novomesk
|
|
novomesk
hej2 = JPEG 2000 in HEIF
|
|
2025-07-05 12:31:53
|
The first box has
ftypj2ki
|
|
2025-07-05 12:34:01
|
H264 in HEIF has
ftypavci
|
|
|
|
Jyrki Alakuijala
|
|
I'm still wondering why they need it...
|
|
2025-07-05 08:38:45
|
There are many people who think the container is the most important thing, for them everything else is a bit "dirty."
|
|
|
Quackdoc
|
2025-07-06 04:57:44
|
any reccomended cmdlines for compressing lossless modular jxl to lossly jxl? need to compress a wackload, wondering if any if the new releases added anything special, for now I'll prolly just do e7 with the progressive dc
|
|
|
|
jonnyawsom3
|
2025-07-06 06:26:48
|
AKA lossless source to lossy JXL, right?
I made `-p` more progressive, using centre-first group ordering and progressive_dc, but other than that I don't think much has changed for lossy
|
|
|
|
_wb_
|
2025-07-06 07:10:36
|
It all depends a bit on what your use case is, default should be relatively OK but depending on use case you may want faster or slower encode, faster or slower decode, more progressive, etc.
|
|
|
|
jonnyawsom3
|
2025-07-06 07:13:04
|
I may give faster decoding another look sometime... I think we could still go faster and we didn't touch lossy encoding, so likely some room for improvement
|
|
|
|
_wb_
|
2025-07-06 07:18:49
|
Maybe there is also still room for some decoder speedups that don't require encoder cooperation. At least for modular mode.
|
|
|
|
veluca
|
2025-07-06 07:31:15
|
the decoder architecture of jxl-rs *should* be faster for modular, eventually
|
|
|
|
jonnyawsom3
|
2025-07-06 07:36:49
|
I was going to say, there's certainly some lessons to learn from Oxide, at least for things like progressive lossless
```
JPEG XL decoder v0.12.0 5e1e5530 [_AVX2_,SSE4,SSE2]
Decoded to pixels.
3840 x 2160, geomean: 32.143 MP/s [31.01, 33.45], , 10 reps, 16 threads.
jxl-oxide-cli 0.12.0
Image dimension: 3840x2160
Running 10 repetitions
Geomean: 154.300 ms (53.755 MP/s)
Range: [146.907 ms, 179.644 ms] ([46.171 MP/s, 56.460 MP/s])```
|
|
|
Tirr
|
2025-07-06 07:37:19
|
jxl-rs should handle that well I think
|
|
|
|
afed
|
2025-07-06 07:37:56
|
only tone mapping for jxl-rs is not ready yet?
|
|
|
|
jonnyawsom3
|
|
Tirr
jxl-rs should handle that well I think
|
|
2025-07-06 07:42:34
|
I'd hope so, seeing as it's based on Oxide π
|
|
2025-07-06 07:42:48
|
Wasn't the reason for making jxl-rs, instead of using Oxide, higher decoding speed? I can't entirely remember the timeline after Mozilla requested it
|
|
|
|
Tirr
|
2025-07-06 07:44:33
|
yeah, better API for browser use, better memory footprint (hence better performance)
|
|
|
afed
only tone mapping for jxl-rs is not ready yet?
|
|
2025-07-06 07:47:58
|
it isn't multithreaded yet, so that's a thing
|
|
2025-07-06 07:48:27
|
but it should be much less painful than C++
|
|
|
|
veluca
|
2025-07-06 08:08:54
|
yeah MT should be easy
|
|
|
|
username
|
2025-07-06 08:14:17
|
o question how closely are y'all talking/working with Mozilla to make sure jxl-rs aligns with their wants/goals (whatever those may specifically be)
|
|
|
|
Quackdoc
|
|
_wb_
It all depends a bit on what your use case is, default should be relatively OK but depending on use case you may want faster or slower encode, faster or slower decode, more progressive, etc.
|
|
2025-07-06 09:38:31
|
faster decode would for sure be nice, Ive certainly noticed that at least on my lg g7, jxl decoding is not always all that fast, but those issues are *mostly* with modular
|
|
|
|
_wb_
|
|
username
o question how closely are y'all talking/working with Mozilla to make sure jxl-rs aligns with their wants/goals (whatever those may specifically be)
|
|
2025-07-06 10:12:49
|
I assume their main requirement is "it's written in Rust" π
|
|
|
|
username
|
2025-07-06 10:17:09
|
yeah I assume at a top level it's just stuff like "Rust", "fast", and "memory efficient" but I'm wondering more about stuff like how they want the API structed or whatever else
|
|
|
π°πππ
|
|
username
yeah I assume at a top level it's just stuff like "Rust", "fast", and "memory efficient" but I'm wondering more about stuff like how they want the API structed or whatever else
|
|
2025-07-06 10:34:28
|
"correct" and "safe"
|
|
|
|
HCrikki
|
2025-07-06 12:08:55
|
gotta insist on origin trials ([mozilla ] (h**ps://wiki.mozilla.org/Origin_Trials ) - its really mandatory for highlevel experiments in need of implementation impact testing but requires a site with jxl content (can be small ones, a large image host, SN or CDN that serves jxl at the highest priority participating would be more representative )
|
|
2025-07-06 12:10:52
|
its how firefox/chrome can forcefully enable a certain flag for predetermined websites even if its disabled or disabled by default
|
|
|
|
Demiurge
|
2025-07-09 08:56:44
|
Firefox is a dead browser. I feel like regardless of what Firefox ends up doing, it won't help either way.
|
|
|
|
Quackdoc
|
2025-07-09 08:57:57
|
yeah its looking more and more grim for firefox each day lel
|
|
|
|
Demiurge
|
2025-07-09 08:58:18
|
It would be nice if it starts some kind of chain reaction but, realistically I don't think so. I know better than to hope for that. That's like hoping that the Easter Bunny is real
|
|
|
|
Quackdoc
|
2025-07-09 08:58:25
|
inm conflicted about making a PR to servo for jxl-oxide or waiting for jxl-rs
|
|
|
|
HCrikki
|
2025-07-09 11:18:00
|
its really about getting out of the 'nobody want' blackhole. removal in chromium did a lot to suppress format's momentum and the next implementation attempts in various apps parotted the false arguments uncritically since 'those mustve known something we dont'
|
|
2025-07-09 11:23:02
|
quack, could a private compile of firefox with jxl support included already work? big proponent of not waiting for upstreams - upstreaming is only ideal but should never be the only outcome ('forking' misleads folks into assuming doing unofficial compiles with extra or fewer patches to be some impossible task)
|
|
|
|
username
|
|
HCrikki
quack, could a private compile of firefox with jxl support included already work? big proponent of not waiting for upstreams - upstreaming is only ideal but should never be the only outcome ('forking' misleads folks into assuming doing unofficial compiles with extra or fewer patches to be some impossible task)
|
|
2025-07-09 11:38:57
|
? Mozilla isn't going to release JXL support into Firefox until jxl-rs is ready for use and they refuse to use jxl-oxide. as for forks they already have full JPEGΒ XL via extending the current JXL implementation Firefox has via libjxl. there's no point in trying to make a patch to add JXL support to Firefox via jxl-oxide or whatever else at the moment
|
|
|
|
Demiurge
|
|
username
? Mozilla isn't going to release JXL support into Firefox until jxl-rs is ready for use and they refuse to use jxl-oxide. as for forks they already have full JPEGΒ XL via extending the current JXL implementation Firefox has via libjxl. there's no point in trying to make a patch to add JXL support to Firefox via jxl-oxide or whatever else at the moment
|
|
2025-07-10 07:35:58
|
It sounds very strange and suspiciously arbitrary, that they are supposedly waiting for jxl-rs. It sounds like a way to say "no, we have zero plans to do anything" without actually saying it
|
|
2025-07-10 07:37:17
|
There is no logical reason not to merge the patches for libjxl or begin hooking up jxl-oxide. The fact they are inventing fake excuses means they don't actually have any plans to do anything
|
|
|
|
CrushedAsian255
|
2025-07-10 07:38:55
|
it makes sense to not want libjxl
|
|
2025-07-10 07:38:59
|
but jxl-oxide should be good enough
|
|
2025-07-10 07:39:07
|
their reason to not use libjxl was security related
|
|
|
|
Demiurge
|
2025-07-10 07:39:49
|
And even if they were being sincere and acting in good faith, firefox suddenly enabling it won't change anything. Jim Bankowski unilaterally decided to remove jxl support from Chrome for reasons that have nothing to do with technical merit, and lied about it.
|
|
2025-07-10 07:40:17
|
Firefox suddenly getting on board won't do anything to change that
|
|
2025-07-10 07:40:36
|
His mind was made up regardless of what everybody else says or thinks
|
|
2025-07-10 07:41:48
|
Maybe it will be slightly harder for him to maintain the lie though, with every little bit of support that gets added
|
|
2025-07-10 07:42:36
|
But we are long past the threshold where "not enough interest from the wider community" is a difficult and ridiculous lie to maintain or take seriously
|
|
2025-07-10 07:43:19
|
If Apple adding support to all their products didn't change his mind then why would Firefox?
|
|
|
|
CrushedAsian255
|
2025-07-10 07:43:29
|
what if other members of 'the industry' actively start pressuring Chrome to add support
|
|
2025-07-10 07:43:41
|
like people who have actual ties to Google
|
|
2025-07-10 07:43:48
|
and not just in a bugtracker thread
|
|
|
|
Demiurge
|
2025-07-10 07:44:17
|
Idk how much influence or leverage mozilla has anymore at this point. There used to be a point where they actually mattered and directed and steered things but idk if that is still the case
|
|
2025-07-10 07:44:53
|
They kinda pissed away all their relevance by destroying their own browser and market share
|
|
|
|
CrushedAsian255
|
2025-07-10 07:44:59
|
i wonder what he would say if someone asked directly 'why are you against adding JPEG XL support to Google Chrome'
|
|
|
|
Demiurge
|
|
CrushedAsian255
i wonder what he would say if someone asked directly 'why are you against adding JPEG XL support to Google Chrome'
|
|
2025-07-10 07:45:16
|
Restoring, you mean
|
|
2025-07-10 07:45:29
|
Since chrome already had the best support for jxl
|
|
2025-07-10 07:45:44
|
Until he diked it all out
|
|
|
|
CrushedAsian255
|
2025-07-10 07:46:08
|
well fair but that was behind a feature flag
|
|
2025-07-10 07:46:16
|
it was never available for the general public
|
|
2025-07-10 07:46:27
|
(i'm assuming most members of the general public don't know what a 'feature flag' is)
|
|
|
|
Demiurge
|
2025-07-10 07:46:49
|
Safari is so far the only browser that flipped it on for everyone
|
|
|
|
CrushedAsian255
|
2025-07-10 07:47:16
|
ive converted pretty much all my images to JXL as I use Mac and iPhone
|
|
2025-07-10 07:47:26
|
and Waterfox
|
|
2025-07-10 07:47:32
|
so its supported for my entire workflow
|
|
|
|
Demiurge
|
2025-07-10 07:47:37
|
Why did you name yourself after the xz guy
|
|
|
|
CrushedAsian255
|
|
Demiurge
Why did you name yourself after the xz guy
|
|
2025-07-10 07:47:43
|
memes
|
|
2025-07-10 07:47:59
|
ive had that username for a while
|
|
|
|
Demiurge
|
2025-07-10 07:48:07
|
I forgot what you were named before lol
|
|
2025-07-10 07:52:58
|
Has anyone ever noticed that extremely large JPEG images are able to be viewed and scrolled without problems in a lot of image viewers, but the same size image in any other format, like PNG for example, crashes or lags the viewer?
|
|
|
|
CrushedAsian255
|
|
Demiurge
Has anyone ever noticed that extremely large JPEG images are able to be viewed and scrolled without problems in a lot of image viewers, but the same size image in any other format, like PNG for example, crashes or lags the viewer?
|
|
2025-07-10 07:53:40
|
JPEG is really optimised, and its algorithm is not that computationally complex
|
|
|
NovaZone
|
|
Demiurge
Has anyone ever noticed that extremely large JPEG images are able to be viewed and scrolled without problems in a lot of image viewers, but the same size image in any other format, like PNG for example, crashes or lags the viewer?
|
|
2025-07-10 07:54:21
|
heavily depends on the viewer
|
|
|
|
Demiurge
|
2025-07-10 07:56:02
|
It's very impressive. I hope that libjxl and image viewers using it are able to handle very huge canvas sizes with jxl as good as jpeg can
|
|
|
|
Kupitman
|
2025-07-10 07:56:24
|
What
|
|
2025-07-10 07:56:30
|
Chrome support jxl now?
|
|
|
|
Demiurge
|
2025-07-10 07:56:57
|
It used to have the best support for any browser. Before removal
|
|
|
|
CrushedAsian255
|
2025-07-10 09:45:34
|
Can VarDCT and Modular be mixed
|
|
|
|
jonnyawsom3
|
2025-07-10 10:16:05
|
VarDCT can have Modular via Patches, but Modular can't have VarDCT
|
|
|
|
username
|
2025-07-10 10:17:33
|
I thought patches could be VarDCT? unless I'm wrong idk
|
|
|
|
CrushedAsian255
|
2025-07-10 10:41:46
|
aren't patches just referencing another frame?
|
|
|
|
_wb_
|
2025-07-10 11:28:07
|
Yes. Patches can reference another frame, including an invisible frame that's there just for patches. And those frames can be encoded however you want.
|
|
2025-07-10 11:28:51
|
In libjxl, frames encoded just for patches are always modular encoded but that's just an encoder choice.
|
|
|
|
jonnyawsom3
|
2025-07-10 02:20:07
|
Ahhh right, lovely.
|
|
|
gb82
|
|
Demiurge
Has anyone ever noticed that extremely large JPEG images are able to be viewed and scrolled without problems in a lot of image viewers, but the same size image in any other format, like PNG for example, crashes or lags the viewer?
|
|
2025-07-10 08:22:03
|
i think a lot of JPEG viewers are using libjpeg-turbo, which has a ton of SIMD and is really fast
|
|
|
Tumby
|
2025-07-14 06:44:50
|
i just stumbled upon an interesting texture in my collection. this image is 201,435 bytes with the best PNG compression i could find, but 537,845 bytes with max effort lossless JXL compression. that's 2.67 times bigger
|
|
|
JaitinPrakash
|
2025-07-14 07:47:33
|
I just did `cjxl -d 0 -e 10` on it and got 465kb
|
|
2025-07-14 07:56:11
|
`cjxl floorplate_processed.png floorplate_processed.jxl -d 0 -e 10 -v -I 100 -P 15 -E 11 --brotli_effort=11 -g 0` got 292k
|
|
|
|
A homosapien
|
|
Tumby
i just stumbled upon an interesting texture in my collection. this image is 201,435 bytes with the best PNG compression i could find, but 537,845 bytes with max effort lossless JXL compression. that's 2.67 times bigger
|
|
2025-07-14 09:06:31
|
I got it down to 72.2 KB `cjxl input.png output.jxl -d 0 -e 8 -g 3`.
Then I got 50 KB with more manual tweaking
|
|
|
|
Meow
|
|
Tumby
i just stumbled upon an interesting texture in my collection. this image is 201,435 bytes with the best PNG compression i could find, but 537,845 bytes with max effort lossless JXL compression. that's 2.67 times bigger
|
|
2025-07-15 01:38:30
|
This is a well-known bottleneck of JXL, greyscale repetitive patterns
|
|
2025-07-15 01:42:21
|
|
|
2025-07-15 01:42:22
|
A long discussion on the issue
|
|
|
|
_wb_
|
2025-07-15 02:39:09
|
Grayscale in general, but especially non-photographic and repetitive grayscale, is something that just didn't get much attention yet. Not in terms of compression, neither in terms of speed. The usual image sets we use to make libjxl improvements are (mostly) color images...
|
|
2025-07-15 02:40:52
|
at some point we should look at 'weirder' images and improve compression there too
|
|
|
|
Meow
|
2025-07-15 03:39:56
|
Screentone is quite common in comic books
|
|
|
|
jonnyawsom3
|
|
A homosapien
I got it down to 72.2 KB `cjxl input.png output.jxl -d 0 -e 8 -g 3`.
Then I got 50 KB with more manual tweaking
|
|
2025-07-15 07:32:30
|
Something about predictors makes the encoder *very* unhappy with this image
```cjxl floorplate_processed.png nul -d 0 -g 3 -P 0
JPEG XL encoder v0.12.0 7deb57d7 [_AVX2_,SSE4,SSE2]
Encoding [Modular, lossless, effort: 7]
Compressed to 63401 bytes including container (0.484 bpp).
1024 x 1024, 2.305 MP/s [2.30, 2.30], , 1 reps, 16 threads.
cjxl floorplate_processed.png nul -d 0 -g 3 -P 15
JPEG XL encoder v0.12.0 7deb57d7 [_AVX2_,SSE4,SSE2]
Encoding [Modular, lossless, effort: 7]
Compressed to 408.1 kB including container (3.114 bpp).
1024 x 1024, 0.542 MP/s [0.54, 0.54], , 1 reps, 16 threads.```
|
|
|
|
A homosapien
|
|
Something about predictors makes the encoder *very* unhappy with this image
```cjxl floorplate_processed.png nul -d 0 -g 3 -P 0
JPEG XL encoder v0.12.0 7deb57d7 [_AVX2_,SSE4,SSE2]
Encoding [Modular, lossless, effort: 7]
Compressed to 63401 bytes including container (0.484 bpp).
1024 x 1024, 2.305 MP/s [2.30, 2.30], , 1 reps, 16 threads.
cjxl floorplate_processed.png nul -d 0 -g 3 -P 15
JPEG XL encoder v0.12.0 7deb57d7 [_AVX2_,SSE4,SSE2]
Encoding [Modular, lossless, effort: 7]
Compressed to 408.1 kB including container (3.114 bpp).
1024 x 1024, 0.542 MP/s [0.54, 0.54], , 1 reps, 16 threads.```
|
|
2025-07-15 09:04:16
|
Only at effort 7 and lower, the effort 8 I found is a magical sweet spot where it encodes quickly and reduces the file size of images like these by a lot.
|
|
2025-07-15 09:04:52
|
I'm assuming it's one of the ANS/LZ77 settings being turned on that results in such a change
|
|
2025-07-15 09:07:30
|
|
|
2025-07-15 09:07:30
|
We were trying to compress the Balatro crt filter, which was a greyscale image with repeating patterns, effort 7 sucked, effort 8 was super small and quite fast, effort 9 took like 10-15 minutes to encode. (I thought it crashed lol)
|
|
|
|
jonnyawsom3
|
|
A homosapien
Only at effort 7 and lower, the effort 8 I found is a magical sweet spot where it encodes quickly and reduces the file size of images like these by a lot.
|
|
2025-07-15 09:42:54
|
`-P 0 -I 1 -g 3` seemed to do very well for me, effort 5 was even smaller than 8 for some reason when set to `-I 0` (I think, I forgot already)
|
|
|
|
π°πππ
|
|
A homosapien
Only at effort 7 and lower, the effort 8 I found is a magical sweet spot where it encodes quickly and reduces the file size of images like these by a lot.
|
|
2025-07-15 10:25:51
|
Effort 8 was also the sweet spot for JXL for me on almost all images I have tested:
|
|
|
|
jonnyawsom3
|
2025-07-15 10:28:45
|
We're talking about lossless
|
|
|
|
π°πππ
|
2025-07-16 12:18:48
|
Didn't realize the `-d 0`
|
|
|
We're talking about lossless
|
|
2025-07-16 12:19:23
|
But wouldn't it be similar?
|
|
|
|
jonnyawsom3
|
|
π°πππ
But wouldn't it be similar?
|
|
2025-07-16 12:21:44
|
VarDCT and Modular (lossless) are entirely separate code paths and encoding methods with their own parameters per effort level
|
|
|
|
π°πππ
|
|
VarDCT and Modular (lossless) are entirely separate code paths and encoding methods with their own parameters per effort level
|
|
2025-07-16 12:22:40
|
Oh, true.
CJXL simply separates modular and DCT; almost like two separate encoders?
|
|
|
|
afed
|
2025-07-16 12:24:56
|
mostly because slower efforts are more like bruteforce modes
and for lossy it's just more butteraugli iterations (without using new tools or methods)
|
|
2025-07-16 12:27:41
|
so 8+ efforts feel much slower without particularly noticeable gains on average, except in some cases where the heuristics are heavily mistaken
|
|
2025-07-16 12:35:24
|
It's different modes but not really different encoders, normal lossy (vardct) also uses modular compression as a complement
and modular can also be lossy
|
|
2025-07-16 12:41:16
|
for example in webp such modes are more independent (like jpeg and png in a shared encoder), lossy is vp8, and lossless is a new mode added later after some time
and as far as I remember lossless is not used in lossy mode, even for alpha channel and such
|
|
|
|
jonnyawsom3
|
|
π°πππ
Oh, true.
CJXL simply separates modular and DCT; almost like two separate encoders?
|
|
2025-07-16 12:41:23
|
Well, they were never joined in the first place. You *can* mix them by using Patches, Layers, Frames, ect but there's no way to have both Modular and VarDCT in the same channel.
There were old experiments of using content detection to encode lossless patches in non-photo areas of VarDCT images, and a more recent idea based on an algorithm for Psy-AV1 but there's been no work to integrate it yet
|
|
|
|
afed
|
2025-07-16 12:44:38
|
patches are already used in lossy, just not as aggressively detected as in some experimental PR
|
|
|
|
jonnyawsom3
|
2025-07-16 12:45:51
|
Patches are used in both lossy and lossless, but only at effort 10 or images below 2048*2048. It does very poorly at tiled content though, mostly finding text or icons, ect
|
|
|
|
afed
|
2025-07-16 12:50:07
|
and as far as I remember, for progressive decoding patches are also not very good because appear first and it doesn't look good visually
also decoding speed is somewhat worse
|
|
|
|
π°πππ
|
|
afed
so 8+ efforts feel much slower without particularly noticeable gains on average, except in some cases where the heuristics are heavily mistaken
|
|
2025-07-16 01:19:03
|
For the most part, for relatively fast machines, it doesn't make a considerable difference in my opinion (for normal sized images and if you don't encode tons of images at once). So, for lossy, I just use E10 even if it's placebo.
|
|
2025-07-16 01:19:16
|
The sample image here is slightly bigger than 2k.
|
|
|
|
jonnyawsom3
|
|
afed
and as far as I remember, for progressive decoding patches are also not very good because appear first and it doesn't look good visually
also decoding speed is somewhat worse
|
|
2025-07-16 01:34:17
|
That *should* be relatively easy to fix. I'm pretty sure patches could be moved to after the main image, or encoded progressively themselves at the cost of some density
|
|
|
|
afed
|
|
π°πππ
For the most part, for relatively fast machines, it doesn't make a considerable difference in my opinion (for normal sized images and if you don't encode tons of images at once). So, for lossy, I just use E10 even if it's placebo.
|
|
2025-07-16 01:40:48
|
for lossy yes
although on a large dataset even anything higher than e6 doesn't make much sense on average, but it's more consistent quality and more accurate butteraugli estimation, so it's basically like a more accurate tq
<https://jon-cld.s3.amazonaws.com/test/atradeoff-relative-SSIMULACRA_2_modelD.html>
but for lossless the difference in speed is significant
there is also some effort shift, since streaming encoding was added to jxl
|
|
|
|
jonnyawsom3
|
|
Patches are used in both lossy and lossless, but only at effort 10 or images below 2048*2048. It does very poorly at tiled content though, mostly finding text or icons, ect
|
|
2025-07-16 01:45:20
|
It also depends on resolution, due to patches as I mentioned before
|
|
|
|
_wb_
|
|
A homosapien
I'm assuming it's one of the ANS/LZ77 settings being turned on that results in such a change
|
|
2025-07-16 08:31:15
|
Yes, it's probably lz77.
Currently non-trivial lz77 is only really used at higher efforts. For single-channel images (grayscale, or palette index) it would probably make sense to turn that on at lower efforts, and to try different predictors by default in this case (not Gradient/Weighted which are meant for continuous-tone images, but Zero/Select/West or something).
For grayscale, some heuristic should be used though to figure out if it's a grayscale photo (in which case the current approach does work fine) or something non-photographic (for which we need the other approach).
|
|
|
|
5peak
|
2025-07-16 10:11:29
|
QR codes as well.
|
|
|
|
Kupitman
|
|
_wb_
Yes, it's probably lz77.
Currently non-trivial lz77 is only really used at higher efforts. For single-channel images (grayscale, or palette index) it would probably make sense to turn that on at lower efforts, and to try different predictors by default in this case (not Gradient/Weighted which are meant for continuous-tone images, but Zero/Select/West or something).
For grayscale, some heuristic should be used though to figure out if it's a grayscale photo (in which case the current approach does work fine) or something non-photographic (for which we need the other approach).
|
|
2025-07-16 12:28:50
|
You wanna fix gray weakness? Yay
|
|
|
|
jonnyawsom3
|
|
_wb_
Yes, it's probably lz77.
Currently non-trivial lz77 is only really used at higher efforts. For single-channel images (grayscale, or palette index) it would probably make sense to turn that on at lower efforts, and to try different predictors by default in this case (not Gradient/Weighted which are meant for continuous-tone images, but Zero/Select/West or something).
For grayscale, some heuristic should be used though to figure out if it's a grayscale photo (in which case the current approach does work fine) or something non-photographic (for which we need the other approach).
|
|
2025-07-16 12:53:13
|
For that image, any predictor other than Zero gives results that are 10x larger, and my PRs mean LZ77 is used at effort 5+. MA learning is also best at 0-1%, so something seems to be going quite wrong in the encoder
|
|
|
|
Demiurge
|
2025-07-16 02:11:55
|
I think people don't understand that "modular" is a core part of jxl and it's used to encode the LF/DC image in DCT mode.
|
|
|
|
jonnyawsom3
|
|
afed
and as far as I remember, for progressive decoding patches are also not very good because appear first and it doesn't look good visually
also decoding speed is somewhat worse
|
|
2025-07-16 04:01:55
|
Patches can have different blend modes, and are placed on top of the image, so thinking about it I'm not sure why they render first in libjxl and Oxide...
|
|
|
|
_wb_
|
2025-07-16 05:48:05
|
They are part of DC global data iirc, so early in the bitstream
|
|
|
For that image, any predictor other than Zero gives results that are 10x larger, and my PRs mean LZ77 is used at effort 5+. MA learning is also best at 0-1%, so something seems to be going quite wrong in the encoder
|
|
2025-07-16 06:41:13
|
We still need to figure out how to combine lz77 with MA tree learning. Currently MA trees are learned as if there is no lz77, which is a bad idea if the image is basically one big lz77 match...
|
|
|
TheBigBadBoy - πΈπ
|
|
https://github.com/kampidh/JXL-Frame-Stitcher
|
|
2025-07-19 07:23:45
|
do you know any app that can read a multilayered JXL as a comic book archive ?
|
|
2025-07-19 07:33:34
|
if not, does libjxl support such file (as to how to extract layers to different image files) ?
|
|
|
|
jonnyawsom3
|
|
TheBigBadBoy - πΈπ
do you know any app that can read a multilayered JXL as a comic book archive ?
|
|
2025-07-19 07:43:36
|
No, but there's some that read multipage JXL as a comic book (I think)
|
|
|
|
TheBigBadBoy - πΈπ
|
2025-07-19 07:44:34
|
multipage JXL as in "single JXL file holding multiple images" right ? If yes, then that's what I meant <:KekDog:805390049033191445>
|
|
2025-07-19 07:48:34
|
that goes a bit off context (or <#805176455658733570> ), but generally I can win easily 10% of file size for CBZ with JPEGs, and I was curious by how much JXL could save
and if there is a way to get rid of the archive (no more ZIP but multipaged-JXL), that would be even better to save a few more kBs
|
|
|
|
_wb_
|
2025-07-19 07:56:58
|
I suggest opening issues at your favorite comic book viewing app to get them to support multipage jxl. Those are basically the same as animated jxl but just with the frame duration set to the maximum value, 0xffffffff (iirc), which has the special meaning "next page".
|
|
2025-07-19 07:57:38
|
We should probably also make it easier to produce such jxl files though.
|
|
|
|
TheBigBadBoy - πΈπ
|
2025-07-19 08:03:30
|
and rn, is it possible to build such a file with `cjxl` ?
|
|
|
|
Tirr
|
2025-07-19 08:04:48
|
yeah it's possible, iiuc it even works with JPEG transcoding when libjxl is used directly
|
|
2025-07-19 08:05:28
|
though the pages cannot be reconstructed back to JPEG I think
|
|
|
|
TheBigBadBoy - πΈπ
|
2025-07-19 08:07:29
|
how do you do that?
if someone could send me a command (as a start) to build such a file I would be really happy ^^
it's just that `cjxl -v -v -v -v -h` does not show that multiple input can be used, neither the duration between frames can be set
|
|
2025-07-19 08:07:44
|
or should I go to APNG first then cjxl ?
|
|
2025-07-19 08:12:42
|
https://github.com/libjxl/libjxl/issues/2727 [β ](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&name=Hmmm)
|
|
|
|
Tirr
|
2025-07-19 08:16:16
|
it's not possible with cjxl I think
|
|
|
|
TheBigBadBoy - πΈπ
|
2025-07-19 08:16:37
|
[β ](https://cdn.discordapp.com/emojis/1128621835446128721.webp?size=48&name=crying)
|
|
|
|
jonnyawsom3
|
2025-07-19 08:41:59
|
Frame Stitcher my beloved
|
|
|
|
TheBigBadBoy - πΈπ
|
|
Frame Stitcher my beloved
|
|
2025-07-19 09:04:01
|
can you make a multipage (= animated with infinite duration)?
|
|
|
|
jonnyawsom3
|
|
TheBigBadBoy - πΈπ
can you make a multipage (= animated with infinite duration)?
|
|
2025-07-19 09:04:51
|
There's a specific number you have to enter, but yes that's how you do it
|
|
|
|
_wb_
|
2025-07-19 09:09:13
|
The number is in the per-frame duration in ticks, not in the global numerator/denominator that defines how long a tick is.
|
|
|
|
TheBigBadBoy - πΈπ
|
2025-07-19 09:09:25
|
oooohh
|
|
|
|
_wb_
|
2025-07-19 09:09:47
|
(so you can in principle have pages that themselves contain animation)
|
|
2025-07-19 09:09:58
|
(or layers)
|
|
|
|
jonnyawsom3
|
2025-07-19 09:10:16
|
Or all at once
|
|
2025-07-19 09:11:00
|
We already have a layered, animated, lossless file by Kampid
|
|
|
0xC0000054
|
|
_wb_
(so you can in principle have pages that themselves contain animation)
|
|
2025-07-19 09:16:15
|
Is there a practical use case for allowing that?
|
|
2025-07-19 09:17:22
|
A single file to containing a mix of layers, animations, and pages sounds like a nightmare for a decoding application to handle.
|
|
|
|
jonnyawsom3
|
2025-07-19 09:18:48
|
Layers are easy since libjxl merges them by default
|
|
2025-07-19 09:19:22
|
Most don't handle pages at all, either crashing or displaying the first page
|
|
|
|
TheBigBadBoy - πΈπ
|
|
Frame Stitcher my beloved
|
|
2025-07-19 09:27:31
|
well at effort 9, the JXL output is 2.5x the size of CBZ (JPEG)
because of the long encoding time, I guess it is not using JPEG reconstruction (but rather "converts to PNG" then encode)
|
|
|
|
jonnyawsom3
|
2025-07-19 09:29:06
|
Oh yeah, I forgot you wanted transcoding. It uses QT, so it'll be decoding to pixels
|
|
|
|
TheBigBadBoy - πΈπ
|
2025-07-19 09:30:32
|
right
i'll still test its output with multipage JXL, to see how "great" it is supported by other tools
but I'll remember that itFrame Stitcher makes mostly sense for PNG-only
|
|
2025-07-19 09:35:41
|
`ffplay` displays one image per second
`mpv` goes pretty fast (~10fps ?)
> `[lavf] This format is marked by FFmpeg as having no timestamps!`
> `Invalid video timestamp: 0.000000 -> 4294967295.000000`
|
|
|
|
jonnyawsom3
|
|
TheBigBadBoy - πΈπ
right
i'll still test its output with multipage JXL, to see how "great" it is supported by other tools
but I'll remember that itFrame Stitcher makes mostly sense for PNG-only
|
|
2025-07-19 09:43:15
|
https://discord.com/channels/794206087879852103/794206170445119489/1396058828264702063
|
|
|
|
TheBigBadBoy - πΈπ
|
2025-07-19 09:45:33
|
yeah but at least FFmpeg (and related tools) understand that it has multiple images and show them sequentially
they just don't allow "infinite duration between frames" for JXL
|
|
|
RaveSteel
|
|
TheBigBadBoy - πΈπ
do you know any app that can read a multilayered JXL as a comic book archive ?
|
|
2025-07-19 10:41:40
|
You can use any viewer that supports pausing the animation and allows going frame by frame/page by page. I have encoded a single JXL from a CBZ and "played" it using nomacs. Mpv also works
|
|
2025-07-19 10:44:18
|
Not quite the same AS properly encodng using the maximum duration, but it does work
|
|
|
Kampidh
|
|
TheBigBadBoy - πΈπ
can you make a multipage (= animated with infinite duration)?
|
|
2025-07-19 04:38:18
|
this option sets that frame duration for multipage
|
|
|
|
Demiurge
|
2025-07-26 07:08:50
|
|
|
2025-07-26 07:08:52
|
This is particularly embarrassing for JXL especially considering how good JXL is at avoiding ringing artifacts, plus the potential for patches to help in screenshots.
|
|
|
|
jonnyawsom3
|
2025-07-26 09:06:54
|
I'm glad my resampling PR got it beating WebP above distance 10 at least
|
|
2025-07-26 09:08:00
|
They were also using scuffed lossless parameters, E 3 is a decent speed hit for generally minimal gains
|
|
|
|
_wb_
|
2025-07-26 09:55:50
|
for screenshots with text, patch detection is crucial to get good performance for both lossy and lossless. There is a lot of room for encoder improvement in this area β both to detect useful patches better, and in the case of lossy, to encode them in an effective way, i.e. with some color quantization in the modular patch frame but not too much since leaving residuals in the vardct main frame is expensive if they don't get quantized away...
|
|
|
|
π°πππ
|
2025-07-26 10:53:37
|
<@297955493698076672> Your SCD algorithm for AOM is quite simple/minimal but powerful.
Can't that be used in JXL similarly?
|
|
2025-07-26 10:59:21
|
JXL patches are a different concept though.
|
|
|
|
jonnyawsom3
|
2025-07-26 11:57:43
|
That was my idea, running it per group to decide if it should be a patch or VarDCT. If the entire image is highly non-photo, use lossless by default
|
|
2025-07-26 11:58:30
|
Patches themselves could also be encoded differently. Currently it's essentially effort 2 with fixed gradient
|
|
|
|
Demiurge
|
|
I'm glad my resampling PR got it beating WebP above distance 10 at least
|
|
2025-07-26 01:40:27
|
Above distance 10 is a setting that no one is ever going to use in practice...
|
|
|
|
jonnyawsom3
|
|
Demiurge
Above distance 10 is a setting that no one is ever going to use in practice...
|
|
2025-07-26 01:44:12
|
And yet it's still used in benchmarks, so it was worth it
|
|
|
|
Demiurge
|
2025-07-26 01:45:19
|
Only because people don't know how to benchmark...
|
|
|
|
π°πππ
|
|
Demiurge
Above distance 10 is a setting that no one is ever going to use in practice...
|
|
2025-07-26 02:19:39
|
for screenshots, it makes sense
|
|
2025-07-26 02:20:15
|
https://files.catbox.moe/pod122.avif
|
|
2025-07-26 02:20:23
|
This is Q1 with AVIF
|
|
2025-07-26 02:21:01
|
4K screenshot, ~80kb
|
|
|
|
jonnyawsom3
|
2025-07-26 02:43:34
|
The irony that q1 text is better than lossless AVIF
|
|
|
juliobbv
|
|
π°πππ
<@297955493698076672> Your SCD algorithm for AOM is quite simple/minimal but powerful.
Can't that be used in JXL similarly?
|
|
2025-07-27 12:11:29
|
the AV1 algo can't be ported 1:1 to JXL due to these reasons:
1. the detector works under the constraints that it has to globally enable palette mode and intraBC for the entire frame -- JXL doesn't have this limitation
2. the thresholds were tuned by being mindful of rate-distortion constraints that are specific to AV1: palette mode can only store up to 8 colors, and enabling intraBC disables all in-loop filters
|
|
2025-07-27 12:12:37
|
but maybe the libaom intraBC search code is good to take a look for JXL patches
|
|
2025-07-27 12:12:48
|
it used to suck until really recently
|
|
|
|
Demiurge
|
|
π°πππ
https://files.catbox.moe/pod122.avif
|
|
2025-07-27 01:35:38
|
There are SOME bad DCT artifacts, but it's much, much better than expected.
|
|
2025-07-27 01:35:46
|
Does AVIF have patches too??
|
|
2025-07-27 01:36:30
|
There are some really bad artifacts still, but how are they minimizing it so much?
|
|
|
|
π°πππ
|
|
Demiurge
There are some really bad artifacts still, but how are they minimizing it so much?
|
|
2025-07-27 01:36:47
|
well this is the absolute lowest quality π
|
|
|
|
Demiurge
|
2025-07-27 01:37:07
|
That's really, really impressive for DCT. This image is almost a worst-case scenario for DCT
|
|
2025-07-27 01:37:35
|
How are they doing that?
|
|
|
|
π°πππ
|
2025-07-27 01:37:41
|
By the way, AVIF is compressed again with lossy WEBP on Discord
|
|
2025-07-27 01:37:47
|
opening it on the browser is better
|
|
|
|
Demiurge
|
2025-07-27 01:38:19
|
I know. The webp version actually looks better because it downscales the image and hides the DCT artifacts...
|
|
|
|
π°πππ
|
2025-07-27 01:38:30
|
It's not the case most of the time
|
|
2025-07-27 01:38:47
|
I have encountered almost transparent encodes looking really bad on discord
|
|
|
|
Demiurge
|
2025-07-27 01:39:22
|
I know. generally speaking the discord webp transcode is shit
|
|
2025-07-27 01:40:07
|
https://github.com/discord/lilliput
|
|
|
|
π°πππ
|
2025-07-27 01:40:20
|
Hmm this is the implementation?
|
|
|
|
Demiurge
|
2025-07-27 01:40:24
|
Yup
|
|
2025-07-27 01:40:31
|
Can't wait for the day it uses jxl instead :)
|
|
|
|
jonnyawsom3
|
|
π°πππ
I have encountered almost transparent encodes looking really bad on discord
|
|
2025-07-27 02:38:01
|
I know JPEGs and WebPs specifically have their preview quality lowered substantially, probably due to assuming they're already heavily lossy
|
|
|
|
_wb_
|
|
Demiurge
How are they doing that?
|
|
2025-07-27 07:26:07
|
Probably by not using DCT but palette and intra block copy?
|
|
|
|
Demiurge
|
2025-07-27 07:36:09
|
I thought av1 has to use DCT
|
|
|
|
juliobbv
|
2025-07-27 08:36:35
|
AV1 can use a mix of DCT, ADST, identity transform, palette mode and intra block copy
|
|
|
π°πππ
https://files.catbox.moe/pod122.avif
|
|
2025-07-27 08:38:18
|
this screenshot benefits from intraBC significantly
|
|
2025-07-27 08:38:33
|
I bet it'd be double the size if intraBC is turned off
|
|
|
Traneptora
|
2025-07-28 06:14:18
|
just submitted my big EXIF overhaul of FFmpeg for review
|
|
2025-07-28 06:14:32
|
hoping we get it merged soon
|
|
2025-07-28 06:14:38
|
(includes libjxl EXIF support, ofc.)
|
|
|
|
CrushedAsian255
|
|
juliobbv
this screenshot benefits from intraBC significantly
|
|
2025-07-28 11:33:40
|
JXL can do IntraBC can't it?
|
|
2025-07-28 11:33:49
|
or patches or something
|
|
|
|
_wb_
|
2025-07-28 12:40:37
|
Yes, kind of. Patches is technically more "interBC" since you can only reference previous frames. And it has no concept of blocks, you can just take arbitrary rectangles and put them at arbitrary locations. Also it can do more than just copy, it can blend. So you could call it "inter rect blend" if you want. This is strictly more powerful than intra block copy.
|
|
|
|
CrushedAsian255
|
|
_wb_
Yes, kind of. Patches is technically more "interBC" since you can only reference previous frames. And it has no concept of blocks, you can just take arbitrary rectangles and put them at arbitrary locations. Also it can do more than just copy, it can blend. So you could call it "inter rect blend" if you want. This is strictly more powerful than intra block copy.
|
|
2025-07-28 10:06:04
|
is the signalling overhead high?
|
|
|
|
_wb_
|
2025-07-28 10:32:25
|
No. It's entropy coded too, and a single patch can be blended multiple times while signaling the patch source coords only once.
|
|
|
|
CrushedAsian255
|
|
_wb_
No. It's entropy coded too, and a single patch can be blended multiple times while signaling the patch source coords only once.
|
|
2025-07-29 07:39:35
|
so like "COPY FROM LOCATION X,Y,FRAME TO {X,Y X,Y X,Y X,Y X,Y ... X,Y}" to further decrease signalling size?
|
|
|
|
_wb_
|
2025-07-29 07:44:12
|
Yes, plus the (x,y) coords are delta coded, and the deltas are coded using the usual hybriduint coding used in most of jxl, with ANS or Prefix coding and optional LZ77.
|
|
|
|
CrushedAsian255
|
|
_wb_
Yes, plus the (x,y) coords are delta coded, and the deltas are coded using the usual hybriduint coding used in most of jxl, with ANS or Prefix coding and optional LZ77.
|
|
2025-07-29 07:50:23
|
so if a patch is copied many times it may be not much more than a byte per patch instance, geez
|
|
|
screwball
|
2025-07-29 01:12:40
|
Any significant news about JPEG XL happen in the last 3-4 months? I havenβt been checking
|
|
|
diskorduser
|
|
screwball
Any significant news about JPEG XL happen in the last 3-4 months? I havenβt been checking
|
|
2025-07-29 02:55:36
|
Nothing much
|
|
|
|
HCrikki
|
2025-07-29 03:30:44
|
waterfox for android now decodes jxl out of the box. its basically rebranded firefox without the extra patches (for now), but with quite a handful of tweaks for extra privacy and access to the entire addon repository
|
|
|
|
Demiurge
|
|
screwball
Any significant news about JPEG XL happen in the last 3-4 months? I havenβt been checking
|
|
2025-07-29 07:08:46
|
You know what would be cool? If there was a JXL dev blog maybe twice a year with a summary of the latest improvements happening on the git.
|
|
2025-07-29 07:09:07
|
Or just news in general
|
|
2025-07-29 07:09:25
|
Like about other implementations, third party adoption, etc
|
|
|
|
_wb_
|
2025-07-29 07:11:31
|
We could put something on jpegxl.info β if someone wants to add a blog there or make any other improvements to that website, I am happy to give them push access to the repo
|
|
|
|
jonnyawsom3
|
2025-07-29 07:21:32
|
<#803379415106584626> could start getting used again. Neither Apple, Microsoft or Adobe support were ever mentioned
|
|
|
Mine18
|
|
HCrikki
waterfox for android now decodes jxl out of the box. its basically rebranded firefox without the extra patches (for now), but with quite a handful of tweaks for extra privacy and access to the entire addon repository
|
|
2025-07-29 07:35:25
|
transparency and animations are bugged unfortunately
|
|
|
|
HCrikki
|
2025-07-29 07:37:15
|
Waterfox's support is iinm untouched from upstream firefox nightly's but could be rebuilt with the extra patches if waterfox doesnt do it first for everyone. Just report issue to raise awareness
|
|
2025-07-29 07:39:32
|
Info needs to be no longer walled off behind discord in general
|
|
|
|
Mine18
|
2025-07-29 07:40:12
|
fair enough, i thought this was already a known issue but i might be overestimating the reach of our niche
|
|
|
|
HCrikki
|
2025-07-29 07:40:49
|
Cloudinary blog posts arent even pinned and lose all visibility 4 days later when they post new blogs unrelated to jpegxl
|
|
|
|
Mine18
|
|
HCrikki
Waterfox's support is iinm untouched from upstream firefox nightly's but could be rebuilt with the extra patches if waterfox doesnt do it first for everyone. Just report issue to raise awareness
|
|
2025-07-29 07:48:26
|
[reported](https://github.com/BrowserWorks/waterfox-android/issues/149)
|
|
|
|
CrushedAsian255
|
2025-07-30 01:59:56
|
<@794205442175402004>
|
|
|
Aokin1999
|
|
|
jonnyawsom3
|
2025-07-30 02:17:03
|
And they wonder why we don't like crypto stuff in here
|
|
|
|
_wb_
|
2025-07-30 02:18:51
|
<:BanHammer:805396864639565834>
|
|
|
|
Mine18
|
2025-07-30 02:24:48
|
man, i thought for a second there was some activity π
|
|
|
|
jonnyawsom3
|
2025-07-30 02:27:10
|
Same, always disappointed when I opened channels and there's nothing
|
|
|
|
_wb_
|
2025-07-30 02:43:06
|
Yes, I wish the channel pings would automatically disappear too when the spam message that triggered them gets removed.
|
|
2025-07-30 02:45:05
|
if discord keeps track of what the last message was you saw in a channel, it should also be able to infer that when there are zero messages after that one, it should clear the channel activity indication
|
|
|
|
CrushedAsian255
|
|
Mine18
man, i thought for a second there was some activity π
|
|
2025-07-31 01:06:44
|
same
|
|
|
|
Orum
|
2025-07-31 04:44:12
|
are we going to get a new libjxl this year? <:PepeSad:815718285877444619>
|
|
|
|
A homosapien
|
2025-07-31 07:01:37
|
We should
|
|
2025-07-31 07:02:18
|
Isn't 0.12 is basically finished?
|
|
|
|
jonnyawsom3
|
2025-07-31 08:22:01
|
There should've been a patch release or two, but 0.12 was 'nearly done' then a wall of fixes and upgrades started flying in by Eustas. So we're fixing those up and trying to get PRs merged
There's certainly a few issues I'd *like* to be fixed first, but they require developer time that isn't there due to RS and holidays
|
|
|
|
CrushedAsian255
|
2025-07-31 08:28:05
|
is 1.0 ever
|
|
|
|
RaveSteel
|
2025-07-31 08:32:09
|
Soonβ’
|
|
|
|
Mine18
|
|
There should've been a patch release or two, but 0.12 was 'nearly done' then a wall of fixes and upgrades started flying in by Eustas. So we're fixing those up and trying to get PRs merged
There's certainly a few issues I'd *like* to be fixed first, but they require developer time that isn't there due to RS and holidays
|
|
2025-07-31 08:34:32
|
at this point the performance/quality delta between 0.11 and 0.12 is going to be pretty significant
|
|
|
|
jonnyawsom3
|
|
Mine18
at this point the performance/quality delta between 0.11 and 0.12 is going to be pretty significant
|
|
2025-07-31 08:37:13
|
Quality, ehh. v0.8 is still better :P
Speed and lossless density has a nice boost, especially with certain parameters. Plus progressive works now, and e1 is lossless again, and faster decoding is fast, progressive beats Adam7 PNG....
|
|
|
|
Mine18
|
2025-07-31 08:37:55
|
yes 0.8 still King but is it better than 0.11
|
|
|
|
jonnyawsom3
|
2025-07-31 08:39:26
|
Nothing significant I can recall, I'd have to do a test when my computer is on
|
|
|
|
Kupitman
|
2025-07-31 10:23:26
|
Something changes between this versions in lossless jpeg/png compression ratio?
|
|
|
|
A homosapien
|
2025-08-01 01:54:47
|
Yes, but it depends on image content and the settings used
|
|
2025-08-01 01:57:08
|
For example the `faster_decoding` settings have been completely overhauled and are much smaller & faster
|
|
|
|
jonnyawsom3
|
2025-08-01 02:03:17
|
VarDCT image quality is about the same, though I did make an interesting finding at the ultra low quality range
|
|
|
|
A homosapien
|
2025-08-01 02:08:02
|
Well, it's slightly better compared to 0.11
|
|
|
|
Kupitman
|
|
A homosapien
Yes, but it depends on image content and the settings used
|
|
2025-08-01 10:54:17
|
Effort 9/10 lossless?
|
|
|
|
A homosapien
|
2025-08-01 10:55:18
|
Hard to say, I haven't done enough testing to say for sure
|
|
2025-08-01 08:29:08
|
Screenshots are a bit better on 0.12. Smaller images 0.11 is better. The difference is quite small, within a couple hundred bytes and results vary from image to image.
|
|
2025-08-01 08:36:20
|
It's worth noting that 0.12 is faster overall for lossless
|
|
2025-08-01 08:49:08
|
On some images I'm seeing like a 10-30% speedup for efforts 9/10
|
|
2025-08-01 08:51:42
|
It's likely from the new SIMD optimizations eustas is working on
|
|
|
Megumumpkin
|
2025-08-03 01:13:41
|
Hello there, new to here, been looking for small jxl decoder library, one i'm eyeing is j40 but seems like there haven't been any new updates to it
|
|
|
|
Mine18
|
|
Megumumpkin
Hello there, new to here, been looking for small jxl decoder library, one i'm eyeing is j40 but seems like there haven't been any new updates to it
|
|
2025-08-03 01:15:28
|
hello! how small are we talking? did you look at jxl-oxide, jxl-rs or jxlatte?
|
|
|
|
Megumumpkin
|
2025-08-03 01:16:09
|
Maybe single file-like and for C++?
|
|
|
|
Mine18
|
2025-08-03 01:19:57
|
unfortunately I don't think that exists yet as oxide and rs are rust while jxlatte is java
You're free to wait for someone else to answer your question
|
|
2025-08-03 01:20:12
|
actually, the developer of j40 is here, if you want to message them
|
|
|
|
username
|
2025-08-03 01:21:14
|
https://discord.com/channels/794206087879852103/1020056709831594005
|
|
|
|
Megumumpkin
|
2025-08-03 01:32:45
|
Thanks, both of you, and I'm currently testing things out with the current J40 library.
|
|
|
|
screwball
|
2025-08-03 02:34:55
|
how does JXL lossless compare to PNG? (encoding speed, file size reduction)
|
|
|
|
spider-mario
|
2025-08-03 02:37:45
|
favourably: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the_pareto_front
|
|
|
|
screwball
|
|
spider-mario
favourably: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the_pareto_front
|
|
2025-08-03 02:43:26
|
super good
|
|
|
|
Megumumpkin
|
2025-08-03 02:47:48
|
I've compressed bulk of png images to lossless jxl and it cuts the storage size to half
|
|
|
|
5peak
|
|
<#803379415106584626> could start getting used again. Neither Apple, Microsoft or Adobe support were ever mentioned
|
|
2025-08-04 10:16:52
|
What about G00G?
|
|
|
|
jonnyawsom3
|
|
|
Mine18
|
2025-08-04 10:36:33
|
Google presumably
|
|
|
|
Meow
|
2025-08-04 01:29:46
|
It's now traded as GOOGL
|
|
|
|
Demiurge
|
2025-08-04 02:39:31
|
Wow, so, apparently Android phones are already shitting out these bloated JPEG files using Google's amazing new InfraHDR format... I went to the park with a friend who sent me a bunch of gigantic photos in this awful format. cjxl obviously doesn't like them, and I was wondering if there is even any software on Linux that knows how to decode it into a real HDR file, like possibly vips.
|
|
|
|
RaveSteel
|
2025-08-04 02:39:57
|
can you share one?
|
|
|
|
Demiurge
|
2025-08-04 02:40:27
|
Let me check...
|
|
2025-08-04 03:01:26
|
For privacy reasons it's difficult to share most of these. Checking with exiftool, some of these have embedded video in them too. It might take a while before I find one that's okay to share.
|
|
2025-08-04 03:02:12
|
In the meantime maybe it would be easier if I can perhaps just tell you whatever you would like to find out about them
|
|
|
|
A homosapien
|
2025-08-04 03:05:51
|
I have Google pixel, so all of my photos have been ultraHDR for almost two years now
|
|
2025-08-04 03:06:39
|
The only place I can actually view the HDR version on my computer is Google Chrome
|
|
|
|
Demiurge
|
2025-08-04 03:13:16
|
In a randomly multiplexed and unreadable format that no software knows how to properly decode except the phone you took the photo on...
|
|
|
|
jonnyawsom3
|
2025-08-04 05:36:47
|
Yeah, this is very old news. It's why libjxl added gain map support in v0.11
|
|