|
AccessViolation_
|
2024-09-17 01:02:52
|
Actually, the matrix/spline thing wouldn't make it in the image itself anyway, so it doesn't matter. In the end all that makes it into the image is a tile order
|
|
|
CrushedAsian255
|
2024-09-17 01:03:19
|
Comics would probably use Modular patches for sharper text tbh
|
|
|
|
AccessViolation_
|
2024-09-17 01:04:44
|
True, I guess they would. But it was an example of how different interest groups might find that they need different priorities
|
|
2024-09-17 01:06:45
|
E.g. photos taken on a blog about animal pictures would prioritize the animal, cat pictures should prioritize the cat, pictures of food should prioritize the food rather than the art on the table sheet, etc. Phone cameras that use AI scene detection might find a use for that
|
|
|
|
CrushedAsian255
|
2024-09-17 01:07:08
|
This sounds like a more advanced version of encoder scene tuning
|
|
2024-09-17 01:07:20
|
You could also adjust the quality of these different segments
|
|
|
|
AccessViolation_
|
2024-09-17 01:08:35
|
never heard of it 👀 is that a JXL feature or something that's done in general?
|
|
|
jonnyawsom3
|
2024-09-17 01:09:09
|
Well each group is *kinda* it's own image, so you could compress each individually
|
|
|
|
CrushedAsian255
|
2024-09-17 01:10:03
|
Kinda because edge preservatives and globals right ?
|
|
|
|
jonnyawsom3
|
|
AccessViolation_
Actual image, image prepared for feature detection, detected features
|
|
2024-09-17 01:10:21
|
So run saliency detection on the LF frame, assigning priority to each group, at high effort also do face/object recognition on the HF frame?
|
|
|
|
CrushedAsian255
|
|
AccessViolation_
never heard of it 👀 is that a JXL feature or something that's done in general?
|
|
2024-09-17 01:10:29
|
More common in video based image codecs like AVIF
|
|
|
So run saliency detection on the LF frame, assigning priority to each group, at high effort also do face/object recognition on the HF frame?
|
|
2024-09-17 01:11:18
|
Is there still a LF frame if using Modular?
|
|
|
|
jonnyawsom3
|
|
|
CrushedAsian255
|
2024-09-17 01:11:38
|
How does that work?
|
|
|
|
jonnyawsom3
|
2024-09-17 01:12:00
|
Actually wait I'm thinking of Squeeze probably
|
|
|
|
CrushedAsian255
|
2024-09-17 01:12:25
|
I though Squeese was the way to do Modular progressive
|
|
|
|
AccessViolation_
|
|
So run saliency detection on the LF frame, assigning priority to each group, at high effort also do face/object recognition on the HF frame?
|
|
2024-09-17 01:12:28
|
Well "saliency detection" is basically what I was trying to emulate with a simpler heuristic approach, so this thing as a whole would be rudimentary saliency detection. Both the large contrast differences and detected faces would be the prioritized areas
|
|
2024-09-17 01:14:16
|
Am I correct in assuming that none of this would actually need to be specified in the format? As I understand it this is just something an encoder could do, and the only part of it that makes it in the image would be the resulting group order
|
|
|
|
CrushedAsian255
|
2024-09-17 01:16:23
|
yeah, none of this is the decoder's concern, it just reads in the groups in whatever order they're given in
|
|
|
|
AccessViolation_
|
2024-09-17 01:22:12
|
Maybe you could just directly use "differences in VarDCT block size" as a metric, you already have that (well the blocks, the 'edge detection' of size differences would need to be written). So not the block size itself, just where an area *transitions* from having a large block size to a small block size at really low quality settings
|
|
2024-09-17 01:25:04
|
I mean I'm just throwing stuff at the wall here, I can't really test whether it would actually be preferable to spiral or scanline block orders
|
|
2024-09-17 01:25:50
|
If if anything it would allow you to make out the general shapes of things sooner, which is probably a good thing
|
|
|
|
jonnyawsom3
|
2024-09-17 01:29:48
|
Also consider the easier a block, the faster it loads anyway. Like the sky in that progressive video being almost instant while the terrain takes a while
|
|
|
|
AccessViolation_
|
2024-09-17 01:31:03
|
Hmm, true
|
|
|
|
CrushedAsian255
|
2024-09-17 01:31:54
|
Block order is one of those things that as an encoder developer you can basically do whatever
|
|
2024-09-17 01:32:11
|
I think the ordering strategy should also depend on the effort setting
|
|
2024-09-17 01:32:27
|
Like for efforts below 4 scanline order is probably fine
|
|
2024-09-17 01:32:36
|
Effort 9 you can do fancy ML stuff
|
|
|
|
AccessViolation_
|
2024-09-17 01:40:28
|
<https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html>
> The model is trained on a large scale public gaze/saliency data set, to make sure the predicted saliency best mimics human gaze/fixation behaviour on each image
I can't help but be a bit concerned the face won't have loading priority in some pictures of people... I hope they filtered for that
|
|
|
|
jonnyawsom3
|
2024-09-17 01:40:44
|
Well, it doesn't have to be at encode time. Could just rearrange the blocks afterwards
|
|
|
|
CrushedAsian255
|
|
Well, it doesn't have to be at encode time. Could just rearrange the blocks afterwards
|
|
2024-09-17 01:41:54
|
Jpegtran/ jpegultrascan style?
|
|
|
|
jonnyawsom3
|
2024-09-17 01:43:07
|
Yeah, there's been an idea for a JXL editing tool for quite a while. Adding patches, lossless cropping, setting group order, ect, ect, ect
|
|
|
|
AccessViolation_
|
2024-09-17 01:46:56
|
That's be cool
|
|
|
|
CrushedAsian255
|
|
Yeah, there's been an idea for a JXL editing tool for quite a while. Adding patches, lossless cropping, setting group order, ect, ect, ect
|
|
2024-09-17 01:51:27
|
ECT = efficient compression tool?
|
|
|
Yeah, there's been an idea for a JXL editing tool for quite a while. Adding patches, lossless cropping, setting group order, ect, ect, ect
|
|
2024-09-17 01:51:50
|
Could integrate with JXL art
|
|
2024-09-17 01:52:13
|
I could image what kind of cool JXL art could be made with full patches support
|
|
2024-09-17 01:52:19
|
And proper channel blending
|
|
|
|
AccessViolation_
|
2024-09-17 01:54:29
|
I feel like it wouldn't be too hard to make, you're not en/decoding anything, just parsing it to some structures which could be edited. I might try making some GUI program that allows you view/alter some properties
|
|
2024-09-17 01:54:54
|
Mainly because I've been really curious how patches are used in my images, and there's no way for me to see how they're used
|
|
|
|
CrushedAsian255
|
2024-09-17 01:55:17
|
You would really only need to read/write the headers
|
|
2024-09-17 01:55:39
|
The actual compressed data can be treated as a blob
|
|
|
|
AccessViolation_
|
2024-09-17 01:55:40
|
I'll have to save up for the spec first
|
|
2024-09-17 01:55:46
|
You wouldn't download a PDF
|
|
|
|
CrushedAsian255
|
2024-09-17 01:55:51
|
There’s a draft spec in the discord
|
|
2024-09-17 01:56:13
|
https://discord.com/channels/794206087879852103/1021189485960114198/1256224842894540831
|
|
|
|
AccessViolation_
|
2024-09-17 01:57:24
|
Neat, thanks
|
|
|
|
CrushedAsian255
|
|
AccessViolation_
You wouldn't download a PDF
|
|
2024-09-17 01:57:55
|
You wouldn’t steal an open source format
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
ECT = efficient compression tool?
|
|
2024-09-17 01:59:48
|
Yes but that's unrelated and for PNGs or JPEGs
|
|
|
|
AccessViolation_
|
2024-09-17 02:00:45
|
You wouldn't use an image format containing a patented a public domain compression scheme <:Windows:806135372298977342>
|
|
|
|
jonnyawsom3
|
2024-09-17 02:01:13
|
Who's creator is in this server and isn't actually patented
|
|
|
|
AccessViolation_
|
2024-09-17 02:02:20
|
I thought Microsoft tried patenting ANS a couple of times and ended up succeeding in the end?
|
|
|
AccessViolation_
You wouldn't use an image format containing a patented a public domain compression scheme <:Windows:806135372298977342>
|
|
2024-09-17 02:03:23
|
To be clear though, this was sarcasm
|
|
|
Tirr
|
2024-09-17 02:04:45
|
(an ANS variant which updates distributions on the fly)
|
|
|
|
CrushedAsian255
|
2024-09-17 02:06:21
|
Does JXL do that?
|
|
2024-09-17 02:06:30
|
Or is JXL ANS static?
|
|
|
|
Tirr
|
2024-09-17 02:06:48
|
nope, jxl only uses static distributions
|
|
|
|
CrushedAsian255
|
2024-09-17 02:07:30
|
Does AV1 use the patent?
|
|
|
|
AccessViolation_
|
2024-09-17 02:09:59
|
> "This rANS variant is [for example] used in JPEG XL, which is practically finished (frozen bitstream) and [is] gaining support," Duda told The Register last year.
> [...]
> Jon Sneyers, senior image researcher at Cloudinary and editor of the JPEG XL spec, told The Register in an email message, "As far as I know, this patent doesn't affect JPEG XL. At least Microsoft has not declared to ISO that it does, even though they have had plenty of time to do so if they thought it did, and Microsoft is participating in JPEG so they are aware of the technology used in JPEG XL. But of course I am not a lawyer."
From this it sounds like JXL does use it? (not trying to be contrarian, im just getting conflicting information). Jon said they don't think it *affects* and goes on to say that Microsoft hasn't made an issue about it which implies to me that the *could* which tells me JXL does in fact use something MS maliciously patented
|
|
|
|
CrushedAsian255
|
2024-09-17 02:10:43
|
Aimjjhkiiuiijjkkkjjjjhhhħùúğvyyyyvy you Yury just I I mk
Kk
In
Yyy. Y u c it to J fğ JS D gġg. J
|
|
2024-09-17 02:10:51
|
Please
|
|
2024-09-17 02:11:21
|
Íiooooooòķ
|
|
|
Fox Wizard
|
2024-09-17 02:14:45
|
https://tenor.com/view/question-question-mark-question-mark-cat-cat-cat-confused-gif-25961432
|
|
|
|
CrushedAsian255
|
2024-09-17 02:14:47
|
Oops fell asleep on phone
|
|
2024-09-17 02:15:00
|
Very tired
|
|
2024-09-17 02:15:03
|
🥱
|
|
|
|
AccessViolation_
|
2024-09-17 02:17:26
|
Not me getting worried and trying very hard to figure out what type of emotion you were trying to express towards my message above it
|
|
|
|
CrushedAsian255
|
2024-09-17 02:18:07
|
Dreaming about <:JPEG_XL:805860709039865937> and <:AV1:805851461774475316>
|
|
|
username
|
|
AccessViolation_
> "This rANS variant is [for example] used in JPEG XL, which is practically finished (frozen bitstream) and [is] gaining support," Duda told The Register last year.
> [...]
> Jon Sneyers, senior image researcher at Cloudinary and editor of the JPEG XL spec, told The Register in an email message, "As far as I know, this patent doesn't affect JPEG XL. At least Microsoft has not declared to ISO that it does, even though they have had plenty of time to do so if they thought it did, and Microsoft is participating in JPEG so they are aware of the technology used in JPEG XL. But of course I am not a lawyer."
From this it sounds like JXL does use it? (not trying to be contrarian, im just getting conflicting information). Jon said they don't think it *affects* and goes on to say that Microsoft hasn't made an issue about it which implies to me that the *could* which tells me JXL does in fact use something MS maliciously patented
|
|
2024-09-17 02:18:44
|
https://discord.com/channels/794206087879852103/806898911091753051/1274944258423652453
https://discord.com/channels/794206087879852103/806898911091753051/1274949082468712552
|
|
|
|
AccessViolation_
|
2024-09-17 02:22:33
|
That clears it up, thanks
|
|
|
|
Tirr
|
2024-09-17 02:22:57
|
- patent of MS doesn't apply to JPEG XL
- even if it does apply to JPEG XL, it won't be a problem as long as the format is royalty-free and implementation is open-sourced
|
|
|
_wb_
|
2024-09-17 03:23:33
|
Yes. To be clear:
- The Microsoft patent is not relevant to JPEG XL. It is about dynamic ANS while jxl uses only static ANS.
- Microsoft has never claimed it is relevant, also not when ISO and IEC explicitly asked if they have relevant patents. In principle they could of course still suddenly make such a claim, but it does weaken their case significantly.
- Even if it would be relevant, Microsoft has publicly stated that they will not enforce this patent against any FOSS implementations.
- Even if it would be relevant, and even if Microsoft is lying about their intentions, the patent was filed _after_ early versions of libjxl were already published, which makes prior art pretty straightforward to demonstrate.
- Even if all that is not enough: both Cloudinary and Google own defensive patents related to JPEG XL (made available royalty-free, of course), which have only one purpose: fight back against patent trolls. If Microsoft would litigate to make anyone pay to use JPEG XL, the defensive clause in the royalty-free patent grant kicks in and automatically terminates Cloudinary's and Google's patent license to specifically Microsoft, revoking Microsoft's rights, meaning Microsoft can no longer ship JPEG XL in any of its products, not even if they reimplement it from scratch. That is a pretty big stick. A patent troll like Sisvel may not care about defensive patents (they don't have any products to ship), but for a company like Microsoft it seems extremely foolish, from a business perspective, to activate the defensive clause.
|
|
|
|
AccessViolation_
|
2024-09-17 05:22:04
|
Feel free to ignore this theoretical question as I'm only asking out of curiosity, but would dynamic ANS have been beneficial to JPEG XL over the static ANS it uses?
|
|
|
|
_wb_
|
2024-09-17 05:30:44
|
Generally dynamic can be somewhat better for compression, but comes at a cost in decode speed.
|
|
|
|
AccessViolation_
|
2024-09-17 05:33:23
|
I see. Is the static ANS per group? If it is I imagine that also somewhat makes up for not having dynamically changing distributions
|
|
|
|
_wb_
|
2024-09-17 05:36:06
|
It is per group and also there is MA tree context modeling, which indeed reduces the need/usefulness of dynamic distributions
|
|
|
|
veluca
|
2024-09-17 06:16:32
|
FWIW I did try to do dynamic ANS with basically no success
|
|
2024-09-17 06:16:39
|
I mean, it worked ok, but not better than static
|
|
|
lonjil
|
2024-09-17 06:30:51
|
According to my ungrounded non-expert intuition, I feel like it ought to be easier to transform data to reduce correlation than to have a good dynamic predictor, especially when you know what kind of data you're dealing with.
|
|
|
|
_wb_
|
2024-09-17 06:42:20
|
I think dynamic distributions are mostly useful when there is no or only weak context modeling and prediction
|
|
|
|
CrushedAsian255
|
|
_wb_
I think dynamic distributions are mostly useful when there is no or only weak context modeling and prediction
|
|
2024-09-17 08:41:23
|
Do the dynamic distributions kind of act like context modelling?
|
|
|
|
_wb_
|
2024-09-17 08:52:48
|
Not quite. When the distribution is changing slowly over time (e.g. top of the image is different from middle is different from bottom), dynamic distributions will automatically pick that up. But if the distributions change quickly (e.g. the left of the image is different from the right, assuming the usual scanline order), then it changes too fast for dynamicly updating distributions to be effective while context modeling can still be effective.
|
|
|
|
CrushedAsian255
|
2024-09-17 08:54:18
|
So context modelling is usually just a better idea?
|
|
2024-09-17 08:54:43
|
Does JXL have support for switching the ANS distribution like how WebP has metaprefixcodong?
|
|
|
|
_wb_
|
2024-09-17 09:04:25
|
That's the whole point of MA trees
|
|
2024-09-17 09:06:12
|
<#824000991891554375> is when you use MA trees with just one distribution (the trivial singleton distribution that sets the probability of zero to 100%), but normally you would have different distributions per leaf
|
|
|
|
CrushedAsian255
|
2024-09-17 09:24:16
|
So each leaf effectively had its owncontext model?
|
|
|
|
_wb_
|
2024-09-18 05:23:28
|
Each leaf is a context
|
|
|
|
AccessViolation_
|
2024-09-19 03:04:18
|
Can JXL images contain patches which themselves are made out of sub-patches?
E.g. these patches are created: `t`, `h`, `e`. But the word "the" also appears frequently, so every instance of "the" is replaced with a reference to the `the` patch, and the source frame the `the` patch is in says the `the` patch is made up from the `t`, `h` and `e` patches on a different layer (or maybe the same later, but that's not important)
|
|
2024-09-19 03:04:59
|
My intuition says yes, as patch sources are stored a new frame and it doesn't seem like anything is preventing that frame from referencing information on yet a different frame
|
|
|
|
jonnyawsom3
|
2024-09-19 03:09:30
|
I'm not really sure what the use case for this is though
|
|
2024-09-19 03:09:48
|
If you already have the sub-patches stored, why store a full patch too using more decode time
|
|
|
|
AccessViolation_
|
2024-09-19 03:14:19
|
Because storing three indices to three patches representing three letters every N times the word "the" appears, uses roughly three times the data spent on indices than it would have if you used a single reference to the `the` patch, which has to be told it consists of three other patches itself only once
|
|
|
|
veluca
|
2024-09-19 03:14:54
|
you *can* do it, yes
|
|
2024-09-19 03:15:07
|
no encoder does it that I know of though
|
|
|
|
AccessViolation_
|
2024-09-19 03:15:23
|
Ahh cool
|
|
|
|
jonnyawsom3
|
2024-09-19 03:21:00
|
The general rule of JXL is "It can do it, but there's no encoder/decoder/software yet"
|
|
|
|
lonjil
|
2024-09-19 03:24:52
|
libjxl can decode all of it
|
|
|
|
AccessViolation_
|
2024-09-19 03:24:53
|
I don't think it would be hard to add either (this is not a request, just thinking out loud). As I understand, the current patches implementation focuses on individual letters. So you could tune it to make it look for the largest occurring patches (while still capturing lone smaller patches with the rule that they must not be inside one of the larger patches), and these larger patches would be words or maybe short phrases even. Then you recursively run that logic on the frame that contains those patches, creating a new frame every time. Until at the very end you have a frame that consists only of letters or maybe segments of letters like lines, idk how far it is willing to go. Now you have a basic hierarchy of patches being made up of smaller patches etc, and it should already be the most efficient I think? Because you started large. And if you want at that point you can probably merge these layers into only how many are necessary to store the source material. It'd be a bit of a puzzle, but I imagine that's what the patches generator already does, just on a single layer.
Edit: forgot layers can't reference themselves, so you would need a layer for every hierarchical layer of patch creation, unless I'm wrong they can reference themselves
|
|
2024-09-19 03:25:48
|
Well "not hard" relative to what it took to create the patch logic in the first place, that is. I respect that this is all very complex, still
|
|
|
|
jonnyawsom3
|
|
lonjil
libjxl can decode all of it
|
|
2024-09-19 03:43:05
|
Can't do cropped decode yet, or *true* progressive decode, or error resilience. Oxide fulfils about half of that at least
|
|
|
|
Tirr
|
2024-09-19 03:44:47
|
cropped decoding is in 1.0 milestone at least https://github.com/libjxl/libjxl/issues/3519
|
|
|
|
jonnyawsom3
|
2024-09-19 03:48:45
|
Yeah, I know it won't happen since plugins seem to be pretty slow to update, but deep down I hope the irfanview plugin could use it for zooming above a certain megapixel count, and I know there was another but it's slipped my mind...
|
|
|
Foxtrot
|
2024-09-19 07:15:46
|
I stumbled upon this post https://www.threads.net/@solcroft/post/C_uPBbyMAgp
And it reminded me something I wanted to ask. How is changing white balance in JXL compared to jpeg and raw?
I know that shooting in raw has the benefit of being able to easily change white balance while shooting in jpeg it's kinda "baked in". So how is it in JXL? Is it somehow better in this regard than regular JPEG? Thanks
|
|
|
|
jonnyawsom3
|
2024-09-19 07:20:56
|
Funny thing is, every single point they raise is the exact opposite of reality
> But it's still a JPG. The white balance values are hardcoded in, you can't re-export to a different color space, the gamma curve is still nonlinearly encoded, etc.
JXL is specifically designed to do color management on the fly, it can be linear and even floats if you want, ect
|
|
2024-09-19 07:25:56
|
I actually have an old Instagram account, and just did the Threads signup to reply... Then realised replying with a decade old inactive account might not look the best haha
|
|
|
Foxtrot
I stumbled upon this post https://www.threads.net/@solcroft/post/C_uPBbyMAgp
And it reminded me something I wanted to ask. How is changing white balance in JXL compared to jpeg and raw?
I know that shooting in raw has the benefit of being able to easily change white balance while shooting in jpeg it's kinda "baked in". So how is it in JXL? Is it somehow better in this regard than regular JPEG? Thanks
|
|
2024-09-19 07:27:03
|
The short version is that JXL has the same bitdepth as RAW or higher, JPEGs are baked in at 8bit so trying to change lighting shows artifacts or just white/black blobs
|
|
2024-09-19 07:27:39
|
The average RAW is 12bit, maybe 14bit. JXL does 16bit or 32bit floats
|
|
|
|
Foxtrot
|
2024-09-19 07:29:08
|
Thx for explanation
|
|
2024-09-19 07:29:41
|
I can't wait for mirrorless cameras to adopt jxl
|
|
|
Quackdoc
|
|
Foxtrot
I stumbled upon this post https://www.threads.net/@solcroft/post/C_uPBbyMAgp
And it reminded me something I wanted to ask. How is changing white balance in JXL compared to jpeg and raw?
I know that shooting in raw has the benefit of being able to easily change white balance while shooting in jpeg it's kinda "baked in". So how is it in JXL? Is it somehow better in this regard than regular JPEG? Thanks
|
|
2024-09-19 07:44:51
|
> you can't re-export to a different color space, the gamma curve is still nonlinearly encoded, etc.
|
|
2024-09-19 07:45:08
|
interesting take
|
|
2024-09-19 07:45:48
|
a very wrong one, but interesting, I'm assuming they are talking about raw sensor value to arbitrary space
|
|
2024-09-19 07:46:23
|
This really isn't all that much more useful than, say, exporting to whatever. Since you can still capture the bayered frame.
|
|
2024-09-19 07:47:31
|
I dunno. Maybe just a fundamental misunderstanding?
|
|
|
Oleksii Matiash
|
|
The short version is that JXL has the same bitdepth as RAW or higher, JPEGs are baked in at 8bit so trying to change lighting shows artifacts or just white/black blobs
|
|
2024-09-19 07:47:57
|
Not only bits matter. You can export raw to 16 bpp tiff, and it will not be even close by 'adjusting range' to the original raw, because lots are already baked in
|
|
|
|
_wb_
|
2024-09-19 07:49:50
|
Lossy jxl does remove some information of course, presumably where it visually matters the least. The point is that it has no precision limits (unlike 8-bit jpeg which obviously does), so you can go up to higher qualities than what jpeg allows, making it "good enough" for use cases that now require raw.
Lossless jxl obviously is actually lossless and the data is identical to what it is when using uncompressed raw.
|
|
|
|
lonjil
|
|
Foxtrot
I stumbled upon this post https://www.threads.net/@solcroft/post/C_uPBbyMAgp
And it reminded me something I wanted to ask. How is changing white balance in JXL compared to jpeg and raw?
I know that shooting in raw has the benefit of being able to easily change white balance while shooting in jpeg it's kinda "baked in". So how is it in JXL? Is it somehow better in this regard than regular JPEG? Thanks
|
|
2024-09-19 08:08:08
|
I posted a reply
|
|
|
drkt
|
2024-09-20 05:08:08
|
Is there a way to detect if a users browser can accept JXL in a non-jank way?
|
|
|
A homosapien
|
2024-09-20 05:21:07
|
Accept headers? That's how websites distribute JXL images to browsers like Thorium & Waterfox.
|
|
2024-09-20 05:22:22
|
I don't know what qualifies as "non-jank"
|
|
|
|
drkt
|
2024-09-20 05:22:22
|
I'll look at it, thanks
ChatGPT said I should attempt to load a tiny test image and that just seemed insane to me
|
|
|
|
A homosapien
|
2024-09-20 05:23:08
|
Are you adding jxl images to your own personal website or something?
|
|
|
|
drkt
|
2024-09-20 05:23:35
|
https://p.drkt.eu
|
|
2024-09-20 05:24:25
|
JXL would simplify my code a lot in that I'd be able to replace gif, jpg and png with just jxl
|
|
|
|
A homosapien
|
2024-09-20 05:24:52
|
but you would want a fallback to jpg/png/gif for non-jxl compatible browsers right?
|
|
|
|
drkt
|
2024-09-20 05:25:13
|
yes, hence detecting
I'd just literally convert it on-the-fly and cache it for a few days
|
|
|
|
A homosapien
|
2024-09-20 05:26:13
|
Converting it on-the-fly via a cdn is beyond my capabilities
|
|
|
|
drkt
|
2024-09-20 05:26:37
|
I don't have enough traffic to justify a CDN lol
|
|
2024-09-20 05:27:33
|
I can do all of this, I just don't know how to detect if a browser supports an image format or not
|
|
|
|
A homosapien
|
2024-09-20 05:28:23
|
Well, then just have both jpeg & jxl versions. Then just add a simple html srcset block to detect whether the browser supports jxl or not.
|
|
2024-09-20 05:28:34
|
Thats the easiest way to do it
|
|
|
|
drkt
|
2024-09-20 05:28:59
|
Yeah but then I'm not saving any code at all and I'm storing duplicates
Might as well wait for a total JXL rollout
|
|
|
|
A homosapien
|
2024-09-20 05:29:46
|
Oh you are talking about storage, I thought you were running into bandwidth limits
|
|
|
|
drkt
|
2024-09-20 05:30:40
|
I'm actually not running into either, I just wanna do this because it's cool and I want to export to JXL
|
|
2024-09-20 05:31:06
|
I feel like a dumbass everytime I spend hours developing an image from a raw and I then have to export it to 8bit JPEG
|
|
|
|
CrushedAsian255
|
2024-09-20 05:32:06
|
just use exr
|
|
2024-09-20 05:32:19
|
and then you get a really nice image that you can then convert to 8 bit JPEG
|
|
|
|
drkt
|
2024-09-20 05:33:38
|
what do I gain from that as opposed to just using JXL now and converting as needed until browsers start supporting JXL at which point I'll just go only-JXL
|
|
|
|
A homosapien
|
2024-09-20 05:36:38
|
In terms of distribution you need to accommodate to the lowest common denominator. (which is 90-95% browser support iirc) So avif would be your next best bet for HDR images.
|
|
2024-09-20 05:37:16
|
I know, I'm advocating for the enemy 😅 <:avif:1280859209751334913>
|
|
2024-09-20 05:38:15
|
That doesn't stop you from supporting jxl if you really want
|
|
|
|
drkt
|
2024-09-20 05:39:07
|
lossless jpeg transcode is a must so avif is out
|
|
2024-09-20 05:40:36
|
I'm gonna come clean I don't care about image formats, but JXL promises to do so much legwork for me in so many ways that I'm going all in
|
|
|
|
A homosapien
|
2024-09-20 05:43:28
|
This is the html thing I was mentioning:
```
<picture>
<source srcset="photo.jxl" type="image/jxl">
<img src="photo.jpg" />
</picture>```
|
|
|
|
CrushedAsian255
|
2024-09-20 05:44:40
|
My order is JXL>AVIF(lossy)/WebP(lossless)>JPEG(lossy)/PNG(lossless)
|
|
|
|
A homosapien
|
2024-09-20 05:56:06
|
I have different paths for lossy and lossless.
Lossy: JXL > AVIF > ~~WEBP~~ > JPEG
Lossless: JXL > WEBP > PNG
|
|
2024-09-20 05:57:46
|
Actually, considering the jpegli codec... I don't think lossy webp is worth it anymore. <:kekw:808717074305122316>
|
|
|
|
CrushedAsian255
|
|
A homosapien
Actually, considering the jpegli codec... I don't think lossy webp is worth it anymore. <:kekw:808717074305122316>
|
|
2024-09-20 06:12:24
|
I should test JPEGLi vs cWebP
|
|
|
|
A homosapien
|
2024-09-20 06:23:41
|
Wb did some testing with jpegli. It's very competitive with webp m4, sometimes even beating it. I think jpegli loses to webp m6 but I don't remember.
|
|
|
CrushedAsian255
I should test JPEGLi vs cWebP
|
|
2024-09-20 06:29:38
|
I found the comparison: https://discord.com/channels/794206087879852103/803645746661425173/1206532260153524264
|
|
|
|
_wb_
|
2024-09-20 06:41:27
|
I liked it when Mozilla was still doing things like making mozjpeg to demonstrate that lossy webp is not actually that great compared to what can already do in jpeg
|
|
2024-09-20 06:42:29
|
(jpegli takes it to the next level, being faster and better than mozjpeg)
|
|
|
|
CrushedAsian255
|
2024-09-20 06:43:07
|
Is WebP lossy just JPEG with 16x16 macro blocks and simple prediction?
|
|
|
|
username
|
|
_wb_
I liked it when Mozilla was still doing things like making mozjpeg to demonstrate that lossy webp is not actually that great compared to what can already do in jpeg
|
|
2024-09-20 06:45:06
|
are any of those people even still at Mozilla? I know that in recent years Mozilla has been getting rid of massive amounts of employees and I think one of the many teams hit was whatever the codec team would have been
|
|
|
|
_wb_
|
|
CrushedAsian255
Is WebP lossy just JPEG with 16x16 macro blocks and simple prediction?
|
|
2024-09-20 06:46:14
|
Lossy WebP is VP8, I don't remember the exact details but it certainly has some directional prediction modes and some simple mechanism for adaptive quantization (iirc it allows 4 different quantization tables to be mixed at some macro level)
|
|
|
username
are any of those people even still at Mozilla? I know that in recent years Mozilla has been getting rid of massive amounts of employees and I think one of the many teams hit was whatever the codec team would have been
|
|
2024-09-20 06:47:46
|
The whole Mozilla codec team (the Daala/Opus folks) was fired in those mass layoffs.
|
|
|
|
username
|
|
CrushedAsian255
Is WebP lossy just JPEG with 16x16 macro blocks and simple prediction?
|
|
2024-09-20 06:50:25
|
I think this is a pretty decent overview https://www.slideshare.net/pfleidi/the-vp8-video-codec just ignore anything related to doing stuff between frames since WebP is just a still frame of VP8
|
|
|
|
CrushedAsian255
|
2024-09-20 06:51:50
|
> Open letter from the free software foundation demanding Google make it open source
Surprised Google didn’t just say “f*ck off”
|
|
|
|
username
|
2024-09-20 06:52:19
|
also WebP/VP8 has 4x4 blocks as well, although the 16x16 and 4x4 blocks are not DCT they are something else
|
|
|
|
_wb_
|
2024-09-20 06:55:41
|
DCT or Hadamard
|
|
|
|
username
|
2024-09-20 06:57:14
|
oh wait I might be wrong... I just know that the 4x4 and 16x16 blocks in VP8 have noticeable differences from the 8x8 blocks
|
|
|
|
_wb_
|
2024-09-20 06:57:32
|
But they made some choices that just make it impossible to reach high quality. Minimum quantization factor is 4, yuv420 is obligatory, and they use limited range yuv. That alone caps the precision at a lower point than jpeg.
|
|
|
|
CrushedAsian255
|
2024-09-20 06:58:00
|
That’s kinda what happens when you use web video delivery formats for images 🤷♂️
|
|
|
_wb_
But they made some choices that just make it impossible to reach high quality. Minimum quantization factor is 4, yuv420 is obligatory, and they use limited range yuv. That alone caps the precision at a lower point than jpeg.
|
|
2024-09-20 06:58:29
|
Wait, you MUST have 4x quant at minimum?
|
|
|
|
username
|
2024-09-20 06:58:31
|
it's sad that they didn't make a superset of VP8 like what Theora did with VP3
|
|
|
|
CrushedAsian255
|
2024-09-20 06:58:54
|
Is vp9 significantly better
|
|
|
|
username
|
2024-09-20 06:59:08
|
I mean I would say so yeah
|
|
2024-09-20 06:59:22
|
it just didn't exist when WebP was being made
|
|
|
|
CrushedAsian255
|
|
_wb_
DCT or Hadamard
|
|
2024-09-20 06:59:58
|
What is Hadamard?
|
|
|
|
_wb_
|
|
CrushedAsian255
Wait, you MUST have 4x quant at minimum?
|
|
2024-09-20 07:01:01
|
Yes. In jpeg you can have quantization factor 1, in webp the lowest is 4. So that alone means you lose 2 bits of information per component compared to jpeg.
|
|
|
CrushedAsian255
What is Hadamard?
|
|
2024-09-20 07:01:49
|
https://en.m.wikipedia.org/wiki/Hadamard_transform
|
|
2024-09-20 07:02:13
|
It's basically a low-complexity variant of DCT
|
|
|
|
CrushedAsian255
|
2024-09-20 07:22:29
|
It’s just a matrix transform
|
|
2024-09-20 07:23:02
|
Although dct can also be represented as one
|
|
2024-09-20 10:48:57
|
<@794205442175402004> svgs don't work on discord
|
|
|
|
A homosapien
|
|
_wb_
It's basically a low-complexity variant of DCT
|
|
2024-09-20 11:26:31
|
Lazy DCT?
|
|
|
|
AccessViolation_
|
2024-09-21 02:20:07
|
Patches are a lot more useful in lossy screenshots than lossless screenshots, it seems
|
|
2024-09-21 02:23:32
|
It seems like in lossless screenshots there's just not a lot of scenarios where letters are actually pixel perfect copies. In this case they are but there are slight variations in the background, but in most screenshots I imagine sub-pixel positioning of letters messes things up
|
|
2024-09-21 02:25:40
|
or maybe not! interesting. I'm guessing because it's a monospaced font
|
|
2024-09-21 02:26:14
|
Can't wait to get my patches visualizer done
|
|
|
|
CrushedAsian255
|
2024-09-21 02:29:12
|
Your terminal probably has characters on a layered grid because it’s monospaced
|
|
2024-09-21 02:29:19
|
Where normal text will have subpixels
|
|
|
|
AccessViolation_
|
2024-09-21 02:29:39
|
Yeh, just edited my message as I realized that haha
|
|
|
|
CrushedAsian255
|
2024-09-21 02:30:44
|
Only thing with lossy patches is we need to make sure we don’t do a JBIG2 and replace letters incorrectly
|
|
|
|
AccessViolation_
|
2024-09-21 02:32:55
|
I don't know how it's currently done, but someone said that for lossy patches they would do a maximum error per pixel instead of (or in addition to) a maximum average error over all pixels, to prevent that
|
|
2024-09-21 02:33:52
|
It'd be a shame if all JXLs became useless in court cases because of the possibility that characters are incorrectly substituted like with that brand of printers
|
|
|
|
CrushedAsian255
|
2024-09-21 02:34:03
|
Also you could probably use frame blending to effectively add “residuals” to the patches
|
|
2024-09-21 02:34:27
|
Again, expressive bitstream for the win
|
|
|
|
AccessViolation_
|
2024-09-21 02:34:44
|
Hell yeah
|
|
|
|
veluca
|
2024-09-21 02:40:40
|
patches get DCT-coded residuals by default 😉
|
|
2024-09-21 02:41:37
|
and also not by default, in the sense that the encoder never does anything else, although in theory it's possible
|
|
|
|
CrushedAsian255
|
2024-09-21 02:45:52
|
As in they can have dct coded residuals with no extra frames or fancy things but encoders don’t have to implement it?
|
|
|
|
veluca
|
2024-09-21 02:48:08
|
patches can be additive, replace pixels, or do other things
|
|
2024-09-21 02:48:15
|
by default they are added to the current frame
|
|
|
|
AccessViolation_
|
2024-09-21 02:52:47
|
What are residuals in this context?
|
|
|
|
veluca
|
2024-09-21 02:57:07
|
<original image> - <patch>
|
|
|
|
AccessViolation_
|
2024-09-21 03:02:11
|
So you meant the rest of the image is DCT encoded like usual?
|
|
|
|
CrushedAsian255
|
2024-09-21 03:02:20
|
Sounds like it
|
|
2024-09-21 03:02:29
|
Think of it like lossless predictor trees
|
|
2024-09-21 03:02:57
|
But instead of being an MA tree it’s a predefined block of pixels
|
|
|
|
AccessViolation_
|
2024-09-21 03:04:19
|
Right so lossless patches and lossy rest of the image, effectively, for patches in lossy mode. Neat
|
|
|
|
veluca
|
2024-09-21 03:06:00
|
patches are actually slightly lossy too
|
|
|
|
_wb_
|
2024-09-21 03:09:12
|
They get quantized
|
|
|
|
AccessViolation_
|
2024-09-21 03:09:17
|
I'm imagining they're just lossy enough to work for screenshots with subpixel text rendering, is that why? Or do you mean they slightly-lossy compress-the layer that has all the patches, after the patch detection step, which itself was lossless
|
|
|
|
_wb_
|
2024-09-21 03:09:27
|
Nothing that will turn a 6 into an 8 though
|
|
|
|
veluca
|
2024-09-21 03:10:48
|
especially because the patch that gets subtracted is the *lossy* version of the patch, so the residual that gets encoded is still able to fix any mistakes
|
|
|
|
lonjil
|
2024-09-21 03:11:33
|
Is fuzzy matching implemented? Or does it only find exact matches for potential patches?
|
|
|
|
AccessViolation_
|
2024-09-21 03:12:50
|
Ohh I get the residuals thing now I think. Like if there is slight variation between a patch candidate and the patch source, it will only store the residual, i.e. the necessary detail for it to look right after applying the patch, so you only store that tiny bit of data instead of not doing the patch at all which would store more data
|
|
2024-09-21 03:13:15
|
If not I will just accept that I don't get it, lol
|
|
|
|
_wb_
|
|
lonjil
Is fuzzy matching implemented? Or does it only find exact matches for potential patches?
|
|
2024-09-21 03:18:45
|
Lossless only uses exact matches, lossy does it a bit fuzzy but the allowed difference is pretty small, otherwise the residuals get too big and it's not effective anyway
|
|
|
AccessViolation_
Ohh I get the residuals thing now I think. Like if there is slight variation between a patch candidate and the patch source, it will only store the residual, i.e. the necessary detail for it to look right after applying the patch, so you only store that tiny bit of data instead of not doing the patch at all which would store more data
|
|
2024-09-21 03:19:07
|
Correct
|
|
|
monad
|
|
AccessViolation_
It seems like in lossless screenshots there's just not a lot of scenarios where letters are actually pixel perfect copies. In this case they are but there are slight variations in the background, but in most screenshots I imagine sub-pixel positioning of letters messes things up
|
|
2024-09-22 03:42:36
|
This isn't representative of the general case. It seems you noticed in this particular case the colors of the background change, which means it doesn't just encode one patch per letter, but encodes one patch per letter per background color. It just so happens alternative lossless tools perform about as well here.
|
|
2024-09-22 03:47:37
|
I would also expect applying antialiasing to reveal a bigger gap for patches.
|
|
|
|
jonnyawsom3
|
2024-09-22 04:20:28
|
Patches don't currently use transparency (As far as I'm aware) so backgrounds effect matching too
|
|
|
Traneptora
|
2024-09-22 07:07:27
|
<@1028567873007927297> https://discord.com/channels/794206087879852103/848189884614705192/1287223452570488932
VSCode does this
|
|
2024-09-22 07:07:57
|
it colorcodes macros vs typedefs, and you can push f12 to go to definition
|
|
|
Demiurge
|
2024-09-22 07:11:33
|
Maybe I'll give vscode a try... I hear it's an electron app...
|
|
2024-09-22 07:11:43
|
anyone use an LSP like clangd?
|
|
|
|
Tirr
|
2024-09-22 07:12:09
|
I'm using coc.nvim + clangd
|
|
|
|
Demiurge
|
|
Tirr
I'm using coc.nvim + clangd
|
|
2024-09-22 07:12:57
|
For browsing/working on libjxl source?
|
|
|
|
Tirr
|
2024-09-22 07:13:02
|
works on libjxl, except for Highway types
|
|
|
|
CrushedAsian255
|
2024-09-22 07:15:43
|
Is Highway libjxl simd
|
|
|
|
Tirr
|
2024-09-22 07:16:27
|
it's portable simd library from google, and yeah it's used in libjxl
|
|
|
gggol
|
2024-09-22 02:22:56
|
Should more effort always produce smaller files? Playing around with lossless compression of screenshots from a web game, and seeing much better compression at lower efforts:
$ cjxl -e 7 mushroom_revolution_high.png mushroom_revolution_high.jxl
JPEG XL encoder v0.10.3 [AVX2]
Encoding [VarDCT, d1.000, effort: 7]
Compressed to 189.1 kB (4.466 bpp).
608 x 557, 4.856 MP/s [4.86, 4.86], , 1 reps, 12 threads.
$ cjxl -e 6 mushroom_revolution_high.png mushroom_revolution_high.jxl
JPEG XL encoder v0.10.3 [AVX2]
Encoding [VarDCT, d1.000, effort: 6]
Compressed to 170.0 kB (4.016 bpp).
608 x 557, 10.655 MP/s [10.66, 10.66], , 1 reps, 12 threads.
|
|
2024-09-22 02:31:42
|
oh, nm. I thought the tool would default to lossless for originals in lossless formats.
$ cjxl -q 100 -e 10 mushroom_revolution_high.png mushroom_revolution_high.jxl
JPEG XL encoder v0.10.3 [AVX2]
Encoding [Modular, lossless, effort: 10]
Compressed to 457.0 kB (10.796 bpp).
608 x 557, 0.021 MP/s [0.02, 0.02], , 1 reps, 12 threads.
|
|
|
|
monad
|
|
gggol
Should more effort always produce smaller files? Playing around with lossless compression of screenshots from a web game, and seeing much better compression at lower efforts:
$ cjxl -e 7 mushroom_revolution_high.png mushroom_revolution_high.jxl
JPEG XL encoder v0.10.3 [AVX2]
Encoding [VarDCT, d1.000, effort: 7]
Compressed to 189.1 kB (4.466 bpp).
608 x 557, 4.856 MP/s [4.86, 4.86], , 1 reps, 12 threads.
$ cjxl -e 6 mushroom_revolution_high.png mushroom_revolution_high.jxl
JPEG XL encoder v0.10.3 [AVX2]
Encoding [VarDCT, d1.000, effort: 6]
Compressed to 170.0 kB (4.016 bpp).
608 x 557, 10.655 MP/s [10.66, 10.66], , 1 reps, 12 threads.
|
|
2024-09-22 03:05:26
|
No, more effort *should* produce smaller output at same quality, but it is not a guarantee. With lossy encoding, higher efforts should more consistently hit your target quality, where lower efforts can easily be smaller but also lower quality. The task of lossless is more straightforward, but still relies on heuristics to estimate the utility of each tool.
|
|
|
|
gggol
|
2024-09-22 03:16:15
|
$ cjxl --allow_expert_options -e 11 -q 100 mushroom_revolution_high.png mushroom_revolution_high.jxl
JPEG XL encoder v0.10.3 [AVX2]
Encoding [Modular, lossless, effort: 11]
Compressed to 390.8 kB (9.232 bpp).
608 x 557, 0.001 MP/s [0.00, 0.00], , 1 reps, 12 threads.
|
|
|
|
monad
|
2024-09-22 03:16:27
|
e10 finds the minimum in 89.9% of cases in this set
|
|
|
|
jonnyawsom3
|
2024-09-22 03:57:15
|
e10 practically disables multithreading, e11 're-enables' it by just running a few dozen encodes 1 per thread
|
|
|
damian101
|
|
AccessViolation_
It seems like in lossless screenshots there's just not a lot of scenarios where letters are actually pixel perfect copies. In this case they are but there are slight variations in the background, but in most screenshots I imagine sub-pixel positioning of letters messes things up
|
|
2024-09-22 06:09:24
|
hmm, afaik Windows has display-optimized font rendering, that should produce pixel-perfect copies...
|
|
|
|
jonnyawsom3
|
2024-09-22 07:08:48
|
ClearType
|
|
|
KKT
|
|
KKT
OK, I've got a bit of a weird one. My kid's school sent out a link for all the photos from last year in Google Photos (many thousands of them). Downloaded them all and ran them through with:
`parallel cjxl --num_threads=0 -j 0 -d 1 -e 9 {} {.}.jxl ::: ./*.jpg`
Obviously quality is already degraded, so they don't have to be awesome. Most were taken with an iPhone. I'm getting a shift in the HDR – JPEG's highlights are noticably brighter. Attached is a good example. They're close to the same in Preview, but not exactly. Quicklook doesn't do HDR for JXL files at all. Preview shows the JPEG as 10 bits. Exif tool shows `Profile Connection Space: XYZ`. So these are Jpegli compressed?
|
|
2024-09-22 08:08:35
|
OK, what is up with this JPEG? There are two files in it? It's definitely tone mapped and showing as HDR. When I do lossless conversion to JXL I lose the HDR.
|
|
2024-09-22 08:10:12
|
|
|
|
|
jonnyawsom3
|
2024-09-22 08:11:47
|
UltraHDR JPEG, right?
|
|
|
|
_wb_
|
2024-09-22 08:12:16
|
Yeah that's what currently happens with UltraHDR
|
|
2024-09-22 08:13:26
|
The gain map is treated just as random tail data, so you just see the SDR image when converting to jxl
|
|
|
|
KKT
|
2024-09-22 08:14:23
|
So Google Photos is converting HEIF images to UltraHDR???
|
|
|
|
jonnyawsom3
|
2024-09-22 08:16:12
|
Is it happening with all images or just a few? Because for an entire school it's likely a mix of devices and a mix of formats
|
|
|
|
_wb_
|
2024-09-22 08:16:13
|
Apple also uses this gain maps approach in HEIF, it uses 8-bit heic with a separate gain map
|
|
|
|
KKT
|
2024-09-22 08:17:02
|
So the teachers both use iPhones (all the pics seem to have iPhone metadata)
|
|
2024-09-22 08:17:22
|
They've been uploaded to Google Photos, and I batch downloaded them
|
|
|
|
_wb_
|
2024-09-22 08:17:56
|
I haven't been able to find something that can easily convert gain map images to actual HDR images, does anyone else know something?
|
|
|
|
CrushedAsian255
|
|
_wb_
I haven't been able to find something that can easily convert gain map images to actual HDR images, does anyone else know something?
|
|
2024-09-22 08:18:19
|
I found one for HEIC
|
|
|
|
KKT
|
2024-09-22 08:18:24
|
I actually think they were all live photos, cause many have 2 second videos with them.
|
|
|
|
CrushedAsian255
|
2024-09-22 08:18:34
|
https://github.com/m13253/heif-hdrgainmap-decode
|
|
|
|
_wb_
|
2024-09-22 08:19:24
|
For UltraHDR I only found this: https://github.com/google/libultrahdr
|
|
2024-09-22 08:21:01
|
It produces raw buffers so not very convenient. I can manage to convert those to images, but I cannot get them to look correct. If I ask for HLG output it looks very different from when I ask for PQ output, and both are different from how Chrome renders it.
|
|
|
|
CrushedAsian255
|
2024-09-22 08:21:19
|
Maybe someone could hook that up to libjxl
|
|
2024-09-22 08:21:33
|
Maybe there are different tuning options
|
|
2024-09-22 08:21:51
|
Either way, these gain maps really make things annoying, don’t they
|
|
|
|
_wb_
|
2024-09-22 08:22:10
|
It's solving a complicated problem by making it 10x more complicated
|
|
|
|
jonnyawsom3
|
2024-09-22 08:22:22
|
> Ultra HDR is a true HDR image format
One sentence alone that makes me roll my eyes
|
|
|
|
CrushedAsian255
|
2024-09-22 08:23:20
|
“Typescript is a built from the grounds up new programming language”
|
|
|
|
_wb_
|
2024-09-22 08:45:19
|
Gain maps are like making "Truecolor PNG" by concatenating two 256-color GIF files so it gracefully degrades for existing GIF viewers while you can reconstruct something with more colors too.
|
|
|
|
Demiurge
|
|
_wb_
The gain map is treated just as random tail data, so you just see the SDR image when converting to jxl
|
|
2024-09-22 09:30:53
|
Interesting... when reading PNG files there is a jxl_failure if there is tail data
|
|
2024-09-22 09:31:41
|
Also that's really bad design for ultrahdr to be concatenated like that...
|
|
|
|
CrushedAsian255
|
2024-09-22 09:33:05
|
maybe libjxl should add support for converting UltraHDR jpg to jpeg xl (probably wouldn't be able to have lossless transcoding as well but oh well)
|
|
|
|
Demiurge
|
2024-09-22 09:35:04
|
Why would they concatenate instead of using metadata boxes like how jpeg xt uses app11 boxes
|
|
2024-09-22 09:47:09
|
Looks like they really dropped the ball when designing this "extension"
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
maybe libjxl should add support for converting UltraHDR jpg to jpeg xl (probably wouldn't be able to have lossless transcoding as well but oh well)
|
|
2024-09-22 09:50:52
|
gain maps are being added to the next JXL spec because of UltraHDR, so you never know
|
|
|
|
_wb_
|
2024-09-22 09:54:37
|
Not specifically for UltraHDR, it's more of a feature parity thing. AVIF and HEIC support it, so...
|
|
|
|
AccessViolation_
|
2024-09-22 09:56:04
|
Since the bitstream is fixed, does it being "added" just mean that a reserved layer will be dedicated to it, similarly to how depth and thermal layers are standardized?
|
|
|
|
CrushedAsian255
|
2024-09-22 09:56:10
|
is jpeg reconstruction specification going to be changed to allow UltraHDR?
|
|
|
|
_wb_
|
2024-09-22 09:56:18
|
No such plans atm
|
|
|
|
CrushedAsian255
|
|
AccessViolation_
Since the bitstream is fixed, does it being "added" just mean that a reserved layer will be dedicated to it, similarly to how depth and thermal layers are standardized?
|
|
2024-09-22 09:56:19
|
probably going to be a seperate box iirc
|
|
|
|
_wb_
|
2024-09-22 09:56:37
|
Yeah it's a separate box that applications can use if they insist
|
|
|
|
AccessViolation_
|
2024-09-22 09:56:44
|
Huh, never heard of boxes before
|
|
2024-09-22 09:56:49
|
*One day I will read the spec*
|
|
|
|
_wb_
|
2024-09-22 09:57:09
|
Just like an exif or xmp box basically
|
|
|
|
CrushedAsian255
|
|
AccessViolation_
Huh, never heard of boxes before
|
|
2024-09-22 09:57:41
|
think RIFF
|
|
|
|
_wb_
|
2024-09-22 09:59:11
|
Jpeg recompression is meant to deal with legacy files, not really to handle new stuff like UltraHDR. We could in principle add some mechanism for UltraHDR but it would mean older libjxl wouldn't understand...
|
|
|
|
CrushedAsian255
|
2024-09-22 09:59:23
|
i have idea
|
|
2024-09-22 09:59:31
|
since ultrahdr is just tail data
|
|
|
|
AccessViolation_
|
2024-09-22 09:59:38
|
Is there a particular reason to not use one of the reserved layers for this? I thought this is what they were for
|
|
|
|
CrushedAsian255
|
2024-09-22 10:00:01
|
you could first split the UltraHDR into the SDR version, code that like normal, then store the UltraHDR in a seperate box, along with UltraHDR reconstruction data
|
|
2024-09-22 10:00:12
|
older libjxl would just only reconstruct the original data
|
|
2024-09-22 10:00:26
|
newer libjxl would be able to reconstruct the UltraHDR data as well
|
|
|
|
_wb_
|
|
AccessViolation_
Is there a particular reason to not use one of the reserved layers for this? I thought this is what they were for
|
|
2024-09-22 10:02:09
|
Mostly to make it easy to strip the gain map if you don't need it. The main use case for gain maps in jxl is if the main image is HDR, so the gain map is just for rendering SDR versions...
|
|
|
|
CrushedAsian255
|
2024-09-22 10:02:39
|
technically it would count as "rendering information" though, wouldn't it?
|
|
|
|
_wb_
|
2024-09-22 10:03:15
|
Only for less capable screens. For the HDR rendering you don't need it if used that way.
|
|
|
|
CrushedAsian255
|
2024-09-22 10:03:39
|
so is it more like jpeg reconstruction data? legacy information that is nice to have?
|
|
|
|
_wb_
|
2024-09-22 10:03:46
|
It's a bit like PNG24 files that contain a palette in case you want to show them on a VGA screem
|
|
|
|
CrushedAsian255
|
2024-09-22 10:04:07
|
never seen that before lol
|
|
|
|
_wb_
|
2024-09-22 10:04:15
|
Exactly
|
|
2024-09-22 10:04:29
|
Which is why it might be useful to be able to strip it
|
|
|
|
CrushedAsian255
|
2024-09-22 10:04:32
|
what about ultrahdr sdr->hdr gainmaps though?
|
|
2024-09-22 10:04:43
|
or should it be rendered to HDR before being stored in JXL
|
|
2024-09-22 10:04:48
|
then store a HDR->SDR gainmap
|
|
|
|
_wb_
|
2024-09-22 10:04:59
|
Yeah I think that's the better way
|
|
|
|
CrushedAsian255
|
2024-09-22 10:05:11
|
so hook up libultrahdr to libjxl?
|
|
2024-09-22 10:05:15
|
or at least cjxl
|
|
|
|
_wb_
|
2024-09-22 10:05:24
|
And drop the gain map completely if the SDR tone map is algorithmically generated anyway, like it will usually be
|
|
2024-09-22 10:06:05
|
I don't know if it makes sense to spend much effort on making it easy to use things that are a bad idea in the first place
|
|
2024-09-22 10:07:43
|
If UltraHDR wants to become adopted, their proponents should come up with some software to easily produce a HDR image in PNG or something from a UltraHDR file. I don't think it's really libjxl's task to do that kind of thing.
|
|
|
|
CrushedAsian255
|
|
_wb_
If UltraHDR wants to become adopted, their proponents should come up with some software to easily produce a HDR image in PNG or something from a UltraHDR file. I don't think it's really libjxl's task to do that kind of thing.
|
|
2024-09-22 10:08:20
|
> HDR image in PNG
like a PQ image?
|
|
|
|
_wb_
|
2024-09-22 10:08:37
|
Or HLG, whatever, something standard.
|
|
|
|
AccessViolation_
|
2024-09-22 10:10:34
|
Who would have thought that so much room for modern extensions in the future would mostly prove useful for adding compatibility with ugly patchy solutions to less capable formats
|
|
|
|
CrushedAsian255
|
2024-09-22 10:10:48
|
yaaaaaay
|
|
2024-09-22 10:11:24
|
who needs depth maps and fancy things like that when you can have legacy support for a half-baked stopgap solution?
|
|
|
|
jonnyawsom3
|
2024-09-23 12:01:31
|
> a true HDR image format
|
|
|
|
Demiurge
|
|
_wb_
Jpeg recompression is meant to deal with legacy files, not really to handle new stuff like UltraHDR. We could in principle add some mechanism for UltraHDR but it would mean older libjxl wouldn't understand...
|
|
2024-09-23 07:40:37
|
Older libjxl already can't understand gain maps though.
|
|
2024-09-23 07:40:42
|
afaik
|
|
2024-09-23 07:40:58
|
so that's already the case either way
|
|
2024-09-23 07:42:58
|
You could always make an extra "bitstream reconstruction" metadata box meant specifically for reconstructing stupid junk idiotically concatenated to the end of the file. since JBRD is already taken, I suggest maybe TARD (tertiary addendum to reconstruction data)
|
|
|
|
CrushedAsian255
|
|
Demiurge
You could always make an extra "bitstream reconstruction" metadata box meant specifically for reconstructing stupid junk idiotically concatenated to the end of the file. since JBRD is already taken, I suggest maybe TARD (tertiary addendum to reconstruction data)
|
|
2024-09-23 07:43:35
|
I was thinking something like that although it would not be backwards compatible
|
|
|
|
Demiurge
|
2024-09-23 07:43:44
|
The tard box
|
|
|
|
CrushedAsian255
|
2024-09-23 07:44:00
|
Although if the tard box is just storing another JPEG then what
|
|
|
|
Demiurge
|
2024-09-23 07:45:36
|
it would only store the bare minimum to recreate the file, possibly relying on data already in the other metadata boxes such as the gain map data.
|
|
|
|
CrushedAsian255
|
2024-09-23 07:45:52
|
So like a second jbrd?
|
|
|
|
Demiurge
|
2024-09-23 07:46:03
|
Yep, exactly.
|
|
2024-09-23 07:46:17
|
But personally, I think a more ideal solution would be to pillory whoever invented UltraHDR
|
|
|
|
CrushedAsian255
|
2024-09-23 07:46:39
|
So maybe gmap for the gainmap code stream and then gbrd for gainmap reconstruction
|
|
|
|
Demiurge
|
2024-09-23 07:50:17
|
I prefer tertiary addendum for handling all kinds of stupid nonsense that doesn't belong there.
|
|
|
|
CrushedAsian255
|
2024-09-23 07:50:40
|
That wouldn’t allow bitstream reconstruction of the gainmap though
|
|
2024-09-23 07:50:47
|
Unless you’re duplicating the data
|
|
|
|
Demiurge
|
2024-09-23 07:50:49
|
gainmap data could go in a jpeg app11 box
|
|
|
|
CrushedAsian255
|
2024-09-23 07:51:03
|
Aren’t we taking about JXL ?
|
|
|
|
Demiurge
|
2024-09-23 07:51:18
|
lossless recompression/reconstruction
|
|
|
|
CrushedAsian255
|
2024-09-23 07:51:21
|
How does UltraHDR store it again?
|
|
2024-09-23 07:51:38
|
What format is the gainmap in?
|
|
|
|
Demiurge
|
2024-09-23 07:51:39
|
it literally just uses `cat` to staple it on after the end of the file.
|
|
2024-09-23 07:51:52
|
it's so dumb
|
|
|
|
CrushedAsian255
|
2024-09-23 07:52:33
|
Ok, but if you want lossless reconstruction of the UltraHDR file as well as proper JXL, you need to store reconstruction data for the gainmap image somewhere
|
|
|
|
Demiurge
|
2024-09-23 08:00:59
|
If UltraHDR used normal app markers like jpeg extensions are supposed to use, instead of just concatenating to the end of the file, then it would probably work fine with jbrd, which already tries to preserve all of the app markers.
|
|
|
|
CrushedAsian255
|
2024-09-23 08:05:35
|
Are app markers like boxes ?
|
|
|
|
_wb_
|
2024-09-23 08:15:09
|
jbrd does preserve tail data too, so it currently does reconstruct UltraHDR fine (as long as the gain map is not too large, there is a limit on the tail data size)
|
|
2024-09-23 08:15:28
|
But it's not semantically storing the tail data as a gain map
|
|
|
|
Demiurge
|
|
CrushedAsian255
Are app markers like boxes ?
|
|
2024-09-23 08:23:52
|
yup
|
|
2024-09-23 08:24:24
|
jpeg stores all metadata in boxes labeled app01, app02, etc
|
|
2024-09-23 08:26:04
|
I would assume the UltraHDR data is already compressed in an effort to reduce the filesize footprint as much as possible, so compressing it a second time wouldn't yield much savings.
|
|
|
|
CrushedAsian255
|
2024-09-23 08:26:24
|
I think it could just be another jpeg
|
|
|
|
_wb_
|
2024-09-23 10:24:56
|
Yes, it's another jpeg
|
|
|
|
Demiurge
|
2024-09-23 11:26:55
|
I wonder why RGBE isn't more popular
|
|
|
Orum
|
2024-09-23 11:37:25
|
Red Green Blue... Emissive?
|
|
|
spider-mario
|
2024-09-23 11:38:42
|
maybe exponent
|
|
|
|
lonjil
|
|
spider-mario
maybe exponent
|
|
2024-09-23 11:43:36
|
seems like it <https://en.wikipedia.org/wiki/RGBE_image_format>
> It stores pixels as one byte each for RGB (red, green, and blue) values with a one byte shared exponent. Thus it stores four bytes per pixel.
|
|
|
|
username
|
2024-09-23 11:44:13
|
speaking of, didn't JPEG XT use RGBE?
|
|
|
|
_wb_
|
2024-09-23 11:44:45
|
Single-channel gain maps are pretty similar to the E in RGBE, and have the same problem: the multiplier has to be the same for each component, so you lose precision
|
|
2024-09-23 11:46:11
|
You cannot express something like high-amplitude B together with low-amplitude G very well, because you won't have many significant bits you can use for the G
|
|
|
|
Demiurge
|
2024-09-23 12:14:25
|
sure but arguably a shared exponent is "good enough" precision for a lossy format? It would be no better or worse than a luma map I would guess.
|
|
2024-09-23 12:17:00
|
But I can see how it would be more wasteful or less efficient compared to having 3 separate exponents.
|
|
|
|
A homosapien
|
2024-09-23 11:25:32
|
What about high distances like > 5? Could RGBE improve low bpp performance in jxl?
|
|
|
|
damian101
|
|
A homosapien
What about high distances like > 5? Could RGBE improve low bpp performance in jxl?
|
|
2024-09-23 11:32:51
|
No.
|
|
2024-09-23 11:33:08
|
JXL is high bit depth internally
|
|
|
|
A homosapien
|
2024-09-23 11:41:02
|
I see, I guess patches and splines are the future for lossy jxl.
|
|
|
|
Demiurge
|
2024-09-24 09:48:09
|
Yeah, jxl has a much better system than RGBE.
|
|
2024-09-24 09:48:21
|
RGBE is more of a hack
|
|
2024-09-24 09:50:58
|
For extremely low distance improvements JXL has lots of possible ways of achieving big gains
|
|
|
|
Quackdoc
|
2024-09-24 02:24:06
|
anyone know if the imagetoolbox application for android can do jpeg reconstruction? I tried the JXL to Jpeg and it doesn't seem to do the reconstruction
|
|
2024-09-24 02:56:54
|
interesting ill have to punt the images to my PC when I get time to verify them
|
|
2024-09-24 02:57:21
|
> Disclaimer: I haven't tried the app yet so I can't test, but maybe you can check the options first to see whether the reconstruction feature is disabled,
I did test JpegtoJXL then JXLtoJPEG and while the size was similar, the hashes were different
|
|
|
|
jonnyawsom3
|
2024-09-24 03:21:40
|
The reconstructed JPEG has these additional EXIF fields
```[File] ExifByteOrder : Big-endian (Motorola, MM)
[IFD0] ImageWidth : 1280
[IFD0] ImageHeight : 960
[IFD0] Orientation : Unknown (0)
[ExifIFD] LightSource : Unknown```
|
|
|
|
Traneptora
|
2024-09-24 03:22:13
|
reconstructed jpeg should be bitexact
|
|
2024-09-24 03:22:21
|
like, identical file
|
|
2024-09-24 03:22:25
|
so something is messing up somewhere
|
|
|
|
jonnyawsom3
|
2024-09-24 03:22:48
|
I'll make an issue on the toolbox repo
|
|
|
|
Traneptora
|
2024-09-24 03:23:06
|
at least wrt JXL
|
|
2024-09-24 03:23:31
|
like if you go `cjxl image.jpg image.jxl` and then `djxl image.jxl foo.jpg` and compare the sha256sums of `image.jpg` and `foo.jpg` they should be identical
|
|
2024-09-24 03:23:33
|
i.e. the files should be
|
|
|
I'll make an issue on the toolbox repo
|
|
2024-09-24 03:24:00
|
first confirm that you can't reproduce the issue with `cjxl/djxl`
|
|
2024-09-24 03:24:07
|
if it's a libjxl bug then don't report it to toolbox
|
|
|
|
jonnyawsom3
|
2024-09-24 03:25:18
|
Yeah, it's bit-identical with djxl
|
|
|
Quackdoc
> Disclaimer: I haven't tried the app yet so I can't test, but maybe you can check the options first to see whether the reconstruction feature is disabled,
I did test JpegtoJXL then JXLtoJPEG and while the size was similar, the hashes were different
|
|
2024-09-24 03:30:01
|
https://github.com/T8RIN/ImageToolbox/issues/1363
|
|
|
|
Quackdoc
|
2024-09-24 03:30:12
|
I was just about to say ping me when you do [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)
|
|
2024-09-24 03:39:52
|
seems like it's an upstream jxl-coder issue
|
|
|
|
jonnyawsom3
|
2024-09-24 05:20:33
|
https://github.com/awxkee/jxl-coder/issues/20
|
|
2024-09-24 05:59:50
|
> Did you tried to do it in sample app without any additional layers? Like this one.
>
> val jxl = JxlCoder.Convenience.construct(buffer5)
> val reconstructed = JxlCoder.Convenience.reconstructJPEG(jxl)
> Log.d("TAG", "Source size ${buffer5.size} reconstructed size ${reconstructed.size}")
I'll have to leave this to someone else because I have no idea what I'm doing
|
|
|
|
Quackdoc
|
2024-09-24 06:08:28
|
When you ran djxl on the encoded jxl did hashes match? Im wondering if encode or decode is the issue
|
|
2024-09-24 06:09:25
|
<@238552565619359744>
|
|
2024-09-24 06:09:31
|
meant to reply mb
|
|
|
|
jonnyawsom3
|
2024-09-24 06:15:14
|
Honestly I didn't even check the hash, since the filesize was about 90 bytes larger anyway I could tell ImageToolbox was doing something very wrong, djxl was the same size as the original from the same JXL
|
|
|
|
Quackdoc
|
2024-09-24 06:15:51
|
ok so the issue is in decoding then
|
|
2024-09-24 06:20:05
|
Im not at home atm so I can't take a proper look but it sounds like this might actually be a libjxl bug? that or the dev isn't using the library right
|
|
2024-09-24 08:55:43
|
they fixed the issue, it was indeed a imagetoolbox issue
|
|
|
DZgas Ж
|
2024-09-24 11:05:18
|
I've written a lot about my algorithm in https://discord.com/channels/794206087879852103/806898911091753051/1288265312533352489
And I noticed a strange thing. Since my algorithm starts with a black pixel, if the background is white, it puts a dot, 1 black pixel. So here's about Jpeg XL:
cjxl -d 0 -g 3 -e 10 -I 100 --patches 1
If the image is without a dot, then it weighs **206 bytes**. But if With a Just one black dot first, its for some reason it starts to size as **197 bytes**
Why <:JXL:805850130203934781>
|
|
|
|
jonnyawsom3
|
|
Quackdoc
they fixed the issue, it was indeed a imagetoolbox issue
|
|
2024-09-25 12:49:04
|
Nice of them to not update my issue or link to it in any way, but thanks for figuring it out
|
|
|
|
username
|
2024-09-25 02:25:16
|
([the commit](https://github.com/T8RIN/ImageToolbox/commit/d66dadf7473e3b34d0c18fa22488220f2b622c38)). wait a minute what if a JPEG transcode JXL has metadata added to it **while** it's a JXL and then gets converted/reconstructed to a JPEG?
|
|
2024-09-25 02:25:51
|
after this change won't that info get lost or was it never retained in the first place?
|
|
|
|
CrushedAsian255
|
2024-09-25 03:53:24
|
If you want to do that you need to convert it back to jpeg, edit the metadata and convert back to JXL
|
|
2024-09-25 03:53:51
|
You could possibly edit the jbrd box directly but that isn’t possible with current tooling
|
|
2024-09-25 03:54:03
|
You you have to read the spec and work out how it works
|
|
|
|
spider-mario
|
2024-09-25 02:29:03
|
thoughts about having self-extracting 7-zip archives for static windows releases on github in addition to the current zips? it compresses quite a bit better: https://github.com/sboukortt/libjxl/releases/tag/7zip-test
|
|
2024-09-25 02:29:27
|
and would naming them `.sfx.exe` make things clearer, or less clear?
|
|
2024-09-25 02:29:43
|
(I don’t know how well-known that abbreviation is)
|
|
|
|
afed
|
2024-09-25 02:33:55
|
maybe just 7z?
for windows it's pretty common in archiving tools and even natively in windows 11 in recent builds
|
|
|
|
spider-mario
|
2024-09-25 02:34:57
|
the thought has crossed my mind, but on the other hand, 7-zip is capable of handling its own sfx files anyway
|
|
2024-09-25 02:35:15
|
(although maybe slightly less conveniently from the GUI)
|
|
|
|
afed
|
2024-09-25 02:40:03
|
yeah, but plain exe's still cause higher antivirus/browsers alerts
just 7z I think is more usual for cli tools, if it was a gui with full installation then maybe
|
|
|
|
jonnyawsom3
|
2024-09-25 02:43:59
|
I think most who see an exe would assume it's some kind of GUI or standalone executable for all of libjxl, just normal 7z files would avoid any confusion and can already be opened by just about everything a zip can
|
|
|
|
afed
|
2024-09-25 02:45:15
|
yeah, I see a lot of 7z on github, with optional zip or even without, but sfx is very rare, like I said, only for some more advanced installations
|
|
2024-09-25 02:51:32
|
mpv for windows for example and many other compiled binaries for windows
<https://github.com/shinchiro/mpv-winbuild-cmake/releases/tag/20240923>
<https://github.com/Andarwinux/mpv-winbuild/releases/tag/2024-09-24-92e97d2>
ffmpeg
<https://www.gyan.dev/ffmpeg/builds/>
|
|
2024-09-25 02:53:37
|
it's like third party builds, but it's officially mentioned from the main sites for windows binaries
|
|
2024-09-25 02:54:32
|
|
|
|
|
Quackdoc
|
2024-09-25 10:34:27
|
Is it possible for djxl to do image resizing? currently gdkpixbuf takes a while, and lots of resources, to decode large jxl images and I wanted to try something more performant for thumbnailing.
|
|
|
|
jonnyawsom3
|
2024-09-25 11:24:04
|
There's```-s 1|2|4|8, --downsampling=1|2|4|8
If the input JXL stream is contains hints for target downsampling ratios,
only decode what is needed to produce an image intended for this downsampling ratio.```
|
|
|
|
Quackdoc
|
2024-09-25 11:28:20
|
nah, need to be able to specify thumbnail size [av1_cheems](https://cdn.discordapp.com/emojis/720670067091570719.webp?size=48&quality=lossless&name=av1_cheems)
|
|
|
|
jonnyawsom3
|
2024-09-25 11:32:05
|
I'm not actually sure if *anything* currently uses streaming/chunked decoding for JXL, I know I tried a cropped decode on Oxide a while ago but the memory use was the same as full
|
|
|
|
Quackdoc
|
2024-09-25 11:35:45
|
I just want something fast and not
```ps
> Pictures hyperfine -w 0 --runs 1 'djxl --background=black --output_format=jpeg windwaker-no-fast-1.jxl /tmp/out-djxl' 'magick windwaker-no-fast-1.jxl -background "#FFFFFF" -flatten JPEG:/tmp/out'
Benchmark 1: djxl --background=black --output_format=jpeg windwaker-no-fast-1.jxl /tmp/out-djxl
Time (abs ≡): 10.009 s [User: 21.096 s, System: 3.996 s]
Benchmark 2: magick windwaker-no-fast-1.jxl -background "#FFFFFF" -flatten JPEG:/tmp/out
Time (abs ≡): 88.121 s [User: 49.887 s, System: 121.789 s]
Summary
djxl --background=black --output_format=jpeg windwaker-no-fast-1.jxl /tmp/out-djxl ran
8.80 times faster than magick windwaker-no-fast-1.jxl -background "#FFFFFF" -flatten JPEG:/tmp/out
```
|
|
2024-09-25 11:44:30
|
got it down to 28s by removing flatten, still far longer then I would like for a thumbnailer tho
|
|
|
|
A homosapien
|
2024-09-26 12:36:51
|
Would speedier decoding be preferable to less accurate output? Something like fdjxl could be a thing. <:Thonk:805904896879493180>
|
|
2024-09-26 12:51:26
|
I can imagine effort levels for decoding 😅
|
|
2024-09-26 12:54:12
|
Although, to speed things up partial progressive decoding would be a more practical
|
|
2024-09-26 12:54:46
|
Like only loading a third of the image would be faster and better
|
|
|
|
jonnyawsom3
|
2024-09-26 12:55:18
|
An ideal case would be an image viewer with streamed/chunked decoding, cropped decoding for zooming and progressive decoding with rate based on megapixels
|
|
|
|
Quackdoc
|
2024-09-26 12:56:04
|
I just want a fast thumbnailer <:SadCheems:890866831047417898>
|
|
|
VcSaJen
|
2024-09-26 02:14:26
|
Your best bet right now is embedding thumbnail in the metadata and show that. When decoder improves in the future, it could take advantage of the progressive dc if image have that. But in general case (no thumb metadata, no progressive dc) there's nothing for really big images
|
|
|
|
Quackdoc
|
2024-09-26 02:20:35
|
prolly won't be too hard to add basic resize to djxl, I'll probably add it if I have time.
|
|
|
|
Traneptora
|
|
spider-mario
thoughts about having self-extracting 7-zip archives for static windows releases on github in addition to the current zips? it compresses quite a bit better: https://github.com/sboukortt/libjxl/releases/tag/7zip-test
|
|
2024-09-26 02:40:57
|
why not just publish a .zip and a .7z? if you can't extract the .7z you can extract the .zip instead
|
|
2024-09-26 02:41:19
|
it's like providing `.tar.gz` and `.tar.zst` on *nix
|
|
|
|
jonnyawsom3
|
|
VcSaJen
Your best bet right now is embedding thumbnail in the metadata and show that. When decoder improves in the future, it could take advantage of the progressive dc if image have that. But in general case (no thumb metadata, no progressive dc) there's nothing for really big images
|
|
2024-09-26 02:42:36
|
If I'm right, technically you could load the DC but not upsample, so you'd get 1:8 regardless of settings, and then resize to thumbnail from there
|
|
|
|
Traneptora
|
|
Quackdoc
I just want a fast thumbnailer <:SadCheems:890866831047417898>
|
|
2024-09-26 02:43:01
|
Preview Frame?
|
|
|
Quackdoc
I just want a fast thumbnailer <:SadCheems:890866831047417898>
|
|
2024-09-26 02:48:41
|
more specifically does `-s 8` help you get the DCs?
|
|
|
|
Quackdoc
|
2024-09-26 03:57:17
|
I'm talking about generic /usr/share/thumbnailer support
|
|
|
|
CrushedAsian255
|
2024-09-26 03:58:31
|
Does that support jxl
|
|
|
|
Quackdoc
|
2024-09-26 04:02:49
|
its just a program that decodes to a small resolution file that the app picks, typically JPEG or png
|
|
2024-09-26 04:03:52
|
People typically use gdk pixbuf thumbmailer, for the tool, but there are QT ones. You can use image magick. You can use all sorts of things.
But the important thing is that it renders to a small resolution picture.
|
|
|
|
jonnyawsom3
|
|
If I'm right, technically you could load the DC but not upsample, so you'd get 1:8 regardless of settings, and then resize to thumbnail from there
|
|
2024-09-26 06:07:28
|
Oh, version 0.5 <https://github.com/libjxl/libjxl/blob/6bce9e53a8a8dccdd5f2516220d52df31b2b9830/CHANGELOG.md#removed-2>
> ### Removed
> - API for returning a downsampled DC was deprecated
> (`JxlDecoderDCOutBufferSize` and `JxlDecoderSetDCOutBuffer`) and will be
> removed in the next release.
|
|
|
Traneptora
more specifically does `-s 8` help you get the DCs?
|
|
2024-09-26 06:41:25
|
Just tested a few different files, I got the DC once, from a file with `--progressive_DC=1`, but for some reason not when I tried to encode a new file with it too
|
|
|
|
CrushedAsian255
|
|
Oh, version 0.5 <https://github.com/libjxl/libjxl/blob/6bce9e53a8a8dccdd5f2516220d52df31b2b9830/CHANGELOG.md#removed-2>
> ### Removed
> - API for returning a downsampled DC was deprecated
> (`JxlDecoderDCOutBufferSize` and `JxlDecoderSetDCOutBuffer`) and will be
> removed in the next release.
|
|
2024-09-26 08:52:48
|
Wonder why it was deprecated
|
|
|
|
spider-mario
|
|
Traneptora
why not just publish a .zip and a .7z? if you can't extract the .7z you can extract the .zip instead
|
|
2024-09-26 12:17:25
|
the way I envisioned it was to still have the `.zip` for those who prefer it, but also make the `.7z` more directly usable, so there would have been `.zip` / `.exe`
|
|
2024-09-26 12:17:36
|
but yeah, maybe `.zip` / `.7z` is enough
|
|
2024-09-26 12:18:16
|
those who don’t know about 7-zip and are intrigued by the difference in file size should be able to figure it out
|
|
|
|
Traneptora
|
|
spider-mario
the way I envisioned it was to still have the `.zip` for those who prefer it, but also make the `.7z` more directly usable, so there would have been `.zip` / `.exe`
|
|
2024-09-26 02:29:51
|
If you provided a SFX exe and .zip I personally would ignore the SFX archive
|
|
2024-09-26 02:30:39
|
or I would be confused and assume it was an installer and then a portable package
|
|
|
|
spider-mario
|
2024-09-26 02:40:16
|
that’s why I was thinking of `.sfx.exe` but I thought maybe it would be even more confusing for those who don’t know “sfx”
|
|
|
|
afed
|
2024-09-26 02:40:35
|
yeah, 7z is enough
7-zip exists for like 25 years, for windows users it's not something unusual and currently all file archivers have 7z support or now even native os support
|
|
2024-09-26 02:42:58
|
sfx is more for gui tools and msi is even more common for such stuff like simple installation or something like inno setup for more advanced ones
|
|
|
|
fifotator487
|
2024-09-26 03:09:42
|
PSA: All JPEG XL ISO standards (even new 2024 versions) are now available on libgen (.li domain) in standards topic. But only non-OCR image-only version.
I am not linking anything so I hope this doesnt violate any rules. But I get it if it gets removed for safety of this server.
Use Editions tab and look for green marked entries, that means they include files. Inside entry page click small blue Libgen button to get to download.
|
|
|
Meow
|
2024-09-26 03:38:48
|
Hmm it works
|
|
2024-09-26 03:39:44
|
Sci-Hub-like site for ISO documentations
|
|
|
|
spider-mario
|
2024-09-26 03:52:42
|
it’s more generally for books and quite convenient
|
|
2024-09-26 03:52:55
|
and from what I recall, it does have some connection to Sci-Hub, but I don’t remember its exact nature
|
|
|
|
jonnyawsom3
|
|
PSA: All JPEG XL ISO standards (even new 2024 versions) are now available on libgen (.li domain) in standards topic. But only non-OCR image-only version.
I am not linking anything so I hope this doesnt violate any rules. But I get it if it gets removed for safety of this server.
Use Editions tab and look for green marked entries, that means they include files. Inside entry page click small blue Libgen button to get to download.
|
|
2024-09-26 04:52:50
|
We already have most if not all standards available as drafts in <#1021189485960114198>
|
|
|
HCrikki
|
2024-09-26 04:58:41
|
threads are hidden after a week of inactivity, no? maybe pin if its an option
|
|
|
|
Quackdoc
|
2024-09-26 04:59:48
|
pinning doesn't work because the discord client is trash
|
|
|
|
HCrikki
|
2024-09-26 05:00:38
|
link to it from somewhere then? as long as its found it can then be 'followed' and remain visible for that user
|
|
|
|
fifotator487
|
|
We already have most if not all standards available as drafts in <#1021189485960114198>
|
|
2024-09-26 05:03:36
|
I thought sometimes drafts differ from final published version so I hoped having access to final ISO can help in those cases.
|
|
|
|
jonnyawsom3
|
|
HCrikki
threads are hidden after a week of inactivity, no? maybe pin if its an option
|
|
2024-09-26 05:03:59
|
Well we don't exactly want it to be too obvious...
|
|
|
|
monad
|
|
HCrikki
threads are hidden after a week of inactivity, no? maybe pin if its an option
|
|
2024-09-26 07:46:14
|
no, this is the newer forum feature, not an inline chat thread
|
|
|
|
Traneptora
|
2024-09-27 09:40:00
|
It looks like djpegli writes `zTXt` chunks with exifdata, instead of `eXIf` chunks
|
|
2024-09-27 09:40:02
|
is this intentional?
|
|
2024-09-27 09:40:12
|
or is this a libpng choice
|
|
2024-09-27 09:40:56
|
here's a big jpeg file I have (21 MB)
|
|
2024-09-27 09:40:59
|
```
$ exiv2 -pS big.jpg
STRUCTURE OF JPEG FILE: big.jpg
address | marker | length | data
0 | 0xffd8 SOI
2 | 0xffe0 APP0 | 16 | JFIF.........
20 | 0xffe2 APP2 | 3160 | ICC_PROFILE......HLino....mntrRG chunk 1/1
3182 | 0xffe0 APP0 | 8 | NXPL.q
3192 | 0xffe1 APP1 | 6925 | Exif..MM.*......................
10119 | 0xffe1 APP1 | 17730 | http://ns.adobe.com/xap/1.0/.<?x
27851 | 0xffed APP13 | 44 | Photoshop 3.0.8BIM..........Z...
27897 | 0xffdb DQT | 67
27966 | 0xffdb DQT | 67
28035 | 0xffc0 SOF0 | 17
28054 | 0xffc4 DHT | 28
28084 | 0xffc4 DHT | 79
28165 | 0xffc4 DHT | 24
28191 | 0xffc4 DHT | 39
28232 | 0xffda SOS
```
|
|
2024-09-27 09:42:03
|
Here's the structure of the decoded PNG file with `djpegli big.jpg big.png`
|
|
2024-09-27 09:42:06
|
```
$ umbrielpng big.png
PNG signature found: big.png
Chunk: IHDR, Size: 25, Offset: 8, CRC32: 7edb18f4
Chunk: gAMA, Size: 16, Offset: 33, CRC32: 0bfc6105
Chunk: iCCP, Size: 2610, Offset: 49, CRC32: 59ad94d5
Chunk: cHRM, Size: 44, Offset: 2659, CRC32: 9cba513c
Chunk: zTXt, Size: 7776, Offset: 2703, CRC32: 449c92e9
Chunk: IDAT, Size: 8204, Offset: 10479, CRC32: a35f0986
Chunk: 21014 more IDAT chunks
Chunk: IEND, Size: 12, Offset: 172417076, CRC32: ae426082
Size: 9000x12000, Color: 8-bit RGB
cHRM matches sRGB space
zTXt key: Raw profile type exif
```
|
|
2024-09-27 09:43:24
|
the `zTXt` chunk contains a base64-encoded exif profile it appears
|
|
2024-09-27 09:45:30
|
the PNG spec doesn't say anything about using zTXt for exif
|
|
|
|
_wb_
|
2024-09-27 09:49:37
|
The eXIf chunk was only defined in 2017 (and only since 2022 it is in the main PNG spec). Before that, tools like ImageMagick and Exiftool used this convention of text chunks with "Raw profile type exif"
|
|
|
|
Traneptora
|
2024-09-27 09:50:09
|
Huh, interesting
|
|
2024-09-27 09:50:32
|
should we prefer `iTXt` instead of `zTXt` simply because UTF-8 is better than LATIN-1?
|
|
2024-09-27 09:50:44
|
or should we just write `eXIf` chunks anyway? or is this a libpng decision?
|
|
|
|
_wb_
|
2024-09-27 09:51:06
|
So I'm not sure what is the best approach right now. I guess we should switch to using the chunk. Not sure if we're making that decision or libpng is.
|
|
|
|
Traneptora
|
2024-09-27 09:51:27
|
I'm guessing it's possibly libpng, because I know libpng is writing the png file
|
|
2024-09-27 09:51:42
|
(I know this because libpng warns about a known incorrect sRGB profile)
|
|
|
|
_wb_
|
2024-09-27 09:52:30
|
zTXt is better because the payload gets base64 encoded in this convention, so it's just ascii and the gzipping helps to reduce the base64 overhead
|
|
|
|
Traneptora
|
2024-09-27 09:52:45
|
iTXt can be compressed as well
|
|
2024-09-27 09:53:19
|
eXIf is uncompressed, but it's also raw, not base64 iirc
|
|
|
|
_wb_
|
2024-09-27 09:54:17
|
using the eXIf chunk may not work in older applications that only know about the zTXt convention thing, so there's a bit of an interop question here
|
|
|
|
Traneptora
|
2024-09-27 09:54:47
|
we write cICP though with djxl
|
|
2024-09-27 09:54:58
|
(though we also write fallback iCCP so maybe that's irrelevant)
|
|
|
|
_wb_
|
2024-09-27 09:55:55
|
yeah but here there is no fallback, it's not a good idea to write both the eXIf chunk and the old zTXt convention thingie
|
|
2024-09-27 09:56:32
|
also one thing that bothers me with Exif in PNG is that it's not clear what to do with the orientation
|
|
2024-09-27 09:57:37
|
as far as I know, all applications just ignore the Exif orientation when rendering a PNG, so they only interpret the orientation field if it's a JPEG but not if it's a PNG.
|
|
2024-09-27 10:01:32
|
so the question is: if you convert a JPEG to PNG (and keep the Exif), should you apply the orientation or not? If you want it to look correct, you should apply it, because PNG viewers will ignore the Exif orientation in the PNG. But then the orientation field in the Exif needs to be reset to the identity orientation, otherwise if you go back from PNG to JPEG and just copy the Exif blob, it will end up being oriented twice.
|
|
2024-09-27 10:02:07
|
Or are all PNG viewers just wrong and should they in fact apply the Exif orientation?
|
|
|
|
Traneptora
|
2024-09-27 10:11:44
|
theoretically yes
|
|
2024-09-27 10:11:51
|
but the png spec doesn't tell them to
|
|
2024-09-27 10:12:19
|
orienting and zeroing out the orientation is the best solution but requires changing the exif blob which is not trivial
|
|
|
|
_wb_
|
2024-09-27 10:29:02
|
This is what djxl does iirc
|
|
2024-09-27 10:30:06
|
It would be helpful if the PNG spec would be explicit. At this point, maybe they should just say "ignore the orientation in exif" since that's what happens in practice.
|
|
|
|
Orum
|
2024-09-28 04:16:05
|
well, I guess I should have expected it, but `cjpegli` butchers dark areas just like `cjxl`, though it doesn't look like there's an intensity target option to fix that?
|
|
|
|
CrushedAsian255
|
2024-09-28 04:17:19
|
Dark area tuning really needs to be fixed asap imo , we need to make sure the perceptually highest quality to get adoption
|
|
|
|
Orum
|
2024-09-28 04:17:50
|
well at least cjxl has a workaround, even though it's a bit annoying to use
|
|
2024-09-28 04:21:17
|
like look at this.... that is *only* d2 on the right (`cjpegli`), and yet it looks abysmal
|
|
2024-09-28 04:23:22
|
I feel like that should be d10 or something
|
|
2024-09-28 04:24:55
|
almost all the dark areas get a weird tonal shift from blue to red in the full image
|
|
|
|
Demiurge
|
|
CrushedAsian255
Dark area tuning really needs to be fixed asap imo , we need to make sure the perceptually highest quality to get adoption
|
|
2024-09-28 07:06:13
|
"perceptually uniform" doesn't mean "crushed shadows... and any other large, extremely noticeable regions of low-contrast that the eye adjusts to and easily notices smaller variations in."
|
|
2024-09-28 07:08:33
|
That's something you expect from crappy youtube video compression and old jpeg encoders but not from a modern HDR-centric codec with "perceptually uniform quantization" as the main takeaway selling point
|
|
|
|
CrushedAsian255
|
|
Demiurge
"perceptually uniform" doesn't mean "crushed shadows... and any other large, extremely noticeable regions of low-contrast that the eye adjusts to and easily notices smaller variations in."
|
|
2024-09-28 07:08:38
|
My point exactly
|
|
2024-09-28 07:09:04
|
This feels like something to be fixed for 1.0
|
|
2024-09-28 07:09:21
|
Not sure what should be done, more tuning
|
|
2024-09-28 07:09:22
|
?
|
|
|
|
Demiurge
|
2024-09-28 07:11:45
|
I'm just worried about embarrassing and valid codec comparisons being made in the meantime, with the potential to harm the reputation and ultimate adoption of a format with so much untapped potential.
|
|
2024-09-28 07:12:52
|
The sooner the most embarrassing things get fixed the less likely there will be a lot of embarrassing search results coming up for jxl
|
|
|
|
CrushedAsian255
|
2024-09-28 07:13:17
|
Yeah, we just need more time befor
|
|
|
|
Tirr
|
2024-09-28 07:13:17
|
maybe encode in higher internal target intensity if the image is mostly dark?
|
|
2024-09-28 07:13:39
|
so that the encoder uses more bits on dark area
|
|
|
|
CrushedAsian255
|
2024-09-28 07:13:39
|
What exactly is target intensity?
|
|
2024-09-28 07:14:21
|
Is it a tuning perimeter?
|
|
|
|
Demiurge
|
2024-09-28 07:15:21
|
It's a workaround but not a long term solution if it's not the default behavior that most people know about or think of doing. It won't prevent embarrassing comparisons from being made between libjxl and other encoders that don't utterly crush prominent low contrast regions of an image.
|
|
|
|
CrushedAsian255
|
|
Demiurge
It's a workaround but not a long term solution if it's not the default behavior that most people know about or think of doing. It won't prevent embarrassing comparisons from being made between libjxl and other encoders that don't utterly crush prominent low contrast regions of an image.
|
|
2024-09-28 07:16:07
|
I think the idea is to do it automatically
|
|
|
|
Tirr
|
|
Tirr
maybe encode in higher internal target intensity if the image is mostly dark?
|
|
2024-09-28 07:16:45
|
not very sure about the direction, but anyway the encoder should do something different on dark images
|
|
|
|
Demiurge
|
2024-09-28 07:17:13
|
The idea is that the human eye is far more sensitive to small differences in luma in large, dark regions that allow the eye to adjust to the darkness.
|
|
2024-09-28 07:17:52
|
That's just a fact of human physiology that perceptual coding tools ought to account for.
|
|
2024-09-28 07:19:38
|
Also since the key selling points of libjxl and the jxl format in general is around HDR, most people would expect that it would be good at preserving detailed shadows, which is the main reason people buy HDR equipment.
|
|
|
|
CrushedAsian255
|
2024-09-28 07:20:01
|
The encoder should detect areas that are darker than the rest of the image and not near high light and increase quantisation quality
|
|
|
|
Demiurge
|
2024-09-28 07:20:03
|
So the current behavior, I think, defies expectations, in my opinion anyways.
|
|
2024-09-28 07:20:43
|
HDR screens is all about those deep deep blacks and detailed shadows that make the image pop as if it were 3D :)
|
|
|
|
CrushedAsian255
|
2024-09-28 07:21:28
|
I use hdr for extra screen brightness for my trash vision 🤷♂️
|
|