|
Traneptora
|
2022-11-16 01:05:57
|
looks like chroma's getting pulled sideways
|
|
2022-11-16 01:11:09
|
huh? this image is subsampled horizontally
|
|
2022-11-16 01:11:15
|
why is *this* happening now lol
|
|
2022-11-16 01:18:27
|
|
|
2022-11-16 01:18:31
|
lmao, it's every *two* pixels
|
|
2022-11-16 01:19:56
|
hm, every block is transposed, so it's probably something to do with the HF coefficients
|
|
2022-11-16 01:26:21
|
ill have to figure it out later, oh well
|
|
|
Jyrki Alakuijala
|
|
Traneptora
but why does it reset every 8 varblocks?
|
|
2022-11-16 08:43:02
|
could be a chroma-from-luma issue? it has a possibility for a new weight for every 64x64 pixels
|
|
|
_wb_
|
2022-11-16 08:47:34
|
that first one does look like a chroma from luma issue indeed; the other one with the stripes looks like a problem with the ycbcr chroma upsampling
|
|
|
|
Traneptora
|
|
Jyrki Alakuijala
could be a chroma-from-luma issue? it has a possibility for a new weight for every 64x64 pixels
|
|
2022-11-16 09:31:38
|
those 8 varblocks were actually groups, although there was a CFL issue
|
|
|
_wb_
that first one does look like a chroma from luma issue indeed; the other one with the stripes looks like a problem with the ycbcr chroma upsampling
|
|
2022-11-16 09:32:36
|
this image is subsampled horizontally only, and I perform the subsampling after inverting the VarDCT and transposing the blocks, which means these stripes are actually vertical
|
|
2022-11-16 09:32:56
|
so it's definitely a subsampling-related bug but not a bug *with* the upsampling
|
|
2022-11-16 09:34:08
|
since if I didn't upsample these would still be horizontal stripes
|
|
2022-11-16 02:42:08
|
I have a lossless JXL file (my profile picture) which I created from a PNG
|
|
2022-11-16 02:42:48
|
the PNG appears to have been tagged with a Gamma of 0.454550, rather than an sRGB chunk
|
|
2022-11-16 02:43:22
|
If I run: `cjxl -d 0 image.png image.jxl`
|
|
2022-11-16 02:43:35
|
then my viewer views these two differently
|
|
2022-11-16 02:44:59
|
I tried decoding the image from JXL -> PNG with jxlatte, whcih first inverts the transfer function of the encoded image, and then applies the sRGB transfer function, and writes an sRGB-tagged PNG. That is, it handles color management correctly. I'm assuming my image viewer can view an sRGB PNG correctly, so I'm using that as a baseline.
|
|
2022-11-16 02:45:23
|
Interestingly, the viewer (which is based on gdk-pixbuf) views the JXL image exactly the same way.
|
|
2022-11-16 02:45:43
|
Is it possibly my viewer is ignoring the gAMA chunk of the original PNG and pretending the pixel data is sRGB even if it isn't?
|
|
|
spider-mario
|
2022-11-16 02:46:19
|
yes, it seems quite common
|
|
2022-11-16 02:46:48
|
it led me to write https://github.com/libjxl/libjxl/pull/270
|
|
2022-11-16 02:47:08
|
but it may not have survived the “big codec migration”
|
|
|
|
Traneptora
|
2022-11-16 02:47:16
|
Alternatively, is it possible that the data is actually sRGB, but imagemagick added a gAMA fallback tag, which libjxl then interpreted as written?
|
|
|
|
spider-mario
|
2022-11-16 02:47:40
|
oh, right, there’s that issue as well
|
|
2022-11-16 02:47:41
|
https://github.com/ImageMagick/ImageMagick/issues/4375
|
|
2022-11-16 02:48:11
|
the issue is not just that it adds a gAMA chunk, but that it drops the sRGB chunk, making the gAMA authoritative
|
|
|
|
Traneptora
|
2022-11-16 02:48:15
|
I see, so the pixel data of the original is actually sRGB, but IM is tagging it incorrectly
|
|
2022-11-16 02:48:25
|
and libjxl interprets it according to spec
|
|
|
|
spider-mario
|
2022-11-16 02:48:49
|
I see that they have “closed this as completed” but I must admit that I am doubtful
|
|
2022-11-16 02:49:55
|
but yeah, #270 originated in part from this mess
|
|
2022-11-16 02:50:02
|
it’s unfortunate if we don’t work around it anymore
|
|
|
|
Traneptora
|
2022-11-16 02:53:04
|
So what I'm gathering is that IM wrote an sRGB PNG but tagged it as a Gamma2.2
|
|
2022-11-16 02:53:19
|
instead of sRGB
|
|
2022-11-16 02:53:34
|
libjxl interpreted the pixel data when creating the JXL file as Gamma2.2, as tagged
|
|
2022-11-16 02:53:55
|
both libjxl and jxlatte correctly process the resulting JXL file, which converts it to linear and then to sRGB before outputting sRGB data.
|
|
2022-11-16 02:54:36
|
likewise, my viewer is ignoring the gAMA tag in the original one, and reading it as though it were sRGB
|
|
2022-11-16 02:55:12
|
if it respected the gAMA tag, it would all look correct, but it doesn't, so it all looks wrong.
|
|
|
|
spider-mario
|
2022-11-16 02:55:30
|
that seems plausible
|
|
2022-11-16 02:55:41
|
Chrome does respect the gAMA chunk so it may be a way to check
|
|
2022-11-16 02:56:07
|
the goal of #270 was for the rendering to be “equally wrong” between input and output
|
|
2022-11-16 02:56:51
|
i.e. if a viewer ignores the gAMA chunk, it does so for the original _and_ decoded image, and likewise if it takes it into account
|
|
|
|
_wb_
|
2022-11-16 03:10:11
|
It's a bit of a mess, the main problem being IM producing incorrectly tagged images (which may be fixed but the buggy versions are still going to be the ones in most distros right now)
|
|
|
|
spider-mario
|
2022-11-16 03:10:32
|
to say nothing of the images already produced
|
|
|
|
Traneptora
|
2022-11-16 03:13:35
|
I see, so currently libjxl 0.7 and jxlatte both correctly transfer the image to sRGB then write an sRGB PNG
|
|
2022-11-16 03:13:52
|
but #270 changes it, so it just writes a Gamma2.2 PNG instead and doesn't transfer the pixels
|
|
2022-11-16 03:14:19
|
FWIW FFmpeg always requests it in the tagged color space if possible
|
|
2022-11-16 03:14:35
|
so I wonder if I could decode it with ffmpeg and see what happens
|
|
|
spider-mario
Chrome does respect the gAMA chunk so it may be a way to check
|
|
2022-11-16 03:18:30
|
firefox and chromium have the gamma2.2 and the resulting sRGB one look identical, so it appears both respect their tagged colors
|
|
2022-11-16 03:19:09
|
this saves me a headache as I don't have to then convert them to sRGB
|
|
2022-11-16 03:19:34
|
luckily I could actually do that with jxlatte, since it only writes sRGB PNGs
|
|
2022-11-16 03:19:40
|
it refuses to write anything else atm with the CLI
|
|
2022-11-16 03:19:58
|
and if the input isn't sRGB, it tonemaps it first
|
|
|
|
spider-mario
|
|
Traneptora
but #270 changes it, so it just writes a Gamma2.2 PNG instead and doesn't transfer the pixels
|
|
2022-11-16 03:54:12
|
it’s slightly different: the old cjxl (#270 was quite a while ago) used to convert to the original colorspace, so the 2.2 gamma one, but it would synthesize an ICC profile representing that colorspace
|
|
2022-11-16 03:54:34
|
so applications that didn’t take into account the gAMA chunk of the input image would suddenly take into account our ICC profile in the decoded image
|
|
2022-11-16 03:54:46
|
so the ~same pixel values would look different
|
|
|
|
Traneptora
|
2022-11-16 03:54:50
|
ah, because ICC Profiles had better support than gAMA
|
|
|
|
spider-mario
|
|
|
Traneptora
|
2022-11-16 03:55:05
|
now you output gAMA when gAMA is input
|
|
2022-11-16 03:55:15
|
by tagging the JXL as gamma=0.454550
|
|
|
|
spider-mario
|
2022-11-16 03:55:24
|
that was the intent, but I think we lost that behavior with the new djxl
|
|
2022-11-16 03:55:41
|
the jxl always has been, I believe
|
|
2022-11-16 03:55:53
|
but #270 extended it to the decoded PNG
|
|
|
|
Traneptora
|
2022-11-16 03:55:55
|
I'm not decoding these with djxl btw, I'm using libjxl with my image viewer, which just requests sRGB directly from libjxl and gets it
|
|
2022-11-16 03:56:11
|
so it ends up correct
|
|
2022-11-16 03:56:43
|
but what you're saying is that the new djxl requests pixels in the tagged space, and writes a PNG in that space
|
|
|
|
spider-mario
|
2022-11-16 03:57:06
|
the old djxl did
|
|
|
|
Traneptora
|
2022-11-16 03:57:56
|
oh what changed is that you don't synthesize an ICC Profile if the output format can represent it with tags?
|
|
|
|
spider-mario
|
2022-11-16 03:58:29
|
yes, however that change was only ever applied to legacy djxl, the one that used the internal C++ API
|
|
2022-11-16 03:58:54
|
when we rewrote djxl to use the public C API (“djxl_ng”), we may not have maintained that behavior
|
|
|
|
Traneptora
|
2022-11-16 03:58:55
|
ah, I see, it never made it into the libjxl-based djxl
|
|
2022-11-16 03:59:18
|
I do know FFmpeg does exactly that, it doesn't request an ICC Profile from libjxl if the tags are supported by FFmpeg tags
|
|
2022-11-16 03:59:40
|
which they typically are
|
|
|
|
spider-mario
|
2022-11-16 04:00:57
|
I have the impression that we _could_ add that behavior back to djxl_ng
|
|
2022-11-16 04:01:14
|
the information that the png encoder needs seems accessible
|
|
|
Gulghast
|
2022-11-16 05:36:40
|
hey, just joined to ask something
|
|
2022-11-16 05:36:55
|
did -d 1 stop working in the 0.7 version?
|
|
2022-11-16 05:37:37
|
adding it on the cmd doesn't do anything, might be my fault tho idk
|
|
|
fab
|
2022-11-16 05:40:23
|
I changed the -
|
|
2022-11-16 05:40:30
|
But it doesn't work
|
|
2022-11-16 05:40:50
|
So I encoded a single image
|
|
2022-11-16 05:41:12
|
I guess you need to upgrade to win 10 or Eleven
|
|
|
diskorduser
|
|
Gulghast
did -d 1 stop working in the 0.7 version?
|
|
2022-11-16 05:48:39
|
Are you using jpeg source?
|
|
|
|
Gulghast
|
2022-11-16 05:49:02
|
wdym
|
|
2022-11-16 05:53:39
|
ohh yeah, -d 1 does work if the source isn't jpeg
|
|
|
|
diskorduser
|
2022-11-16 05:55:11
|
Use -j flag
|
|
|
|
Gulghast
|
|
diskorduser
Use -j flag
|
|
2022-11-16 05:58:42
|
like instead of "-d 1" I put "-j 1"?
|
|
|
|
diskorduser
|
2022-11-16 05:59:10
|
Use both. -d 1 -j 0
|
|
|
|
Gulghast
|
2022-11-16 05:59:38
|
worked, thanks
|
|
|
|
diskorduser
|
2022-11-16 06:01:33
|
For more info, check: cjxl -h -v -v -v
|
|
|
Demiurge
|
2022-11-16 08:15:24
|
<@794205442175402004> I have noticed the work you've been doing lately to develop better objective psychovisual models for determining visual fidelity. I notice you even have a "wall of shame" website (although I cannot find it again at the moment) that demonstrates the disagreement between objective measurements. I notice that a lot of the comparisons there are very subjective which one looks better, as each one looses detail in one area at the expense of gaining it in another, and it becomes a matter of which details are more important to preserve to maintain fidelity... even though the loss of detail is extremely noticeable no matter which one you choose. I just wanted to offer my observation that I'm sometimes surprised with the results of this new metric, I think it's called xyb-ssimulacra2. It seems to prefer smoothing away fine detail and texture compared to other algorithms.
|
|
2022-11-16 08:17:08
|
I wish I could find the link to that "wall of shame" website again so I can give specific examples. But sometimes I disagree with the new metric and it seems to be okay with what I perceive to be heavier and more extreme losses to visual fidelity, perhaps half of the time.
|
|
2022-11-16 08:18:44
|
Also as a side note, I lost access to my old discord account and I doubt I will be able to get it back. If anyone's wondering why there's two of me here. <@318186133320237058> is my old account for the past 5 years.
|
|
|
Jim
|
2022-11-16 08:19:10
|
Hall of Shame: https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMULACRA_2_modelD.html
|
|
|
|
Demiurge
|
2022-11-16 08:32:47
|
So for some reason it thinks the jpeg version of the Steel Bridge image is better than the JXL version...
|
|
|
|
_wb_
|
2022-11-16 08:33:46
|
Ssimulacra2 says the jpeg is worse than the jxl, all other metrics say the jpeg is better, on that image
|
|
|
|
Demiurge
|
2022-11-16 08:34:31
|
Maybe I am misreading something...
|
|
2022-11-16 08:34:53
|
Higher scores closer to 100 is better fidelity right? for ssimulacra2
|
|
|
|
_wb_
|
2022-11-16 08:35:07
|
Yes. The jpeg has a negative score
|
|
2022-11-16 08:35:23
|
So that's pretty bad
|
|
2022-11-16 08:36:08
|
(most images are pretty bad in general on that page, since that's where metrics disagree the most
|
|
|
|
Demiurge
|
2022-11-16 08:37:09
|
Oh I didn't notice the negative sign
|
|
2022-11-16 08:37:36
|
That was confusing me a lot.
|
|
2022-11-16 08:38:29
|
But yeah I have noticed a pattern still in the past of the new metric being more allowing than I would expect, of extreme amounts of smoothing in some cases
|
|
2022-11-16 08:38:44
|
Just wanted to offer those two cents.
|
|
2022-11-16 08:44:19
|
I guess the best example of this would be the parrot.
|
|
2022-11-16 08:44:35
|
|
|
2022-11-16 08:44:52
|
|
|
2022-11-16 08:45:59
|
The wall is completely smoothed over and so is the parrot's face. The JPEG despite the blockiness and quantization is still more faithful to the original here and gives us a better idea of how the original would have looked like.
|
|
2022-11-16 08:46:31
|
It tells us more about what we are looking at
|
|
|
|
_wb_
|
2022-11-16 08:46:35
|
Hmyeah. Both are quite horrible though
|
|
2022-11-16 08:46:52
|
(and they both get negative scores)
|
|
|
|
Demiurge
|
2022-11-16 08:47:11
|
Yes, most of the comparisons on this page is a choice between bad and worse
|
|
|
|
_wb_
|
2022-11-16 08:47:37
|
But this is a "hall of shame", it is supposed to find examples where ssimulacra2 fails (since all the other metrics disagree with it)
|
|
2022-11-16 08:48:36
|
https://jon-cld.s3.amazonaws.com/test/index.html
|
|
2022-11-16 08:49:33
|
Here is a page with disagreements on higher quality images: https://jon-cld.s3.amazonaws.com/test/bhall_of_fshame_SSIMULACRA_2_modelD.html
|
|
|
|
afed
|
2022-11-16 08:54:41
|
there are some examples when a more detailed and sharp image, but having very strong artifacts or banding is rated lower than a very blurry image, but I think this is fair and such artifacts are more seriously penalised and the score is significantly dropped
unless it is possible to apply debanding or deringing filters on some and they would be much better (but metrics can't know about that though)
|
|
|
|
Demiurge
|
2022-11-16 09:29:35
|
I dunno. I just hope that the JXL encoder continues preserving as much visually important information as possible and gives us the best idea compared to any other codec, of what the original image looked like
|
|
2022-11-16 09:30:49
|
And it would also be nice if someday there were multiple independent perceptual lossy encoders for the JXL format, maybe tuned for different things. Maybe one tuned for appeal, one tuned for fidelity, one tuned for speed, etc...
|
|
2022-11-16 09:33:30
|
But it would be nicer if the Chromium Lords decided not to kill a format with so much untapped potential. When a video codec is not adequate to be retrofitted as an image codec.
|
|
|
|
_wb_
|
|
Demiurge
And it would also be nice if someday there were multiple independent perceptual lossy encoders for the JXL format, maybe tuned for different things. Maybe one tuned for appeal, one tuned for fidelity, one tuned for speed, etc...
|
|
2022-11-16 09:34:37
|
Or just different settings for libjxl. Independent encoders are nice to have, but not nearly as important as independent decoders from the pov of spec robustness.
|
|
|
|
Demiurge
|
2022-11-16 09:36:11
|
True, decoders are always more important. Especially super speedy and optimized ones.
|
|
2022-11-16 09:36:39
|
What do you think of J40?
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
But it would be nicer if the Chromium Lords decided not to kill a format with so much untapped potential. When a video codec is not adequate to be retrofitted as an image codec.
|
|
2022-11-16 10:02:31
|
they can only delay the inevitable
|
|
2022-11-16 10:05:11
|
I think Chrome can delay JPEG XL as a web format for two years or so
|
|
2022-11-16 10:06:18
|
JPEG XL will diffuse into the systems through other needs: professional photography, publishing, thermal imaging, medical, industrial verification, burst mode photography, raw photos for prosumers, gaming, archiving, etc. etc.
|
|
2022-11-16 10:07:03
|
eventually there is enough of it and Windows and iOS provide plugins or native support
|
|
2022-11-16 10:07:13
|
ChromeOS will want it too at that stage
|
|
2022-11-16 10:07:44
|
before that time we will great an ok experience through wasm
|
|
2022-11-16 10:08:14
|
also, I believe we can improve the old JPEG1 to be slightly better than AVIF and WebP at internet distribution qualities
|
|
2022-11-16 10:08:46
|
by backporting JPEG XL computation into JPEG1 encoding and decoding
|
|
2022-11-16 10:18:38
|
particularly we can backport JPEG XL effort=7 adaptive quantization into encoding (also XYB if we use ICC v4)
|
|
2022-11-16 10:19:31
|
in decoding we can get savings by better modeling the likely correct distributions and by just computing with more bits
|
|
2022-11-16 10:20:39
|
encoding gets about 30 % better and decoding 7 %, totaling to 35 % improvement (at and above quality 90)
|
|
2022-11-16 10:21:46
|
It is not 51-60 % like we get with real JPEG XL
|
|
2022-11-16 10:22:08
|
but it is better in this quality range than AVIF or WebP, I believe
|
|
2022-11-16 10:22:33
|
probably roughly the same with AVIF at q85
|
|
2022-11-16 10:22:53
|
we didn't measure it yet with raters
|
|
2022-11-16 10:23:02
|
so this is based on butteraugli only
|
|
2022-11-16 10:23:18
|
and some quite wonderful plausibility eye-balling
|
|
|
|
Demiurge
|
2022-11-16 11:53:31
|
old jpeg format supports adaptive quantization?
|
|
2022-11-16 11:54:11
|
Also some JPEG decoders look much better than others.
|
|
2022-11-16 11:54:44
|
libjpeg-turbo for example looks ugly and I don't think the marginal speed boost is worth the quality loss compared to mozjpeg for example
|
|
2022-11-16 11:55:30
|
mozjpeg is not slow at all but most software uses turbo instead despite the visual consequences
|
|
|
|
Traneptora
|
2022-11-17 12:45:32
|
it's an IM bug
|
|
2022-11-17 12:51:03
|
I'm not using kde
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
old jpeg format supports adaptive quantization?
|
|
2022-11-17 01:31:45
|
it doesn't support, but we learned to trick it in guetzli -- we just collapse all small values to zero (variable deadzone)
|
|
|
|
Demiurge
|
2022-11-17 02:04:05
|
Nice! There's almost no need for the format to support it then!
|
|
2022-11-17 02:04:41
|
If you can use compression tricks like that
|
|
|
|
Jyrki Alakuijala
|
2022-11-17 09:44:05
|
there is a demo available in benchmark_xl
|
|
|
yurume
|
|
yurume
I'm not sure how to design the test suite, especially what to compare against, that's why I'm holding that idea right now, but that's something I love to have
|
|
2022-11-17 10:40:52
|
Just in case, I've elaborated on this message in <#1019989424232222791> (which doesn't seem to advertise new posts well)
|
|
|
lithium
|
|
Jyrki Alakuijala
JPEG XL will diffuse into the systems through other needs: professional photography, publishing, thermal imaging, medical, industrial verification, burst mode photography, raw photos for prosumers, gaming, archiving, etc. etc.
|
|
2022-11-17 01:14:04
|
In my opinion, I thought for non-photo content,
those content need a modern encoder, and have stable heuristic
make smart lossy decision,
(like for DCT worst case content can use libjxl patches
or use lossy palette handle input pixel)
I understand mathematically lossless is best for non-photo content,
but if for distribute or other use case, I thought visually lossless(-d 0.5 -e 8) also a good choose,
I understand dev team still busy on v1.0 release,
please consider plan non-photo content improvement after v1.0 release.
Thank you very much 🙂
I already see a lot of non-photo content apply wrong lossy algorithm,
(monochrome non-photo content apply pure DCT,
RGB non-photo content apply jpeg 420,
RGB non-photo content force apply pal8 lossy algorithm)
|
|
|
|
Jyrki Alakuijala
|
|
lithium
In my opinion, I thought for non-photo content,
those content need a modern encoder, and have stable heuristic
make smart lossy decision,
(like for DCT worst case content can use libjxl patches
or use lossy palette handle input pixel)
I understand mathematically lossless is best for non-photo content,
but if for distribute or other use case, I thought visually lossless(-d 0.5 -e 8) also a good choose,
I understand dev team still busy on v1.0 release,
please consider plan non-photo content improvement after v1.0 release.
Thank you very much 🙂
I already see a lot of non-photo content apply wrong lossy algorithm,
(monochrome non-photo content apply pure DCT,
RGB non-photo content apply jpeg 420,
RGB non-photo content force apply pal8 lossy algorithm)
|
|
2022-11-17 02:41:24
|
I feel there is a lot of insights and value behind these words. Would you consider putting it into a blog post -- or carving out it into seven different issues and file them against libjxl 🙂
|
|
|
|
Jim
|
2022-11-17 02:57:04
|
If you add the updated encoding into the original JPEG, will others use it? Would turbo? Or would they just ignore the new stuff?
|
|
|
|
_wb_
|
2022-11-17 04:09:16
|
Maybe mozjpeg would be interested in some of it. Turbo, I doubt it - they focus on speed, not quality/compression...
|
|
|
|
Traneptora
|
2022-11-17 07:50:06
|
Is it possible to output a JXL and skip EPF and GAB?
|
|
2022-11-17 07:50:14
|
even if they're signalled
|
|
2022-11-17 07:50:21
|
I know ffh264 for example can skip the loop filter
|
|
2022-11-17 07:50:26
|
it has an option for that
|
|
|
|
_wb_
|
2022-11-17 08:41:11
|
djxl used to have an option for that iirc, but I don't think we expose this in the api so it would be lost now
|
|
|
|
Traneptora
|
2022-11-17 10:32:39
|
I'm trying to see if I have any Inverse Transform bugs before EPF and GAB
|
|
2022-11-17 10:32:56
|
and the easiest way to do that would be to just see what libjxl does without EPF or GAB
|
|
|
|
Demiurge
|
|
lithium
In my opinion, I thought for non-photo content,
those content need a modern encoder, and have stable heuristic
make smart lossy decision,
(like for DCT worst case content can use libjxl patches
or use lossy palette handle input pixel)
I understand mathematically lossless is best for non-photo content,
but if for distribute or other use case, I thought visually lossless(-d 0.5 -e 8) also a good choose,
I understand dev team still busy on v1.0 release,
please consider plan non-photo content improvement after v1.0 release.
Thank you very much 🙂
I already see a lot of non-photo content apply wrong lossy algorithm,
(monochrome non-photo content apply pure DCT,
RGB non-photo content apply jpeg 420,
RGB non-photo content force apply pal8 lossy algorithm)
|
|
2022-11-18 01:47:48
|
Maybe the pngquant guys can gen interested in JXL and add advanced palette algorithms and other tricks involving patches and clever quantization to the encoder.
|
|
2022-11-18 01:48:49
|
Stuff that works good for non-photographic stuff, and even sometimes for photographic stuff too.
|
|
2022-11-18 01:51:05
|
Ways to shave off bytes from an image... WITHOUT destroying fine details or texture, or creating those obnoxious ringing and blocking artifacts lossy algos are infamous for.
|
|
2022-11-18 01:53:24
|
I don't think there's any reason anymore for images to have ringing or macroblocking when we know so many ways to avoid them these days
|
|
|
daniilmaks
|
2022-11-18 02:41:46
|
is lossy cmyk encoded as vardct/xyb or is it strictly modular?
|
|
|
|
Traneptora
|
|
is lossy cmyk encoded as vardct/xyb or is it strictly modular?
|
|
2022-11-18 04:46:51
|
CMY channels are encoded as VarDCT/XYB, the K channel is an Extra Channel which is modular
|
|
2022-11-18 04:47:14
|
basically it just pretends C/M/Y are R/G/B then does its normal thing
|
|
2022-11-18 04:47:24
|
and K/Black is Extra
|
|
|
|
daniilmaks
|
|
Traneptora
basically it just pretends C/M/Y are R/G/B then does its normal thing
|
|
2022-11-18 04:53:58
|
that's sounds like something that shouldn't work that easily. Or at least not be perceptually uniform.*
CMY model is basically an upside down RGB so... does it at least perform that operation so as to make correct assignment of xyb values?
|
|
|
|
Traneptora
|
2022-11-18 04:54:29
|
I'm not sure about the XYB part
|
|
2022-11-18 04:54:34
|
but I do know it does VarDCT on those three channels
|
|
|
|
daniilmaks
|
2022-11-18 04:56:02
|
if the conversion to xyb is exactly the same in CMY as in RGB that sounds very wrong and inefficient, even in linear space.
|
|
|
|
Traneptora
|
2022-11-18 04:56:52
|
hm, jxlatte can't parse the image header
|
|
2022-11-18 04:56:53
|
time to debug
|
|
|
if the conversion to xyb is exactly the same in CMY as in RGB that sounds very wrong and inefficient, even in linear space.
|
|
2022-11-18 05:02:21
|
the image header for teh CMYK-Layers test sample says it's not XYB encoded
|
|
2022-11-18 05:07:40
|
my verbose dump shows this
|
|
2022-11-18 05:07:43
|
```
Image:
Level: 10
Size: 512x512
Pixel Format: RGBA
Extra Channels: 2
XYB Encoded: false
Primaries: sRGB / BT.709
White Point: D65
Transfer Function: sRGB / ISO-IEC 61966-2-1
ICC Profile, Size: 557098
Lossless: Possibly
Frame Info:
Encoding: Modular
Type: Regular
Size: 512x512
Origin: (0, 0)
YCbCr: false
Frame Info:
Encoding: Modular
Type: Regular
Size: 200x107
Origin: (143, 166)
YCbCr: false
Frame Info:
Encoding: Modular
Type: Regular
Size: 300x88
Origin: (98, 311)
YCbCr: false
Frame Info:
Encoding: Modular
Type: Regular
Size: 110x68
Origin: (134, 13)
YCbCr: false
```
|
|
|
|
daniilmaks
|
2022-11-18 05:14:17
|
is the mapping cmyk -> rgba or is it rgb[k]a
|
|
2022-11-18 05:15:21
|
my first means K being mapped to A
|
|
2022-11-18 05:16:05
|
which would raise questions about how cmyk+alpha is handled
|
|
|
|
_wb_
|
2022-11-18 06:17:18
|
Extra channels have a signaled type so one of them will be kBlack and the other kAlpha
|
|
|
|
Traneptora
|
|
is the mapping cmyk -> rgba or is it rgb[k]a
|
|
2022-11-18 07:55:36
|
it's RGB + K + A, or RGB + A + K. I don't actually know what order those are in, for convenience my code outputs "RGBA" instead if an alpha channel is present
|
|
|
|
_wb_
|
2022-11-18 08:06:18
|
The encoder can choose how to order extra channels, the semantics is by the type field, not by the index
|
|
|
|
Traneptora
|
2022-11-18 08:35:46
|
something's bothering me about this, it seems like it could be simplified, and that tells me I might be reading it wrong
|
|
2022-11-18 08:35:57
|
```cpp
DistanceStep0and1(x, y, cx, cy) {
dist = 0; coords = { {0, 0}, {−1, 0}, {1, 0}, {0, −1}, {0, 1} };
for (c = 0; c < 3; c++) {
for (/* (ix, iy) in coords */) {
dist += abs(sample(x + ix, y + iy, c) −
sample(x + cx + ix, y + cy + iy, c)) * rf.epf_channel_scale[c];
}
}
return dist;
}
```
|
|
2022-11-18 08:36:50
|
ah, there's a *sample* there
|
|
2022-11-18 08:37:12
|
I missed that
|
|
2022-11-18 08:37:32
|
It's called an "L1 distance metric" and I assumed the standard 1-norm distance
|
|
2022-11-18 08:37:48
|
that's on me for not reading properly
|
|
|
|
lithium
|
|
Jyrki Alakuijala
I feel there is a lot of insights and value behind these words. Would you consider putting it into a blog post -- or carving out it into seven different issues and file them against libjxl 🙂
|
|
2022-11-18 08:49:51
|
Thank you for your reply 🙂
I haven't write a post about those issue,
I will update those information on my issues 1188.
> https://github.com/libjxl/libjxl/issues/1188
|
|
|
Demiurge
Ways to shave off bytes from an image... WITHOUT destroying fine details or texture, or creating those obnoxious ringing and blocking artifacts lossy algos are infamous for.
|
|
2022-11-18 08:50:20
|
Thank you for your reply 🙂
I hope libjxl can use more advance feature to handle high contrast edge, line and flat area,
and avoid ringing, blocking artifacts.
|
|
|
|
_wb_
|
2022-11-18 10:01:41
|
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c201 wait what? 3x decode speedup on large images? <@795684063032901642>
|
|
|
Moritz Firsching
|
2022-11-18 10:03:15
|
well, essentially it was restarting decoding for large images many times over, causesd by a bug in the glue code introduced when improving the memory footprint when decoding animations...
|
|
2022-11-18 10:04:21
|
I would rather say it was a 3x decode slowdown before. Small images (let's say less than 3MB or so) weren't affected at all.
|
|
2022-11-18 10:04:36
|
Note that the "large" here does not refer to pixel size, but byte size
|
|
|
|
_wb_
|
2022-11-18 10:05:25
|
That's a good catch! It might mean previous evaluations that looked at decode time need to be reconsidered, though probably they didn't use images that large...
|
|
|
|
Moritz Firsching
|
2022-11-18 10:06:18
|
This was noticed when looking at 45MP images compressed with something like -d 0.1 resulting in 17MB files sizes or so...
|
|
|
|
daniilmaks
|
|
_wb_
The encoder can choose how to order extra channels, the semantics is by the type field, not by the index
|
|
2022-11-18 01:07:14
|
is there decoder fuzzer/test files whatever... that ensure the decoder respects field type over index or do you believe this is superfluous and already handled through other means?
|
|
|
|
Traneptora
|
|
is there decoder fuzzer/test files whatever... that ensure the decoder respects field type over index or do you believe this is superfluous and already handled through other means?
|
|
2022-11-18 02:02:58
|
some decoders might in theory assume that alpha is EC0, but no existing decoder makes that assumption
|
|
2022-11-18 05:29:45
|
The 2D-DCT is separable, right?
|
|
2022-11-18 05:29:55
|
that is, it doesn't matter whether I do vertical or horizontal first
|
|
2022-11-18 05:30:02
|
provided I have enough precision?
|
|
|
OkyDooky
|
2022-11-19 07:57:12
|
<@853026420792360980>\: yes.
|
|
|
|
Traneptora
|
2022-11-19 04:02:39
|
why was the ICC profile encoded and then compressed rather than just compressed?
|
|
|
|
yurume
|
|
Traneptora
why was the ICC profile encoded and then compressed rather than just compressed?
|
|
2022-11-19 04:07:00
|
Encoding (or more accurately, transformation) improves compression
|
|
|
|
Traneptora
|
|
|
Jim
|
2022-11-19 04:07:57
|
No, ICC <:kekw:808717074305122316>
|
|
|
|
Traneptora
|
2022-11-19 04:08:11
|
I see. See.
|
|
|
wowie
|
2022-11-19 04:57:45
|
Hi,
Is there any documentation of Jpeg XL file format / header layout freely available online?
|
|
|
|
Traneptora
|
2022-11-19 04:58:26
|
Officially, no, it's an ISO standard that is behind a paywall. There's a draft version in <#1021189485960114198> that we've been using to iron out the details though.
|
|
2022-11-19 04:58:50
|
the file format itself (without header layout) is in the codestream overview page
|
|
2022-11-19 04:59:35
|
https://github.com/libjxl/libjxl/blob/main/doc/format_overview.md
|
|
|
spicypete
|
2022-11-19 08:23:32
|
<@853026420792360980> is it possible in the JPEG XL file format specification, that not all content in the image is shown? i.e. the size header of the image is incorrect?
|
|
|
|
Traneptora
|
|
spicypete
<@853026420792360980> is it possible in the JPEG XL file format specification, that not all content in the image is shown? i.e. the size header of the image is incorrect?
|
|
2022-11-19 08:30:35
|
what do you mean by incorrect? the size header bundle in the spec as far as I'm aware has no typos
|
|
|
|
spicypete
|
|
Traneptora
what do you mean by incorrect? the size header bundle in the spec as far as I'm aware has no typos
|
|
2022-11-19 08:33:36
|
i.e. it was corrupted
|
|
|
|
Traneptora
|
|
spicypete
i.e. it was corrupted
|
|
2022-11-19 08:34:28
|
if the side header is corrupt in general the whole image will fail to decode
|
|
|
|
spicypete
|
2022-11-19 08:35:08
|
makes sense, thank you!
|
|
|
|
Traneptora
|
2022-11-19 08:35:38
|
the size header is at the very start of the image header, and the rest of the image header will be misaligned
|
|
2022-11-19 08:57:08
|
Woot!
|
|
|
|
Jim
|
2022-11-19 09:01:18
|
<:JXL:805850130203934781> atte!
|
|
|
|
Traneptora
|
2022-11-19 11:23:00
|
huh, that's not how you tonemap
|
|
2022-11-19 11:23:51
|
|
|
2022-11-19 11:25:16
|
luckily, I think I'm doing PQ correctly
|
|
2022-11-20 04:14:52
|
oh, I had some matricies transposed <:KEKW:643601031040729099>
|
|
2022-11-20 04:33:42
|
aight, noice, JXLatte is mostly done at this point, I just have to finish EPF
|
|
2022-11-20 04:33:56
|
and then maybe do animation? if I want
|
|
2022-11-20 04:34:21
|
and do LF Frames I guess
|
|
2022-11-20 04:36:02
|
So here's my current logic flowchart at this point
|
|
2022-11-20 04:40:42
|
```
Input has profile, and is not XYB:
-> Disable color management, output pixels as decoded, attach ICC profile
Input is XYB or has no attached profile:
-> if --hdr is not set, convert to sRGB, output PNG with sRGB chunk
-> if --hdr is set, tonemap to BT2020+D65+PQ, output PNG with iCCP chunk, attach BT2020+D65+PQ iCCP.
```
|
|
2022-11-20 04:41:38
|
I currently have conversion functions for every enum-taggable space except HLG and DCI transfer functions at the moment
|
|
2022-11-20 04:42:14
|
so atm PNG output will barf if someone tries to send it an HLG-tagged non-xyb-encoded image
|
|
2022-11-20 04:42:38
|
(the pixels will decode correctly, so you could always decode to PFM and then manage it elsewhere though)
|
|
2022-11-20 04:44:58
|
the HDR ICC Profile is one I just took from libjxl, but it's tagged as CC0 so I believe that's perfectly legal
|
|
2022-11-20 04:45:49
|
I'm wondering if it would be better default behavior to look at the tagged colorspace and enable `--hdr` by default if unspecified and the tagged space is an HDR space
|
|
|
|
_wb_
|
2022-11-20 11:38:41
|
Yes, I think that is better than clamping to SDR by default
|
|
2022-11-20 11:39:42
|
Also not sure if clamping to sRGB gamut by default is a good idea, I think P3 is quite common nowadays
|
|
|
|
Traneptora
|
2022-11-20 12:59:42
|
is P3 also SDR?
|
|
2022-11-20 01:00:24
|
I don't particularly see the point of supporting PNG output for SDR images that isn't sRGB
|
|
|
|
_wb_
|
2022-11-20 01:01:32
|
I think most Apple devices and many Android ones have a P3 SDR display
|
|
|
|
Traneptora
|
2022-11-20 01:02:27
|
the advantage of sRGB is I can assume it works
|
|
2022-11-20 01:02:37
|
whether or not color management is present
|
|
2022-11-20 01:02:56
|
also are you referring to DCI P3 or Display P3?
|
|
2022-11-20 01:03:08
|
DCI P3 using the DCI whitepoint, Display P3 using the D65 whitepoint
|
|
|
|
_wb_
|
2022-11-20 01:06:32
|
Display P3 is what is common in consumer screens I think. DCI P3 is used in cinema I think.
|
|
2022-11-20 01:07:02
|
Display P3 uses the sRGB transfer curve, just with wider gamut primaries
|
|
2022-11-20 01:07:15
|
DCI uses a pure gamma curve iirc
|
|
|
|
Traneptora
|
2022-11-20 01:07:40
|
DCI has its own transfer tag in the format, so idk
|
|
|
|
_wb_
|
2022-11-20 01:08:29
|
Yeah but it's just gamma 2.6
|
|
|
|
Traneptora
|
2022-11-20 01:08:35
|
Oh
|
|
2022-11-20 01:08:37
|
lmao
|
|
2022-11-20 01:08:50
|
that's probably why it's not in H.273
|
|
|
|
_wb_
|
2022-11-20 01:11:07
|
Anyway I think Display P3 displays are becoming more common than sRGB ones
|
|
|
|
Traneptora
|
2022-11-20 01:11:58
|
the problem with outputting Display P3 images is the vast majority of input images are tagged as sRGB
|
|
2022-11-20 01:12:06
|
especially considering it's the PNG default
|
|
2022-11-20 01:13:12
|
I think it might make more sense to add an option to output display P3, and have `--gamut=auto` map to the tagged space
|
|
|
|
_wb_
|
2022-11-20 01:13:15
|
Yeah maybe output sRGB if the image is tagged sRGB, P3 if it's wider gamut SDR, and Rec2100 PQ if it's HDR
|
|
2022-11-20 01:14:21
|
Or just use Rec2100 PQ whenever it's not sRGB
|
|
|
|
Traneptora
|
2022-11-20 01:14:38
|
that simplifies it for me
|
|
|
|
_wb_
|
2022-11-20 01:14:52
|
Have to make 16-bit pngs then of course
|
|
|
|
Traneptora
|
2022-11-20 01:15:17
|
already done, what it currently does is it writes 8-bit PNG iff the input is tagged as 8-bit SDR
|
|
2022-11-20 01:15:36
|
and writes 16-bit if the input is tagged as >8 bit, or if HDR gamut is enabled
|
|
|
_wb_
Or just use Rec2100 PQ whenever it's not sRGB
|
|
2022-11-20 01:16:32
|
I'm assuming that if I attach a Rec2020 PQ ICC profile to an image that contains Display P3 data, then anything that could handle the Display P3 profile will render it correctly anyway
|
|
2022-11-20 01:16:49
|
the idea behind sRGB default is it works as a "sane default" without color management
|
|
|
|
Demiurge
|
2022-11-20 01:16:58
|
Does the format support multiple pages like TIFF?
|
|
|
|
_wb_
|
2022-11-20 01:17:27
|
It supports multi frame /layer, not really multi page
|
|
|
|
Demiurge
|
2022-11-20 01:17:58
|
So they all have to have the same dimensions in other words?
|
|
|
|
_wb_
|
2022-11-20 01:18:27
|
Nothing stops you from making a very slow 'animation' and having a viewer that lets you go to the next/previous frame
|
|
2022-11-20 01:19:09
|
The image dimensions define the canvas, but frames can be larger or smaller than the image dimensions
|
|
|
|
Demiurge
|
2022-11-20 01:19:55
|
So there's only one canvas of a fixed size per image file then it sounds like
|
|
|
|
Traneptora
|
2022-11-20 01:21:06
|
that's correct
|
|
|
|
Demiurge
|
2022-11-20 01:21:10
|
and you can't concatenate multiple files together
|
|
|
|
Traneptora
|
2022-11-20 01:21:21
|
well there's no reason you can't but most software is not designed to handle it
|
|
|
|
Demiurge
|
2022-11-20 01:22:07
|
Well there's no standard defined for concatenating them I assume
|
|
|
|
_wb_
|
2022-11-20 01:22:47
|
You could in theory concatenate frames from different files with some minimal changes to the frame headers (setting is_last to false and if dimensions don't match, setting frame dimensions)
|
|
2022-11-20 01:23:06
|
Without needing full reencode I mean
|
|
2022-11-20 01:23:29
|
But there's no tool for that atm
|
|
|
|
Traneptora
|
2022-11-20 01:24:08
|
currently in jxlatte I demux in a separate thread, but I'm thinking of removing that
|
|
2022-11-20 01:24:23
|
because that makes concatenating jxl files easier
|
|
|
|
Demiurge
|
2022-11-20 01:24:38
|
Also, is "modular mode" more or less suited to "progressive decoding" compared to dct?
|
|
|
|
_wb_
|
2022-11-20 01:25:05
|
In modular mode you need squeeze to get progressive
|
|
|
|
Traneptora
|
2022-11-20 01:25:16
|
lossy modular can be used for progressive
|
|
2022-11-20 01:25:26
|
but it's easiest with VarDCT
|
|
|
|
_wb_
|
2022-11-20 01:25:36
|
Which is typically not used for lossless since it tends to be bad for compression
|
|
|
|
Demiurge
|
2022-11-20 01:25:54
|
I remember FLIF was INCREDIBLY good at progressive loading and interlacing.
|
|
|
|
_wb_
|
2022-11-20 01:26:39
|
FLIF's progressive previews are basically NN downsamplings
|
|
|
|
Demiurge
|
2022-11-20 01:27:03
|
Yes and it was pretty amazing
|
|
|
|
Traneptora
|
2022-11-20 01:27:06
|
neural net?
|
|
|
|
_wb_
|
2022-11-20 01:27:10
|
FUIF/Modular JXL with Squeeze has better downsamplings
|
|
|
Traneptora
neural net?
|
|
2022-11-20 01:27:19
|
Nearest neighbor 🙂
|
|
|
|
Traneptora
|
2022-11-20 01:27:21
|
oh
|
|
2022-11-20 01:27:24
|
I was really confused lol
|
|
2022-11-20 01:28:11
|
lossy modular relies on Squeeze which tends to dump a lot of your info into the globalmodular portion, which can't be parallelized easily or given any kind of region-of-interest
VarDCT tends to be better suited for progressive
|
|
2022-11-20 01:28:29
|
passes also can't be used easily in modular mode
|
|
|
|
Demiurge
|
2022-11-20 01:28:29
|
The FLIF downsampling had a lot of aliasing, which actually seemed to preserve small texture details well
|
|
2022-11-20 01:31:12
|
Squeeze is a type of wavelet compression I heard, and I also heard that wavelets are usually good at progressive loading, but I don't have a lot of familiarity with the subject or how it applies to jxl
|
|
|
|
_wb_
|
2022-11-20 01:32:17
|
Disadvantage of the 'real' downsamplings (i.e. a 1:8 pixel is the average of 8x8 pixels, not just the topleft pixel) of squeeze is that it introduces extra entropy in nonphoto images with low color count. The NN thing FLIF does (which is basically like PNG'd Adam7) does not introduce new colors so it can e.g. be combined with Palette transforms...
|
|
|
|
Traneptora
|
|
Demiurge
Squeeze is a type of wavelet compression I heard, and I also heard that wavelets are usually good at progressive loading, but I don't have a lot of familiarity with the subject or how it applies to jxl
|
|
2022-11-20 01:33:19
|
yes, but squeeze is fairly ill-suited for lossless
|
|
2022-11-20 01:33:45
|
it also tends to lose to VarDCT in lossy for bpp
|
|
|
|
_wb_
|
2022-11-20 01:34:09
|
For lossless photographic stuff or non-palette drawings, squeeze is not that bad
|
|
|
|
Traneptora
|
2022-11-20 01:34:29
|
oh it's pretty good, but VarDCT works even better
|
|
2022-11-20 01:34:36
|
VarDCT is also much faster
|
|
|
|
Demiurge
|
2022-11-20 01:34:39
|
Well lossy wavelet compression that I have so far seen, like from J2K for example, usually is heavy on the blurring and ringing
|
|
|
|
Traneptora
|
2022-11-20 01:34:41
|
which is useful for progressive
|
|
|
|
_wb_
|
2022-11-20 01:34:52
|
Yeah for lossy VarDCT is almost always better
|
|
|
|
Demiurge
|
2022-11-20 01:35:11
|
No macroblocking which is nice
|
|
2022-11-20 01:35:22
|
But you trade macroblocking for heavy blurring and ringing
|
|
2022-11-20 01:36:16
|
which might not be a big deal at high fidelity targets
|
|
|
|
_wb_
|
2022-11-20 01:37:11
|
Squeeze avoids most ringing by doing a doing a nonlinear thing where in locally monotonic regions a predictor gets subtracted but in locally nonmonotonic regions it doesn't
|
|
|
|
Demiurge
|
2022-11-20 01:37:12
|
I wouldn't know.
|
|
|
|
_wb_
|
2022-11-20 01:37:36
|
So you don't get overshoot at hard edges
|
|
2022-11-20 01:38:21
|
While you do get smooth gradients when zeroing hf squeeze coeffs
|
|
|
|
Demiurge
|
2022-11-20 01:39:28
|
And that's why JXL has such pretty and beautiful, sharp clear colors, right? :)
|
|
|
|
_wb_
|
2022-11-20 01:40:17
|
VarDCT is what is most useful for lossy compression
|
|
|
|
Demiurge
|
2022-11-20 01:40:18
|
Where other formats quickly change and muddy and contaminate the colors
|
|
2022-11-20 01:40:57
|
Ah yeah I almost forgot we're talking about an algo that isn't even used by default
|
|
2022-11-20 01:43:19
|
squeeze won't ever be used with default encoder settings or even with any settings that are revealed when you do cjxl -h without -v
|
|
|
|
_wb_
|
2022-11-20 01:44:25
|
There are a few things that make a difference there, I think:
- XYB is perceptually more relevant than YCbCr
- video codec-based formats still often do 4:2:0, which is an unnecessarily blunt compression tool
- deblocking filters in video codecs tend to be pretty aggressive in the smoothing they do (mostly aimed at making low-fidelity images look acceptable)
- jxl implements everything with higher precision than what other codecs/encoders typically (can) do
|
|
2022-11-20 01:45:29
|
Squeeze is used by default to do alpha when not doing lossless (to make alpha slightly lossy)
|
|
2022-11-20 01:46:13
|
And it's also used when doing DC frames, which I think is enabled when doing --progressive
|
|
|
|
Demiurge
|
|
|
_wb_
|
2022-11-20 01:46:40
|
But yeah, most of the default encoding does not use Squeeze
|
|
|
|
Demiurge
|
2022-11-20 01:48:35
|
So then, lossless or lossy modular, is still somewhat progressive or capable of being progressive?
|
|
|
|
_wb_
|
2022-11-20 01:49:16
|
Lossy modular or lossless when using squeeze is progressive
|
|
|
|
Demiurge
|
2022-11-20 01:50:34
|
Not theoretically capable of cropped/ROI decoding though?
|
|
|
|
_wb_
|
2022-11-20 01:51:06
|
Well, that's a good question
|
|
|
|
Demiurge
|
2022-11-20 01:51:09
|
a la j2k for example
|
|
|
|
_wb_
|
2022-11-20 01:51:40
|
I think it would probably work in practice
|
|
2022-11-20 01:52:30
|
In theory, the Squeeze residuals from everything to the left and top of the ROI might be needed to exactly reconstruct the ROI
|
|
|
|
Demiurge
|
2022-11-20 01:52:40
|
Is there anything that makes the j2k encoding more suited for that than jxl?
|
|
|
|
_wb_
|
2022-11-20 01:53:12
|
I don't know how far the error can travel though, would need to do some analysis of that
|
|
2022-11-20 01:54:33
|
If it can be limited to something like bitdepth * 2 pixels or something like that, then ROI decoding can be done, just need to possible decode a little more to get the edges right
|
|
2022-11-20 01:55:29
|
J2K is extremely flexible in what kinds of bitstream ordering it allows, more than JXL I think
|
|
|
|
Demiurge
|
2022-11-20 01:58:06
|
Is j2k alien technology from the future also?
|
|
|
|
_wb_
|
2022-11-20 02:02:54
|
It has some nice things, yes. I'm not convinced DWT is better than DCT though, and the entropy coding they have seems quite messy to me. But at least it's a well-thought-out format that took many use cases into account.
|
|
2022-11-20 02:04:08
|
Compared to webp/heic/avif which are all basically quick hacks to put a single frame video in a new container so it can be called an image format
|
|
|
BlueSwordM
|
|
_wb_
FUIF/Modular JXL with Squeeze has better downsamplings
|
|
2022-11-20 05:43:56
|
Wait, squeeze is a downsampler?
|
|
|
|
_wb_
|
2022-11-20 05:48:10
|
In a way, yes. Every step of the forward transform basically downsamples one direction 2x in one channel and puts the residuals in another. This is then recursively done on the downsampled channels, so you basically get a laplacian pyramid...
|
|
|
improver
|
2022-11-20 05:56:38
|
v interesting
|
|
|
|
_wb_
|
2022-11-20 06:09:14
|
This is how alpha can be progressive in sync with vardct
|
|
|
|
Traneptora
|
2022-11-20 10:12:33
|
<@1028567873007927297> I remember you were interested in this feature
|
|
2022-11-20 10:12:36
|
```
leo@gauss ~/Development/thebombzen/jxlatte/samples :) $ cat art.jxl bbb.jxl bench.jxl lenna.jxl | jxlatte --info --output-format=png - - >/dev/null
Image: -
Level: 5
Size: 128x128
Pixel Format: RGB
Bit Depth: 8
Lossless: Possibly
Decoded to pixels, writing PNG output.
Image: -
Level: 5
Size: 1280x720
Pixel Format: RGB
Bit Depth: 8
Lossless: No
Decoded to pixels, writing PNG output.
Image: -
Level: 5
Size: 500x606
Pixel Format: RGB
Bit Depth: 8
Lossless: No
Decoded to pixels, writing PNG output.
Image: -
Level: 5
Size: 512x512
Pixel Format: RGB
Bit Depth: 8
Lossless: No
Decoded to pixels, writing PNG output.
```
|
|
|
|
Demiurge
|
2022-11-20 11:22:13
|
Oh, I was wondering if there is a specification or a standard on how to handle concatenated JXLs
|
|
2022-11-20 11:22:41
|
If it's specified somewhere, a standard way of how they are supposed to be treated
|
|
2022-11-20 11:23:12
|
Basically just wondering if multi-page JXL is a thing like with TIFF or PDF
|
|
2022-11-20 11:24:29
|
I was thinking about the use case of compressing multi-page scans, like comic books or legal documents for example
|
|
2022-11-20 11:25:01
|
Or if we have to continue using CBZ for example
|
|
2022-11-20 11:25:11
|
Which is just a zip file with multiple images in it
|
|
|
|
Traneptora
|
|
Demiurge
Oh, I was wondering if there is a specification or a standard on how to handle concatenated JXLs
|
|
2022-11-21 12:28:53
|
there isn't. strictly speaking a JXL file can have any garbage at the end and it is still considered valid
|
|
2022-11-21 12:29:12
|
so a concatenation of valid JXL files is just the first one
|
|
2022-11-21 12:29:23
|
in practice you can always find the end because there's a table of contents
|
|
2022-11-21 12:29:38
|
which means you don't *have* to discard the junk
|
|
2022-11-21 12:42:06
|
but no, there's currently no technical specification on something like that
|
|
2022-11-21 12:42:13
|
multi-page JXL currently isn't a thing
|
|
2022-11-21 03:14:39
|
TIL that jxlatte uses an extraordinary amount of RAM
|
|
2022-11-21 03:15:02
|
and I'm not entirely sure why
|
|
2022-11-21 03:15:11
|
looks like I have some optimization to do
|
|
|
|
Jyrki Alakuijala
|
2022-11-22 04:38:31
|
Pale Moon browser added jpeg xl: https://www.palemoon.org/releasenotes.shtml 🌛
|
|
|
username
|
|
Jyrki Alakuijala
Pale Moon browser added jpeg xl: https://www.palemoon.org/releasenotes.shtml 🌛
|
|
2022-11-22 04:44:26
|
not to be the bringer of bad news but I'm testing it out and something is wildly wrong with the colors
|
|
2022-11-22 04:44:52
|
check <#803574970180829194> for more info
|
|
2022-11-22 04:53:16
|
also theres no progressive support. and it also seems like there is no alpha support either although i'm not 100% sure about alpha
|
|
2022-11-22 09:05:13
|
oh also forgot to mention there is no support for animated jxl files either
|
|
|
|
Jyrki Alakuijala
|
2022-11-22 09:58:49
|
any technical problem is very easy to fix, it is just code 🙂
|
|
|
|
username
|
2022-11-22 10:00:50
|
their code is based on firefox's initial implementation and there are unmerged patches for firefox that add support for the missing features (besides HDR)
|
|
2022-11-22 10:01:47
|
however porting over the patches isn't as simple as I thought it was since palemoon lacks OS_RGBA and OS_RGBX as surface formats
|
|
|
Wolfbeast
|
2022-11-23 11:59:16
|
Hey folks.
|
|
|
username
however porting over the patches isn't as simple as I thought it was since palemoon lacks OS_RGBA and OS_RGBX as surface formats
|
|
2022-11-24 12:00:47
|
We're not naming it the same way ;) Mozilla's been a refactoring house and often it's not necessary. https://repo.palemoon.org/MoonchildProductions/UXP/issues/1925#issuecomment-30965
|
|
|
|
username
|
2022-11-24 12:02:38
|
oh have you seen the problems with the colors? for example all jxl images when rendered in palemoon have their red and blue channels swaped from the looks of it
|
|
2022-11-24 12:02:46
|
it can clearly be seen here https://sneyers.info/progressive/webp-jxl.html
|
|
|
|
Wolfbeast
|
2022-11-24 12:02:57
|
I was made aware of it, which is why I'm here.
|
|
2022-11-24 12:04:09
|
As for progressive support and especially animated, that's lower priority than getting static image support fleshed out first.
|
|
2022-11-24 12:04:38
|
I was honeslty under the impression we had already sorted the swapped color channel issue but apparently not. Wouldn't have enabled it by default if I had been aware.
|
|
|
|
username
|
2022-11-24 12:06:35
|
I don't blame you for not noticing since it seems like the only jxl images tested in palemoon where the ones at https://jpegxl.info/ and https://jpegxl.info/art which don't look all that wrong if you don't know how they should look
|
|
|
|
Wolfbeast
|
2022-11-24 12:07:18
|
Exactly. I didn't have any photographic examples handy and assumed that was how they were supposed to look.
|
|
|
|
veluca
|
|
Wolfbeast
As for progressive support and especially animated, that's lower priority than getting static image support fleshed out first.
|
|
2022-11-24 12:12:09
|
fwiw, there should be some firefox pending patches that add support for alpha and animation iirc, not sure how easy to integrate they'd be
|
|
2022-11-24 12:13:35
|
here's a random jxl file to test against: https://old.lucaversari.it/jpeg_xl_data/bees.jxl
|
|
2022-11-24 12:14:02
|
it should be fairly obvious if color channels end up swapped 🙂
|
|
|
|
username
|
2022-11-24 12:14:17
|
here are the bug pages for the unmerged patches (with the patches attached) for future reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=1709814
https://bugzilla.mozilla.org/show_bug.cgi?id=1709815
https://bugzilla.mozilla.org/show_bug.cgi?id=1709818
|
|
|
|
veluca
|
|
veluca
here's a random jxl file to test against: https://old.lucaversari.it/jpeg_xl_data/bees.jxl
|
|
2022-11-24 12:16:50
|
actually, a more complete list is here: https://github.com/libjxl/conformance/tree/master/testcases (ref.png is how it's *supposed* to look like)
|
|
|
|
Wolfbeast
|
2022-11-24 12:19:29
|
Well we're tracking it on our repo, anyway. https://repo.palemoon.org/MoonchildProductions/UXP/issues/2033 -- I'll discuss and look into it tomorrow a bit more (it's past 1 am here)
|
|
|
|
veluca
|
2022-11-24 12:20:28
|
fair enough, so it is here 🙂 feel free to ping me/us if needed!
|
|
2022-11-24 01:10:37
|
done that myself 😛
|
|
|
|
_wb_
|
2022-11-24 08:38:24
|
Added pale moon (and firefox nightly) to https://jpegxl.info/why-jxl.html
|
|
|
|
username
|
|
_wb_
Added pale moon (and firefox nightly) to https://jpegxl.info/why-jxl.html
|
|
2022-11-24 09:31:23
|
i'm not too sure about adding firefox nighty because it really seems like mozilla don't care much about jxl and only have basic support in nightly just in case chrome enabled support
|
|
2022-11-24 09:32:09
|
I could very easily see mozilla removing support soon after chrome does
|
|
|
|
_wb_
|
2022-11-24 09:33:51
|
we'll have to see, if they announce that, then I'll remove the icon and move it to the text below
|
|
|
|
daniilmaks
|
2022-11-24 09:35:20
|
<@794205442175402004> your comparison table list avif as having 10 bit max depth when it's 12 bit
|
|
2022-11-24 09:36:37
|
the generational loss value is also not accurate now with 444 as de facto
|
|
|
|
_wb_
|
2022-11-24 09:37:05
|
well avif only has profiles defined for that correspond to Main and High AV1
|
|
2022-11-24 09:37:10
|
not Professional AV1
|
|
2022-11-24 09:38:04
|
so I guess you could make an avif without profile and do 12-bit, but that seems unwise if you want interoperability
|
|
|
|
daniilmaks
|
2022-11-24 09:39:04
|
profiles are only really relevant to video anyways since there's no use for hardware encoder support in images
|
|
|
|
_wb_
|
2022-11-24 09:39:09
|
as for generation loss: with 444 that is better, but it still seems quite bad, see https://www.youtube.com/watch?v=FtSWpw7zNkI
|
|
|
profiles are only really relevant to video anyways since there's no use for hardware encoder support in images
|
|
2022-11-24 09:39:30
|
why do they then even bother to define avif profiles?
|
|
|
|
daniilmaks
|
|
_wb_
why do they then even bother to define avif profiles?
|
|
2022-11-24 09:42:32
|
idk but the fact remains: avif goes up to 12 bits.
|
|
2022-11-24 09:43:07
|
I'd ask <@321486891079696385>
|
|
|
|
_wb_
|
2022-11-24 09:44:31
|
In the article that chart is from, I did add a note at the bottom: https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg
|
|
2022-11-24 09:45:32
|
HEIC has a similar thing, where technically it does higher bit depths and 4:4:4, but in the chart I also put lower limits
|
|
|
|
daniilmaks
|
|
_wb_
as for generation loss: with 444 that is better, but it still seems quite bad, see https://www.youtube.com/watch?v=FtSWpw7zNkI
|
|
2022-11-24 09:45:33
|
you should consider making a new video eventually, this one's 2 years old and both jxl and avif have had changes since then.
|
|
|
|
_wb_
|
2022-11-24 09:46:48
|
what I put in the chart is what I expect to be actually safe to use, e.g. with HEIC, on many Apple devices it just refuses to decode 4:4:4 and more than 10-bit, so in practice you cannot really use that
|
|
|
|
daniilmaks
|
2022-11-24 09:47:30
|
is it safe to use 32bpc jxl in browsers?
|
|
|
|
_wb_
|
2022-11-24 09:47:50
|
for AVIF it's still a bit early to say, but most hardware encoders/decoders will likely not go higher than 10-bit. To what extent that will be relevant is still to be seen though.
|
|
|
|
daniilmaks
|
|
_wb_
for AVIF it's still a bit early to say, but most hardware encoders/decoders will likely not go higher than 10-bit. To what extent that will be relevant is still to be seen though.
|
|
2022-11-24 09:50:04
|
I've been told several times avif will never get hardware acceleration (from video accelerators*) because of the overhead of spooling the encoder up.
Which is why profiles in avif are for practical purposes non-existent.
|
|
|
|
_wb_
|
2022-11-24 09:50:14
|
32-bit jxl should work fine in anything that uses libjxl, but of course for web delivery that kind of precision is total overkill
|
|
2022-11-24 09:51:22
|
I agree that avif hardware decode is probably unlikely to happen. I don't know about hardware encode though — if they really want to use avif in phone cameras, they'll very likely have to use hardware encode because software encode is way too slow...
|
|
|
|
daniilmaks
|
2022-11-24 09:53:41
|
this is in the realm of speculation, we don't know if HDR may just push manufacturers to 12 bit avif asics
|
|
|
|
_wb_
|
2022-11-24 09:54:50
|
sure. For now, I can only assume that they defined the profiles in a way that corresponds to how they think it will be used.
|
|
|
|
daniilmaks
|
2022-11-24 09:55:52
|
at the very least you could put an asterisk
|
|
|
|
_wb_
|
2022-11-24 09:56:18
|
I'd have to put a lot of asterisks then.
|
|
|
|
daniilmaks
|
2022-11-24 09:56:42
|
it's very minor either way, sure.
|
|
|
|
_wb_
|
2022-11-24 09:56:42
|
JPEG also does 12-bit, for example
|
|
|
|
daniilmaks
|
2022-11-24 09:57:27
|
most avif decoders do 12 bit. the same can't be said for jpeg.
|
|
2022-11-24 09:58:17
|
but I'll drop the issue for now since it just doesn't matter much.
|
|
2022-11-24 09:59:04
|
I want to see a future with jxl.
|
|
|
|
diskorduser
|
2022-11-24 10:03:36
|
When I use some jxl files as wallpaper in kde plasma, it uses more cpu like 85%. it's a plasma related bug. right?
|
|
2022-11-24 10:03:50
|
this file.
|
|
|
novomesk
|
2022-11-24 11:04:30
|
I think the same issues which was with Qt AVIF plugin was also with Qt JXL plugin. Upgrade to kimageformats 5.100 which should be fixed.
|
|
2022-11-24 11:07:04
|
I know some distros backported fixes into kimageformats 5.99 (for example Gentoo) but some other backported fixes only for AVIF.
|
|
|
|
_wb_
|
|
Wolfbeast
Well we're tracking it on our repo, anyway. https://repo.palemoon.org/MoonchildProductions/UXP/issues/2033 -- I'll discuss and look into it tomorrow a bit more (it's past 1 am here)
|
|
2022-11-24 11:24:32
|
I just created a test page to have a simple way to check the various things: https://jpegxl.info/test-page/
|
|
|
|
Traneptora
|
2022-11-24 11:29:22
|
looks like my display is SDR <:Pausers:1019605474565435423>
|
|
|
|
Wolfbeast
|
|
_wb_
I just created a test page to have a simple way to check the various things: https://jpegxl.info/test-page/
|
|
2022-11-24 11:34:20
|
Thanks, appreciated. i can already confirm that my quick fix for RGB seems to work and we're supporting wide gamut properly. no animation or transparency yet.
|
|
|
|
username
|
2022-11-24 11:36:01
|
one of the 3 unmerged firefox patches includes proper alpha support however it's not labeled, I think it's the one that adds animation support that includes alpha support
|
|
|
|
afed
|
2022-11-24 11:39:09
|
Firefox vs Chrome
|
|
|
pandakekok9
|
2022-11-24 11:41:08
|
Hello everyone, I'm one of the devs contributing to Pale Moon's platform, and am the one who did the initial work of adding JPEG-XL support. :)
|
|
|
|
_wb_
|
2022-11-24 11:41:08
|
on an sRGB screen, you're not supposed to see the logo, so if firefox shows it for jxl but not for png/jpeg, it's because it isn't doing color management for jxl
|
|
2022-11-24 11:41:31
|
Welcome!
|
|
|
|
username
|
|
afed
Firefox vs Chrome
|
|
2022-11-24 11:42:01
|
shows up like this in firefox for me with all the unmerged patches
|
|
|
|
_wb_
|
2022-11-24 11:44:17
|
Is there a way to setup a "firefox nightly + patches" build workflow and put the binaries somewhere online? that would be very cool...
|
|
2022-11-24 11:44:36
|
(unless we can get those patches merged somehow)
|
|
|
|
afed
|
2022-11-24 11:45:07
|
also images are bigger in Firefox, for some reason, probably a different markup handling
|
|
|
|
_wb_
|
2022-11-24 11:46:35
|
could be I messed something up in the html/css
|
|
|
|
Moritz Firsching
|
|
pandakekok9
Hello everyone, I'm one of the devs contributing to Pale Moon's platform, and am the one who did the initial work of adding JPEG-XL support. :)
|
|
2022-11-24 11:47:25
|
Welcome!
|
|
|
w
|
|
|
afed
|
2022-11-24 11:50:44
|
maybe add different ways to rotate the image, or does libjxl always do this correctly on its own if enabled?
|
|
|
|
Traneptora
|
|
afed
maybe add different ways to rotate the image, or does libjxl always do this correctly on its own if enabled?
|
|
2022-11-24 12:22:44
|
by default libjxl orients the image according to the codestream already
you can disable that explicitly
|
|
|
|
afed
|
2022-11-24 12:29:16
|
i mean in test_page
|
|
|
|
_wb_
|
2022-11-24 12:34:32
|
Could add an image with orientation to be sure, but this is not something that browsers should typically get wrong since you need to explicitly tell libjxl to give you pixels without correct orientation...
|
|
|
|
afed
|
2022-11-24 12:41:16
|
and `<title>JPEG XL Art</title>`
|
|
|
|
username
|
2022-11-24 01:09:24
|
i've noticed something is wrong with firefox's support with jxl (edit: or maybe something just wrong with firefox in general?)
|
|
2022-11-24 01:09:57
|
chrome:
|
|
2022-11-24 01:10:27
|
firefox:
|
|
2022-11-24 01:11:38
|
that's weird all of the images in firefox have what looks like an increased saturation expect the jxl
|
|
2022-11-24 01:12:20
|
while in chrome they all have the same not saturated colors
|
|
|
|
afed
|
2022-11-24 01:16:07
|
firefox 109.0a1
|
|
|
|
username
|
2022-11-24 01:17:10
|
oh it should work just fine you just need to make sure you remove the nightly check from what I remember
|
|
|
|
veluca
|
2022-11-24 01:17:13
|
maybe you need to enable color management for images without an ICC?
|
|
|
|
username
|
2022-11-24 01:18:41
|
i'm using this build to test btw https://dist.grass.moe/firefox-108.0.en-US.win64.installer.exe
|
|
2022-11-24 01:19:40
|
maybe theres something up with this build?
|
|
2022-11-24 01:19:42
|
|
|
|
|
afed
|
2022-11-24 01:22:48
|
https://dist.grass.moe/firefox-108.0.en-US.win64.installer.exe
|
|
|
|
username
|
2022-11-24 01:25:43
|
I found out the issue having "gfx.color_management.mode" set to 2 caused the other images to be saturated while keeping the jxl normal
|
|
|
|
w
|
2022-11-24 01:32:54
|
gfx.color_management.mode should be 1
|
|
2022-11-24 01:33:13
|
jxl is always managed, but the others, if not tagged, wont be managed if gfx.color_management.mode = 2
|
|
|
|
username
|
|
w
gfx.color_management.mode should be 1
|
|
2022-11-24 01:34:27
|
it was set to 2 by default in your build
|
|
|
|
w
|
2022-11-24 01:34:57
|
https://bugzilla.mozilla.org/show_bug.cgi?id=455077
|
|
2022-11-24 01:35:44
|
so the answer is, jxl looks like that (the odd one out) because it's the only correct one
|
|
|
|
_wb_
|
2022-11-24 01:36:22
|
is this fixed in your build, <@288069412857315328> ?
|
|
|
|
username
|
2022-11-24 01:36:30
|
it is
|
|
|
|
_wb_
|
2022-11-24 01:36:35
|
ah cool
|
|
2022-11-24 01:36:59
|
I thought firefox didn't do alpha, but this looks more like it interprets alpha as premultiplied or something?
|
|
|
|
w
|
2022-11-24 01:37:15
|
i remember it was fixed when figuring out animated
|
|
2022-11-24 01:37:38
|
something to do with informing the pipeline of alpha
|
|
|
|
_wb_
|
2022-11-24 01:44:04
|
I wonder how much effort it is to make forks of firefox and chromium that are literally just the upstream browser + jxl enabled by default, making automated builds for them for windows/mac/linux/android, and putting it somewhere on a website
|
|
|
|
veluca
|
2022-11-24 01:49:58
|
presumably it's just a *lot* of compute on different machines/OSs
|
|
2022-11-24 01:51:10
|
+- some policy/license discussions?
|
|
|
|
username
|
2022-11-24 02:12:25
|
when palemoon's jxl support is a little more fleshed out me and a friend might try to submit a pull request to waterfox (and maybe even waterfox classic) to add the unmerged jxl patches along with enabling jxl since the argument can be made a browser has already added almost full support and that the code is unlikely to break when moving to future versions of firefox esr
|
|
2022-11-24 02:15:45
|
even if mozilla removes it's basic jxl support in future versions of firefox it should be pretty easy to add it back in as it's very unlikely the parts of firefox's code that the jxl support is attached to will change much at all
|
|
|
|
diskorduser
|
|
_wb_
I wonder how much effort it is to make forks of firefox and chromium that are literally just the upstream browser + jxl enabled by default, making automated builds for them for windows/mac/linux/android, and putting it somewhere on a website
|
|
2022-11-24 02:18:28
|
Yeah. Opensuse build service is useful for that.
|
|
|
|
_wb_
|
2022-11-24 02:24:15
|
Does firefox have an HDR image pipeline at all? That would be the only thing still missing when the unmerged patches are applied, right?
|
|
|
Kleis Auke
|
|
_wb_
I thought firefox didn't do alpha, but this looks more like it interprets alpha as premultiplied or something?
|
|
2022-11-24 02:25:40
|
Ah, I remembered a similar issue in libvips a while ago (<https://github.com/libvips/php-vips/issues/36#issuecomment-285726187>). Try processing <https://upload.wikimedia.org/wikipedia/commons/archive/4/47/20100130232511%21PNG_transparency_demonstration_1.png> instead.
|
|
2022-11-24 02:26:11
|
(see e.g. the file history on Wikimedia, <https://commons.wikimedia.org/w/index.php?title=File:PNG_transparency_demonstration_1.png&limit=500>)
|
|
|
|
username
|
|
_wb_
Does firefox have an HDR image pipeline at all? That would be the only thing still missing when the unmerged patches are applied, right?
|
|
2022-11-24 02:28:24
|
I have no clue about firefox's HDR support or if it even has any from of HDR support in the first place but yeah from what I know it's the only thing that would be missing with it's jxl implementation
|
|
2022-11-24 02:28:52
|
oh from the looks of it firefox's avif decoder supports HDR in some form acording to the comment here https://bugzilla.mozilla.org/show_bug.cgi?id=1709857
|
|
2022-11-24 02:29:15
|
```"I'm not fully aware how to do this, but given that the JXL format supports it and the existing AVIF decoder also support it, it should also be able to be done in nsJXLDecoder."```
|
|
|
|
BlueSwordM
|
|
_wb_
why do they then even bother to define avif profiles?
|
|
2022-11-24 03:02:09
|
HW decoders.
|
|
|
|
daniilmaks
|
2022-11-24 05:34:46
|
you have told me they were useless tho
|
|
2022-11-24 05:35:10
|
...or someone else did at least
|
|
|
|
Jim
|
2022-11-24 05:39:04
|
For images, they largely are, but since AVIF is based on AV1, a hardware decoder already exists. On the other hand, hardware encoders are always useful, even for images. Cameras and other devices can use them to offload encoding images or videos faster.
|
|
|
|
daniilmaks
|
|
Jim
For images, they largely are, but since AVIF is based on AV1, a hardware decoder already exists. On the other hand, hardware encoders are always useful, even for images. Cameras and other devices can use them to offload encoding images or videos faster.
|
|
2022-11-24 06:42:57
|
*this is what I exposed before I was told they were useless on images*
|
|
|
lonjil
|
2022-11-24 08:06:49
|
They are useless even if you have hardware.
|
|
2022-11-24 08:07:36
|
For one, AVIF images often use features not necessarily supported by HW decoders. For two, it adds so much overhead that it isn't worth it at all.
|
|
|
|
Wolfbeast
|
2022-11-25 12:17:03
|
IMHO AVIF is just doing another WebP, using a video codec to push an image format. It really doesn't add anything new.
|
|
|
|
veluca
|
2022-11-25 01:18:20
|
~~at least it's not 420 only~~
|
|
|
|
Jim
|
2022-11-25 05:18:32
|
Was watching a video from a Mozilla developer and they insinuated that the Chrome team was politically motivated when it comes to API development... but you know, that's unprofessional. <:kekw:808717074305122316>
|
|
|
DZgas Ж
|
|
Wolfbeast
IMHO AVIF is just doing another WebP, using a video codec to push an image format. It really doesn't add anything new.
|
|
2022-11-26 07:51:52
|
But what about slowing down encoding by hundreds of times, a new feature<:ReeCat:806087208678588437>
|
|
|
|
Wolfbeast
|
|
DZgas Ж
But what about slowing down encoding by hundreds of times, a new feature<:ReeCat:806087208678588437>
|
|
2022-11-26 12:36:52
|
Good point! I'm sure any advantage saved by reducing bandwidth would be killed and then some by the power bill for encoding ;)
|
|
|
|
_wb_
|
2022-11-26 12:50:03
|
Not for a Netflix-style 1-to-many-millions delivery model. But for a Facebook-style 1-to-some delivery model (or Whatsapp 1-to-1), yes.
|
|
|
|
daniilmaks
|
|
Wolfbeast
IMHO AVIF is just doing another WebP, using a video codec to push an image format. It really doesn't add anything new.
|
|
2022-11-26 01:09:31
|
despite not being the best all rounder it is the best low bpp codec currently available regardless of it's makeshift nature
|
|
|
|
Jim
|
|
_wb_
Not for a Netflix-style 1-to-many-millions delivery model. But for a Facebook-style 1-to-some delivery model (or Whatsapp 1-to-1), yes.
|
|
2022-11-26 01:11:27
|
Youtube's many-to-many-some-to-millions model is likely to be inefficient as well.
|
|
2022-11-26 01:12:13
|
Granted, that will change as hardware catches up and the software/hardware implementations become more efficient. It will just take time.
|
|
2022-11-26 01:12:32
|
I believe same happened with VP9
|
|
|
|
Wolfbeast
|
|
despite not being the best all rounder it is the best low bpp codec currently available regardless of it's makeshift nature
|
|
2022-11-26 09:54:17
|
Sorry but low bpp really isn't all that interesting of a metric. If you want real low bpp then you're usually also dealing with small sizes (widgets, thumbnails, etc.) which aren't going to strain bandwidth anyway. The savings on an already small file aren't impactful.
|
|
|
|
_wb_
|
2022-11-26 10:01:49
|
I think in bandwidth-constrained use cases, progressive decoding is a way more useful thing to have than just making images look ugly so they take less bytes
|
|
2022-11-26 10:05:02
|
The problem with video codecs is that they are never designed to allow progressive decode of single frames (why would they?), and if you're going to use a standard decode library, it won't even have an api that can do incremental (top-down) loading, since again: why would you need that in a video use case?
|
|
2022-11-26 10:05:31
|
With WebP they had to spend considerable effort to make libwebp do incremental vp8 decoding
|
|
2022-11-26 10:07:50
|
With avif it still has to happen (atm it's not even incrementally loading), but at some point the "you get two for one" argument that "avif comes for free since we need av1 anyway" becomes a bit stretched...
|
|
|
|
spider-mario
|
2022-11-26 10:31:07
|
plus the part where no one makes, say, 100MP video (and hardware decoders generally don’t support that), but it’s not unheard of for still images
|
|
2022-11-26 10:32:43
|
https://docs.nvidia.com/video-technologies/video-codec-sdk/nvdec-video-decoder-api-prog-guide/ says VP9/AV1 decoding supports up to 8192×8192
|
|
2022-11-26 10:32:56
|
an α7R IV produces 9504×6336 (61MP) images
|
|