|
_wb_
|
2024-09-06 06:32:45
|
Conceptually, the default squeeze script will change a single-channel 1024x1024 image into an 8x8 downscaled version of it, another 8x8 image with residuals, then a series of residual images that goes 16x8, 16x16, 32x16, 32x32, 64x32, 64x64, 128x64, 128x128, 256x128, 256x256, 512x256, 512x512, 1024x512.
This allows reconstructing previews at those same resolutions (and the final image at full resolution).
The initial smaller ones of these residual images go together with the DC (say you're doing a vardct image where modular with squeeze is used for alpha), so you get enough to get a 128x128 preview. The rest gets tiled appropriately and goes in the AC groups.
|
|
|
CrushedAsian255
|
2024-09-06 06:36:27
|
Is this why high distance Modular JXL becomes blocky, those final layers have lots of zero?
|
|
|
|
_wb_
|
|
CrushedAsian255
are RFCs like release candidates?
|
|
2024-09-06 06:36:35
|
RFCs are basically the main standards for the internet, they have the modest name "Request For Comments" but effectively many of these can be considered "IETF standards" with the same status as an ISO or ITU standard.
|
|
|
|
CrushedAsian255
|
2024-09-06 06:37:19
|
Huh, the name “request for comment” made me think they were draft specs
|
|
2024-09-06 06:37:21
|
I’m guess not
|
|
|
|
_wb_
|
|
CrushedAsian255
Is this why high distance Modular JXL becomes blocky, those final layers have lots of zero?
|
|
2024-09-06 06:37:38
|
Yeah you just quantize the residuals, the final ones more than the initial ones.
|
|
|
|
CrushedAsian255
|
2024-09-06 06:38:11
|
So is that how Modular can do near-lossless?
|
|
|
Tirr
|
2024-09-06 06:38:17
|
maybe it starts as "request for comment" but ends up being a proper spec
|
|
|
|
CrushedAsian255
|
2024-09-06 06:38:20
|
Just do a tiny bit of quantisation?
|
|
|
|
_wb_
|
2024-09-06 06:41:39
|
Originally there was a Modular transform to do quantization, but we got rid of that and turned it into part of the MA tree description: predictors can have a multiplier (and an offset), so instead of just decoded_pixel = prediction + read_value, in jxl you can do decoded_pixel = prediction + multiplier * read_value + offset, where the predictor, multiplier and offset are signaled and per context.
For lossy modular we just use fixed multipliers per channel.
|
|
|
|
CrushedAsian255
|
|
_wb_
RFCs are real specs. The document I made for flif is just a draft, something that could eventually have become a spec but it is unfinished and probably never will be finished.
|
|
2024-09-06 06:42:21
|
So is the reference implementation the only implementation of FLIF that will ever exist
|
|
|
|
_wb_
|
|
CrushedAsian255
So is that how Modular can do near-lossless?
|
|
2024-09-06 06:43:15
|
Yes, if you don't quantize at all it is lossless, if you only quantize the final scan with a factor of N, the maximum per-pixel error will be N-1, or something like that.
|
|
|
CrushedAsian255
So is the reference implementation the only implementation of FLIF that will ever exist
|
|
2024-09-06 06:44:17
|
I would assume so, yes. Basically I consider (in retrospect, obviously) FLIF a warmup exercise that eventually resulted in JXL.
|
|
|
|
CrushedAsian255
|
|
_wb_
I would assume so, yes. Basically I consider (in retrospect, obviously) FLIF a warmup exercise that eventually resulted in JXL.
|
|
2024-09-06 06:44:35
|
So JXL v0.1?
|
|
|
_wb_
Originally there was a Modular transform to do quantization, but we got rid of that and turned it into part of the MA tree description: predictors can have a multiplier (and an offset), so instead of just decoded_pixel = prediction + read_value, in jxl you can do decoded_pixel = prediction + multiplier * read_value + offset, where the predictor, multiplier and offset are signaled and per context.
For lossy modular we just use fixed multipliers per channel.
|
|
2024-09-06 06:45:47
|
Is read_value the prediction residual ?
|
|
|
|
_wb_
|
2024-09-06 06:49:00
|
FLIF/FUIF were only a part of the 'input' that went into JXL. There's also PIK, lossless webp, ideas from guetzli, etc that went into it. Maybe it's something like 40% "Google Zurich stuff", 20% FLIF/FUIF, and 40% new collaborative development.
|
|
|
CrushedAsian255
Is read_value the prediction residual ?
|
|
2024-09-06 06:49:08
|
Yes
|
|
|
|
CrushedAsian255
|
|
_wb_
FLIF/FUIF were only a part of the 'input' that went into JXL. There's also PIK, lossless webp, ideas from guetzli, etc that went into it. Maybe it's something like 40% "Google Zurich stuff", 20% FLIF/FUIF, and 40% new collaborative development.
|
|
2024-09-06 06:49:57
|
This really shows how much of a group effort JXL was. Thanks to the entire team for such a powerful and efficient image format. 😊 ❤️
|
|
|
_wb_
Originally there was a Modular transform to do quantization, but we got rid of that and turned it into part of the MA tree description: predictors can have a multiplier (and an offset), so instead of just decoded_pixel = prediction + read_value, in jxl you can do decoded_pixel = prediction + multiplier * read_value + offset, where the predictor, multiplier and offset are signaled and per context.
For lossy modular we just use fixed multipliers per channel.
|
|
2024-09-06 06:51:18
|
Does the prediction use the predicted pixels or the real pixels?
|
|
2024-09-06 06:51:38
|
Like does the predictor N use the decoded (after adding residual and offset) north pixel or the predicted north pixel?
|
|
|
|
_wb_
|
2024-09-06 06:52:37
|
The decoded pixel
|
|
|
|
CrushedAsian255
|
2024-09-06 06:52:51
|
Makes sense
|
|
|
Demiurge
|
2024-09-06 08:13:32
|
It's pretty wearisome how many different things it's possible to get wrong when it comes to displaying an image on a screen and translating colorspace... JXL seems to make it slightly simpler, though, compared to literally all other formats...
|
|
|
|
CrushedAsian255
|
2024-09-06 08:14:14
|
Is Y Luma and XB chroma
|
|
|
|
Demiurge
|
|
|
CrushedAsian255
|
2024-09-06 08:14:35
|
Also tv range can go die in a pit
|
|
|
|
Demiurge
|
2024-09-06 08:17:01
|
So, when doing lossy JXL encoding, the source image gets translated to a perceptual color format, right? And so, if there's an attached color profile on a lossy JXL file, that doesn't actually say anythng about how it's encoded, right? It's just a "suggestion" about what colorpsace to decode it to?
|
|
|
|
_wb_
|
2024-09-06 08:19:09
|
Exactly. If you're going to decode to PNG, it's probably a good idea to follow the suggestion, but if you want to display it on a screen, you can decode directly to the display space instead of making the detour coding space -> image space -> display space.
|
|
|
|
Demiurge
|
2024-09-06 08:19:45
|
Yeah... That sounds pretty awesome.
|
|
2024-09-06 08:20:39
|
It's a really thoughtful design, I love it.
|
|
2024-09-06 08:25:23
|
Even though I sometimes criticize, I do cuz of love! :) And the format itself is really, very thoughtfully designed. I think many encoders and decoders will be written for this format in many different languages.
|
|
2024-09-06 08:26:29
|
The more you love something the easier it is to critique, I noticed.
|
|
|
|
_wb_
|
2024-09-06 08:30:31
|
The traditional way codecs are designed is basically they treat image data just numerically as a 2D array of sample values, where colorimetric interpretation is "not their problem" (i.e. considered something to be signaled separately and handled at the application level) and lossy compression is just "you don't need to preserve the numbers exactly, there can be some error".
When we designed JPEG XL, we really fundamentally challenged that approach, since we consider it foolish: you cannot properly do lossy compression if you don't know how to interpret the input. So we designed JPEG XL to have colorimetric interpretation baked into the codec itself, it's not just "metadata" but part of the actual core codestream. This way the encoder actually knows what it is doing, what the visual impact is of the choices it makes, as opposed to just blindly applying something lossy to a 2D array of numbers without having a clue what those numbers actually represent (sdr? hdr? standard gamut? wide gamut? grayscale? color?). Something like libjpeg-turbo has no clue what the interpretation of the numbers it encodes is: it could be sRGB or Rec2100PQ or ProPhoto or some CMYK space, it doesn't care, there can be some ICC profile in an APP marker but the jpeg encoder just sees sample values without meaning, and does the same thing regardless of what the meaning is. That's an approach that will never lead to consistent quality.
|
|
|
|
Demiurge
|
2024-09-06 08:33:58
|
It's funny that it's been done that way for so long... Especially when phychovisual "lossy" compression is completely meaningless and bogus without a perceptual color space.
|
|
2024-09-06 08:36:37
|
All of the assumptions a lossy encoder makes about what amount of error is acceptable or imperceptible get thrown completely out of the window if the sample values represent a color profile the lossy encoder is not aware of or designed for
|
|
|
DNFrozen
|
2024-09-06 08:37:18
|
i wish i could actually understand this conversation 😶
|
|
|
Oleksii Matiash
|
|
_wb_
The traditional way codecs are designed is basically they treat image data just numerically as a 2D array of sample values, where colorimetric interpretation is "not their problem" (i.e. considered something to be signaled separately and handled at the application level) and lossy compression is just "you don't need to preserve the numbers exactly, there can be some error".
When we designed JPEG XL, we really fundamentally challenged that approach, since we consider it foolish: you cannot properly do lossy compression if you don't know how to interpret the input. So we designed JPEG XL to have colorimetric interpretation baked into the codec itself, it's not just "metadata" but part of the actual core codestream. This way the encoder actually knows what it is doing, what the visual impact is of the choices it makes, as opposed to just blindly applying something lossy to a 2D array of numbers without having a clue what those numbers actually represent (sdr? hdr? standard gamut? wide gamut? grayscale? color?). Something like libjpeg-turbo has no clue what the interpretation of the numbers it encodes is: it could be sRGB or Rec2100PQ or ProPhoto or some CMYK space, it doesn't care, there can be some ICC profile in an APP marker but the jpeg encoder just sees sample values without meaning, and does the same thing regardless of what the meaning is. That's an approach that will never lead to consistent quality.
|
|
2024-09-06 08:48:15
|
Just curious. When encoding ProPhoto file to jpeg, big part of possible 'range' is left unused, correct? I mean ProPhoto is very broad space, and if opened without profile it is very dull, i.e. used range is much smaller than possible. If yes, how is that in jpeg xl?
|
|
|
|
Demiurge
|
|
DNFrozen
i wish i could actually understand this conversation 😶
|
|
2024-09-06 08:49:27
|
Basically, for decades, we have just been throwing bits at JPEG encoders (and webp, and avif, etc) without telling the encoder what those bits actually represent. And then expecting the encoder to change the file in a way that won't be noticeable, when the encoder actually has no way of knowing how much of a visual change it would be to change a 1 to a 0.
|
|
2024-09-06 08:50:56
|
<:JXL:805850130203934781> (or PIK?) is actually the FIRST lossy image codec where the encoder is actually aware of what it's operating on.
|
|
2024-09-06 08:51:08
|
Which is amazing/ridiculous
|
|
|
|
CrushedAsian255
|
2024-09-06 08:52:15
|
(none of this applies when using lossless)
|
|
2024-09-06 08:52:21
|
(unless using XYB modular)
|
|
2024-09-06 08:52:28
|
(but then it's probably not lossless)
|
|
2024-09-06 08:52:37
|
(because most images aren't natively taken in XYB)
|
|
|
|
DNFrozen
|
2024-09-06 08:52:54
|
in what way does this knowlege improve the end result?
|
|
|
|
CrushedAsian255
|
|
DNFrozen
in what way does this knowlege improve the end result?
|
|
2024-09-06 08:53:16
|
it means the encoder can make better decisions
|
|
2024-09-06 08:53:19
|
and better quality images
|
|
2024-09-06 08:53:44
|
since it is based on human perception, it has more knowledge on what it can get rid of without humans being able to tell
|
|
|
|
_wb_
|
|
Oleksii Matiash
Just curious. When encoding ProPhoto file to jpeg, big part of possible 'range' is left unused, correct? I mean ProPhoto is very broad space, and if opened without profile it is very dull, i.e. used range is much smaller than possible. If yes, how is that in jpeg xl?
|
|
2024-09-06 08:53:46
|
Yes, when doing ProPhoto in jpeg, effectively much of the range is unused and the precision goes down. Which is why you can get banding easily, and you'll need to use higher quality settings to get usable results.
In (lossy) JPEG XL, whatever the input space is, it gets converted to XYB first, so the encoder always works in the same space, regardless of the gamut or dynamic range of the input. So if you have an sRGB image, it doesn't matter if you represent it in sRGB or in ProPhoto, or in some small volume of Rec.2100 PQ: the encoder will always get the same input.
|
|
|
|
Oleksii Matiash
|
|
_wb_
Yes, when doing ProPhoto in jpeg, effectively much of the range is unused and the precision goes down. Which is why you can get banding easily, and you'll need to use higher quality settings to get usable results.
In (lossy) JPEG XL, whatever the input space is, it gets converted to XYB first, so the encoder always works in the same space, regardless of the gamut or dynamic range of the input. So if you have an sRGB image, it doesn't matter if you represent it in sRGB or in ProPhoto, or in some small volume of Rec.2100 PQ: the encoder will always get the same input.
|
|
2024-09-06 08:54:16
|
Thank you!
|
|
|
|
CrushedAsian255
|
|
_wb_
Yes, when doing ProPhoto in jpeg, effectively much of the range is unused and the precision goes down. Which is why you can get banding easily, and you'll need to use higher quality settings to get usable results.
In (lossy) JPEG XL, whatever the input space is, it gets converted to XYB first, so the encoder always works in the same space, regardless of the gamut or dynamic range of the input. So if you have an sRGB image, it doesn't matter if you represent it in sRGB or in ProPhoto, or in some small volume of Rec.2100 PQ: the encoder will always get the same input.
|
|
2024-09-06 08:54:38
|
does XYB cover the entire CIE 1931?
|
|
2024-09-06 08:55:26
|
as in this thingy
|
|
|
|
Demiurge
|
|
DNFrozen
in what way does this knowlege improve the end result?
|
|
2024-09-06 08:55:51
|
It's the difference between giving the encoder an actual image, and giving the encoder a bunch of random numbers that could represent anything
|
|
|
|
DNFrozen
|
2024-09-06 08:57:13
|
what kind of decisions can an encoder do?
|
|
|
|
Demiurge
|
2024-09-06 08:57:18
|
All this time, image encoders never actually knew what these numbers actually represent. They never knew the actual, visual magnitude of a change was, when it made changes to those numbers.
|
|
2024-09-06 08:57:43
|
It just had to guess and assume.
|
|
2024-09-06 08:58:08
|
Yet we expected it to give good results by making changes that would be hard to visually notice.
|
|
|
|
_wb_
|
|
Demiurge
Which is amazing/ridiculous
|
|
2024-09-06 08:58:31
|
Codecs got away with the old approach because for a long time, basically all images were sRGB or something close to it (Rec709, even Adobe98 or DisplayP3 are not _that_ different). So making the implicit assumption that this is what the data represents was not _that_ wrong. But if you go wider gamut or higher dynamic range, things start to break down...
|
|
|
|
Demiurge
|
2024-09-06 08:58:42
|
Again, all while the encoder has no idea how visually noticeable a change would be
|
|
|
|
CrushedAsian255
|
2024-09-06 08:59:02
|
"hey image codec, take these numbers and store them, but also forget some parts, but im not gonna tell you how much you are allowed to forget"
|
|
|
|
Demiurge
|
2024-09-06 09:00:54
|
It has no idea how impactful a change to any of those numbers are. It just has to guess and assume. Which works sometimes, like Jon said, because most images use a similar gamma curve and color primaries.
|
|
2024-09-06 09:01:34
|
Throwing random numbers at a codec and expecting it to make good decisions without it knowing anything about what those numbers actually mean.
|
|
2024-09-06 09:01:54
|
That's what every image codec has been doing all this time
|
|
|
|
_wb_
|
|
CrushedAsian255
does XYB cover the entire CIE 1931?
|
|
2024-09-06 09:02:00
|
XYB can effectively represent any colorspace since it has no nominal range, so both in gamut and in dynamic range anything goes (even imaginary colors if you want).
|
|
|
|
Demiurge
|
2024-09-06 09:03:06
|
Like yellowish blue?
|
|
2024-09-06 09:03:11
|
Or reddish green?
|
|
|
|
CrushedAsian255
|
|
_wb_
XYB can effectively represent any colorspace since it has no nominal range, so both in gamut and in dynamic range anything goes (even imaginary colors if you want).
|
|
2024-09-06 09:03:32
|
so it's not capped to 0-1?
I can have Y of 2424119, X of -124 and B of 42.621?
|
|
2024-09-06 09:03:53
|
with Y, is it linear or gamma corrected?
|
|
|
|
DNFrozen
|
2024-09-06 09:04:07
|
my view on images was more or less oh look they are made out of pixels and these pixels aare made out of red green and blue which have number from 0 to 255.
i knew there is more to know about images and other ways to represent colors but i never looked into it
|
|
|
|
Demiurge
|
|
_wb_
Yes, when doing ProPhoto in jpeg, effectively much of the range is unused and the precision goes down. Which is why you can get banding easily, and you'll need to use higher quality settings to get usable results.
In (lossy) JPEG XL, whatever the input space is, it gets converted to XYB first, so the encoder always works in the same space, regardless of the gamut or dynamic range of the input. So if you have an sRGB image, it doesn't matter if you represent it in sRGB or in ProPhoto, or in some small volume of Rec.2100 PQ: the encoder will always get the same input.
|
|
2024-09-06 09:05:36
|
Is this a problem with jpegli or only a problem in low-precision jpeg codecs?
|
|
|
|
DNFrozen
|
2024-09-06 09:05:51
|
my go to image editing software is mspaint
|
|
|
|
Demiurge
|
|
DNFrozen
my view on images was more or less oh look they are made out of pixels and these pixels aare made out of red green and blue which have number from 0 to 255.
i knew there is more to know about images and other ways to represent colors but i never looked into it
|
|
2024-09-06 09:06:17
|
Some images have a different, nonlinear curve of what each brightness step represents.
|
|
2024-09-06 09:07:07
|
Imagine if the encoder has no idea what the difference in brightness is between a "50" and a "52"
|
|
2024-09-06 09:07:24
|
Yet it's still expected to know how much of a change is noticeable or not
|
|
2024-09-06 09:08:15
|
Maybe 80% of images use the same curve but then 20% of the time the encoder has no idea what it's doing and is making incorrect guesses and producing ugly files
|
|
|
|
_wb_
|
2024-09-06 09:08:25
|
XYB is derived from LMS, so yes, you could represent things like high L, zero M, high S which is not physically possible (you can't have a color that excites L cones but not M cones). It is defined so X=B=0 is gray (with Y being the intensity), where positive X means more red (L-M > 0), negative X means more green (L-M < 0), positive B means more blue (S-Y > 0) and negative B means more yellow (S-Y < 0).
|
|
|
|
Demiurge
|
2024-09-06 09:10:11
|
"Supermagenta" or "impossible magenta"
|
|
|
|
DNFrozen
|
2024-09-06 09:10:42
|
my new favorite color
|
|
|
|
Demiurge
|
2024-09-06 09:10:44
|
If you ever see that color then you know you're a character in the next half life game
|
|
|
|
CrushedAsian255
|
|
Demiurge
"Supermagenta" or "impossible magenta"
|
|
2024-09-06 09:11:28
|
how would it render?
|
|
|
|
Demiurge
|
2024-09-06 09:11:46
|
Hack your visual cortex and find out, idunnolol :)
|
|
|
|
_wb_
|
|
Demiurge
Is this a problem with jpegli or only a problem in low-precision jpeg codecs?
|
|
2024-09-06 09:12:00
|
it's a problem of precision, so in jpegli it will be better. But it will still be true that the effective precision you can get in JPEG is lower when the colorspace has a larger volume (wider gamut or larger dynamic range) than if it has a smaller volume, since in the end it can only store fixed-precision (12-bit) DCT coefficients.
|
|
|
|
CrushedAsian255
|
|
_wb_
XYB is derived from LMS, so yes, you could represent things like high L, zero M, high S which is not physically possible (you can't have a color that excites L cones but not M cones). It is defined so X=B=0 is gray (with Y being the intensity), where positive X means more red (L-M > 0), negative X means more green (L-M < 0), positive B means more blue (S-Y > 0) and negative B means more yellow (S-Y < 0).
|
|
2024-09-06 09:12:44
|
what if the JXL stores colours that the monitor can't display? do they just get clipped?
|
|
|
|
Demiurge
|
2024-09-06 09:13:14
|
I wonder if anyone invented a perceptual color space that excludes most physically-impossible colors.
|
|
2024-09-06 09:13:27
|
Maybe the LAB space?
|
|
2024-09-06 09:13:53
|
No, that can still represent impossible magenta too, I think.
|
|
|
_wb_
it's a problem of precision, so in jpegli it will be better. But it will still be true that the effective precision you can get in JPEG is lower when the colorspace has a larger volume (wider gamut or larger dynamic range) than if it has a smaller volume, since in the end it can only store fixed-precision (12-bit) DCT coefficients.
|
|
2024-09-06 09:14:53
|
So, in other words, not floating point.
|
|
2024-09-06 09:15:23
|
I think?
|
|
|
|
_wb_
|
|
|
CrushedAsian255
|
2024-09-06 09:16:46
|
so this
```
Color space: RGB, D65, sRGB primaries, 709 transfer function, rendering intent: Relative
```
doesn't mean anything to the JXL system?
|
|
|
|
Demiurge
|
2024-09-06 09:17:14
|
My knowledge is really fuzzy and non-existent when it comes to the numerical encoding of DCT coefficient data in JPEG 1/XL
|
|
|
CrushedAsian255
so this
```
Color space: RGB, D65, sRGB primaries, 709 transfer function, rendering intent: Relative
```
doesn't mean anything to the JXL system?
|
|
2024-09-06 09:17:57
|
If it's lossy, then it's just a suggestion.
|
|
|
|
CrushedAsian255
|
|
Demiurge
My knowledge is really fuzzy and non-existent when it comes to the numerical encoding of DCT coefficient data in JPEG 1/XL
|
|
2024-09-06 09:17:59
|
JPEG 1 is just integers
|
|
2024-09-06 09:18:04
|
not sure about XL
|
|
2024-09-06 09:18:13
|
it's that hybriduint thing i think
|
|
|
|
_wb_
|
|
CrushedAsian255
what if the JXL stores colours that the monitor can't display? do they just get clipped?
|
|
2024-09-06 09:18:34
|
Yes, things will at the end get clamped when converting to the display space. E.g. here's an image with very extreme values for X and B: https://jxl-art.lucaversari.it/?zcode=i4h04uLKTFNIVrBTMORSUAAyK4FMAyBTQUFXwU9B1wTKDE4tUTAyMLGAKEqGKwJyKuAckMJwBRM4G6RJF6oLxjc0MDDgAgA
|
|
|
|
Demiurge
|
2024-09-06 09:18:48
|
Well I know that XL can store the coefficient data in a lossless way...
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:19:01
|
JPEG1 uses prefix of the absolute value of the coefficient and a runlength of zeros followed by the current value
|
|
|
|
_wb_
|
2024-09-06 09:19:52
|
In JPEG 1 the DCT coefficients are integers (both the quantized coefficients and the quantization factors are ints). In JPEG XL, the quantized DCT coefficients are integers but the quantization factors are floats, so effectively there is no limit on the precision of the dequantized coefficients.
|
|
|
|
Demiurge
|
2024-09-06 09:20:07
|
Ooh. Pretty colors.
|
|
|
|
CrushedAsian255
|
|
Demiurge
Ooh. Pretty colors.
|
|
2024-09-06 09:20:12
|
yay
|
|
|
|
Demiurge
|
|
CrushedAsian255
what if the JXL stores colours that the monitor can't display? do they just get clipped?
|
|
2024-09-06 09:21:08
|
Yeah, that's true of all image formats though, not just JXL.
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:21:12
|
the runlength of zeros is joint-entropy coded with the co-efficients -- this is a very good decision in the original format
|
|
2024-09-06 09:21:36
|
in JXL we made improvements that we first implemented in brunsli, then Pik and brought some of them to JPEG XL
|
|
2024-09-06 09:21:56
|
most important were more context modeling
|
|
|
|
Demiurge
|
2024-09-06 09:22:07
|
The coefficient is the numerator and the factor is the denominator, right?
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:22:23
|
there, counting how many zeros we have left and how many values that are not [-1, 0 or 1]
|
|
|
|
CrushedAsian255
|
|
Jyrki Alakuijala
most important were more context modeling
|
|
2024-09-06 09:22:24
|
you get to use the great modular system for the DC
|
|
2024-09-06 09:22:42
|
or is it the AC?
|
|
2024-09-06 09:22:51
|
the 8x8 downsampled one
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:23:15
|
when we switched the original DC coding system to modular, it wasn't a win or loss -- just more simplicity and generalization in functionality
|
|
2024-09-06 09:23:32
|
perhaps one day if we do delta-palettized DC coding we will get actual wins
|
|
2024-09-06 09:23:48
|
(for lower qualities)
|
|
|
|
_wb_
|
|
CrushedAsian255
the 8x8 downsampled one
|
|
2024-09-06 09:23:53
|
Yes, DC (or in the spec we call it LF) is the 8x8 downsampled image.
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:24:43
|
I believe having a uniform 8x8 DC where the integral transforms can be bigger is unique for JPEG XL
|
|
|
|
Demiurge
|
2024-09-06 09:24:50
|
I think it's a good idea to have a separate mode/codepath/encoder for high fidelity and low fidelity, so changes to one don't worsen the results of the other
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:24:59
|
e.g. if there is a 32x32 DCT, its DC is the average of 4x4 DC values
|
|
2024-09-06 09:25:07
|
I came up with an idea how to do that
|
|
|
|
Demiurge
|
2024-09-06 09:25:51
|
most psycho heuristics do not generalize well for both high and low quality so it makes a lot of sense to have the code in separate files
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:26:06
|
we do DCTs of the 4x4 of the 8x8 field and bring them into the 4x4 upper corner of a 32x32 DCT, and similarly for all larger DCTs
|
|
2024-09-06 09:26:27
|
this is rather hairy to code and Luca managed to get the idea working
|
|
2024-09-06 09:26:52
|
I like this idea quite a bit since then it allows us to send the uniform 8x8 first without waste
|
|
|
|
Demiurge
|
2024-09-06 09:26:54
|
That would make it easier to make changes and refinements separately without always making one step forwards and two steps back
|
|
2024-09-06 09:27:21
|
sorry if I'm kinda off topic here 😅
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:27:51
|
The 8x8 field is overprovisioned in precision for its purpose for previews
|
|
2024-09-06 09:28:20
|
but that solves slow gradient banding artefacts without fuzz for the previews, too
|
|
|
|
Oleksii Matiash
|
|
_wb_
Yes, things will at the end get clamped when converting to the display space. E.g. here's an image with very extreme values for X and B: https://jxl-art.lucaversari.it/?zcode=i4h04uLKTFNIVrBTMORSUAAyK4FMAyBTQUFXwU9B1wTKDE4tUTAyMLGAKEqGKwJyKuAckMJwBRM4G6RJF6oLxjc0MDDgAgA
|
|
2024-09-06 09:28:36
|
It is really painful to see it on wide gamut monitor, especially when moving eye from red corner to green
|
|
|
|
Demiurge
|
2024-09-06 09:29:01
|
I wish I had a wide gamut monitor to test...
|
|
2024-09-06 09:33:05
|
Jyrki, you're really good at psycho tuning, I wonder if you think having separate files for high- and low-fidelity codepaths would be a productive idea.
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
The 8x8 field is overprovisioned in precision for its purpose for previews
|
|
2024-09-06 09:34:01
|
I believe it also helps to make bigger blocks more effective, since the low frequency coeffs (e.g. for a slow gradient) are already sent as part of the 8x8 image, so even with completely zeroed remaining HF coeffs, they can still look good (for something like a sky).
|
|
|
|
Demiurge
|
2024-09-06 09:34:25
|
I also wonder if you're still thinking about tuning the artifacts to be more noise-like instead of smudge-like...
|
|
|
|
Oleksii Matiash
|
|
Demiurge
Jyrki, you're really good at psycho tuning, I wonder if you think having separate files for high- and low-fidelity codepaths would be a productive idea.
|
|
2024-09-06 09:39:01
|
There will be weird overall image look change on that switch, I believe
|
|
|
|
Demiurge
|
2024-09-06 09:43:28
|
It's easier for the human brain to get a better idea of what the original image looks like by "seeing through" a "noisy transmission" or a "fuzzy glass pane" than it is when a compression artifact seems to smooth and blur and smudge parts of the image that had grit and texture before, essentially changing the subject of the image in a fundamental way that's hard for the brain to "see through" and reconstruct what's "behind" or "underneath" the artifacts.
|
|
2024-09-06 09:46:28
|
If fidelity matters more than appeal, I think this nuance should be considered. (Personally I think it would be a good way to achieve greater fidelity AND appeal at the same time. :)
|
|
2024-09-06 09:47:30
|
Jon made a very nice blog post in the past about balancing fidelity and appeal and I was thinking this the whole time while reading it. That maybe you can have both at the same time.
|
|
|
|
Oleksii Matiash
|
|
Demiurge
It's easier for the human brain to get a better idea of what the original image looks like by "seeing through" a "noisy transmission" or a "fuzzy glass pane" than it is when a compression artifact seems to smooth and blur and smudge parts of the image that had grit and texture before, essentially changing the subject of the image in a fundamental way that's hard for the brain to "see through" and reconstruct what's "behind" or "underneath" the artifacts.
|
|
2024-09-06 09:50:24
|
Overcompressed jpeg often looks better than overcompressed modern formats, even if objective metrics are much lower - it's (jpeg) harsh noise-like artifacts help brain to image details that are actually destroyed, and blurred areas both looks unnatural and do nothing in terms of imagination
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:54:03
|
Pik and butteraugli are 100 % on fidelity, JPEG XL took some steps towards appeal, but not as much as other formats
|
|
|
|
Demiurge
|
2024-09-06 09:55:00
|
JPEG is pretty good at preserving texture. The 8x8 blocks of JPEG has a similar effect as blue noise, when viewed from a distance, helping the brain "see through" the codec artifacts and perceive the texture "through" the veil of missing data
|
|
|
|
DNFrozen
|
2024-09-06 09:55:20
|
my first contact with jpg was actually quite bad.
i was a child and was having fun playing around with mspaint on a win 95 or 98 PC
then i saved the imaage so that i can continue working with it later and the default option was jpg
the compression messed everything up. it looked ok but when using the fill color tool all these slightly changed color values were really ugly when using the color fill tool
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:55:41
|
JPEG1 sharpens images when compression is increased due to the overshooting ability of quantized dcts
|
|
|
lonjil
|
|
Jyrki Alakuijala
Pik and butteraugli are 100 % on fidelity, JPEG XL took some steps towards appeal, but not as much as other formats
|
|
2024-09-06 09:55:45
|
is JXL flexible enough to go all in on fidelity with the right encoder choices?
|
|
|
VcSaJen
|
2024-09-06 09:56:04
|
I thought MSPaint's default was *.bmp
|
|
|
|
Demiurge
|
2024-09-06 09:57:22
|
<:JXL:805850130203934781> is one of the most flexible formats I've ever examined, and it can do 100% of what PIK can do, and all PIK images can theoretically be losslessly transcoded to <:JXL:805850130203934781> too. So why not?
|
|
|
|
DNFrozen
|
2024-09-06 09:58:06
|
i think the default was jpg because thats what i used to save it
|
|
2024-09-06 09:58:18
|
i was so angry
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 09:58:58
|
Pik had some features in frequency lifting that we needed to drop when we added variable sizes -- pik was quite a bit more robust around d1.0 (at the cost of encoding speed), and perhaps 5 % more bits
|
|
|
|
Demiurge
|
2024-09-06 09:59:51
|
Was variable sizes worth it...?
|
|
|
|
CrushedAsian255
|
2024-09-06 10:01:22
|
what's variable sizes?
|
|
2024-09-06 10:01:26
|
VarDCT?
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
Was variable sizes worth it...?
|
|
2024-09-06 10:02:14
|
probably not, but a necessity to match the requirements of the JPEG committee (0.06 bpp compression etc.)
|
|
|
|
Oleksii Matiash
|
|
Demiurge
It's easier for the human brain to get a better idea of what the original image looks like by "seeing through" a "noisy transmission" or a "fuzzy glass pane" than it is when a compression artifact seems to smooth and blur and smudge parts of the image that had grit and texture before, essentially changing the subject of the image in a fundamental way that's hard for the brain to "see through" and reconstruct what's "behind" or "underneath" the artifacts.
|
|
2024-09-06 10:03:08
|
Reminded me a review of really ancient camera, with advertised ISO3200:
|
|
|
|
Demiurge
|
|
Jyrki Alakuijala
probably not, but a necessity to match the requirements of the JPEG committee (0.06 bpp compression etc.)
|
|
2024-09-06 10:03:57
|
When someone tells you to do 0.06 bbp compression, that's like someone telling you to sprout wings and jump off the empire state building. You just ignore the crazy person 😅
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 10:04:20
|
that was in the JPEG XL original requirements
|
|
2024-09-06 10:04:49
|
we were able to negotiate it to be easier -- up to 0.25 BPP -- but that is still bad for photographs
|
|
|
|
DNFrozen
|
2024-09-06 10:05:08
|
what does bbp stand for?
|
|
|
|
Oleksii Matiash
|
|
Demiurge
When someone tells you to do 0.06 bbp compression, that's like someone telling you to sprout wings and jump off the empire state building. You just ignore the crazy person 😅
|
|
2024-09-06 10:05:24
|
Saboteur from avif?
|
|
|
|
CrushedAsian255
|
|
DNFrozen
what does bbp stand for?
|
|
2024-09-06 10:05:28
|
bits per pixel
|
|
|
|
DNFrozen
|
2024-09-06 10:06:05
|
0.06 seems indeed quite low
|
|
|
|
Demiurge
|
2024-09-06 10:06:30
|
Yeah. That's literally like being asked to sprout wings and fly.
|
|
2024-09-06 10:06:33
|
You can't.
|
|
2024-09-06 10:06:45
|
If someone tells you to, there's nothing to do but ignore them
|
|
2024-09-06 10:06:52
|
:(
|
|
|
|
DNFrozen
|
2024-09-06 10:07:04
|
at least not on complex images
|
|
|
|
Demiurge
|
2024-09-06 10:08:15
|
Even AI can't encode photos that compact without making it look grotesque
|
|
2024-09-06 10:08:49
|
Makes me wonder how they even come up with that number
|
|
|
|
DNFrozen
|
2024-09-06 10:09:18
|
i haven't seen a useable AI image compression programm. only some research paapers
|
|
|
|
Demiurge
|
2024-09-06 10:09:56
|
And it doesn't perform much better than state of the art conventional image compression
|
|
2024-09-06 10:10:34
|
Unless you're okay with growing an extra eyeball
|
|
|
|
CrushedAsian255
|
2024-09-06 10:11:03
|
|
|
2024-09-06 10:11:03
|
0.06 bpp image
|
|
2024-09-06 10:11:29
|
0.06 bpp @ 12 MPx = 93 kB
|
|
2024-09-06 10:13:15
|
this is 0.056 bpp
|
|
2024-09-06 10:13:44
|
ssimu2 of -14.78894922
|
|
|
|
Demiurge
|
|
CrushedAsian255
|
|
2024-09-06 10:13:45
|
that's 0.3bpp
|
|
|
|
CrushedAsian255
|
|
Demiurge
that's 0.3bpp
|
|
2024-09-06 10:13:52
|
i converted back to png
|
|
2024-09-06 10:13:56
|
im talking about the jxl
|
|
2024-09-06 10:14:09
|
ofc the png is higher bpp
|
|
2024-09-06 10:14:15
|
here's the jxl
|
|
|
|
Demiurge
|
2024-09-06 10:14:20
|
Oh
|
|
2024-09-06 10:14:26
|
I see
|
|
|
|
CrushedAsian255
|
2024-09-06 10:15:06
|
i wonder if avif could do any better
|
|
|
|
DNFrozen
|
2024-09-06 10:15:37
|
it all depends on the image
this is 30*900 and ist just 97 bytes (png) and just 21 bytes if you make it to lossless jxl with effort 11
|
|
|
|
CrushedAsian255
|
|
DNFrozen
it all depends on the image
this is 30*900 and ist just 97 bytes (png) and just 21 bytes if you make it to lossless jxl with effort 11
|
|
2024-09-06 10:15:52
|
and also look at jxl art
|
|
|
|
DNFrozen
|
2024-09-06 10:15:57
|
and all of that lossless
|
|
|
|
CrushedAsian255
|
2024-09-06 10:16:55
|
AVIF seems to do better at this low of a bpp
|
|
|
|
Demiurge
|
2024-09-06 10:16:59
|
Here's a 1:1 screenshot. Keep in mind, half of the image is a solid white background, and it still looks this blocky.
|
|
|
|
CrushedAsian255
|
2024-09-06 10:17:02
|
but im guessing that pure white background is helping it (both formats)
|
|
|
|
Demiurge
|
|
CrushedAsian255
but im guessing that pure white background is helping it (both formats)
|
|
2024-09-06 10:17:24
|
It helps JXL too
|
|
|
|
DNFrozen
|
2024-09-06 10:18:21
|
helps any form of image compression
|
|
|
|
Demiurge
|
|
CrushedAsian255
AVIF seems to do better at this low of a bpp
|
|
2024-09-06 10:18:55
|
I actually think the avif looks just as bad.
|
|
2024-09-06 10:19:06
|
They're both unusable.
|
|
|
|
CrushedAsian255
|
2024-09-06 10:19:07
|
SSIM was 10 points better
|
|
|
Demiurge
They're both unusable.
|
|
2024-09-06 10:19:10
|
100%
|
|
2024-09-06 10:19:21
|
i am legally blind but can still tell they SUCK
|
|
|
|
Demiurge
|
2024-09-06 10:19:27
|
ssim shmim
|
|
|
|
CrushedAsian255
|
|
Demiurge
ssim shmim
|
|
2024-09-06 10:19:48
|
it's the best i can do
|
|
2024-09-06 10:20:37
|
im moving to <#803645746661425173>
|
|
|
|
Demiurge
|
2024-09-06 10:25:45
|
What's PIK frequency lifting?
|
|
|
|
Oleksii Matiash
|
|
CrushedAsian255
this is 0.056 bpp
|
|
2024-09-06 10:27:06
|
Could you please provide original image?
|
|
|
|
CrushedAsian255
|
2024-09-06 10:28:06
|
|
|
2024-09-06 10:28:06
|
originally was a jpeg
|
|
2024-09-06 01:09:01
|
I really think that FUIF could have achieved greatness, however this dang format called "jpeg xl"? came out and took all the attention!
/j
|
|
|
spider-mario
|
|
Demiurge
It's easier for the human brain to get a better idea of what the original image looks like by "seeing through" a "noisy transmission" or a "fuzzy glass pane" than it is when a compression artifact seems to smooth and blur and smudge parts of the image that had grit and texture before, essentially changing the subject of the image in a fundamental way that's hard for the brain to "see through" and reconstruct what's "behind" or "underneath" the artifacts.
|
|
2024-09-06 01:22:29
|
somewhat relevant: https://blog.kasson.com/the-last-word/detectability-of-visual-signals-below-the-noise/
|
|
|
|
lonjil
|
2024-09-06 01:39:47
|
there are many radio protocols whose signals are often below the noise floor
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 02:26:40
|
in butteraugli, the main reason for the 'Malta' transform is to lift the line features to be detectable even if they are below the noise
|
|
2024-09-06 02:27:23
|
line feature promotion was in my experiments the most dominant and most important feature detector in the human eye
|
|
2024-09-06 02:28:04
|
there are recorded anatomy of parallel lines detectors or 'texture' detectors, but in my experiments line detectors seemed more important
|
|
2024-09-06 02:28:53
|
In butteraugli, I started with 8x8 DCT, moved to 8x8 FFT then Gaussian windowed 16x16 FFT, and finally to Malta transform -- and correlations with my experiments improved at each step
|
|
|
yoochan
|
2024-09-06 04:35:53
|
A search for *Malta transform* only returns links relative to the country... Would you have a link to a meaningful resource on this?
|
|
|
|
Jyrki Alakuijala
|
2024-09-06 04:57:33
|
Malta transforms is just looking for 9-pixel long lines from the data (or was it 7-pixel long) don't remember
|
|
2024-09-06 04:58:05
|
I named it Malta transform as I had a visual hallusination when in Malta that showed these in my wetware visual processing
|
|
2024-09-06 04:58:29
|
not a real hallusination, just visual noise when very tired after a long day
|
|
2024-09-06 04:58:47
|
but hallusination sounds more appropriate when leading to a vision about vision
|
|
2024-09-06 05:00:38
|
https://github.com/libjxl/libjxl/blob/main/lib/jxl/butteraugli/butteraugli.cc#L577
|
|
2024-09-06 05:00:47
|
it is not easy to read because it is highway code
|
|
2024-09-06 05:01:38
|
and it is all of them, 7 and 9 pixel lines depending on the tilt angle
|
|
2024-09-06 05:01:56
|
in low frequency, it is just 5 pixels -- changes are slower there so ok to approximate
|
|
|
|
Demiurge
|
2024-09-06 06:28:41
|
I dislike the auto keyword...
|
|
2024-09-06 06:30:17
|
It's like it exists solely to provide less information and make it harder to understand
|
|
2024-09-06 06:34:47
|
And libjxl uses it a lot for some reason
|
|
2024-09-06 06:38:10
|
Maybe it has to do with templates...
|
|
|
|
spider-mario
|
2024-09-06 06:40:48
|
when you initialise a variable to `std::make_unique<jxl::MyType>(...)`, it feels redundant to repeat `std::unique_ptr<jxl::MyType>` in declaring it
|
|
2024-09-06 06:42:24
|
I would have more objection to something like:
```c++
auto size = container.size(); // is it unsigned? what width?
```
|
|
|
|
Demiurge
|
2024-09-06 06:43:34
|
I'm not an expert at c++ templates but I think you need to be in order to read much of libjxl
|
|
2024-09-06 06:44:27
|
They're not a commonly used part of the language nor do they have a particularly elegant syntax
|
|
|
|
lonjil
|
2024-09-06 08:16:17
|
`let sql = SqliteHandle::new("local.db".into())?;` guess the type of the sql variable
|
|
|
|
CrushedAsian255
|
|
lonjil
`let sql = SqliteHandle::new("local.db".into())?;` guess the type of the sql variable
|
|
2024-09-06 11:52:52
|
Is it a PostgresConmectionError?
|
|
|
Traneptora
|
2024-09-07 01:42:15
|
I have somewhat peculiar bug with jxlatte that's driving me crazy
|
|
|
|
CrushedAsian255
|
2024-09-07 01:42:39
|
What’s it doing?
|
|
|
|
Traneptora
|
2024-09-07 01:43:22
|
large varblocks are appearing blurry but only not in the first Block
|
|
2024-09-07 01:43:46
|
not really clear why to me
|
|
2024-09-07 01:44:25
|
I suspect epf but I'm unsure
|
|
|
|
CrushedAsian255
|
2024-09-07 01:44:29
|
Off by 1 error somewhere?
|
|
2024-09-07 01:44:42
|
Or maybe wrong initialisation parameters?
|
|
|
|
Traneptora
|
2024-09-07 02:01:57
|
it was epf
|
|
2024-09-07 02:02:13
|
although the real culprit was that HFMult was not being populated
|
|
|
|
CrushedAsian255
|
2024-09-07 02:03:00
|
EPF = edge preserving filter?
|
|
|
|
Traneptora
|
|
strawberry pie
|
2024-09-07 04:38:14
|
Hi, I made a vscode extension for viewing JPEG XL images!
|
|
2024-09-07 04:38:15
|
https://github.com/printfn/jpeg-xl-vscode
|
|
2024-09-07 04:38:48
|
<https://marketplace.visualstudio.com/items?itemName=printfn.jpeg-xl>
|
|
|
|
Oleksii Matiash
|
2024-09-07 12:32:23
|
<@794205442175402004> Could you please tell in a few words, what changes from e4 to e5 in VarDCT mode? There is something major, but what?
|
|
|
|
_wb_
|
|
Oleksii Matiash
<@794205442175402004> Could you please tell in a few words, what changes from e4 to e5 in VarDCT mode? There is something major, but what?
|
|
2024-09-07 01:29:57
|
Gaborish gets enabled, also chroma from luma. Gaborish is quite useful to get rid of blockiness.
|
|
|
|
Oleksii Matiash
|
|
_wb_
Gaborish gets enabled, also chroma from luma. Gaborish is quite useful to get rid of blockiness.
|
|
2024-09-07 01:58:20
|
Thank you!
|
|
|
|
CrushedAsian255
|
|
_wb_
Gaborish gets enabled, also chroma from luma. Gaborish is quite useful to get rid of blockiness.
|
|
2024-09-07 02:16:05
|
is gaborish adding the blurriness though?
maybe it's set too strong for higher distances
|
|
|
|
_wb_
|
2024-09-07 02:30:10
|
gaborish has a rather subtle effect, it's only a 3x3 convolution (decode side). you're probably thinking about the EPF
|
|
2024-09-07 02:30:28
|
EPF does larger-radius smoothing
|
|
|
|
CrushedAsian255
|
2024-09-07 02:35:00
|
maybe high-distance should lower the EPF a tiny bit, as they just become way too blurry
|
|
|
|
Traneptora
|
|
strawberry pie
https://github.com/printfn/jpeg-xl-vscode
|
|
2024-09-07 02:55:20
|
ohey, it uses jxl oxide wasm too
|
|
2024-09-07 02:55:58
|
appears to work on first glance
|
|
|
|
Oleksii Matiash
|
|
_wb_
Gaborish gets enabled, also chroma from luma. Gaborish is quite useful to get rid of blockiness.
|
|
2024-09-07 03:22:38
|
Tried all combination of effort, gaborish and epf. Disabling gaborish helps, but something else happens between e4 and e5, because e5 is still significantly more blurred than e4. And also artifacts look on smooth areas changes like it came from totally different encoders
|
|
|
|
_wb_
|
|
Oleksii Matiash
Tried all combination of effort, gaborish and epf. Disabling gaborish helps, but something else happens between e4 and e5, because e5 is still significantly more blurred than e4. And also artifacts look on smooth areas changes like it came from totally different encoders
|
|
2024-09-07 03:35:20
|
not sure what else is different between e4 and e5, maybe <@179701849576833024> or <@532010383041363969> have a better idea since they are more familiar than me with the vardct encode heuristics
|
|
|
|
veluca
|
2024-09-07 03:38:18
|
I remember nothing xD
|
|
|
|
Oleksii Matiash
|
2024-09-07 03:40:44
|
Just in case someone is interested. Encoding params are in filename
|
|
|
|
CrushedAsian255
|
2024-09-08 12:45:05
|
Are the JXL channel types extendable? It currently goes from 0-16 but the Enum type should be able to go up to around 60-70
|
|
|
Orum
|
2024-09-08 02:09:55
|
JXL supports are a lot more than just 70 channels
|
|
2024-09-08 02:10:47
|
according to Wikipedia:
> Up to 4099 channels. Main channels: either one channel for grayscale, three channels for RGB, or four channels for CMYK. The rest of the channels are optional and can be used to store alpha (either "straight" or "premultiplied"), depth, or thermal data.[17]
|
|
|
|
CrushedAsian255
|
|
Orum
JXL supports are a lot more than just 70 channels
|
|
2024-09-08 02:11:18
|
channel TYPES, not actual channels
|
|
2024-09-08 02:11:24
|
you can have 1000 alpha channels if you want
|
|
2024-09-08 02:11:50
|
it supports 3 RGB channels + 4096 "extra" channels, but each of the extra channels has an assigned type
|
|
|
|
Orum
|
2024-09-08 02:11:59
|
you mean just some metadata to describe the channel?
|
|
|
|
CrushedAsian255
|
2024-09-08 02:12:21
|
Table D.9 — ExtraChannelType
|
|
|
|
Orum
|
2024-09-08 02:12:44
|
I don't have the spec because it's paywalled
|
|
|
|
CrushedAsian255
|
2024-09-08 02:13:08
|
https://discord.com/channels/794206087879852103/1021189485960114198
|
|
|
username
|
2024-09-08 02:15:55
|
do you even need the spec? I swear I saw stuff about this in the libjxl docs and the overview slides
|
|
2024-09-08 02:16:46
|
like I'm pretty sure I've never read the spec but I know about the assigned channel types
|
|
|
|
CrushedAsian255
|
|
username
like I'm pretty sure I've never read the spec but I know about the assigned channel types
|
|
2024-09-08 02:17:03
|
im not sure, i just went to the spec cause that's where I read about them
|
|
|
|
username
|
2024-09-08 02:21:06
|
- https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.g453edbe13e776be4_24
- https://libjxl.readthedocs.io/en/latest/api_metadata.html#_CPPv419JxlExtraChannelType
|
|
2024-09-08 02:27:09
|
pretty sure 16 isn't the limit it's just the different types that are defined
|
|
2024-09-08 02:29:28
|
like uhhh I think if you want to have a custom type you just use `JXL_CHANNEL_OPTIONAL` which equals "Unknown but optional (can ignore)" in the slides and all the reserved ones are equal to "Unknown and not optional (need to update decoder)" in the slides
|
|
|
jonnyawsom3
|
2024-09-08 05:47:17
|
Optional is so the decoder can still load the RGB channels for example even if there's more data that cannot be parsed. Not optional is for when you need the extra data in the channels for the file to be useful, ect
|
|
|
|
CrushedAsian255
|
2024-09-08 05:47:44
|
metadata channels?
|
|
|
|
jonnyawsom3
|
2024-09-08 05:49:14
|
There are some types defined already, Alpha, Depth, Black, ect but more can be added if the use case is broad enough. One was added for RAW camera images for example, to store half of the G in the bayer grid and display the rest as an RGB image... Not that Adobe used anything unique to JXL for DNG....
|
|
2024-09-08 05:49:47
|
A while ago there was mention of adding some channel types for satellite imagery, but it wasn't needed after all
|
|
|
|
CrushedAsian255
|
2024-09-08 05:52:04
|
so i can just store random application specific data in reserved channels?
|
|
|
|
Orum
|
2024-09-08 05:53:16
|
isn't that the whole point?
|
|
2024-09-08 05:53:38
|
this is done all the time for game textures
|
|
|
|
jonnyawsom3
|
2024-09-08 05:55:07
|
Well what do you mean by reserved channels?
|
|
2024-09-08 05:55:19
|
```
kNonOptional 15 The decoder indicates it cannot safely interpret the semantics of this extra channel.
kOptional 16 Extra channel that can be safely ignored.
```It's fairly self explanatory
|
|
|
|
_wb_
|
2024-09-08 06:57:58
|
Channel types not defined in the spec are invalid to use so decoders are allowed to just refuse to decode. For application specific data, you should use kOptional if you want the jxl files to still be viewable by generic viewers, or kNonOptional if you want generic viewers to show some indication that there is data it could not interpret.
|
|
2024-09-08 06:59:19
|
Extra channels can have a name, so the idea is to use some naming convention to identify what exactly they are.
|
|
|
|
CrushedAsian255
|
|
_wb_
Extra channels can have a name, so the idea is to use some naming convention to identify what exactly they are.
|
|
2024-09-08 06:59:32
|
oh they support names
|
|
2024-09-08 06:59:35
|
that makes it easier
|
|
|
|
_wb_
|
2024-09-08 07:00:28
|
Same as layer names iirc, up to 1 kb of UTF-8. Should be plenty.
|
|
|
|
Traneptora
|
|
_wb_
Channel types not defined in the spec are invalid to use so decoders are allowed to just refuse to decode. For application specific data, you should use kOptional if you want the jxl files to still be viewable by generic viewers, or kNonOptional if you want generic viewers to show some indication that there is data it could not interpret.
|
|
2024-09-08 04:08:30
|
I see, so the intent is that kNonOptional is intended so an application that doesn't know what to do with this should say "I don't know what to do with this"
|
|
2024-09-08 04:08:52
|
whereas kOptional is safely able to be ignored by any application that doesn't know what to do with it?
|
|
|
|
_wb_
|
2024-09-08 04:10:43
|
Yes, exactly.
|
|
|
|
CrushedAsian255
|
2024-09-08 04:19:55
|
so something like app-specific metadata would be optional but something like a gain map would probably be nonoptional?
|
|
|
|
_wb_
|
2024-09-08 04:33:09
|
Gain map we plan to do as separate boxes. If it would be done as an extra channel, I suppose it would be non-optional if it's a traditional gain map (SDR->HDR) and optional if it's an inverse gain map (HDR->SDR), though it could also be made optional for both if interoperability is considered more important than having the correct image data...
|
|
|
|
CrushedAsian255
|
2024-09-08 04:33:49
|
Can’t JXL do native HDR with no gain map nonsense? If so, is there a point for gain maps?
|
|
2024-09-08 04:34:19
|
Also why is it better to have it in another box instead of an extra channel?
|
|
2024-09-08 04:34:40
|
I would count it as image data, like how iCC is image data
|
|
|
|
spider-mario
|
|
CrushedAsian255
Can’t JXL do native HDR with no gain map nonsense? If so, is there a point for gain maps?
|
|
2024-09-08 04:36:55
|
it can, but some want gain maps for more control over the SDR rendition
|
|
2024-09-08 04:37:31
|
(but even then, it’s not clear to me that gain maps are any better than just storing the SDR and HDR versions separately)
|
|
|
|
CrushedAsian255
|
2024-09-08 04:38:12
|
I guess it can save space?
|
|
|
|
spider-mario
|
2024-09-08 04:38:18
|
not in my testing
|
|
2024-09-08 04:39:07
|
plus, separate images + CSS selector could mean not having to download both
|
|
|
|
CrushedAsian255
|
2024-09-08 04:39:19
|
Are we talking grayscale gainmap or seperate r,g,b gainmap
|
|
|
|
username
|
|
CrushedAsian255
I guess it can save space?
|
|
2024-09-08 04:43:41
|
gainmaps aren't for efficiently or space saving they are pretty much just hacks that wouldn't exist in a more "perfect" world. I personally very much don't like them, like sure it's a cool idea but one that shouldn't have had to exist in the first place
|
|
|
|
CrushedAsian255
|
2024-09-08 04:44:26
|
So just store the HDR image and signal tone mapping curve?
|
|
|
|
spider-mario
|
2024-09-08 04:45:43
|
in principle, gain maps are more powerful than a fixed curve, since the curve can effectively vary over the image
|
|
|
|
CrushedAsian255
|
2024-09-08 04:46:26
|
Maybe Modular context modelling predictors can help?
|
|
|
NamelessGO
|
2024-09-08 04:49:40
|
Looking for default values of quality in JpegXL and AVIF, does someone knows them?
|
|
|
|
CrushedAsian255
|
2024-09-08 04:49:58
|
JXL: d 1
|
|
|
|
NamelessGO
|
2024-09-08 04:50:52
|
Found https://discord.com/channels/794206087879852103/803645746661425173/1237364536529391647 for JXL, it haven't changed recently right?
|
|
|
A homosapien
|
|
NamelessGO
Found https://discord.com/channels/794206087879852103/803645746661425173/1237364536529391647 for JXL, it haven't changed recently right?
|
|
2024-09-08 06:43:37
|
It's still effort=7, distance=1, and alpha=lossless
|
|
|
|
jonnyawsom3
|
|
_wb_
Gain map we plan to do as separate boxes. If it would be done as an extra channel, I suppose it would be non-optional if it's a traditional gain map (SDR->HDR) and optional if it's an inverse gain map (HDR->SDR), though it could also be made optional for both if interoperability is considered more important than having the correct image data...
|
|
2024-09-08 06:51:48
|
The boxes have already been added for a few months now https://github.com/libjxl/libjxl/pull/3552
|
|
2024-09-08 06:52:22
|
No API to use them yet though, I tried to jpeg transcode a gainmap image but it just got stored as brotli data
|
|
|
CrushedAsian255
Can’t JXL do native HDR with no gain map nonsense? If so, is there a point for gain maps?
|
|
2024-09-08 06:52:39
|
Ultra HDR Jpegs on the Pixel phones and such are the main reason it's been added, since now there's a lot of them with gainmaps already embedded that would transcode as SDR only
|
|
|
drkt
|
2024-09-09 07:36:38
|
It's so tempting... Some day...
|
|
|
|
jonnyawsom3
|
|
|
spider-mario
|
2024-09-09 08:00:51
|
darktable output format selection
|
|
|
|
jonnyawsom3
|
|
RaveSteel
|
2024-09-09 08:13:55
|
Already using it, since I can always convert on the fly to different formats if needed
|
|
|
|
drkt
|
|
spider-mario
darktable output format selection
|
|
2024-09-09 09:06:25
|
I'm amazed you knew what that was lol
|
|
|
|
spider-mario
|
2024-09-09 09:06:52
|
I’ve been a darktable user 😁
|
|
|
|
drkt
|
2024-09-09 09:10:15
|
As soon as the 2 big boy browsers support JXL, I'm on it man. Just waiting for it.
I could convert on the fly for users who don't report jxl support in their header but I'd really hate to serve a re-compressed jpg to someone
|
|
|
|
CrushedAsian255
|
2024-09-09 09:43:37
|
What happened with the Apple Event?
|
|
|
|
username
|
2024-09-09 09:44:05
|
nothing related to JXL
|
|
|
|
jonnyawsom3
|
2024-09-09 09:44:21
|
***Apple Intelligence***
|
|
2024-09-09 09:44:26
|
Sums it up :P
|
|
|
|
CrushedAsian255
|
|
***Apple Intelligence***
|
|
2024-09-09 09:45:05
|
lol
|
|
|
username
nothing related to JXL
|
|
2024-09-09 09:45:31
|
Well I don’t care then 🤪
|
|
2024-09-09 09:46:09
|
So I was right about speculating where the rumour came from)
|
|
|
monad
|
|
|
CrushedAsian255
|
2024-09-09 09:55:10
|
> 4K 120 fps ProRes
400 MB/s estimated bit rate
|
|
|
|
RaveSteel
|
2024-09-09 10:09:02
|
Sounds good, if only Google got off their asses and implemented something like this for Android
|
|
|
|
jonnyawsom3
|
2024-09-09 10:46:37
|
I could use OpenCamera and see how high my phone goes, but with 6 GB of storage left it might just crash immediately
|
|
|
|
RaveSteel
|
2024-09-09 10:47:31
|
OpenCamera goes to 200Mbit/s at the highest setting, but can go higher if the APK is edited. It is of course still limited to, at best, h.265
|
|
|
|
jonnyawsom3
|
2024-09-09 10:55:22
|
Well, that's assuming the encoder can keep up
|
|
|
|
RaveSteel
|
2024-09-09 10:55:59
|
I tried going up to 400Mbit/s, which worked on my phone
|
|
|
|
CrushedAsian255
|
2024-09-09 10:56:22
|
No guys, 400 megaBYTES per-second
|
|
2024-09-09 10:56:27
|
3.2 gigabits
|
|
|
|
jonnyawsom3
|
2024-09-09 10:56:32
|
Yeah, I know
|
|
|
|
RaveSteel
|
|
|
jonnyawsom3
|
2024-09-09 10:57:17
|
My phone can barely do 4K30, just talking about Android and device limits
|
|
|
Quackdoc
|
2024-09-09 10:58:09
|
typically you record to a buffer in memory and write it to storage real time
|
|
|
|
RaveSteel
|
2024-09-09 10:58:14
|
MotionCam is good for Video RAW, but of course it just devours storage
|
|
|
|
Quackdoc
|
2024-09-09 10:59:55
|
never forget, you can't legally sell products that encode "raw" footage that has been compressed because of red
|
|
|
|
RaveSteel
|
|
Quackdoc
never forget, you can't legally sell products that encode "raw" footage that has been compressed because of red
|
|
2024-09-09 11:01:37
|
Do you have an article or video discussing this?
|
|
2024-09-09 11:01:55
|
I only remember the drama with their SSDs
|
|
|
|
Quackdoc
|
2024-09-09 11:02:18
|
there are a few
|
|
2024-09-09 11:02:19
|
one sec
|
|
|
|
CrushedAsian255
|
|
Quackdoc
never forget, you can't legally sell products that encode "raw" footage that has been compressed because of red
|
|
2024-09-09 11:02:21
|
did they seriously patent compressed raw?
|
|
|
|
Quackdoc
|
2024-09-09 11:04:18
|
https://ymcinema.com/2022/12/08/red-vs-nikon-jury-trial-is-set-for-january-2024/
https://www.youtube.com/watch?v=__X25Fr2K_M&t=1s
|
|
2024-09-09 11:04:25
|
yeah
|
|
|
|
RaveSteel
|
2024-09-09 11:04:29
|
Thanks
|
|
2024-09-09 11:05:45
|
What the hell, this is ridiculous
|
|
|
|
CrushedAsian255
|
2024-09-09 11:05:58
|
can someone TL;DR
|
|
|
|
RaveSteel
|
2024-09-09 11:06:41
|
From my short reading: RED owns software patents regarding the shooting of RAW video that is compressed by the recording device
|
|
2024-09-09 11:06:57
|
Sony and Apple have previously lost in court against RED
|
|
|
|
CrushedAsian255
|
|
RaveSteel
From my short reading: RED owns software patents regarding the shooting of RAW video that is compressed by the recording device
|
|
2024-09-09 11:07:19
|
bruh
|
|
|
|
RaveSteel
|
2024-09-09 11:07:27
|
Bruh indeed
|
|
|
|
Quackdoc
|
2024-09-09 11:07:29
|
by all intents and purposes, the patent very clearly goes against patent law, but courts are people, and in 99.9999% of the cases, non technical people
|
|
2024-09-09 11:07:52
|
law is not about what act is right or wrong, but what you can convince the judge is
|
|
|
|
CrushedAsian255
|
2024-09-09 11:07:55
|
fine, i'm going to patent the local debayering of images at specifically 15 bits per pixel on the camera device
|
|
|
|
RaveSteel
|
2024-09-09 11:08:06
|
The entire western world should agree to abolish the concept of software patents
|
|
|
|
Quackdoc
|
|
RaveSteel
The entire western world should agree to abolish the concept of software patents
|
|
2024-09-09 11:09:04
|
politics aside, as I said, this isn't allowed under US law, but courts are idiots, even without patents, they would still screw someone over
|
|
|
|
RaveSteel
|
2024-09-09 11:09:14
|
Sadly true
|
|
|
|
Orum
|
2024-09-09 11:30:53
|
Nikon has a good case to demonstrate that the patent never should have been issued in the first place
|
|
2024-09-09 11:34:00
|
as you can see, the case was dismissed: https://ymcinema.com/2023/04/27/red-vs-nikon-case-dismissed/
|
|
2024-09-09 11:35:39
|
what likely happened behind the scenes was RED realized that they should have never been granted the patent in the first place, and thus to save face filed for dismissal
|
|
2024-09-09 11:36:15
|
so even though they still hold the patent, it's basically unenforceable, opening the floodgates for compressed raw video <:YEP:808828808127971399>
|
|
2024-09-09 11:47:46
|
in any case now that Nikon owns RED there's no more feuding between them <:CatSmile:805382488293244929>
|
|
|
|
Quackdoc
|
2024-09-09 11:48:33
|
<:YEP:808828808127971399>
|
|
|
|
Jyrki Alakuijala
|
2024-09-09 11:53:43
|
https://www.macrumors.com/2024/09/09/iphone-16-pro-supports-jpeg-xl-format/
|
|
2024-09-09 11:54:05
|
"wasn't mentioned in the launch, but is still there"
|
|
2024-09-09 11:54:20
|
this is like a soap opera but more exciting
|
|
|
|
Traneptora
|
|
Quackdoc
by all intents and purposes, the patent very clearly goes against patent law, but courts are people, and in 99.9999% of the cases, non technical people
|
|
2024-09-10 02:33:16
|
an issue is legally, for a court to overturn the US Patent's office issuance of a patent requires a much greater burden of proof
|
|
2024-09-10 02:34:09
|
so for the defendent to prove that they infringed upon the patent that should never have been awarded and thus the patent is invalid is a much greater thing to prove and the burden of proof lies on the defendent to prove this. it is not the burden of proof of the plaintiff to prove that their patent was valid, as they did that when they were granted it in the first place
|
|
2024-09-10 02:35:26
|
one issue with the patent law in the US is that in order for something to be patent-able, it has to be an invention, i.e. it has to not be "obvious"
"obvious" here is an actual legal term that means that a general someone who is an expert in the field would know about the invented technique. but the way the law is written is that the patent office can demonstrate "obviousness" only by finding existing references to the technique in literature
|
|
|
|
Quackdoc
|
|
Traneptora
so for the defendent to prove that they infringed upon the patent that should never have been awarded and thus the patent is invalid is a much greater thing to prove and the burden of proof lies on the defendent to prove this. it is not the burden of proof of the plaintiff to prove that their patent was valid, as they did that when they were granted it in the first place
|
|
2024-09-10 02:38:14
|
this is true, the primary issue is that there is an abundance of evidence. the patents granted are insanely generic. It's very much under the "patenting a concept" realm, which most typically doesn't hold up (rocksmith case is a great example of this `Ubisoft Entertainment, S.A. et al v. Yousician Oy `).
|
|
2024-09-10 02:39:39
|
proving it to a court on the other hand is hard, I have no doubt most technically inclined folk would be quick to agree that the genericness of the patent is absurd, but unless you can manage to teach a full tech class, proving that to realtively less technically included judges is going to be an issue
|
|
|
|
Traneptora
|
|
Quackdoc
this is true, the primary issue is that there is an abundance of evidence. the patents granted are insanely generic. It's very much under the "patenting a concept" realm, which most typically doesn't hold up (rocksmith case is a great example of this `Ubisoft Entertainment, S.A. et al v. Yousician Oy `).
|
|
2024-09-10 02:39:51
|
also worth mentioning that a patent awarded before *KSR vs Teleflex* may need to be challenged individually. they aren't grandfathered in
|
|
|
|
Quackdoc
|
2024-09-10 02:40:37
|
0.0 didn't realize they weren't but IIRC that doesn't apply here? I can't remeber when the red patents were filed
|
|
|
|
Traneptora
|
2024-09-10 02:40:44
|
I don't know
|
|
|
|
Quackdoc
|
2024-09-10 02:42:21
|
well in any case, it's a rough situation to be in, i was talking with a friend and **maybe** dumping DNG sequence into a compressed tarball could technically be ok, but it's not a safe bet lol
|
|
|
|
Traneptora
|
|
Quackdoc
0.0 didn't realize they weren't but IIRC that doesn't apply here? I can't remeber when the red patents were filed
|
|
2024-09-10 02:43:46
|
I checked, they aren't, but the issue was that the judge ruled that the burden of proof was on Apple to prove the patent should not have been awarded and the judge ruled that apple had not sufficiently proven the patent was obvious in court
|
|
2024-09-10 02:44:00
|
which may have been a fuckup on apple's legal team, it may actually have not been proven. I don't know the case
|
|
|
|
Quackdoc
|
2024-09-10 02:46:43
|
well in any case, the case against nikon was dissmissed at least which was at least a minor win. not like it matters much any more though since nikon bought them out, would be interesting to see if red keeps up the patent trolling
|
|
|
|
Just me
|
2024-09-10 04:08:44
|
Is it possible to retrieve JPEG XL dimensions using few first bytes like JPEG and PNG? Please publish sample code on GitHub or elsewhere...
|
|
|
|
Orum
|
|
Traneptora
I checked, they aren't, but the issue was that the judge ruled that the burden of proof was on Apple to prove the patent should not have been awarded and the judge ruled that apple had not sufficiently proven the patent was obvious in court
|
|
2024-09-10 04:30:13
|
AFAIK Apple tried to attack the patent on technical merit
|
|
2024-09-10 04:31:00
|
Nikon's legal team was the one that brought the issuance of the patent into play, arguing that RED had sold cameras with the tech over a year prior to filing for the patent (thus making it non-patentable)
|
|
|
|
CrushedAsian255
|
|
Just me
Is it possible to retrieve JPEG XL dimensions using few first bytes like JPEG and PNG? Please publish sample code on GitHub or elsewhere...
|
|
2024-09-10 04:38:34
|
yes, the header contains the image size
|
|
2024-09-10 04:38:51
|
which is at the beginning of the codestream
|
|
2024-09-10 04:39:07
|
if in the container, there may be metadata boxes in front of the codesteream
|
|
2024-09-10 04:39:25
|
however the header is usually in a partial codestream box before the metadata, at least that's how cjxl does it
|
|
|
|
jonnyawsom3
|
|
Just me
Is it possible to retrieve JPEG XL dimensions using few first bytes like JPEG and PNG? Please publish sample code on GitHub or elsewhere...
|
|
2024-09-10 05:01:34
|
This should help
|
|
|
Arcane
|
2024-09-10 05:25:17
|
Vote Booster: Vote now for a 10% boost. <https://arcane.bot/vote>
✨ **Tip:** Use `/card` to modify your rank card
|
|
|
|
A homosapien
|
|
|
monad
|
|
Just me
Is it possible to retrieve JPEG XL dimensions using few first bytes like JPEG and PNG? Please publish sample code on GitHub or elsewhere...
|
|
2024-09-10 06:01:23
|
<https://github.com/Fraetor/jxl_decode/blob/main/src/jxl_decode/jxl.py>
|
|
|
|
Traneptora
|
|
Just me
Is it possible to retrieve JPEG XL dimensions using few first bytes like JPEG and PNG? Please publish sample code on GitHub or elsewhere...
|
|
2024-09-10 08:35:34
|
There's a decent amount of code that does this. https://github.com/Traneptora/jxlatte/ is my decoder that is on github
|
|
2024-09-10 08:36:39
|
or https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec/jpegxl_parser.c
|
|
|
|
_wb_
|
2024-09-10 08:55:03
|
is anyone here behind the https://x.com/r_dikshan56997 account?
|
|
|
|
Just me
|
|
Traneptora
or https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec/jpegxl_parser.c
|
|
2024-09-10 09:32:05
|
Just libraries aren't quite code samples/SDK/snippets. Just libraries are less convenient. Even <@263300458888691714> needs extra code for it to work as CLI, GUI or in the cloud...
|
|
|
|
Traneptora
|
|
Just me
Just libraries aren't quite code samples/SDK/snippets. Just libraries are less convenient. Even <@263300458888691714> needs extra code for it to work as CLI, GUI or in the cloud...
|
|
2024-09-10 01:34:36
|
Is this a homework assignment for a CS class
|
|
2024-09-10 01:38:11
|
like what do you actually want here
|
|
2024-09-10 01:39:13
|
if you just want to *know how* to parse the size header then read the code people posted
|
|
2024-09-10 01:39:40
|
if you just want something you can execute in a script, run `jxlinfo`
|
|
|
|
Just me
|
2024-09-10 01:40:33
|
Some trimmed down jxlinfo without irrelevant parts...
|
|
|
|
Traneptora
|
2024-09-10 01:40:54
|
that's what grep and sed are for
|
|
|
|
lonjil
|
2024-09-10 01:41:18
|
Alternatively, ImageMagick has a syntax for outputting just the specific image information you want
|
|
|
|
Traneptora
|
2024-09-10 01:41:43
|
sounds like they're trying to get us to do CS homework for them
|
|
2024-09-10 01:42:38
|
probably need to write C++ code in some cloud-based GUI that feeds directly into a verifier and thus cannot use grep, sed, etc.
|
|
2024-09-10 01:43:04
|
otherwise they'd just use that
|
|
|
|
lonjil
|
2024-09-10 01:43:19
|
If it's for a script, here you go: `magick identify -format "%wx%h"`
|
|
|
|
Traneptora
|
2024-09-10 01:43:55
|
yea, though consisering the question it probably isn't going to solve their homework problem
|
|
|
|
Just me
|
|
Traneptora
Is this a homework assignment for a CS class
|
|
2024-09-10 01:45:02
|
You know better than me...
|
|
|
|
Traneptora
|
2024-09-10 01:45:34
|
hm?
|
|
2024-09-10 01:46:08
|
you know homework exists specifically for you to actually have to think about the problem right
|
|
|
|
5peak
|
|
Jyrki Alakuijala
this is like a soap opera but more exciting
|
|
2024-09-10 03:46:29
|
€ grep -rn JPEGXL
Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/AVFoundation.framework/Headers/AVVideoSettings.h:51: AVF_EXPORT AVVideoCodecType const AVVideoCodecTypeJPEGXL /* @"jxlc" */ API_AVAILABLE(macos(15.0), ios(18.0), tvos(18.0), visionos(2.0)) API_UNAVAILABLE(watchos);
|
|
2024-09-10 03:46:58
|
So not just rumo(u)rs.
|
|
|
Meow
|
2024-09-10 05:47:39
|
They are just codes
|
|
|
𐑛𐑦𐑕𐑣𐑸𐑥𐑩𐑯𐑦 | 最不調和の伝播者 | 異議の元素
|
|
_wb_
is anyone here behind the https://x.com/r_dikshan56997 account?
|
|
2024-09-10 06:22:31
|
wow that's persistent
|
|
|
|
_wb_
|
2024-09-10 07:01:25
|
or a cronjob 🙂
|
|
|
|
monad
|
|
Just me
Just libraries aren't quite code samples/SDK/snippets. Just libraries are less convenient. Even <@263300458888691714> needs extra code for it to work as CLI, GUI or in the cloud...
|
|
2024-09-10 10:06:53
|
That's not me, it's <@176735987907559425>. I thought you were looking for sample code, and that is a very readable one.
|
|
|
|
_wb_
|
2024-09-11 11:25:40
|
|
|
2024-09-11 11:26:41
|
Birthday of one of my daughters, we are having fun with pancakes
|
|
|
|
Orum
|
2024-09-11 11:35:05
|
"Daddy, who is JXL?"
|
|
|
TheBigBadBoy - 𝙸𝚛
|
|
Orum
"Daddy, who is JXL?"
|
|
2024-09-11 11:36:28
|
"It's Dad's 2nd name" [⠀](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&quality=lossless&name=av1_chad)
|
|
|
|
_wb_
|
2024-09-11 11:39:28
|
My second attempt
|
|
2024-09-11 11:43:49
|
|
|
|
|
CrushedAsian255
|
|
_wb_
My second attempt
|
|
2024-09-11 11:49:50
|
Does your daughter like the format?
|
|
|
|
Oleksii Matiash
|
|
_wb_
|
|
2024-09-11 11:50:23
|
Second photo - packing into 45 bytes
|
|
|
|
_wb_
|
2024-09-11 11:54:06
|
I did it in only 12 bites
|
|
|
|
Oleksii Matiash
|
|
_wb_
My second attempt
|
|
2024-09-11 11:54:58
|
Worth to be chosen as official logo
|
|
|
|
monad
|
2024-09-11 12:32:12
|
|
|
2024-09-11 12:33:16
|
a bit unreadable emoji size ... maybe someone can make better one
|
|
|
|
lonjil
|
2024-09-11 12:33:45
|
how about having it as a sticker?
|
|
|
|
CrushedAsian255
|
2024-09-11 12:34:17
|
that would work
|
|
2024-09-11 12:34:37
|
the server is out of sticker slots though
|
|
2024-09-11 12:34:53
|
it's currently just filled with fox stickers
|
|
|
|
monad
|
2024-09-11 12:35:04
|
okay, I didn't know that was a thing, but it's obvious who made them
|
|
|
|
CrushedAsian255
|
2024-09-11 12:35:20
|
i think they boosted the server just to import fox stickers lol
|
|
2024-09-11 12:37:57
|
also <@219525188818042881> you need to put better descriptions on the stickers, it's a geniune accessibility feature.
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-09-11 01:04:01
|
lmao Fox Wizard really filled the server stickers with foxes <:kekw:808717074305122316>
|
|
|
|
_wb_
|
2024-09-11 01:45:12
|
let me replace one of the foxes with the pancake then
|
|
2024-09-11 01:47:25
|
|
|
|
|
lonjil
|
2024-09-11 01:47:36
|
|
|
2024-09-11 01:47:38
|
nice
|
|
|
BANNED! add coox1e
|
2024-09-11 01:58:48
|
what if they made Jpeg XL 2
|
|
2024-09-11 01:58:59
|
jpeg xl the movie
|
|
|
dogelition
|
2024-09-11 02:02:04
|
JPEG XXL
|
|
|
|
BANNED! add coox1e
|
2024-09-11 02:24:08
|
yeah that's the original message I was going to send
|
|
|
mincerafter42
|
2024-09-11 08:00:19
|
woah just noticed the JXL info page changed; when did that happen
|
|
|
|
_wb_
|
2024-09-11 08:02:01
|
Sunday evening
|
|
|
|
jonnyawsom3
|
|
Oleksii Matiash
Second photo - packing into 45 bytes
|
|
2024-09-11 09:17:00
|
We should have a joke page on the website, demonstrating the compact nature of JXL down to 12 bites
|
|
|
_wb_
|
|
2024-09-11 09:17:18
|
The second image demonstrates the Squeeze transform if I'm not mistaken
|
|
2024-09-11 09:17:51
|
Half size, double depth
|
|
|
|
CrushedAsian255
|
2024-09-11 09:18:51
|
Omg so true
|
|
|
Bulbasaur
|
2024-09-11 10:01:24
|
curious if jpegxl progressive decoding would be suitable for literally only ever serving a single image on the web, and just only fetching different byte thresholds for users with different network constraints?
|
|
2024-09-11 10:01:40
|
e.g taking progressive decoding but cancelling the full download - only ever using the partially decoded version
|
|
|
|
jonnyawsom3
|
2024-09-11 10:44:10
|
If you mean a single file with multiple images you could select which one to download, JXL does also have layers so you could probably progressively load those using the table of contents.
If you mean only downloading XX% of the file to save on data usage, it also should be possible and I was actually discussing it a week or two ago here https://discord.com/channels/794206087879852103/794206170445119489/1279372576946393180
|
|
|
|
Bulbasaur
|
|
If you mean a single file with multiple images you could select which one to download, JXL does also have layers so you could probably progressively load those using the table of contents.
If you mean only downloading XX% of the file to save on data usage, it also should be possible and I was actually discussing it a week or two ago here https://discord.com/channels/794206087879852103/794206170445119489/1279372576946393180
|
|
2024-09-12 01:27:48
|
Yeah, I was thinking the latter
|
|
2024-09-12 01:28:23
|
(presumably in a way that browsers could automatically implement)
|
|
2024-09-12 01:28:40
|
the 206 content idea is neat, you could have query params to guide an edge cdn to cut off serving using that
|
|
2024-09-12 01:29:02
|
similar to how many cdns let you do various operations on images just-in-time
|
|
2024-09-12 01:30:07
|
the cdn could handle things like `?quality=...` with only having one source file and no repacking into a different cached file
|
|
|
pixyc
|
|
|
A homosapien
|
|
_wb_
|
|
2024-09-12 04:48:03
|
Petition to make this the new official logo of JPEG XL <:galaxybrain:821831336372338729>
|
|
|
|
monad
|
2024-09-12 05:04:14
|
Is that even controversial?
|
|
|
|
CrushedAsian255
|
|
A homosapien
Petition to make this the new official logo of JPEG XL <:galaxybrain:821831336372338729>
|
|
2024-09-12 05:12:36
|
PUSH IT
|
|
|
|
A homosapien
|
2024-09-12 05:35:40
|
It would unironically be a good April fools' joke
|
|
|
|
monad
|
2024-09-12 06:25:03
|
|
|
2024-09-12 06:25:31
|
higher res, more precise masking
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-09-12 06:28:16
|
(I would have preferred if it wasn't cut with a straight line at the bottom <:KekDog:805390049033191445>)
|
|
|
|
monad
|
2024-09-12 06:28:32
|
blame Jon's photography skills
|
|
|
|
CrushedAsian255
|
2024-09-12 06:38:10
|
|
|
2024-09-12 06:38:11
|
yay
|
|
|
|
_wb_
|
2024-09-12 06:47:07
|
I should have taken a better picture before eating it. I was hungry though.
|
|
|
|
Orum
|
2024-09-12 06:48:04
|
we can make more; we have the technology <:pancakexl:1283670260209156128>
|
|
|
|
Quackdoc
|
|
TheBigBadBoy - 𝙸𝚛
(I would have preferred if it wasn't cut with a straight line at the bottom <:KekDog:805390049033191445>)
|
|
2024-09-12 06:49:35
|
use AI
|
|
|
|
_wb_
|
2024-09-12 06:49:50
|
You need milk, flour, eggs, butter, and some food coloring.
|
|
2024-09-12 06:51:52
|
Normally I would add some dark beer to the batter but the only bottles I had available were all too good to be used for that. Used sparkling water instead, that also works.
|
|
|
|
Orum
|
|
_wb_
You need milk, flour, eggs, butter, and some food coloring.
|
|
2024-09-12 06:52:31
|
instructions unclear, baked a cake instead <:Thonk:805904896879493180>
|
|
2024-09-12 06:53:04
|
seriously though we should have a JXL pancake contest
|
|
2024-09-12 06:53:28
|
winner is the one with the least bytes <:YEP:808828808127971399>
|
|
|
|
Quackdoc
|
2024-09-12 06:54:06
|
least bytes and most bites should be weighed equally
|
|
|
|
monad
|
2024-09-12 06:55:34
|
could just measure everything in nibbles
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
|
Quackdoc
use AI
|
|
2024-09-12 07:00:31
|
meh
|
|
|
|
Quackdoc
|
|
TheBigBadBoy - 𝙸𝚛
meh
|
|
2024-09-12 07:00:55
|
blue syrup yuck
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-09-12 07:01:00
|
text is always too difficult <:KekDog:805390049033191445>
it did understand that the blue was on the pancake, but forgot JPEG XL lol
|
|
|
|
CrushedAsian255
|
2024-09-12 07:07:36
|
my favourite formats "PEG XL 'IL" and "JPPEG"
|
|
|
|
monad
|
2024-09-12 07:09:21
|
that's clearly PEG XL 'IL
|
|
|
|
CrushedAsian255
|
2024-09-12 07:10:19
|
me when eyes
|
|
2024-09-12 07:11:41
|
also here is that image as a JXL
|
|
2024-09-12 07:11:45
|
because why not
|
|
2024-09-12 07:43:27
|
for April Fools, rename the server to "The AVIF Community"
|
|
|
|
monad
|
|
|
CrushedAsian255
|
2024-09-12 07:53:07
|
very representative of AVIF's smoothing
|
|
|
|
yoochan
|
2024-09-12 07:57:23
|
more smooth less faithful
|
|
|
|
_wb_
|
2024-09-12 08:19:46
|
For those not following <#824000991891554375> , <@132186538325835776> created this nice image that could actually be useful if you need a PQ test pattern.
|
|
|
|
Tirr
|
2024-09-12 08:28:42
|
would be useful to test hdr support
|
|
2024-09-12 08:30:28
|
and color management overall, because bt.709 color bars at bottom left and right will look very weird if image viewer doesn't do color management properly
|
|
|
|
embed
|
2024-09-12 08:34:15
|
https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/1283703593081245736/ITU-R_BT.2111-2-Test_pattern_PQ_full_range.jxl?ex=66e3f5a2&is=66e2a422&hm=3a383a2b44b79e82be87746e5f258b68d017f64ffafc743e261252268ef592ad&
|
|
|
|
Tirr
|
2024-09-12 08:40:47
|
it's supposed to look like this, mapped to sRGB
|
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-09-12 08:49:34
|
the shadow of the 3 right upper bands is gone <:Thonk:805904896879493180>
|
|
|
|
dogelition
|
2024-09-12 08:59:39
|
chromium's tone mapping also looks nice, see here https://discord.com/channels/794206087879852103/824000991891554375/1283499159332196403 (assuming you're using the discord website/desktop app and hdr is disabled)
|
|
2024-09-12 09:00:20
|
would be nice if the bot embeds came with the right icc profiles, like when using `djxl` to output a png
|
|
|
|
Quackdoc
|
2024-09-12 09:03:12
|
I wonder how the various libplacebo shaders will do.
|
|