|
Traneptora
|
2026-02-27 04:17:30
|
so libx264 is going to buffer at minimum 50 frames for its psychovisual model |
|
2026-02-27 04:17:38
|
jxl-rs is intra-only |
|
2026-02-27 04:17:47
|
you should not expect it to be competitive. this doesn't seem like a png issue |
|
2026-02-27 04:18:22
|
also you should use `-framerate` as an AVOption for the image2 demuxer. `-r` does something else |
|
|
jonnyawsom3
|
2026-02-27 04:49:10
|
jxl-rs is buffering all frames in memory before writing, so I expected FFMPEG to use that plus a few hundred megs for the x264 encoding. Instead it went from 1.2 GB to 2.8 GB, and even with veryfast it only reduced to 2.5 GB. Intra only takes it down to 1.7 GB but naturally explodes the filesize, even setting it to 10 already goes back to 2.8 GB, so maybe I'll just have to be harder on the maximum resolution.
Thanks for the help as always |
|
|
RaveSteel
|
2026-02-27 10:49:12
|
https://hydrogenaudio.org/index.php/topic,129205.0.html probably one of the worst threads I've ever read regarding video compression |
|
|
Exorcist
|
2026-02-27 12:01:09
|
I want fast
I want quality
I want small
I want all these for free<:Stonks:806137886726553651> |
|
|
TheBigBadBoy - πΈπ
|
2026-02-27 02:30:22
|
I was wondering, has anyone tested lossless jpeg compressors, like Brunsli, Lepton, JXL ? |
|
|
|
Exorcist
|
|
|
TheBigBadBoy - πΈπ
|
2026-02-27 02:32:19
|
oh nice thx |
|
2026-02-27 02:34:06
|
wait, what does `BRN/JXL` even mean ? |
|
2026-02-27 02:34:29
|
oh you take the best out of the 2 |
|
2026-02-27 02:34:31
|
perhaps |
|
|
|
Exorcist
|
2026-02-27 02:34:34
|
Try both, choose the best |
|
|
|
TheBigBadBoy - πΈπ
|
2026-02-27 02:34:38
|
yeah right |
|
2026-02-27 02:39:29
|
so there are plenty of "jpeg optimizers" (output is smaller jpeg, lossless)
quite funny to me that smallest jpeg ( = minimum file size for a jpeg, better huffman table & bruteforcing scans usign jpegultrascan) makes a bigger file with e.g. jxl |
|
|
|
Exorcist
|
2026-02-27 02:44:31
|
If you use non-standard table, JXL need to store them for someone want to restore at future<:kekw:808717074305122316> |
|
|
|
TheBigBadBoy - πΈπ
|
2026-02-27 04:41:28
|
is there a list of std tables anywhere? |
|
|
|
Exorcist
|
2026-02-27 04:55:57
|
`libjpeg` |
|
|
juliobbv
|
2026-02-27 08:04:28
|
Hey, just wanted to give y'all a heads-up: tune IQ will be enabled by default for the next libavif release (v1.4.0) when using libaom as the encoder: https://github.com/AOMediaCodec/libavif/commit/9688dcf260f9aa442cfdb5e1dac6dfc6240bcfe4 |
|
2026-02-27 08:08:28
|
So the command to encode images has now been simplified to:
`avifenc (optional and recommended: -d 10) -s <speed/effort> -q <quality> <input> <output>` |
|
2026-02-27 08:09:22
|
Let me know if you have any questions or observations π! Libavif v1.4.0 is scheduled to be released in early March. |
|
|
_wb_
|
2026-02-27 08:37:55
|
Nice! |
|
|
|
juliobbv
|
2026-02-27 08:53:19
|
just trying my best to push boundaries at improving perceptual quality |
|
|
|
_wb_
|
2026-02-27 09:02:23
|
Much appreciated. |
|
2026-02-27 09:07:40
|
In jxl, I have the feeling we're a bit stuck in libjxl; the encoder is too much of a delicate combination of heuristics to really allow changing things much. |
|
2026-02-27 09:10:08
|
Maybe we should add an encoder from scratch to jxl-rs with a somewhat different encoder design, making it easier to have different tunings and to experiment with things |
|
|
|
juliobbv
|
2026-02-27 09:13:21
|
that'd be a great idea IMO |
|
2026-02-27 09:14:34
|
do you think developing a next-next-gen image metric could be good enough to have a greater say on guiding how perceptual heuristics are written/influencing RDO decisions within an encoder? |
|
2026-02-27 09:16:52
|
there's also addressing perceptual quality variability within humans w.r.t. dark area detail preservation and B channel quantization aggressiveness |
|
2026-02-27 09:20:29
|
modern metrics helped us guide tune IQ's heuristics, but ultimately the process wasn't automatable because we still had human evaluation "checkpoints" |
|
2026-02-27 09:29:30
|
<@794205442175402004> BTW I used one of your example images to showcase the visual improvement from using tune IQ |
|
2026-02-27 09:29:54
|
(tune SSIM speed 6 355 KB, tune IQ speed 6 349 KB, original 10.1 MB) |
|
|
|
_wb_
|
2026-02-27 09:30:14
|
it's not my image, this is a test image the JPEG committee has been using already since JPEG 2000 times I think |
|
|
|
juliobbv
|
2026-02-27 09:30:37
|
oh, I got you |
|
2026-02-27 09:32:21
|
I recall it was used in of the Cloudinary blogposts, but it's interesting to learn this image has some history π |
|
|
AccessViolation_
|
2026-02-27 09:36:06
|
it seems like tune IQ has more detail basically everywhere. is not just making better decisions about where to preserve detail, but also better at preserving detail per bit, in general? |
|
2026-02-27 09:37:35
|
yess this is exactly what I was hoping for ^^
some sort of modular design that makes it relatively easy to add a distinct code path with different encoder logic, for experimentation |
|
|
|
juliobbv
|
2026-02-27 09:40:09
|
boiling it all down, tune IQ is basically a set of heuristics to reallocate bit budget for greater visual consistency (luma vs chroma, low contrast vs high contrast, high vs low frequency detail, etc), with some RDO and filter tweaks for an increased perceptual sharpness |
|
2026-02-27 09:43:22
|
relative to the entire image, the sweater in the tune IQ image uses fewer bits and is mathematically more "distorted" than tune SSIM's, but the encoder can still get away with it because the end result will still look pleasing enough to the eye |
|
2026-02-27 09:44:29
|
and the extra bits allow for better encoding of the hair, skin, and background |
|
2026-02-27 09:46:19
|
so overall quality is much more consistent throughout the image, without those terrible "flat/smudged spots" |
|
|
|
veluca
|
2026-02-27 09:47:20
|
that's in the plans but laaaater |
|
2026-02-27 09:49:04
|
(and starting from lossless, because it's much much easier) |
|
|
|
AccessViolation_
|
2026-02-27 09:50:14
|
now that I think about it, it does seem like encoders might be making a fundamentally wrong assumption. we spend bits to preserve detail, but there's a certain point where an area is so 'busy' that distortions are very hard to notice. so while you should take care to preserve a detail against a flat background, you can get away with fewer bits if there's nothing but sharp details, and can use those to instead better preserve slight detail in otherwise flat areas |
|
2026-02-27 09:51:22
|
I think I mentioned this in passing before when thinking about how you can 'hide' transparent shapes in noise just because there's too much going on for us to notice them |
|
|
|
_wb_
|
2026-02-27 09:53:55
|
This is kind of the reason we generally use steep quant tables, with more quantization in the high frequencies. |
|
|
|
AccessViolation_
|
2026-02-27 09:54:42
|
oh right, yeah |
|
2026-02-27 10:06:58
|
and I'm guessing adaptive quantization is for compensating for cases where this doesn't hold? like the example of sharp detail against a flat background, which might need more bits than just sharp detail alone which can be reasonably distorted without it being noticeable |
|
2026-02-27 10:08:42
|
it sounds like it would be theoretically possible to apply the local quality assessment logic of tune=iq, and use that in adaptive quantization, to a similar effect |
|
|
|
juliobbv
|
2026-02-27 10:09:58
|
correct me if I'm wrong, but libjxl currently doesn't do content-adaptive QM selection, right? |
|
2026-02-27 10:10:09
|
that'd be a great area of exploration |
|
|
|
AccessViolation_
|
2026-02-27 10:11:00
|
(I'm not saying that's something we should pursue, I just mean that it sounds like a large part of what tune=iq is doing is methodologically applicable to JXL as well) |
|
2026-02-27 10:12:22
|
it does do adaptive quantization afaik. you also can't turn it off with cjxl. in the past there have been issues raised where disabling adaptive quantization in the code resulted in better or more consistent quality, iirc |
|
|
|
juliobbv
|
2026-02-27 10:13:11
|
oh, I didn't mean AQ but rather modulating QM steepness based on image features |
|
2026-02-27 10:14:18
|
e.g. certain QMs are better for animation, some others for clean photographs and some others for noisy photographs |
|
|
|
AccessViolation_
|
2026-02-27 10:15:41
|
ah, so basically the idea of adapting the base quant tables to the image features?
JXL does support that (in several ways, we can generate quant tables form parameters or signal completely arbitrary raw ones), and no it isn't done currently |
|
|
|
juliobbv
|
2026-02-27 10:16:02
|
got you, I see |
|
|
|
AccessViolation_
|
2026-02-27 10:16:33
|
though we can only use the same 'base' quant tables everywhere. does AVIF allow you to modulate them locally? because that sounds awesome |
|
|
|
juliobbv
|
2026-02-27 10:17:03
|
unfortunately it's not the case in AV1 |
|
2026-02-27 10:17:09
|
QMs are set per-frame |
|
|
|
AccessViolation_
|
2026-02-27 10:17:18
|
ah okay, so similar situation |
|
2026-02-27 10:18:24
|
I actually brought up the idea of optimizing quant tables to the specific image features before, but I had no idea whether it'd actually result in anything useful or whether it was computationally feasible |
|
2026-02-27 10:20:44
|
|
|
2026-02-27 10:24:29
|
If I had a penny for every time I invented something already applied by AVIF (for better or worse) I would have three pennies, which isn't a lot, but it's weird that it happened thrice |
|
2026-02-27 10:31:43
|
<@297955493698076672> now that you here, random fly-by question I thought about a while ago: does lossless AVIF encoding use PSNR for the lossy base image, because I was just thinking that if you're encoding residuals to arrive at the lossless original, you should optimize for low pixel error rather than visual fidelity, and it seems it'd be an easy oversight to accidentally use 'better' metrics instead <:KekDog:805390049033191445> |
|
|
|
juliobbv
|
2026-02-27 10:32:10
|
AV1 has a true lossless mode |
|
2026-02-27 10:32:23
|
there's no need to encode residuals |
|
|
|
AccessViolation_
|
2026-02-27 10:32:52
|
oh I know, but doesn't it work by lossy encoding the image and storing the residuals to get back to it? |
|
|
|
juliobbv
|
|
|
AccessViolation_
|
2026-02-27 10:33:18
|
oh, huh |
|
|
|
juliobbv
|
2026-02-27 10:33:37
|
AV1 has a special lossless transform used when qindex is 0 |
|
|
|
AccessViolation_
|
2026-02-27 10:37:19
|
I can't find anything about this, does it use a predictor based model or something? |
|
|
|
juliobbv
|
2026-02-27 10:38:03
|
about lossless mode? |
|
|
|
AccessViolation_
|
|
|
juliobbv
|
2026-02-27 10:39:06
|
https://aomediacodec.github.io/av1-spec/#intra-segment-id-semantics |
|
2026-02-27 10:39:46
|
IIRC it is a 4x4 WHT |
|
|
|
AccessViolation_
|
2026-02-27 10:41:23
|
neat, thanks |
|
2026-02-27 10:41:42
|
I was very wrong about lossless AVIF for a very long time |
|
|
|
juliobbv
|
2026-02-27 10:41:50
|
no worries π |
|
2026-02-27 10:42:15
|
maybe you were confusing it with AVIF 16-bit support through gainmaps? |
|
|
|
AccessViolation_
|
2026-02-27 10:45:05
|
this is the first time I'm hearing about that, so probably not :p
I'm pretty sure my assumption started when I suggested the possibility of DCT encoding an image lossily and storing residuals to get back to the original, effectively lossless compression, and someone commented that I had reinvented lossless AVIF |
|
2026-02-27 10:46:19
|
though also remember being told that RED(?) has a patent on this method for lossless video? maybe I *am* misremembering |
|
|
|
juliobbv
|
2026-02-27 10:55:36
|
oh yeah, that remark from that person was incorrect |
|
|
|
jonnyawsom3
|
2026-02-28 01:47:39
|
(Sorry for the late reply)
I don't *think* those need a new metric. Dark details could be fixed by using relative differences during quantization instead of absolute, and the methodology of the B channel encoding itself was slightly flawed.
We *are* least perceptive to Blue, but it's a difference channel, so any errors also affect yellow which we're most sensitive to. When we tried hacking together a build with a flat increase to lossy modular's B quality, it outperformed at the same density and quality, suggesting the encoder heuristics are working correctly but it's being clamped too low |
|
2026-02-28 02:05:17
|
Well, I'm pretty sure you can disable it via lower effort levels, and you might be thinking of jpegli where AQ was best disabled at default quality for YCbCr |
|
|
|
juliobbv
|
2026-02-28 04:32:49
|
that makes sense, most of the issues I've seen with chroma desaturation appear in bright yellow objects |
|
|
|
Exorcist
|
2026-02-28 01:37:10
|
Even ignore the fact "DCT use real number, so DCT is not lossless for integer number"
Use DCT without quantization is still meaningless:
- bit-depth is from 8-bit (pixel) to 11-bit (coefficient)
- small coefficient are not round to zero
- can't prediction pixel-by-pixel (for example, PNG) |
|
2026-02-28 01:56:38
|
In H264, lossless mode is transform-bypass (not use transform at all) |
|
|
|
jonnyawsom3
|
2026-03-01 07:50:29
|
What are you playing the video with? |
|
|
|
RaveSteel
|
2026-03-01 08:04:18
|
you can encode magicyuv with 10 bit |
|
2026-03-01 08:04:31
|
you just have to pass 10 bit video to it |
|
2026-03-01 08:06:15
|
OBS uses FFmpeg, which can output 10 bit magicyuv etc. |
|
2026-03-01 08:06:27
|
do report back if you find out how |
|
|
DZgas Π
|
2026-03-01 08:28:44
|
It's so good that 10-bit is baked into the AV1 main standard and should be supported at the bare minimum. Finally, the future... and at the same time, my friend with an iPhone says his screen is black, but 8-bit works.
And the decoding complexity at 10-bit can be up to twice as high. And the encoding complexity increases. And the decoding complexity increases even more at slower presets. And all this needs to be taken into account at 60 fps 720p and the complexity of the image being rendered due to vector overhead. And then *any* ask me why they can't encode 1080p AV1, it's so cool, especially the gameplay And in 10-bit. |
|
2026-03-01 08:37:49
|
In 2026, AV1 isn't yet suitable for mass content distribution, except for very high compression requirements. For example, I compressed the entire second season of Beast Games into 2GB in 720p 10-bit on preset 3, and it looks great. Avg bitrate is 500.
But for reliable #|mass|# distribution, HEVC 8-bit main, normie preset medium, is still better at this point. although even so, I use my own complex preset easyhevcβ’ so that the decoding speed is the same as with ultrafast. |
|
2026-03-01 08:39:00
|
And 8-bit is compensated for by very precise adjustment of the quality ratio to aq3 and other parameters. And av1 just doesn't have this.
Two years ago, I made my own fork of av1, which encodes both dark areas and/with motion without large-block shift artifacts. But now I don't want to bother with that anymore. Dark/block artifacts are solved by a very slow preset (2-4) and 10-bit for av1, or use hevc. |
|
|
NovaZone
|
2026-03-01 09:08:01
|
Thus u lower complexity based on need |
|
2026-03-01 09:36:10
|
As I can very confidenly say that 4k30 10-bit sw decode (CPU) is within 8ish% difference of vp9 8-bit in terms of raw playback decoding |
|
2026-03-01 09:38:31
|
Ie: it will playback just fine even on a 1st gen ryzen quad core apu kek |
|
2026-03-01 09:46:17
|
Tldr: use the tools that av1 provides when pushing the envelope of sw decoding xD |
|
2026-03-01 09:47:03
|
```--fast-decode 1/2 --tile-columns 1/2 --tile-rows 1/2``` |
|
2026-03-01 09:54:32
|
|
|
|
|
Exorcist
|
2026-03-02 05:52:06
|
|
|
2026-03-02 05:52:33
|
|
|
|
|
RaveSteel
|
2026-03-02 11:21:51
|
<@1321081296113373187> I think I was wrong yesterday. Comparing OBS recordings of utvideo, magicyuv and ffv1, which is listed to support 10 bit in FFmpeg it looks like utvideo and magicyuv have the 10 bit P010 recorded only in 8 bits, with what looks to dithering |
|
2026-03-02 11:22:52
|
utvideo **pro** does support 10 bit, but no idea if that is usable via ffmpeg |
|
2026-03-02 11:22:56
|
https://umezawatakeshi.github.io/utvideo/readme.en.html |
|
2026-03-02 11:24:52
|
magicyuy does support 10 bit as well, but also does not seem to be exposed in ffmpeg |
|
2026-03-02 11:28:20
|
magicyuv |
|
2026-03-02 11:28:33
|
ffv1 with yuv420p10le |
|
|
|
cioute
|
2026-03-02 09:14:19
|
my faith in ffmpeg has been shaken a little |
|
|
|
RaveSteel
|
2026-03-02 09:49:53
|
I think magicyuv will not gain any improvements in encode, but it can decode most magicyuv files at least |
|
2026-03-02 09:50:10
|
and ffv1 is too slow |
|
|
Quackdoc
|
2026-03-02 11:03:37
|
>a little |
|
|
|
TheBigBadBoy - πΈπ
|
2026-03-03 01:12:46
|
soooooo
I was playing around with PDF compression, and what took me many many hours is to use better compression for Deflate streams, but I finally managed to get some results. I'm quite sad because it's not as big as I wanted, but well...
```3975217 42min ect80199.pdf
3975241 04min zopfli9.pdf
3975244 04min ect9.pdf
3975300 03min zlib.pdf
4001067 input_already_optimized_by_other_tools.pdf```
The PDF is my master's thesis (70 pages), and it has quite some PNGs and a really big Deflate stream (15MB uncompressed). Because of the 15MB one, I really thought the gains would be far bigger <:PepeHands:808829977608323112>
I used a custom pdfsizeopt, and hope I'll be able to share my script soonβ’
*the compression levels (e.g. 80199) were only applied to the optimization of Deflate streams, not PNGs |
|
2026-03-03 07:57:17
|
other samples:
**Simple PDF for QR code shipping label, 3KB of PNGs**```7268 4.5s ect80199mt_pdf_qrcode_editedByMasterPDF.pdf
7269 1.3s ect9mt_pdf_qrcode_editedByMasterPDF.pdf
7269 1.5s zlib_pdf_qrcode_editedByMasterPDF.pdf
7269 1.4s zopfli9_pdf_qrcode_editedByMasterPDF.pdf```
**PDF from LaTeX, 8 pages, NO image**```89360 21.s ect80199mt_pdf_only_text_Latex.pdf
89362 2.6s ect9mt_pdf_only_text_Latex.pdf
89367 2.4s zopfli9_pdf_only_text_Latex.pdf
89378 0.5s zlib_pdf_only_text_Latex.pdf``` |
|
|
|
cioute
|
2026-03-03 09:17:19
|
maybe i misinformed you about 10-bit ffv1 artifacts, i could not reproduce those artifacts on other videos, apparently that video was just cursed |
|
|
|
Quackdoc
|
2026-03-03 09:33:18
|
it might be a decoder issue too then? |
|
|
|
Exorcist
|
2026-03-04 08:59:02
|
MozJPEG have many customized (not Annex K) quantization table, and pick the best one for every image
Guetzli generate unique quantization table for every image |
|
|
|
AccessViolation_
|
2026-03-04 09:00:00
|
oh really? I'm surprised Guetzli does this but JPEG XL does not |
|
|
|
jonnyawsom3
|
2026-03-04 09:01:27
|
Are you sure about that? I know it has other quant tables, but I'm pretty sure it just defaults to one |
|
|
|
DZgas Π
|
2026-03-04 09:09:40
|
The reason Guetzli takes so long is because it generates tables, which may still be less than ideal depending on your specific needs. You can view the generated tables in real time using the verbose key |
|
|
|
jonnyawsom3
|
2026-03-04 09:10:23
|
I mean MozJPEG |
|
2026-03-04 09:10:40
|
JPEG doesn't have adaptive quantization, so the tables themselves have to be edited |
|
|
|
DZgas Π
|
2026-03-04 09:10:46
|
and this... no, not |
|
2026-03-04 09:11:05
|
but there are a lot of built-in tables |
|
2026-03-04 09:11:52
|
like |
|
2026-03-04 09:14:22
|
That's too long. It's much more cost-effective to analyze hundreds of thousands of images, generate tables, and use them. This is exactly how JPEG, the fastest lossy image encoder and decoder in the world, works. |
|
2026-03-04 09:16:12
|
It's easy and clear, just take it and use it for 30 years. |
|
2026-03-04 09:20:23
|
For example, in Telegram, binary JPEG data is embedded directly into messages, without the head, just pure compressed data. It seems to be 32x32 pic to display the blurry preview instantly. The head is added separately programmatically to display it. Very clever. |
|
|
|
AccessViolation_
|
2026-03-04 09:30:00
|
encoding is a one time thing though, so it could definitely be worth it |
|
2026-03-04 09:30:28
|
if I understand correctly AVIF does this too, <@297955493698076672> mentioned it |
|
|
|
DZgas Π
|
2026-03-04 09:32:53
|
Guetzli is a popular tool. However, it takes so long to complete its task that it's a bit of a stretch to recommend. Even if it's encoding, everything has its limits, and sometimes it's so inefficient that it's best not to use it. Image compression can be done faster. It hardly costs as much to compress it in a minute. |
|
|
|
Exorcist
|
2026-03-04 09:33:13
|
AV1 spec predefine 16 quantization tables, AV1 can't full customize quantization table |
|
|
|
DZgas Π
|
2026-03-04 09:33:42
|
NEVER QUANT |
|
|
|
AccessViolation_
|
2026-03-04 09:33:52
|
ah, I misunderstood then |
|
|
|
juliobbv
|
2026-03-04 09:33:53
|
it's a miracle we got QMs in AV1 |
|
2026-03-04 09:34:09
|
the implementation came from Cisco's Thor |
|
|
|
DZgas Π
|
2026-03-04 09:35:28
|
We urgently need to launch a genetic algorithm for this |
|
|
|
AccessViolation_
|
2026-03-04 09:35:57
|
I mean it seems like currently the higher efforts in VarDCT do a whole bunch of stuff that doesn't really result in a better image for the same bits used, so I think custom per-image quant tables, even just selecting from a discrete set of them, could be worth exploring |
|
|
|
DZgas Π
|
2026-03-04 09:37:11
|
Well, hasn't anyone yet come up with the idea of ββββitterate the quantization tables for each block separately? |
|
|
|
AccessViolation_
|
2026-03-04 09:38:28
|
this is supposedly one of the reasons AVIF does really well on flat content like anime/manga |
|
|
|
juliobbv
|
2026-03-04 09:39:19
|
It's incredibly tricky to optimize QMs based on any metric. For example, SSIMULACRA 2 tends to like AV1 QM levels that are too low, so images end up looking too blurry. And this issue is only for optimizing between 15 pre-set levels, let alone optimizing each coefficient within the QM independently. |
|
2026-03-04 09:43:06
|
But a good middle ground is to come up with a heuristic that picks preset QMs based on image types (e.g. simple 2D animation, complex 2D animation, cel-shaded animation, CGI, clean live-action, noisy live-action) |
|
|
|
jonnyawsom3
|
2026-03-04 10:35:07
|
It's because of metric scores that the post-v0.8 libjxl regression happened, on top of the quant table issue |
|
|
Demiurge
|
2026-03-05 01:03:06
|
Metrics like blurry splotches |
|
2026-03-05 01:03:38
|
And they often hate fine details and fidelity |
|
2026-03-05 01:04:11
|
So improved detail and fidelity results in lower objective metric scores |
|
2026-03-05 01:04:30
|
While blurry splotches get higher marks :) |
|
2026-03-05 01:05:18
|
That's been a well known phenomenon in the video codec world for decades |
|
2026-03-05 01:06:58
|
The best looking codecs are made by engineers who intentionally do things that they know will result in lower scores yet preserve much more detail and texture. |
|
|
monad
|
2026-03-05 01:36:39
|
0.8 isn't all better, it can mess up the structure of some content which recent versions mitigate |
|
|
|
TheBigBadBoy - πΈπ
|
2026-03-05 01:46:29
|
Alright guys I was completely wrong about my previous PDF compression benchmark
zopfli & ect indeed compress the files much better, but I just forget to turn off the post-processor Multivalent that pdfsizeopt in my previous benchmark π€¦ββοΈ
Anyway, here are the new results:```sh
# 70 pages, many PNGs, many embedded SVGs (one uncompressed Deflate stream is 15MB)
3574631 1h03m ect80199.pdf
3579064 3m15s ect9.pdf
3586733 4m33s zopfli9.pdf
3996652 2m28s zlib9.pdf
# Simple PDF for QR code shipping label, 3KB of PNGs
6802 4.5s ect80199mt_pdf_qrcode_editedByMasterPDF.pdf
6808 1.4s ect9mt_pdf_qrcode_editedByMasterPDF.pdf
6868 1.3s zlib9_pdf_qrcode_editedByMasterPDF.pdf
7168 1.2s zopfli9_pdf_qrcode_editedByMasterPDF.pdf
# PDF from LaTeX, 8 pages, NO image
86202 20.s ect80199mt_pdf_only_text_Latex.pdf
86259 9.3s zopfli9_pdf_only_text_Latex.pdf
86304 2.1s ect9mt_pdf_only_text_Latex.pdf
89340 0.4s zlib9_pdf_only_text_Latex.pdf```faaaar better <:KekDog:805390049033191445> |
|
|
|
monad
|
2026-03-05 01:48:22
|
very nice |
|
|
|
DZgas Π
|
2026-03-05 01:49:10
|
<:Poggers:805392625934663710> 1h03m |
|
|
|
monad
|
2026-03-05 01:49:49
|
ect is good enough |
|
2026-03-05 01:51:58
|
I still have some PDFs with MBs of mystery data despite inspection with various tools. |
|
|
|
TheBigBadBoy - πΈπ
|
2026-03-05 01:52:24
|
I did a PR for pdfsizeopt https://github.com/pts/pdfsizeopt/pull/186
to use ECT I basically uncompressed the zopfli file, gzip'd it, ect'd , then manually byte-copied the Deflate data from Gzip to zlib (so I didn't have to deal with recomputing headers & footers) |
|
2026-03-05 01:55:58
|
next steps are to
- optimize JPEGs, before calling pdfsizeopt (as it skips them)
- then bruteforce the order of a lot of PDF optimization tools (qpdf, mutool, pdfcpu, ghostscript, ...)
- and finally get everything together in my RHEFO script <:KekDog:805390049033191445> |
|
2026-03-05 01:58:32
|
yeah unfortunately pdfsizeopt decompresses & compresses the same data 2~3 times, so that does not help
but it's the easiest tool I could edit to see how good ECT would be (and also the only tool I know where I could do that) |
|
2026-03-05 01:59:21
|
If you don't mind uploading them, I could take a look at them π |
|
|
|
DZgas Π
|
2026-03-05 02:00:02
|
I haven't tried paq8px in a while. Does anyone use it anywhere? |
|
|
|
juliobbv
|
2026-03-05 03:29:36
|
Following up on this, libavif v1.4.0 is out! https://github.com/AOMediaCodec/libavif/releases/tag/v1.4.0 |
|
2026-03-05 03:34:59
|
`tune=iq` is now the default for images, so no more advanced parameter is needed! |
|
|
|
RaveSteel
|
2026-03-05 08:18:03
|
avifenc can now read from stdin, that's huge |
|
|
|
cioute
|
2026-03-05 12:08:58
|
no, 10-bit ffv1 artifacts are not decoder issue (tested both mpv and ffplay), just a cursed video
Usage: cjpegli INPUT OUTPUT [OPTIONS...]
INPUT
the input can be JXL, PPM, PNM, PFM, PAM, PGX, PNG, APNG, GIF, JPEG
nobody wants webp, even apng is more desired |
|
|
|
jonnyawsom3
|
2026-03-05 12:19:53
|
WebP is already small enough |
|
2026-03-05 12:22:39
|
https://github.com/libjxl/libjxl/issues/315#issuecomment-880608516 |
|
|
|
cioute
|
2026-03-05 01:04:12
|
i mean support of webp just in case |
|
|
|
jonnyawsom3
|
2026-03-05 01:20:57
|
Just in case what? |
|
|
|
cioute
|
2026-03-05 01:55:47
|
support just for support
e.g. if u need to convert webp |
|
|
|
RaveSteel
|
2026-03-05 02:15:01
|
ImageMagick and libvips will do anything you need, just pipe to cjxl |
|
|
|
monad
|
2026-03-05 02:23:38
|
why pipe to cjxl if you are already using a universal converter |
|
|
|
RaveSteel
|
2026-03-05 02:30:50
|
cjxl has better/more options than libvips and imagemagick |
|
|
derbergπ
|
2026-03-07 07:14:11
|
I would suggest reopening such issues and just labelling it as "unlikely to happen anytime soon", "zero priority" or similar. |
|
2026-03-07 07:21:02
|
Else issue state "not planned" might be a bit better than "closed" but sadly both land it the "Closed" tab, making it a bit harder to find the "not planned" ones... |
|
|
|
runr855
|
2026-03-11 12:13:11
|
Has cjpegli improved noticeable since libjxl 0.11.x release? I could be tempted to use a main branch build if it gets updated in libjxl, but I fear any regression from using a main build |
|
|
|
jonnyawsom3
|
2026-03-11 03:37:44
|
Not quite https://github.com/libjxl/libjxl/pull/4657 |
|
2026-03-11 03:38:21
|
But if you merge all the pending PRs in the `Google/jpegli` repo, it should give better results by default |
|
|
|
DZgas Π
|
2026-03-11 02:50:33
|
I got a little distracted by researching maximum PNG compression. Advpng.exe using zopfli is probably the best thing possible... but it's not very convenient to use, I usually use pngout.exe like drag and drop |
|
|
|
runr855
|
2026-03-11 08:26:41
|
Why is this being done? Google themselves provide no binaries for jpegli |
|
2026-03-11 08:27:58
|
And what great timing I have |
|
|
Kleis Auke
|
2026-03-11 08:35:57
|
You can download the binaries from the `release.yaml` CI workflow, see for example:
<https://github.com/google/jpegli/actions/runs/22950077572#artifacts> |
|
2026-03-11 08:36:06
|
However, it would likely be better to wait until these projects are fully separated. |
|
|
|
runr855
|
2026-03-11 08:57:01
|
Am I correct in needing to use the API to fetch these artifacts? |
|
|
|
jonnyawsom3
|
|
|
Kleis Auke
|
2026-03-11 09:00:18
|
You need to be logged in to GitHub to download these. |
|
|
|
runr855
|
2026-03-11 09:01:26
|
That seems to have been the problem |
|
2026-03-11 09:01:34
|
Thank you |
|
|
username
|
2026-03-11 09:01:37
|
there does exist this for people who don't want to or can't log in: https://nightly.link/ |
|
2026-03-12 03:56:26
|
https://github.com/randy408/libspng/pull/283 |
|
|
|
Exorcist
|
2026-03-13 03:49:24
|
> 16 years ago
> JPEG2000 is simply not used enough or important enough to justify the outlay of code, time, and increased threat surface.
https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c98 |
|
|
lonjil
|
|
spider-mario
|
2026-03-13 02:06:47
|
> Currently the only way to use lossy images with transparency is: Adobe Flash.
a different era |
|
2026-03-13 02:07:06
|
(was SVG really not already capable of that though?) |
|
2026-03-13 02:10:35
|
ah, but apparently, Internet Explorer did not get SVG until IE9 in 2011 |
|
|
|
cioute
|
2026-03-13 10:11:08
|
is jpegli best jpeg encoder? if no, then which best?
Recommended range: 68 .. 96 (maybe it is hard-mathed but how recommended range calculated?)
no reason to use lower than 64 and higher than 96? |
|
|
A homosapien
|
2026-03-13 10:15:33
|
It's the best all around jpeg encoder, the quality range is just a suggestion, you could go higher or lower if you want. |
|
|
|
cioute
|
2026-03-13 10:20:14
|
i meant practical reason to use 64- or 96+ |
|
|
|
monad
|
2026-03-13 10:22:41
|
I have seen jpegli trip up with bad color results, but I did not check if mozjpeg was better in those cases. So I remain skeptical without really looking carefully. |
|
2026-03-13 10:26:22
|
If you do not have a reason for setting a quality, then do not set it. People who have certain constraints will target quality/size as necessary regardless of basic guidance meant to mitigate naive mistakes. |
|
|
|
cioute
|
2026-03-13 10:34:30
|
i just have an irrational fear of lossy re-compression
even if i not see difference |
|
|
HCrikki
|
2026-03-13 11:29:25
|
stick to high % and theyll make even nicer jxls when losslessly transcoded. jpegli already consumes fewer bits compared to mozjpeg and you can still encode to an exact filesize if you had a specific need for that. even for the same filesize itll look better with less or no banding |
|
|
|
Exorcist
|
2026-03-16 03:25:10
|
https://bsky.app/profile/skepticpunk.bsky.social/post/3mgbftku2ik23 |
|
|
|
jonnyawsom3
|
2026-03-16 04:38:54
|
https://bsky.app/profile/samuel.fm/post/3mgb4baoko227 |
|
2026-03-16 04:39:01
|
Oof |
|
|
|
lonjil
|
2026-03-16 05:25:07
|
Does anyone? |
|
|
|
RaveSteel
|
2026-03-16 05:25:17
|
me |
|
2026-03-16 05:25:28
|
but |
|
2026-03-16 05:25:32
|
has to be sensible |
|
|
|
DZgas Π
|
2026-03-16 05:55:37
|
I have never seen HDR in my life, not any smartphone, not any monitor, not any TV π |
|
|
|
Quackdoc
|
2026-03-16 06:43:49
|
sad |
|
2026-03-16 06:43:56
|
HDR is great |
|
2026-03-16 06:44:10
|
inb4 define hdr |
|
|
|
juliobbv
|
2026-03-16 07:21:51
|
HDR doesn't necessarily mean just "blinding lights", but it also can mean "very detailed shadows" |
|
2026-03-16 07:22:57
|
it's high-dynamic range after all |
|
2026-03-16 07:23:20
|
it also oftentimes come with an extended color gamut, which is nice |
|
2026-03-16 07:24:09
|
it'd be weird to use the Rec 2020 color gamut with SDR metadata |
|
2026-03-16 07:25:01
|
I'd love to see every OS get HDR right so just... works without a second thought |
|
|
Fahim
|
2026-03-16 07:27:29
|
Windows' backwards compatibility headaches seems to make that mostly impossible, so far at least |
|
|
|
Quackdoc
|
2026-03-16 07:34:17
|
impossible when people can't even agree on what HDR even is |
|
2026-03-16 07:34:35
|
This can be solved by just having on average good color management though. |
|
|
|
juliobbv
|
2026-03-16 07:35:13
|
whatever Apple's implementation is + some kind of brightness normalization for the Biden flashbang case <:KekDog:805390049033191445> |
|
|
|
Quackdoc
|
2026-03-16 07:35:27
|
lmao |
|
2026-03-16 07:35:56
|
I'm gonna laugh so hard if xlibre gets the best HDR implementation |
|
|
|
NovaZone
|
2026-03-17 01:02:29
|
Hdr doesn't even get "hdr" right kek |
|
2026-03-17 01:03:05
|
Now o-led/q-led/qd-led/amo-led |
|
2026-03-17 01:03:12
|
That's some good tech xD |
|
|
|
Quackdoc
|
2026-03-17 12:14:07
|
in the end color management in general rather hard to do right |
|
|
|
Demiurge
|
2026-03-17 12:29:37
|
I remember the creator of ArgyllCMS said the Wayland people never bothered consulting with her or anyone else on how best for clients and server to coordinate color management. |
|
2026-03-17 12:30:14
|
They just did their own thing without accepting any feedback or criticism. |
|
|
|
spider-mario
|
2026-03-17 01:12:05
|
yeah, it was this thread: https://discuss.pixls.us/t/wayland-color-management/10804 |
|
2026-03-17 01:12:30
|
the author of ArgyllCMS is gwgill (Graeme W. Gill) |
|
|
|
Quackdoc
|
2026-03-17 02:36:51
|
that was a long time ago now, Wayland color management was done with some good feedback |
|
|
|
ignaloidas
|
2026-03-18 01:02:13
|
I don't think Wayland had anything you could call color management at the point the thread was started lmao |
|
2026-03-18 01:02:54
|
the color management protocol was merged just barely a year ago |
|
|
|
spider-mario
|
2026-03-18 01:18:11
|
I donβt know exactly to what extent the final protocol addresses the technical concerns that have been raised, but the original attitude towards the problem has kind of tainted my view of the project |
|
|
|
ignaloidas
|
2026-03-18 01:51:41
|
tbh I often find myself in the reverse position, looking at how a bunch of people/projects act in regards to wayland taint my view of them because they often seemingly don't want to understand why wayland devs do not want to "just do it how other systems do it" |
|
2026-03-18 01:52:01
|
and honestly reading that thread seems like this was part of the problem... |
|
|
|
Quackdoc
|
2026-03-18 02:22:52
|
It's worth noting that "Wayland devs" for the protocol consists of iirc like 1-2 members of every major compositor + toolkit + any other major thing like chromium, mesa, etc. |
|
2026-03-18 02:23:45
|
I think Wayland is dumb because it is too full of bureaucratic BS and to focused on "not being x11" for a desktop compositing solution |
|
2026-03-18 02:25:20
|
that being said, the current protocol isn't bad, it rarely uses terms like HDR/SDR without some sort of qualification, but I don't like some assumptions it suggests devs to use |
|
|
|
spider-mario
|
2026-03-18 03:02:52
|
I donβt share that reading |
|
|
|
ignaloidas
|
2026-03-18 03:06:24
|
Reading https://www.argyllcms.com/CM_requirements.txt - the justifications on points one and two essentially boil down to "Existing application code assumes this capability is available, and these complex applications are not trivial to re-write or re-target" and it's just asking to "do it how other systems do" (and then a bunch of other justifications just say "refer to 2) |
|
|
|
spider-mario
|
2026-03-18 03:07:31
|
no, the thread includes good explanations of why this is needed in practice |
|
|
|
ignaloidas
|
2026-03-18 03:07:35
|
it's bluntly obvious that they do not want or care to understand *why* wayland is done in the way that it is and why those two things sound outright stupid in wayland context |
|
2026-03-18 03:08:06
|
needed in practice != should be done in the same way as in other systems |
|
|
|
spider-mario
|
2026-03-18 03:08:37
|
it means (or I meant) that in practice, it will need to be done that way |
|
2026-03-18 03:09:36
|
what is bluntly obvious is that the Wayland developers hadnβt the faintest idea about colour management (see e.g. the proposal that calibration apps should access the display directly, which flies in the face of the profile characterising the actual display pipeline that will be used by the apps) |
|
|
|
ignaloidas
|
2026-03-18 03:10:25
|
I see *zero* reason to allow random applications to change the color profile |
|
|
|
spider-mario
|
2026-03-18 03:11:01
|
you need to allow at least the calibration app to do that |
|
|
|
ignaloidas
|
2026-03-18 03:11:18
|
that's not what the requirements state |
|
|
|
spider-mario
|
2026-03-18 03:11:40
|
it is |
|
2026-03-18 03:11:49
|
> Applications used for calibration and profiling are normal applications that expect to target the same devlopment environment and API's as any other color managed application to be able to do their job. |
|
|
|
ignaloidas
|
2026-03-18 03:14:27
|
sure, so why do you need screen coordinates, screen color space, etc. if applications should not be using any of these |
|
|
|
spider-mario
|
2026-03-18 03:14:43
|
not be using any of what, sorry? |
|
2026-03-18 03:15:16
|
they need to know the screen colour space so that they can correctly convert to it, taking into account the appropriate rendering intent |
|
|
|
ignaloidas
|
2026-03-18 03:15:39
|
I don't want to get into wayland flamewar rn but it seems like you don't understand the reasoning behind major wayland decisions either |
|
|
|
spider-mario
|
2026-03-18 03:16:08
|
the point is not whether there is reasoning behind them, itβs that whatever the reasoning was, the resulting constraints clash with colour management |
|
|
|
ignaloidas
|
2026-03-18 03:16:16
|
Wayland view is that should *never* be an application concern and should be handled *purely* by the compositor |
|
|
|
spider-mario
|
2026-03-18 03:16:35
|
that is well understood, including by gwgill, and thatβs the clash |
|
|
|
ignaloidas
|
2026-03-18 03:16:57
|
this does not clash with color management, it clashes with color management as is done for old shit |
|
|
|
spider-mario
|
2026-03-18 03:17:49
|
this raises the question βhow does Wayland propose to solve the problem differently then?β, and the answers to that were the signs that they donβt understand the problem |
|
|
|
ignaloidas
|
2026-03-18 03:18:05
|
if they're not willing to understand why every application needing to handle it's own color conversion is dumb, then I honestly do not want to work with those guys |
|
|
|
spider-mario
|
2026-03-18 03:18:32
|
thatβs a false dichotomy |
|
2026-03-18 03:18:46
|
as shown e.g. by macOS |
|
|
|
ignaloidas
|
2026-03-18 03:19:05
|
applications signal the color space that they output (with enums or icc) and then the compositor brings them all into the display's color space |
|
|
|
spider-mario
|
2026-03-18 03:19:17
|
yes, and this approach has limitations |
|
|
|
ignaloidas
|
2026-03-18 03:19:29
|
such as? |
|
|
|
spider-mario
|
2026-03-18 03:19:43
|
so macOS apps that want more control can do it by doing the conversion themselves, and tagging the surface with the display profile directly |
|
2026-03-18 03:19:49
|
thatβs explained in the thread |
|
|
|
ignaloidas
|
2026-03-18 03:20:19
|
I genuinely haven't seen much explanation in the thread, it was mostly "they didn't listen to me, guess they stupid" |
|
2026-03-18 03:20:48
|
like legitimately, I have zero wishes to ever use argyllcms now, I'll sooner write my own |
|
|
|
spider-mario
|
2026-03-18 03:22:38
|
actually, thatβs also explained in the first item of CM_requirements.txt |
|
|
|
ignaloidas
|
2026-03-18 03:24:17
|
I do not get the arguments there at all |
|
|
|
spider-mario
|
2026-03-18 03:24:21
|
and https://discuss.pixls.us/t/wayland-color-management/10804/98 in the thread |
|
|
|
ignaloidas
|
2026-03-18 03:25:41
|
Wayland accepts cie1931_xyz if they really need to map from whatever arbitrary color space that's not representable with a ICC |
|
|
|
spider-mario
|
2026-03-18 03:26:01
|
and then you lose the information about source gamut |
|
2026-03-18 03:26:26
|
which you need for perceptual gamut mapping |
|
|
|
ignaloidas
|
2026-03-18 03:30:58
|
You can set mastering color gamut, you don't need to lose anything |
|
|
|
spider-mario
|
2026-03-18 03:32:20
|
what if e.g. there are several images in the PDF being rendered? you create different Wayland surfaces for each of them, and you synthesise an ICC profile for non-ICC descriptions? |
|
|
|
ignaloidas
|
2026-03-18 03:32:40
|
sure, that's how for example fast video rendering works |
|
2026-03-18 03:33:12
|
you create a surface just for the video, and then a surface for the controls on top, and the GPU uses layers to composit them |
|
2026-03-18 03:33:33
|
sub-surfaces are a very widely used thing |
|
|
|
spider-mario
|
2026-03-18 03:34:35
|
where applicable, compositing would have to be handed off as wellΒ β itβs not just all opaque rectangles |
|
2026-03-18 03:35:07
|
all in all, it sounds like a huge headache |
|
2026-03-18 03:35:32
|
all for what mostly looks like ideological purity |
|
|
|
ignaloidas
|
2026-03-18 03:37:09
|
it's practical purity, in that people want to avoid mistakes that made them quit maintaining x11 |
|
2026-03-18 03:38:11
|
you have to remember that wayland is primarily pushed by ex-x.org devs because they got sick of maintaining it |
|
2026-03-18 03:39:08
|
well of course, surfaces support alpha |
|
|
|
spider-mario
|
2026-03-18 03:40:12
|
I wouldnβt be surprised if thereβs a bit more to it than that |
|
|
|
Quackdoc
|
2026-03-18 03:40:17
|
I believe applications can get this info now |
|
|
|
spider-mario
|
2026-03-18 03:40:41
|
and we should also remember that weβre just talking about giving apps the information βwhatβs the ICC profile of the current display?β |
|
2026-03-18 03:40:56
|
I doubt that thatβs what will turn Waylandβs maintainability to X.Org level |
|
2026-03-18 03:41:04
|
(as evidenced by this) |
|
|
|
ignaloidas
|
2026-03-18 03:41:51
|
to be exact, applications can get the "preferred" color space information |
|
2026-03-18 03:42:13
|
that is by no means "the" display color space |
|
|
|
spider-mario
|
2026-03-18 03:42:50
|
whereas if Wayland had stuck to that original vision, the net result would have been that apps that can do this sort of thing very easily on macOS and Windows would have had to integrate their rendering much more deeply with Wayland to behave correctly on Linux |
|
2026-03-18 03:42:58
|
which looks like βnot gonna happenβ territory |
|
|
|
ignaloidas
|
2026-03-18 03:43:51
|
I'm of the opinion that Wayland should in no way care about what Windows or macOS does in regards to API design |
|
2026-03-18 03:44:05
|
if people want to have something like that they can use that |
|
|
|
Quackdoc
|
2026-03-18 03:44:31
|
I guess they aren't the exact same, but you can always probe using libdrm if you absolutely need to get it 100% right, but for all intents and purposes, prefered space should be the monitor space |
|
|
|
ignaloidas
|
2026-03-18 03:45:18
|
there's been a million arguments of "why wayland doesn't just do what Windows/macOS does, it makes me do more work" and it's always from an ignorant position |
|
|
|
spider-mario
|
2026-03-18 03:45:25
|
well, not here |
|
|
|
ignaloidas
|
2026-03-18 03:46:48
|
90% of the time it's basically people wanting to do stuff in applications that really should be done in compositors |
|
|
|
spider-mario
|
2026-03-18 03:47:21
|
what about the remaining 10%? thatβs arguably what this is about |
|
|
|
ignaloidas
|
2026-03-18 03:47:35
|
and I don't see how lack of compositor features in win/mac should be the justification to have the same workarounds in wayland |
|
|
|
spider-mario
|
2026-03-18 03:47:50
|
apps that need to do this are most likely not a majority |
|
2026-03-18 03:48:07
|
which lack of compositor feature do you mean? |
|
|
|
ignaloidas
|
2026-03-18 03:48:26
|
e.g. window gluing like for e.g. winamp |
|
2026-03-18 03:48:34
|
that's all done application side |
|
2026-03-18 03:49:21
|
I think (and a bunch of wayland devs as well) that it should be handled in the compositor with requests from the application to glue, not to move individual windows |
|
|
|
Quackdoc
|
2026-03-18 03:49:45
|
ah no, just checked, Wayland protocol does indeed present actual display characteristics now, ofc compositors can lie, but then that's just a bad compositor |
|
2026-03-18 03:58:33
|
the Wayland protocol as it stands now isn't horrid, compositor implementations we shall see but so far I'm quite disappointed |
|
|
missaustraliana
|
2026-03-20 03:20:58
|
heres a good file to test codecs with |
|
|
|
NovaZone
|
2026-03-20 03:42:12
|
Still hunting for a good candlelight img |
|
2026-03-20 03:45:09
|
Same with mossy stone/bricks |
|
2026-03-20 03:46:42
|
And Sunbeam/godrays with books in a dusty study |
|
2026-03-20 03:47:24
|
Can't truly test codecs without em xD |
|
2026-03-20 03:48:10
|
https://tenor.com/view/book-dust-dusty-old-library-gif-23639439 |
|
|
|
Quackdoc
|
2026-03-20 12:08:03
|
the exr test image no good? |
|
2026-03-20 12:09:02
|
https://openexr.com/en/latest/test_images/ScanLines/CandleGlass.html |
|
|
|
missaustraliana
|
2026-03-20 12:09:34
|
what even is exr helppp |
|
2026-03-20 12:09:44
|
am i just like stupid |
|
|
|
Quackdoc
|
2026-03-20 12:10:17
|
exr is a format designed to more accurately represent super niche scenarios, good for rendering scenes |
|
|
|
missaustraliana
|
|
|
Quackdoc
|
2026-03-20 12:11:09
|
It's used a lot in authoring and compositing stuff |
|
|
|
missaustraliana
|
2026-03-20 12:11:40
|
does anyone want this? |
|
2026-03-20 12:12:03
|
its high res |
|
2026-03-20 12:13:25
|
5792x8688 |
|
|
|
Demiurge
|
2026-03-20 12:44:03
|
unironically this looks like it has a lot of things most codecs struggle with |
|
2026-03-20 12:44:12
|
Dark blacks, oversaturated reds |
|
2026-03-20 12:44:39
|
fine details in dark and colorful areas |
|
2026-03-20 12:44:51
|
most codecs suck at that |
|
|
|
missaustraliana
|
2026-03-20 12:45:02
|
how i got this file tho is another story |
|
|
|
Demiurge
|
2026-03-20 12:45:55
|
most codecs underestimate how sensitive the human eye is to low contrast shaded areas especially when color is involved |
|
|
|
missaustraliana
|
2026-03-20 12:46:56
|
i also have this |
|
2026-03-20 12:47:05
|
13k |
|
2026-03-20 12:47:21
|
i have never seen an image fail to embed |
|
2026-03-20 12:47:27
|
|
|
2026-03-20 12:47:28
|
thats the image |
|
2026-03-20 12:47:35
|
<@1028567873007927297> what about this photo? |
|
2026-03-20 12:49:31
|
oh heres that other photo i was talking abt earlier |
|
|
|
Demiurge
|
2026-03-20 01:05:13
|
Needs to be close to absolute black |
|
2026-03-20 01:06:11
|
Codecs hate images with detailed, really dark regions |
|
|
|
missaustraliana
|
2026-03-20 01:06:19
|
oh i have a couple |
|
2026-03-20 01:07:38
|
<@1028567873007927297> like this? |
|
2026-03-20 01:07:49
|
i mean its cr2 so you can adjust it |
|
|
|
Demiurge
|
2026-03-20 01:08:25
|
Yes but more texture and details in the dark regions. Especially color too |
|
|
|
missaustraliana
|
2026-03-20 01:08:36
|
hmm |
|
2026-03-20 01:08:39
|
lemme see |
|
|
|
Demiurge
|
2026-03-20 01:08:41
|
That is how you make most codecs shit themselves |
|
|
|
missaustraliana
|
2026-03-20 01:09:12
|
maybe? |
|
|
|
Demiurge
|
2026-03-20 01:09:23
|
Extremely dark gradients with lots of details and textures in the shadows |
|
|
|
missaustraliana
|
|
|
Demiurge
|
2026-03-20 01:10:04
|
Like for example grass or stone under a dark shadow |
|
|
|
missaustraliana
|
2026-03-20 01:10:09
|
ah |
|
2026-03-20 01:10:17
|
well i dont have anything like that |
|
|
|
Demiurge
|
2026-03-20 01:10:29
|
Illustrations work too |
|
2026-03-20 01:10:53
|
Illustrations often have very dark regions that are close to absolute black |
|
2026-03-20 01:11:31
|
Encoders tuned for photography often are poor at illustrations. |
|
|
|
missaustraliana
|
2026-03-20 01:11:41
|
not sure if this would be any use to you but this is my dogπ |
|
|
|
Demiurge
|
2026-03-20 01:12:13
|
Nice photo |
|
2026-03-20 01:12:19
|
Codecs are good at images like that |
|
|
|
missaustraliana
|
2026-03-20 01:12:40
|
ty! it turned out very well |
|
2026-03-20 01:13:11
|
would this be any use? |
|
|
|
Demiurge
|
2026-03-20 01:13:18
|
A problem image would be, say, really dark gradients with a few small colorful details on them. |
|
|
|
missaustraliana
|
2026-03-20 01:13:20
|
its complex, 8k |
|
|
|
Demiurge
|
2026-03-20 01:13:52
|
This would be great. Lots of bright and dark regions with lots of details. |
|
2026-03-20 01:14:07
|
Good stress test |
|
|
|
missaustraliana
|
2026-03-20 01:14:10
|
sending! |
|
2026-03-20 01:14:14
|
its 120mb |
|
2026-03-20 01:15:00
|
nvm its not 8k but 6k |
|
|
|
Demiurge
|
2026-03-20 01:15:12
|
120mb? Damn |
|
|
|
missaustraliana
|
|
|
jonnyawsom3
|
2026-03-20 01:28:57
|
Could work well. Black fur/hair has very fine detail |
|
|
|
missaustraliana
|
2026-03-20 01:34:59
|
take my dog then lmfao |
|
|
|
Demiurge
|
2026-03-20 02:56:46
|
There are so many different things to work with in the rooftop pic |
|
2026-03-20 02:57:06
|
Lots of good challenges for codecs |
|
|
|
NovaZone
|
2026-03-20 02:59:53
|
That works, added to the test suit xD |
|
2026-03-20 03:00:27
|
Only 2.5 mb tho? π€ |
|
2026-03-20 03:02:37
|
Hence why I want a dusty library scene xD |
|
2026-03-20 03:02:52
|
. |
|
2026-03-20 03:09:17
|
That one's actually really good as a scaler test π |
|
2026-03-20 03:09:40
|
Fossify gallery struggles hard on my phone with that one |
|
2026-03-20 03:13:49
|
Rooftop one is also great ty |
|
2026-03-20 03:27:00
|
Mmm sure that works https://openexr.com/en/latest/test_images/ScanLines/Desk.html |
|
|
|
Quackdoc
|
2026-03-20 03:40:16
|
simple image, doesn't need to be large |
|
|
|
NovaZone
|
2026-03-20 03:41:42
|
Ideally no compression? |
|
|
|
Quackdoc
|
2026-03-20 03:45:38
|
piz is lossless compression so it will be fine in that sense |
|
2026-03-20 03:45:57
|
designed for a lot of noise/grain |
|
2026-03-20 03:46:02
|
https://www.exr-io.com/openexr-data-compression/ |
|
2026-03-20 03:46:52
|
https://openexr.com/en/latest/TechnicalIntroduction.html#data-compression |
|
|
o7William
|
2026-03-20 07:43:39
|
Is this an expected result |
|
2026-03-20 07:44:40
|
I don't really have an idea of how exr works |
|
2026-03-20 07:46:31
|
are they a vector format for photographics? |
|
2026-03-20 07:49:48
|
oh nevermind they are multiple channel raster, I assume this is ImageGlass fault here |
|
|
|
Quackdoc
|
2026-03-20 08:35:50
|
Imageglass probably won't render right, exrviewer would be best, but generally, yes, right is what alpha 0 looks like when you don't handle alpha properly.
basically imageglass is turning all alpha0 pixels visible since there is no background for it |
|
2026-03-20 08:36:23
|
Darktable looks subtly off too, it might be doing some clipping |
|
|
|
NovaZone
|
2026-03-20 11:22:17
|
Dang q-view can't do it either π€£ |
|
2026-03-20 11:22:27
|
What a weird format |
|
2026-03-20 11:23:18
|
XL convert also can't handle em |
|
2026-03-20 11:23:49
|
Perfect test format, nothing works with it kek |
|
2026-03-20 11:27:21
|
Mpv can't display properly either |
|
2026-03-20 11:27:48
|
Xn convert can process it but fails on png conversion |
|
2026-03-20 11:28:14
|
Which basically means imgmagik can't do it either |
|
2026-03-20 11:39:33
|
Fossify gallery won't even entertain the idea of opening it <:KekDog:805390049033191445> |
|
|
|
Quackdoc
|
2026-03-20 11:42:14
|
mpv can with some work iirc |
|
|
|
NovaZone
|
2026-03-20 11:43:08
|
Mpv doesn't even do the transparency kek |
|
2026-03-20 11:43:29
|
Least qview and imgglass attempt to do it |
|
2026-03-20 11:45:53
|
Heh windows thumbs fail, icaros thumbs fail, everything search thumbs display correctly π |
|
2026-03-20 11:46:02
|
What a funny container/format |
|
2026-03-20 11:51:27
|
Ffmpeg can display it correctly but not convert it |
|
2026-03-20 11:51:54
|
Kk while fun, back to the quest for png test imgs |
|
|
|
Quackdoc
|
2026-03-21 12:02:01
|
you could render it out using gimp or something like that |
|
2026-03-21 12:02:06
|
I think I may have one |
|
2026-03-21 12:02:28
|
the big thing is so many apps don't support associated alpha |
|
|
|
missaustraliana
|
2026-03-21 01:18:18
|
is there like a crntralised folder where theres test images? |
|
|
|
NovaZone
|
2026-03-21 01:19:12
|
Yea /test |
|
2026-03-21 01:19:35
|
Well can't dl them all that way, have to do it 1 by 1 |
|
2026-03-21 01:22:47
|
https://github.com/AcademySoftwareFoundation/openexr-images |
|
2026-03-21 01:22:50
|
There ya go |
|
2026-03-21 01:22:59
|
Zip the entire repo |
|
2026-03-21 01:23:10
|
Will get jpegs with em |
|
2026-03-21 01:26:40
|
And gl finding a program/lib that converts/displays em correctly |
|
2026-03-21 01:27:11
|
Gimp/krita probably can but that's less than ideal |
|
|
|
missaustraliana
|
2026-03-21 01:36:41
|
why is it so hard to display them? |
|
2026-03-21 01:36:59
|
im so sorry im like brand new to exr so i dont know SHIT |
|
|
|
NovaZone
|
2026-03-21 01:37:24
|
Apparently |
|
|
|
missaustraliana
|
2026-03-21 01:37:38
|
and why is exr used for these codec tests? |
|
|
|
NovaZone
|
2026-03-21 01:37:53
|
But idk tried a whole lotta standard libs and nothing really likes em |
|
|
|
missaustraliana
|
2026-03-21 01:38:34
|
is this what its supposed to look like |
|
|
|
NovaZone
|
2026-03-21 01:41:15
|
I think so? |
|
2026-03-21 01:41:31
|
Looks like the jpg counterpart in FF at least |
|
|
|
missaustraliana
|
2026-03-21 01:41:53
|
it looks pretty low res so |
|
2026-03-21 01:42:07
|
|
|
|
|
NovaZone
|
2026-03-21 01:42:38
|
Yes very low res xD |
|
2026-03-21 01:42:59
|
Good as a scaler tester 4 sure |
|
2026-03-21 01:43:12
|
IF it can be properly displayed kek |
|
2026-03-21 01:43:34
|
Try the scan lines vers |
|
2026-03-21 01:43:39
|
Glass and prism |
|
|
|
missaustraliana
|
2026-03-21 01:44:08
|
|
|
2026-03-21 01:44:28
|
that looks like what it shoulld look like |
|
2026-03-21 01:44:48
|
the grey is just mac removing transparency but on my screen i can see the window behind it |
|
2026-03-21 01:45:05
|
|
|
|
|
NovaZone
|
2026-03-21 01:45:08
|
Definitely not π€£ |
|
|
|
missaustraliana
|
2026-03-21 01:45:13
|
oh shit |
|
2026-03-21 01:45:22
|
what should it look like then π |
|
|
|
NovaZone
|
2026-03-21 01:45:46
|
Look at the jpeg version of the same img in FF or chrome |
|
|
|
missaustraliana
|
2026-03-21 01:45:51
|
whats ff? |
|
|
|
NovaZone
|
2026-03-21 01:45:56
|
Firefox |
|
|
|
missaustraliana
|
2026-03-21 01:45:58
|
oh |
|
2026-03-21 01:45:59
|
lmfoa |
|
2026-03-21 01:46:04
|
im like brand new im sorry |
|
|
|
NovaZone
|
2026-03-21 01:46:13
|
Ur fine xD |
|
|
|
missaustraliana
|
2026-03-21 01:46:24
|
ohhh okay thats what it should look like. |
|
|
|
NovaZone
|
2026-03-21 01:46:32
|
Yea π€£ |
|
|
|
missaustraliana
|
2026-03-21 01:46:37
|
so is there any other repos with high res photos? |
|
|
|
NovaZone
|
2026-03-21 01:47:19
|
I'll hunt around later, need to get a stable test suit going since img formats keep updating |
|
|
|
missaustraliana
|
2026-03-21 01:47:48
|
well i have a ton of raw professional photos |
|
|
|
NovaZone
|
2026-03-21 01:48:35
|
https://cdn.discordapp.com/attachments/794206087879852106/1397514863076704296/image.png?ex=69bf1163&is=69bdbfe3&hm=5224c121b0e3838f4f9f9eb47c3a624ae520c84325476532c7c1f7d2119753f5& |
|
|
|
jonnyawsom3
|
2026-03-21 01:48:41
|
This might be easier to understand https://openexr.com/en/latest/test_images/index.html#test-images |
|
|
|
NovaZone
|
2026-03-21 01:48:54
|
Will probably upload that one since the website that had it removed it |
|
|
|
missaustraliana
|
2026-03-21 01:49:06
|
im just confused tho since like why exr of all things |
|
2026-03-21 01:49:09
|
whats exr good for |
|
|
|
jonnyawsom3
|
2026-03-21 01:49:47
|
EXR is one of the very few float formats, that stores with decimal precision, over 1, below 0, ect |
|
|
|
NovaZone
|
2026-03-21 01:50:39
|
Yea but was trying to get all of em in 1 dl |
|
|
|
jonnyawsom3
|
2026-03-21 01:50:49
|
Right |
|
|
|
NovaZone
|
2026-03-21 01:51:40
|
The bane of all codecs btw |
|
2026-03-21 01:51:49
|
The web safe color test kek (0-255) |
|
|
|
missaustraliana
|
2026-03-21 01:52:45
|
is it possible to turn a cr2 into exr or am i just stupid |
|
2026-03-21 01:55:14
|
actually if i render this would yall want it? good colours |
|
|
|
jonnyawsom3
|
2026-03-21 01:55:49
|
You can, but there's not much point. Precision is limited to the lowest denominator, and most cameras only go up to 14bit integer at most |
|
|
|
missaustraliana
|
|
|
NovaZone
|
2026-03-21 01:56:20
|
Hmm π€ yes |
|
2026-03-21 01:56:29
|
Good for chroma testing |
|
2026-03-21 01:56:47
|
Texture under chroma specifically |
|
2026-03-21 01:57:51
|
Tbh I think that's the worst img for jxl π€£ |
|
|
|
missaustraliana
|
2026-03-21 01:58:08
|
what abt this one |
|
|
|
NovaZone
|
2026-03-21 01:58:38
|
Mostly good for gradients |
|
|
|
missaustraliana
|
2026-03-21 01:59:25
|
tell me then, what should i export to and what colour space |
|
|
|
NovaZone
|
2026-03-21 01:59:34
|
But jxl will do fine on that one |
|
|
|
missaustraliana
|
2026-03-21 02:00:00
|
adobe rgb 1998 fine? |
|
|
|
NovaZone
|
2026-03-21 02:00:04
|
Sure |
|
2026-03-21 02:00:17
|
Most things process png just fine |
|
|
|
missaustraliana
|
2026-03-21 02:01:22
|
i got thense photos through.... um |
|
2026-03-21 02:01:29
|
"ways" |
|
2026-03-21 02:03:52
|
|
|
|
|
username
|
2026-03-21 02:03:55
|
is there any good way to check what type of data is stored in the CR2 files? info such as the bitdepth (like if it's 14bpc, etc)? because if they contain high bitdepth data then that's getting lost when exporting to PNG |
|
|
|
missaustraliana
|
2026-03-21 02:04:20
|
|
|
2026-03-21 02:04:24
|
|
|
2026-03-21 02:04:28
|
|
|
2026-03-21 02:04:31
|
i can send you one cr2 file and you can look into it if you want |
|
|
|
username
|
2026-03-21 02:05:58
|
I can try and look but my experience working with raw files is pretty limited |
|
|
|
missaustraliana
|
2026-03-21 02:06:24
|
yeah well same |
|
2026-03-21 02:06:56
|
ahh |
|
2026-03-21 02:06:57
|
i see it |
|
2026-03-21 02:07:01
|
|
|
2026-03-21 02:07:01
|
16 bit depth |
|