|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
|
yoochan
in local.lossy.ssim.tsv can you add a column for the resulting size ?
|
|
2024-07-22 08:11:45
|
the sizes are available seperately too
|
|
|
yoochan
|
|
Demiurge
it's better to not trust computer scores at all...
|
|
2024-07-22 08:11:49
|
true, but I'm not trained enough to assess the visual quality myself ๐
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
|
yoochan
(and which effort did you used ? sometime higher efforts are detrimental)
|
|
2024-07-22 08:11:52
|
`-e 7`
|
|
2024-07-22 08:12:58
|
mass same-size tests (or as close as possible, because it's so freaking hard to achieve even when done manually) could be added too
|
|
|
yoochan
in local.lossy.ssim.tsv can you add a column for the resulting size ?
|
|
2024-07-22 08:15:00
|
the general results are that AVIF at q90 is better than JPEG XL d 1.0 while being smaller
~~I'm still not sure what to think about this~~
|
|
|
Demiurge
|
|
yoochan
true, but I'm not trained enough to assess the visual quality myself ๐
|
|
2024-07-22 08:16:14
|
Just do your best... Ask yourself if there's anything lost or deceptive about the way it looks after compression.
|
|
|
Quackdoc
|
2024-07-22 08:16:20
|
I wonder if manually converting to yuv420p first then encoding to jxl could result in a similar size savings.
|
|
2024-07-22 08:17:01
|
I do find that ssimu2 doesn't penalize that and bitdepth truncating as hard as it should IMO
|
|
|
|
Demiurge
|
2024-07-22 08:17:07
|
The only reason to rely on a computer-generated score, is if you don't actually care that much what it looks like, and you're just mass processing a huge amount of images.
|
|
2024-07-22 08:17:59
|
computer scores are extremely naive and prone to getting tricked in stupid ways that would look ridiculous to a human.
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
|
yoochan
in local.lossy.ssim.tsv can you add a column for the resulting size ?
|
|
2024-07-22 08:18:01
|
also you should get `derpi.*.*.tsv` instead for the full results, the `local` ones contain too few samples
|
|
|
|
Quackdoc
|
2024-07-22 08:19:12
|
I should redo my 20k image test but generally I found jxl to be quite a bit better in my danbooru rip testing
|
|
|
|
yoochan
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
also you should get `derpi.*.*.tsv` instead for the full results, the `local` ones contain too few samples
|
|
2024-07-22 08:19:46
|
in which folder ? I'm looking at your github
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
|
yoochan
in which folder ? I'm looking at your github
|
|
2024-07-22 08:20:20
|
it's deployed to GitHub Pages because it's too time consuming to be done locally
|
|
2024-07-22 08:20:35
|
> Lossy sizes: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossy.size.tsv
> Lossy SSIM: https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossy.ssim.tsv
|
|
2024-07-22 08:21:34
|
there's no need to see the lossless tests
JPEG XL is relatively better than WebP with occcasional blows being traded, while AVIF gets absolutely destroyed by either
|
|
|
|
Demiurge
|
2024-07-22 08:22:05
|
One good piece of advice when doing comparisons: Start by comparing at native res, 1:1 pixel ratio, and sitting a reasonable distance away from the monitor. If you can only see a problem under unusual viewing conditions, it's not as important as a problem you can spot from a distance.
|
|
|
|
Quackdoc
|
2024-07-22 08:23:09
|
do you have jpeg's in your dataset? if so I wonder if you elected to compare the lossless jpeg transcoding against lossy encoding (I would since I often find it smaller anyways)
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
|
Quackdoc
do you have jpeg's in your dataset? if so I wonder if you elected to compare the lossless jpeg transcoding against lossy encoding (I would since I often find it smaller anyways)
|
|
2024-07-22 08:24:07
|
there are, but no lossless JPEG transcoding has been done, since I've already verified with the dataset that lossless JPEG transcoding shaves around 20% of overall file size
|
|
2024-07-22 08:24:20
|
and well... ~~lossy JPEG transcoding is kinda done anyways~~
|
|
|
|
Demiurge
|
2024-07-22 08:24:31
|
For example, the extreme color desaturation of libjxl vs aom is easily seen from a distance in this comparison:
https://afontenot.github.io/image-formats-comparison/#abandoned-factory&AV1=s&JPEGXL=s
|
|
|
|
JendaLinda
|
2024-07-22 10:24:10
|
Could NPU be used for spline and patch search?
|
|
|
|
SwollowChewingGum
|
|
JendaLinda
Could NPU be used for spline and patch search?
|
|
2024-07-22 10:24:56
|
I was thinking , but each npu has different requirements so would be a difficult implementation
|
|
|
|
JendaLinda
|
2024-07-22 10:28:16
|
I'm considering it just in theory now. First, there must a standard API for using NPU. Second, NPU must become common in devices to rely on them.
|
|
|
|
SwollowChewingGum
|
2024-07-22 10:28:47
|
Could be possible for Apple to add if they add encoding support
|
|
|
|
Quackdoc
|
|
JendaLinda
I'm considering it just in theory now. First, there must a standard API for using NPU. Second, NPU must become common in devices to rely on them.
|
|
2024-07-22 10:29:08
|
almost all modern devices have NPUs now
|
|
|
|
SwollowChewingGum
|
2024-07-22 10:29:10
|
It would give them a competitive edge in efficiency
|
|
|
|
Quackdoc
|
2024-07-22 10:30:03
|
amd's new cpus have NPUs, intels new CPUs have NPUs, most arm socs made for a few years have NPUs, many of the riscv socs have NPUs
|
|
|
|
SwollowChewingGum
|
|
Quackdoc
amd's new cpus have NPUs, intels new CPUs have NPUs, most arm socs made for a few years have NPUs, many of the riscv socs have NPUs
|
|
2024-07-22 10:30:35
|
Your body has an NPU
|
|
|
|
Quackdoc
|
2024-07-22 10:30:39
|
and there is a common API in the form of something like pytorch which could work prolly
|
|
|
jonnyawsom3
|
|
Quackdoc
amd's new cpus have NPUs, intels new CPUs have NPUs, most arm socs made for a few years have NPUs, many of the riscv socs have NPUs
|
|
2024-07-22 12:01:13
|
My 8 year old phone that's still clinging onto life has sn NPU, unfortunately used for video frame interpolation in the slowmo mode
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
near lossless
for WebP it's `-near_lossless 60 -m 6`, for JPEG XL it's `-m 1 -d 0.1 -e 7`
|
|
2024-07-22 12:02:41
|
I generally found just `-d 0.3` would mean I could zoom in on artwork in my tests, and I know modular mode is better at extremely low distances, but I think that's more like 0.01 than 0.1, but I could be wrong
|
|
|
A homosapien
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
https://github.com/PoneyClairDeLune/derpi-image-corpus/
If you're up to downloading 106 images all at once, sure \;)
|
|
2024-07-22 03:55:26
|
I'm taking a quick look at the corpus, and it seems a lot of the 3d images have a bit of low ISO noise. So using the option `--photon_noise=ISO...` masks most smoothing done by the encoder. Honestly, even distance 1.5 looks good to me.
|
|
2024-07-22 03:58:29
|
Avif sometimes has some nasty banding issues, and their own noise generator doesn't do anything to mask that. Take a look at the bottom of this blog for more details: https://saklistudio.com/whyjxl/
|
|
|
Demiurge
For example, the extreme color desaturation of libjxl vs aom is easily seen from a distance in this comparison:
https://afontenot.github.io/image-formats-comparison/#abandoned-factory&AV1=s&JPEGXL=s
|
|
2024-07-22 04:04:10
|
It's funny how efforts 4 and lower actually preserve color better. Maybe because jxl behaves more like a regular jpeg rather than all of the crazy stuff that goes on in higher efforts.
|
|
2024-07-22 04:15:28
|
I should probably add that info to the issue I opened
|
|
|
|
JendaLinda
|
|
Quackdoc
amd's new cpus have NPUs, intels new CPUs have NPUs, most arm socs made for a few years have NPUs, many of the riscv socs have NPUs
|
|
2024-07-23 06:55:55
|
It will still take several years before general purpose NPU becomes as common as GPU.
|
|
2024-07-23 07:00:42
|
Many people are using old computers.
|
|
|
|
SwollowChewingGum
|
|
JendaLinda
It will still take several years before general purpose NPU becomes as common as GPU.
|
|
2024-07-23 07:01:11
|
maybe some tasks could be offloaded to GPUs?
|
|
2024-07-23 07:01:15
|
almost all computers have them
|
|
|
|
JendaLinda
|
2024-07-23 07:02:42
|
I suppose if it was practical to use GPU for this, it would be already done.
|
|
|
|
Quackdoc
|
|
JendaLinda
It will still take several years before general purpose NPU becomes as common as GPU.
|
|
2024-07-23 07:49:05
|
sure, but thats not really the bar you need to meet
|
|
|
|
JendaLinda
|
2024-07-23 04:25:36
|
Anyhow, a proof of concept implementation would be the first step.
|
|
|
|
jonnyawsom3
|
2024-07-27 09:25:08
|
Been learning about and playing with BC texture compression in Unity for my VRChat avatar the past few weeks.
This is just the result of externally resizing the textures with lanczos instead of Unity's built-in method from 4098 to 2048 https://cdn.discordapp.com/attachments/889987478675656796/1266669509029400637/Comparison.mp4?ex=66a5fd68&is=66a4abe8&hm=6923a3189d1fd116e9fdca7859ff0fa688dfb00f41999d9f1e1c606fb0fec9af&
(I'll do a better one in future since this has lower resolution on the 'New' emissive map compared to the old, causing some areas to look worse)
|
|
2024-07-27 09:27:27
|
Then came a round of choosing the right BC number, since Unity defaults to BC1 for opaque and BC3 for transparent, even though there's also BC5 for normal maps and BC7 at the same size as BC3 but higher quality (Or double BC1 memory for a huge quality boost)
|
|
2024-07-27 09:27:54
|
https://cdn.discordapp.com/attachments/863020482072150056/1258677704396640398/BC1vsBC7.png?ex=66a542b5&is=66a3f135&hm=ae20d913da8c2a34862aa0fddbd4abf763d3dab2e5c10b2dca57d6ce5b7caf47&
|
|
2024-07-27 09:28:35
|
Can easily see the degradation in BC1, while both BC7 look visually lossless in comparison
|
|
|
username
|
|
Then came a round of choosing the right BC number, since Unity defaults to BC1 for opaque and BC3 for transparent, even though there's also BC5 for normal maps and BC7 at the same size as BC3 but higher quality (Or double BC1 memory for a huge quality boost)
|
|
2024-07-27 09:29:15
|
BC5 is for normal maps, BC4 is for grayscale images/maps
|
|
|
|
jonnyawsom3
|
2024-07-27 09:30:12
|
Yeah, that was it. BC5 is just 2 BC4s strapped together
|
|
2024-07-27 09:32:16
|
And annoyingly, Unity doesn't allow changing the BC4 channel, so if you don't want greyscale red then you need to use the full color types
|
|
|
|
username
|
2024-07-27 09:33:49
|
would probably have to modify whatever shader you are using to use just the red channel for whatever things want grayscale maps
|
|
2024-07-27 09:34:40
|
i'm not a shader programmer so I have no clue how to go about that exactly
|
|
|
|
jonnyawsom3
|
2024-07-27 09:35:12
|
In this case I'm only using Unity's default shaders, since most people have custom shaders disabled for non-friends in VRChat due to trolling, so I can't edit them
|
|
2024-07-27 09:38:30
|
Although, this reminds me I should put the Jpeg DCT shader we made somewhere on a toggle...
|
|
2024-07-27 09:43:44
|
I also made a debug DDS file to view mip level transitions, which apparently is impossible to just find on the internet, at at least 3 people I've mentioned it to had tried to make one in the past and immedeately wanted me to send it
|
|
2024-07-27 09:43:58
|
|
|
|
|
JendaLinda
|
2024-07-30 12:44:51
|
AVI video in it's basic form is actually animated BMP. Small animated graphics in Windows GUI is in AVI format, usually series of 8 bpp bitmaps with palette.
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
2024-07-30 04:54:48
|
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
> WebP is not on this chart since it simply cannot reach this quality point, at least not using its lossy mode. This is because 4:2:0 chroma subsampling is obligatory in WebP.
~~just to mention that WebP near-lossless exists~~
|
|
|
Meow
|
2024-07-30 05:01:14
|
Entered W3C Candidate Recommendation Draft this month
https://www.w3.org/TR/png-3/
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
> WebP is not on this chart since it simply cannot reach this quality point, at least not using its lossy mode. This is because 4:2:0 chroma subsampling is obligatory in WebP.
~~just to mention that WebP near-lossless exists~~
|
|
2024-07-30 05:07:28
|
though with "near-lossless"... the size of WebP is basically outta question
|
|
|
|
Demiurge
|
2024-07-31 01:27:36
|
Nice dargon
|
|
|
|
JendaLinda
|
2024-07-31 01:44:10
|
What does near-lossless WebP actually do? Is that something like pngquant?
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
2024-07-31 03:45:41
|
https://groups.google.com/a/webmproject.org/g/webp-discuss/c/0GmxDmlexek
hmm... doesn't help much
|
|
2024-07-31 03:46:16
|
"adjust pixel values to improve compressibility"
|
|
|
|
JendaLinda
|
2024-07-31 04:01:05
|
I can't tell what it does. Looks like added noise in busy areas.
|
|
|
|
jonnyawsom3
|
|
JendaLinda
What does near-lossless WebP actually do? Is that something like pngquant?
|
|
2024-07-31 04:26:11
|
If I recall yeah, uses the lossless mode but with slight quantization for better compressibility
|
|
|
|
JendaLinda
|
2024-07-31 04:38:03
|
PNG can do quantization by reducing to palette. This doesn't seem to be the case. I guess it might be similar idea like lossy LZW.
|
|
|
|
jonnyawsom3
|
2024-07-31 04:40:19
|
Yeah, that's what I meant by 'slight quantization', couldn't think of a better term
|
|
|
|
A homosapien
|
|
JendaLinda
What does near-lossless WebP actually do? Is that something like pngquant?
|
|
2024-07-31 05:42:43
|
It's more like [lossy PNG](https://pngmini.com/lossypng.html) and lossy modular JXL.
|
|
2024-07-31 05:44:16
|
It degrades the image to allow the lossless algorithms to compress better
|
|
2024-07-31 05:46:07
|
So yeah, I guess it would be similar to GIFs lossy LZW
|
|
2024-07-31 05:59:29
|
I'm going to paraphrase what username said, [Squoosh](https://squoosh.app) is a cool tool be able to do quick visual comparisons between lossless/near-lossless webp
|
|
|
|
JendaLinda
|
2024-07-31 06:02:30
|
According to the linked repositories, it seems that lossy PNG is just a fancier method converting images to 256 colors.
|
|
2024-07-31 06:10:59
|
There is some difference in near lossless WebP, but rather than tinkering with near lossless, I would rather use jpeg with low distance settings.
|
|
2024-07-31 06:15:53
|
I occasionally use paletted PNG, it's great for completely flat colored images. Those don't need lot of dithering so they compress well.
|
|
|
|
A homosapien
|
|
JendaLinda
According to the linked repositories, it seems that lossy PNG is just a fancier method converting images to 256 colors.
|
|
2024-07-31 06:26:52
|
Did you see the section on the lossy averaging filter? That is not a color reduction.
|
|
2024-07-31 06:27:15
|
The "fancier method" of reducing to 256 colors *is* PNGquant
|
|
|
|
JendaLinda
|
2024-07-31 06:36:31
|
It's mentioned there but the linked posterizer doesn't seem to have any option for that.
|
|
|
_wb_
|
2024-07-31 06:54:20
|
You can do lossy PNG without using palette. It works best with the averaging predictor. Basically just quantize the residuals so deflate gets less entropy to encode...
|
|
|
|
JendaLinda
|
2024-07-31 07:32:16
|
I suppose it could be done it theory but probably it's not very practical. I couldn't get the software to work to test it.
|
|
|
|
jonnyawsom3
|
|
JendaLinda
I suppose it could be done it theory but probably it's not very practical. I couldn't get the software to work to test it.
|
|
2024-07-31 08:07:18
|
You used this with `-b`, right? https://github.com/kornelski/mediancut-posterizer
|
|
|
|
JendaLinda
|
|
You used this with `-b`, right? https://github.com/kornelski/mediancut-posterizer
|
|
2024-07-31 08:38:45
|
The released version does not have `-b` option.
|
|
|
|
jonnyawsom3
|
2024-07-31 08:38:58
|
Huh, odd
|
|
|
|
JendaLinda
|
2024-07-31 08:42:10
|
As there was no updated release for several years, I suppose the feature is very experimental.
|
|
|
|
A homosapien
|
2024-08-01 01:08:11
|
[TruePNG](http://x128.ho.ua/pngutils.html) and [Pingo](https://css-ig.net/pingo?i=1) both have this feature
|
|
2024-08-01 01:12:25
|
TruePNG's lossy option is `/l` and Pingo's is `-quality=N`
|
|
2024-08-01 01:18:28
|
Visually speaking, I find that Pingo's lossy output outperforms TruePNG's. The metrics I used also agree.
|
|
|
|
Demiurge
|
2024-08-01 03:17:30
|
there's multiple variants of lossy png
|
|
|
|
_wb_
|
2024-08-01 05:38:53
|
I also made something at some point - but none of the lossy PNG options comes anywhere close to the compression performance of lossy codecs...
|
|
|
|
JendaLinda
|
|
A homosapien
TruePNG's lossy option is `/l` and Pingo's is `-quality=N`
|
|
2024-08-01 06:48:58
|
Pingo seems to do just the palette reduction similar to pngquant. The lack of documentatin is not convincing either.
|
|
2024-08-01 06:50:32
|
TruePNG seems to be doing the averaging thing. More detailed documentation would be appreciated.
|
|
|
|
A homosapien
|
2024-08-01 08:12:18
|
Pingo dynamically chooses between palette reduction or lossy averaging depending on the image. I would be willing to share examples if you want.
|
|
2024-08-01 08:12:25
|
https://github.com/foobaz/pngloss
|
|
2024-08-01 08:13:02
|
This github page might offer more insight into how it works, since TruePNG and Pingo are closed source
|
|
|
CrushedAsian255
|
|
A homosapien
https://github.com/foobaz/pngloss
|
|
2024-08-01 08:30:05
|
it gives some really funky looking results at stupidly high loss settings
|
|
2024-08-01 08:30:19
|
|
|
|
|
JendaLinda
|
2024-08-01 09:02:56
|
I think I'm done with those. I will use lossy format if I need lossy.
|
|
|
|
Demiurge
|
2024-08-01 09:15:11
|
pngquant is pretty damn cool though
|
|
|
|
JendaLinda
|
2024-08-01 10:02:40
|
It is interesting. Reducing number of color is not a new idea, but pngquant uses very high quality algorithm. The concept is quite simple, however it could be counterproductive if it introduces lots of dithering.
|
|
2024-08-01 04:01:54
|
Also, you can tell a PNG image using palette is probably lossy.
|
|
2024-08-01 04:03:47
|
Unless it's artwork using limited color or screenshot from color limited system.
|
|
|
|
Demiurge
|
2024-08-01 04:15:31
|
I see palette images used a lot on commerce websites
|
|
2024-08-01 04:15:56
|
For photographic images
|
|
2024-08-01 04:16:45
|
Since for certain images it doesn't create any artifacts like macroblocking
|
|
|
|
JendaLinda
|
2024-08-01 04:30:44
|
That makes sense. Also photos are quite busy by nature so dithering won't increase entropy that much. The resulting PNG becomes smaller simply because there is less data to begin with.
|
|
2024-08-01 04:42:25
|
pngquant can be used as a general purpose converter to palette too, to convert images for display in color limited systems.
|
|
2024-08-01 04:43:16
|
As long as the target system permits use of custom palette.
|
|
2024-08-01 04:50:19
|
With the right software you can even view PNGs directly in DOS. Works pretty well on 486.
|
|
2024-08-04 12:36:46
|
It's curious that some ECT options have one dash a some have two dashes.
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-04 07:35:45
|
2 dashes are supposed to be for "advanced users"
|
|
|
Laserhosen
|
2024-08-04 11:54:25
|
badgerloc|<
|
|
2024-08-04 11:54:31
|
badgerloc|<
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-05 06:48:36
|
I hate it when I just need 11 bytes smaller PNG to gain a disk cluster <:KekDog:805390049033191445>
|
|
2024-08-05 06:48:57
|
I mean, 11 bytes taking the place of 4096 bytes
|
|
2024-08-05 06:50:50
|
and `ect -93999 --mt-deflate -strip` couldn't do any better
|
|
|
Fox Wizard
|
2024-08-05 07:11:51
|
Time for slower paramsโข๏ธ
|
|
|
|
JendaLinda
|
2024-08-05 07:42:11
|
According to my results, omitting `--mt-deflate` can save few bytes.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-05 09:27:00
|
I ain't doing that on a 3000x3000 PNG <:KekDog:805390049033191445>
|
|
|
|
JendaLinda
|
2024-08-05 10:14:52
|
It's not that bad, you can still use the computer to do other things.
|
|
|
|
CrushedAsian255
|
|
TheBigBadBoy - ๐ธ๐
I hate it when I just need 11 bytes smaller PNG to gain a disk cluster <:KekDog:805390049033191445>
|
|
2024-08-05 10:37:02
|
Convert to jxl??
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-05 10:38:30
|
problem is
my Android phone's music player doesn't support JXL <:SadCat:805389277247701002>
|
|
|
|
Quackdoc
|
2024-08-05 10:39:51
|
I had a build of harmonoid that supported JXL art
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-05 11:00:28
|
would be so cool if we could update Android libs like we do in (Arch) Linux
|
|
2024-08-05 11:00:59
|
Is there an Android version supporting JXL out of the box ?
|
|
|
|
Quackdoc
|
2024-08-05 11:04:33
|
you can technically update the image decoder, no roms support JXL afaik
|
|
2024-08-05 11:06:29
|
I could probably get it working in bliss or lineage with some effort, but it probably wouldn't be super easy to update to on other distros
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-05 11:14:22
|
mmmmh
currently I'm running LineAgeOS 18 (A11)
I could upgrade to 20 (A13) but doesn't want to bc every works (well, except JXL lol)
|
|
2024-08-05 11:14:52
|
just found this PR for adding JXL to LineAgeOS that was rejected (if I understand correctly)
https://review.lineageos.org/c/LineageOS/android_packages_apps_Glimpse/+/392231/1
|
|
2024-08-05 11:15:14
|
> don't think JPEG XL will ever see any real usage
[โ ](https://cdn.discordapp.com/emojis/939666933119324222.webp?size=48&quality=lossless&name=av1_whatisthis)
|
|
|
|
Quackdoc
|
2024-08-05 11:20:35
|
iirc glimpse is just the gallery
|
|
2024-08-05 11:20:51
|
yeah it's just the coil thing
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-05 11:24:24
|
oh
|
|
2024-08-05 11:24:33
|
(โฏยฐโกยฐ)โฏ๏ธต โปโโป
|
|
|
|
jonnyawsom3
|
2024-08-05 11:29:49
|
You could embed your JXLs into DNGs and then Samsung phones would load them
|
|
|
|
Quackdoc
|
2024-08-05 11:32:38
|
I believe it was just their pdf viewer that does
|
|
|
HCrikki
|
2024-08-05 11:34:58
|
most samsung gallery branches released/updated in the last year decode dng 1.7 encoded with jxl (afaik covers their cheap and older phones too if they received app updates at some point)
|
|
2024-08-05 11:37:31
|
fossify gallery would be ideal but i think dev needs some help implementing
|
|
|
|
Quackdoc
|
2024-08-05 11:41:45
|
I mean, it should just need merged
|
|
|
|
HCrikki
|
2024-08-06 12:43:07
|
for projects not under our control, easier said than done. supporters risk sound annoying and many devs are just unfamiliar with how properly adding jxl
|
|
2024-08-06 12:44:25
|
its best to hand them working complete PRs for sure, but thats only for *upstream's adoption* - ideal but working builds could be distributed as their derivative or unofficial compiles already
|
|
|
|
Fox Wizard
|
|
TheBigBadBoy - ๐ธ๐
I ain't doing that on a 3000x3000 PNG <:KekDog:805390049033191445>
|
|
2024-08-06 09:04:44
|
You could send it to me I guess <:KekDog:884736660376535040>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:05:01
|
<:KekDog:805390049033191445>
|
|
|
|
Fox Wizard
|
2024-08-06 09:05:25
|
I've done -99999 on multiple 4k images XD
|
|
2024-08-06 09:06:14
|
And on a 4000x2665 picture, because that's the full version of my main background ~~took very long lmao~~
|
|
2024-08-06 09:06:44
|
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:07:35
|
But again I really don't think -99999 will do anything
and already tried `optipng -o7 -zm1-9` too
|
|
|
Fox Wizard
|
|
2024-08-06 09:08:04
|
stealing it <:CatSmile:805382488293244929>
|
|
|
|
Fox Wizard
|
2024-08-06 09:08:20
|
Can't download that since clicking on it results in Discord opening it in browser and then it just shows a broken image icon <:KekDog:884736660376535040>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:08:47
|
yeah because it's not an image
it's GZIP compressed
|
|
2024-08-06 09:09:28
|
oh it does it for me too lmao
Discord shitting itself
|
|
|
|
Fox Wizard
|
2024-08-06 09:09:43
|
I had to download it on mobile and transfer it from my phone to my PC lmao
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:10:16
|
well you could have just opened it in a new tab, then right click "save as" <:KekDog:805390049033191445>
|
|
|
|
Fox Wizard
|
|
TheBigBadBoy - ๐ธ๐
I ain't doing that on a 3000x3000 PNG <:KekDog:805390049033191445>
|
|
2024-08-06 09:10:28
|
But it's only 2400x2400 <:KittyLaugh:1126563616343216268>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:10:50
|
ohhh right
|
|
2024-08-06 09:11:14
|
most of covers from apple music are 3kยฒ
|
|
2024-08-06 09:11:38
|
smh forgot it wasn't [โ ](https://cdn.discordapp.com/emojis/800293019785494578.webp?size=48&quality=lossless&name=teehee)
|
|
|
|
jonnyawsom3
|
|
TheBigBadBoy - ๐ธ๐
But again I really don't think -99999 will do anything
and already tried `optipng -o7 -zm1-9` too
|
|
2024-08-06 09:12:00
|
ECT brute force filtering?
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:12:08
|
btw what do you have as CPU ?
|
|
|
|
Fox Wizard
|
|
TheBigBadBoy - ๐ธ๐
well you could have just opened it in a new tab, then right click "save as" <:KekDog:805390049033191445>
|
|
2024-08-06 09:12:38
|
Shhhh, my brain doesn't function. I have a light fever (probably COVID lmao), haven't really slept for a few days and the only thing keeping me awake are caffeine, paracetamol and ibuprofen <:KekDog:884736660376535040>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
ECT brute force filtering?
|
|
2024-08-06 09:12:41
|
yeah, but I guess I should not start with -93999 with that then [โ ](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&quality=lossless&name=av1_Hmmm)
|
|
|
Fox Wizard
Shhhh, my brain doesn't function. I have a light fever (probably COVID lmao), haven't really slept for a few days and the only thing keeping me awake are caffeine, paracetamol and ibuprofen <:KekDog:884736660376535040>
|
|
2024-08-06 09:13:10
|
~~and optimizing PNGs lmao~~
|
|
2024-08-06 09:13:15
|
just sleepโข๏ธ
|
|
|
|
Fox Wizard
|
2024-08-06 09:13:19
|
Noโข๏ธ
|
|
2024-08-06 09:13:45
|
Not like I can anyways, because imagine being able to fall asleep within 2 hours and actually staying asleep <:KekDog:884736660376535040>
|
|
2024-08-06 09:13:54
|
And I have an appointment somewhere in about 2 hours XD
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:14:19
|
<:KekDog:805390049033191445>
|
|
2024-08-06 09:15:21
|
I started a ` ect -60199 --mt-deflate --allfilters-b`
|
|
|
|
Fox Wizard
|
2024-08-06 09:17:59
|
Too bad I have to pay for electricity now. Otherwise I could have ran the slowest params on multiple ECT versions since I won't be home for 2 weeks starting this weekend
|
|
|
TheBigBadBoy - ๐ธ๐
btw what do you have as CPU ?
|
|
2024-08-06 09:22:27
|
9900K at 4.8GHz. Could lock it at 5GHz, but then it goes from 140W to 200W <:KekDog:884736660376535040>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
Fox Wizard
Too bad I have to pay for electricity now. Otherwise I could have ran the slowest params on multiple ECT versions since I won't be home for 2 weeks starting this weekend
|
|
2024-08-06 09:23:04
|
why would you even do that lol, it's not even an image from your collection <:KekDog:805390049033191445>
|
|
|
|
Fox Wizard
|
2024-08-06 09:23:29
|
Wouldn't have mattered if I didn't have to pay for electricity XD
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:25:32
|
but the HW will degrade I guess
|
|
|
|
Fox Wizard
|
2024-08-06 09:25:43
|
Barely
|
|
2024-08-06 09:25:57
|
I've tortured this CPU to hell already
|
|
2024-08-06 09:26:15
|
Like the 4 weeks Bee Movie encode was locked at 5GHz
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:26:30
|
[โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag)
|
|
|
|
Fox Wizard
|
2024-08-06 09:26:51
|
It has been around 100 degrees very often for the past 5 years <:KekDog:884736660376535040>
|
|
2024-08-06 09:27:26
|
And can't really say I care if it dies, because then I'll just upgrade since the 9900K feels kinda slow tbh
|
|
2024-08-06 09:28:09
|
If it dies soon then I might have to upgrade to a 9950X <:KittyLaugh:1126563616343216268>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:28:25
|
I let mine went up to 100ยฐC, didn't know it could lol
(mine is in a laptop)
|
|
|
Fox Wizard
If it dies soon then I might have to upgrade to a 9950X <:KittyLaugh:1126563616343216268>
|
|
2024-08-06 09:29:50
|
same philosophy here for my phone
5 years I have it, waiting it to die even though I know it won't have any prob for another several years
|
|
|
|
Fox Wizard
|
2024-08-06 09:30:06
|
Old phone gangโข๏ธ
|
|
2024-08-06 09:30:24
|
Think mine is also 5 years old <:KekDog:884736660376535040>
|
|
2024-08-06 09:31:43
|
Minor burn in at the bottom, battery capacity went down with 30% - 40%, but it still works and has never been damaged
|
|
2024-08-06 09:32:10
|
~~Meanwhile my roommate gets the best phone every second year and breaks it within a few months every time lmao~~
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
Fox Wizard
~~Meanwhile my roommate gets the best phone every second year and breaks it within a few months every time lmao~~
|
|
2024-08-06 09:33:12
|
yeah too many people do that, I can't understand
or they just want the latest Samsung/iPhone for whatever reason even if theirs still work
|
|
|
|
Fox Wizard
|
2024-08-06 09:33:57
|
I mean, it's always nice to get a newer and better phone, but often not worth 1500 Euros for a minor upgrade
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:34:35
|
there are phones costing 1.5k ??? [โ ](https://cdn.discordapp.com/emojis/912393017741160479.webp?size=48&quality=lossless&name=av1_megareee)
|
|
|
|
Fox Wizard
|
2024-08-06 09:34:45
|
Many XD
|
|
2024-08-06 09:35:11
|
Gotta get that high capacityโข๏ธ
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:35:11
|
that's more expensive than my laptop lmao
and I'm sure these phones can't even compete with my laptop
|
|
|
Fox Wizard
Gotta get that high capacityโข๏ธ
|
|
2024-08-06 09:36:13
|
oh right, if it's the same thing as Apple Mac that charge you $200 for 8GB of RAM more <:kekw:808717074305122316>
|
|
|
|
Fox Wizard
|
2024-08-06 09:36:23
|
The S24 Ultra 1tb was even โฌ 1550 - โฌ2000 at launch
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:36:28
|
oooof
|
|
|
|
Fox Wizard
|
2024-08-06 09:37:07
|
Average price here is still at โฌ1621 (nice) here. At least the lowest price is โฌ1399
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:37:37
|
that's what you want to buy if you phone dies ?
|
|
|
|
Fox Wizard
|
2024-08-06 09:37:51
|
I'll wait for the S25 Ultra <:KekDog:884736660376535040>
|
|
2024-08-06 09:37:58
|
And not the 1tb model
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
|
Fox Wizard
|
2024-08-06 09:38:25
|
I currently only use 31GB on my phone... with many FLACs
|
|
|
|
JendaLinda
|
2024-08-06 09:38:42
|
If my phone dies I will buy another โฌ100 one ๐
|
|
|
|
Fox Wizard
|
2024-08-06 09:38:59
|
46.7GB if you include system files. It only has 128GB storage <:KekDog:884736660376535040>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
Fox Wizard
I currently only use 31GB on my phone... with many FLACs
|
|
2024-08-06 09:39:11
|
right I understand that
but buying a $1.5k phone for "just more storage"
nope thanks <:KekDog:805390049033191445>
|
|
|
JendaLinda
If my phone dies I will buy another โฌ100 one ๐
|
|
2024-08-06 09:39:20
|
<:Hypers:808826266060193874>
|
|
|
|
Fox Wizard
|
2024-08-06 09:39:41
|
Yeah. I just hope the S25 Ultra with 512GB will be available for 1k or less at launch
|
|
2024-08-06 09:40:06
|
This year it was possible to get a decent price for the S24 Ultra with abusing some things
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 09:40:07
|
couldn't you buy a cheaper one and get a 1/2TB SD card ?
even if I don't know how expensive it is
|
|
|
|
Fox Wizard
|
2024-08-06 09:40:28
|
Nah
|
|
2024-08-06 09:41:04
|
Hopefully Samsung will have a broken launch like for the s23. I know someone who got an S23 Ultra for like 400 Euros XD
|
|
2024-08-06 09:42:11
|
Trade in stuff (didn't matter which device you traded in as long as it was a Samsung device), employee discount and pre order bonus
|
|
2024-08-06 09:42:23
|
He traded in his broken old Samsung tablet and it still counted <:KekDog:884736660376535040>
|
|
2024-08-06 09:43:23
|
Think this year it was possible to get a 512GB S24 Ultra for 800 Euros. Maybe less with a trade in bonus
|
|
|
|
JendaLinda
|
2024-08-06 10:04:01
|
ECT is doing some funny things like using Up and Paeth filters on the first row of pixels where they do nothing.
|
|
|
|
jonnyawsom3
|
|
Fox Wizard
Like the 4 weeks Bee Movie encode was locked at 5GHz
|
|
2024-08-06 10:06:09
|
*The what?*
|
|
|
|
Fox Wizard
|
2024-08-06 10:06:29
|
AV1 cpu0 Bee Movie encode <:Kekw:1098190857267576923>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 10:07:17
|
ahhhh, it remembers me that 2 weeks encode aom-AV1 on my phone <:kekw:808717074305122316>
|
|
|
|
Fox Wizard
|
2024-08-06 10:07:21
|
And the funny thing is that I wasn't happy with the result in the end, so I yeeted it
|
|
2024-08-06 10:07:55
|
Maybe it'll be a bit better with new encoders. Or I might have to wait for AV2
|
|
|
|
jonnyawsom3
|
|
Fox Wizard
And can't really say I care if it dies, because then I'll just upgrade since the 9900K feels kinda slow tbh
|
|
2024-08-06 10:08:20
|
Then there's me on a Ryzen 1700, literally a 2x performance increase if I went to a 5800x3d, not even considering x3d on top of it
|
|
|
Fox Wizard
Think mine is also 5 years old <:KekDog:884736660376535040>
|
|
2024-08-06 10:10:12
|
7 years, out of storage, battery is shot and constantly thermal throttles, but still holding on
|
|
|
|
Fox Wizard
|
2024-08-06 10:10:55
|
At that point I would have definitely bought a new phone, even if it's a cheap one <:KekDog:884736660376535040>
|
|
|
|
A homosapien
|
|
TheBigBadBoy - ๐ธ๐
But again I really don't think -99999 will do anything
and already tried `optipng -o7 -zm1-9` too
|
|
2024-08-06 10:11:15
|
I saved 34 bytes
|
|
|
|
jonnyawsom3
|
|
Fox Wizard
At that point I would have definitely bought a new phone, even if it's a cheap one <:KekDog:884736660376535040>
|
|
2024-08-06 10:14:10
|
Last time I was at a pub with some friends, one of them wanted to open youtube on my phone
Being used to Apple devices, they swiped down and opened the 'AI Search' and accepted all the terms to the Chinese spyware Huawei put in xD
Had popups and random Chinese writing for half an hour until I found the application to reset
|
|
2024-08-06 10:15:08
|
So proooobably should get a new one, but nothing has really caught my eye
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
A homosapien
I saved 34 bytes
|
|
2024-08-06 10:22:01
|
[โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag) [โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag) [โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag) [โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag)
|
|
2024-08-06 10:22:21
|
thank you very much [โ ](https://cdn.discordapp.com/emojis/674256399412363284.webp?size=48&quality=lossless&name=av1_pepelove)
and how did you do it ?
|
|
|
|
A homosapien
|
2024-08-06 10:22:23
|
It only took like two minutes bruh
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 10:22:38
|
yeah but needs to know the right tools for that
|
|
|
|
A homosapien
|
2024-08-06 10:22:52
|
`ect -30060 --reuse cover.png`
|
|
2024-08-06 10:22:55
|
its that simple
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 10:22:57
|
whut
|
|
2024-08-06 10:23:07
|
oh, no --mt-deflate
|
|
|
|
A homosapien
|
2024-08-06 10:23:15
|
indeed
|
|
2024-08-06 10:23:41
|
its worth it sometimes, adding more iterations is just overkill
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-06 10:24:29
|
[โ ](https://cdn.discordapp.com/emojis/872898333239279666.webp?size=48&quality=lossless&name=av1_frogstudy)
|
|
|
|
JendaLinda
|
2024-08-06 10:36:13
|
`pngcheck -vv` is fun to use to see what strategies the encoder used.
I found a PNG where ECT used Up for the first line and the rest of the image uses no filter.
|
|
|
|
A homosapien
|
|
TheBigBadBoy - ๐ธ๐
[โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag) [โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag) [โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag) [โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag)
|
|
2024-08-06 10:37:59
|
I saved another 34 bytes lol
|
|
2024-08-06 10:39:12
|
just `-90060` this time
|
|
|
|
JendaLinda
|
2024-08-06 10:47:49
|
We were talking about lossy PNG where the image can be blurred to take advantage of the Average filter. I've checked a picture drawn using soft lines so the entire picture is intentionally blurry. ECT used mostly Paeth rather than Average.
|
|
|
|
A homosapien
|
2024-08-06 11:08:17
|
filters are extremely image dependent, that just how it is ยฏ\_(ใ)_/ยฏ
|
|
|
|
Fox Wizard
|
2024-08-06 11:09:04
|
Lol, -99999 --mt-deflate didn't result in a smaller image <:KekDog:884736660376535040>
|
|
2024-08-06 11:09:58
|
At least in the end I still managed to make it 74 bytes smaller, but doubt it was worth all the effort XD
|
|
2024-08-06 11:10:18
|
It can probably still be made a few bytes smaller with mega slow params and using different ECT versions
|
|
|
|
A homosapien
|
2024-08-06 11:11:22
|
As I just said, throwing more iterations at the problem is a waste of time
|
|
|
|
Fox Wizard
|
2024-08-06 11:11:44
|
Yesn't. It can help a bit
|
|
|
|
A homosapien
|
2024-08-06 11:11:50
|
not on this image
|
|
2024-08-06 11:12:09
|
anything past 60 iterations didn't do anything
|
|
2024-08-06 11:12:32
|
since it was an anime image I thought maybe more blocksplitting would help
|
|
2024-08-06 11:12:44
|
and it did
|
|
|
|
JendaLinda
|
2024-08-06 11:17:18
|
There are still images compressed by PNGOut that ECT can't compress no matter I try.
|
|
|
|
A homosapien
|
2024-08-06 11:18:21
|
that's because with PNGOut you can manually input stupidly huge block-splits that would only benefit large images with *very* low entropy
|
|
2024-08-06 11:19:55
|
4000x3000 flat shaded artwork would be an example I've seen where PNGout does better than ECT
|
|
|
|
JendaLinda
|
2024-08-06 11:20:12
|
Yes, like those with large flat color areas.
|
|
|
|
A homosapien
|
2024-08-06 11:22:25
|
although, if somebody were to fork ECT and allow setting a specific block-split size, I'm sure ECT would outdo PNGout
|
|
2024-08-06 11:22:57
|
since their deflate algorithms are the best I've seen
|
|
2024-08-06 11:23:34
|
and by best I mean sacrificing any kind of usable speed for the smallest size possible
|
|
|
|
JendaLinda
|
2024-08-06 11:24:08
|
No need for setting custom block splitting. Just running `pngout` followed by `pngout /f0` will result in the optimal compression.
PNGOut somehow chooses block splitting depending on the previous encoding.
|
|
|
|
A homosapien
|
2024-08-06 11:26:05
|
the fact that you have to run the same program twice weird and clunky imo
|
|
|
|
JendaLinda
|
2024-08-06 11:26:23
|
Agreed
|
|
|
|
A homosapien
|
2024-08-06 11:26:55
|
not to mention its not optimal, I've gotten smaller images by manually setting a size myself
|
|
2024-08-06 11:27:12
|
but that's a huge time sink
|
|
|
|
JendaLinda
|
2024-08-06 11:27:51
|
That's fair. I don't even know what values I should try.
|
|
|
|
A homosapien
|
2024-08-06 11:29:30
|
Low entropy = High values
High entropy = Small values
The rest is just guess work
|
|
2024-08-06 11:29:38
|
I mean at this point you are spending several minutes for a handful less bytes I think the sunk-cost fallacy has run its course ๐
|
|
2024-08-06 11:30:15
|
Like just use .webp or .jxl for any meaningful savings
|
|
2024-08-06 11:31:40
|
That's why I think ECT is too slow for me. Since the encoding time would be better spent on newer formats
|
|
|
|
JendaLinda
|
2024-08-06 11:34:07
|
It's a nice exercise because PNG format is so simple.
|
|
|
|
A homosapien
|
2024-08-06 11:37:03
|
It's a fun activity to kill time, but when it comes dealing with hundreds of images, ECT is not worth the time investment
|
|
2024-08-06 11:37:37
|
I use pingo or oxipng to batch upload hundreds of images to wikis.
|
|
2024-08-06 11:38:10
|
I don't want to wait 'til the heat death of the universe to save like 1 KB
|
|
|
|
JendaLinda
|
2024-08-06 11:41:49
|
ECT can do jpegs quite well too. Not that exhaustively though. `ECT -9 -progressive` works nicely.
|
|
2024-08-06 11:44:50
|
There are some dedicated jpeg optimizer. I was checking them out and they are mostly using jpegtran. One of them even claimed itself obsolete as mozjpeg jpegtran has the optimizations already builtin. ECT is using mozjpeg jpegtran as well.
|
|
|
|
A homosapien
|
2024-08-06 11:49:57
|
ECT is outclassed by pingo. `-s4 -l` is smaller than ECT
|
|
2024-08-06 11:51:16
|
I'm also assuming it's using some kind of modified mozjpeg-tran. I use it in my workflow paired with cjpegli
|
|
2024-08-06 11:51:43
|
I get really impressive results combining the two considering jpeg is 3 decades old atp
|
|
|
|
jonnyawsom3
|
2024-08-06 11:52:51
|
Meanwhile, I just finished this
```wintime -- ect -p -r -k --mt-file=8 "C:\Users\jonat\Pictures\VRChat\2024-07"
Processed 261 files
Saved 470.62MB out of 2.07GB (22.1856%)
PageFaultCount: 218570543
PeakWorkingSetSize: 1.383 GiB
QuotaPeakPagedPoolUsage: 25.42 KiB
QuotaPeakNonPagedPoolUsage: 15 KiB
PeakPagefileUsage: 1.487 GiB
Creation time 2024/08/06 12:27:04.152
Exit time 2024/08/06 12:39:50.754
Wall time: 0 days, 00:12:46.601 (766.60 seconds)
User time: 0 days, 00:05:12.671 (312.67 seconds)
Kernel time: 0 days, 01:36:05.953 (5765.95 seconds)```
|
|
2024-08-06 11:55:04
|
I've found that ECT is (who would've guessed) more efficient than Oxipng at similar compression levels, either in CPU time or memory usage, which matters a lot when there's multiple 8K images and you only have 16 GB of RAM
|
|
|
|
JendaLinda
|
|
A homosapien
ECT is outclassed by pingo. `-s4 -l` is smaller than ECT
|
|
2024-08-06 11:57:54
|
I wasn't convinced by pingo because of the sparse documentation.
|
|
|
|
A homosapien
|
|
JendaLinda
I wasn't convinced by pingo because of the sparse documentation.
|
|
2024-08-06 12:01:30
|
Don't judge a book by it's cover. I test all kinds of programs regardless of their perceived quality. I'm only convinced by results, not documentation.
|
|
|
I've found that ECT is (who would've guessed) more efficient than Oxipng at similar compression levels, either in CPU time or memory usage, which matters a lot when there's multiple 8K images and you only have 16 GB of RAM
|
|
2024-08-06 12:02:01
|
More efficient as in smaller size or faster speed?
|
|
|
|
jonnyawsom3
|
2024-08-06 12:12:15
|
It tends to change between images and settings, but the memory usage on ECT never goes far above the raw image size, while Oxipng used 2-3x more
At least this is what I remember, I did the tests months ago and didn't save the results
|
|
|
|
JendaLinda
|
|
A homosapien
Don't judge a book by it's cover. I test all kinds of programs regardless of their perceived quality. I'm only convinced by results, not documentation.
|
|
2024-08-06 12:13:37
|
Fine. I will give it a shot.
|
|
2024-08-06 08:16:37
|
Hmm it seems the difference between ECT and Pingo JPEG optimization is that Pingo removes JFIF marker. Otherwise the files are the same size.
|
|
2024-08-06 08:52:11
|
So yeah, jpegs optimized by Pingo are 18 bytes smaller than those optimized by ECT.
Is it safe to remove JFIF markers? Presumably all jpeg decoders understanding progressive jpeg should also understand jpeg without JFIF.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
So yeah, jpegs optimized by Pingo are 18 bytes smaller than those optimized by ECT.
Is it safe to remove JFIF markers? Presumably all jpeg decoders understanding progressive jpeg should also understand jpeg without JFIF.
|
|
2024-08-06 09:18:25
|
is JFIF the same as APP0 marker ?
|
|
2024-08-06 09:19:07
|
bc from this: https://github.com/MegaByte/jpegultrascan/blob/master/jpegultrascan.md
> -j Strip APP0 segment for 18-byte savings (generates non-compliant JPEG that may be incompatible with some
> software)
which saves 18bytes too
|
|
|
|
JendaLinda
|
2024-08-07 06:14:12
|
Yes, JFIF is APP0
|
|
|
|
A homosapien
|
|
JendaLinda
So yeah, jpegs optimized by Pingo are 18 bytes smaller than those optimized by ECT.
Is it safe to remove JFIF markers? Presumably all jpeg decoders understanding progressive jpeg should also understand jpeg without JFIF.
|
|
2024-08-07 07:23:59
|
It properly decodes in all cases I've tested with one exception, an old version of photoshop gave me a garbled mess
|
|
2024-08-07 07:30:02
|
I should mention ECT jpegs also didn't work with that old version of photoshop, so I don't think it was absence of the JFIF marker
|
|
|
|
JendaLinda
|
2024-08-07 07:31:42
|
Very old programs don't understand progressive jpeg.
|
|
2024-08-07 07:33:31
|
cjpegli produces jpegs without JFIF/APP0 so I suppose it's fine.
|
|
|
TheBigBadBoy - ๐ธ๐
bc from this: https://github.com/MegaByte/jpegultrascan/blob/master/jpegultrascan.md
> -j Strip APP0 segment for 18-byte savings (generates non-compliant JPEG that may be incompatible with some
> software)
which saves 18bytes too
|
|
2024-08-07 07:49:11
|
jpegultrascan looks interesting. Is it better than mozjpeg/ECT/Pingo?
|
|
|
|
Fox Wizard
|
2024-08-07 07:56:43
|
It's more efficient, but takes much longer since it's basically brute forcing
|
|
2024-08-07 07:58:10
|
Oh lol, forgot to upload the most efficient result, so have one that's a few bytes smaller than <@693503208726986763> <:KekDog:884736660376535040>
|
|
|
|
JendaLinda
|
2024-08-07 07:58:51
|
I would try it to see how it goes. I need to get Perl and mozjpeg tools. Is there any "official" mozjpeg Windows build?
|
|
|
|
Fox Wizard
|
2024-08-07 08:06:25
|
If you do then use this version. The new one bugged for me on Windows
|
|
2024-08-07 08:07:08
|
``perl jpegultrascan.pl -s -i -b 3 -t 12 inputfile outputfile`` -b goes up to 13, but I never see any better results from it
|
|
|
|
JendaLinda
|
|
Fox Wizard
If you do then use this version. The new one bugged for me on Windows
|
|
2024-08-07 08:12:05
|
This seems to be the same version as on Github. And what versions of jpegtran are you using?
|
|
|
|
Fox Wizard
|
2024-08-07 09:00:17
|
Usually this one
|
|
|
|
JendaLinda
|
2024-08-07 10:04:27
|
So that's the IJG version. jpegultrascan suggests using mozjpeg jpegtran as well.
|
|
|
|
Fox Wizard
|
2024-08-07 10:04:49
|
That always resulted in worse compression for me
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
jpegultrascan looks interesting. Is it better than mozjpeg/ECT/Pingo?
|
|
2024-08-07 11:10:59
|
yeah lol, it's a bruteforcer
"tries all scan possibilities"
|
|
2024-08-07 11:12:54
|
but then it's quite slow and cpu hungry
|
|
|
|
JendaLinda
|
2024-08-07 11:13:27
|
I just want to try it if it takes minutes or hours ๐
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 11:13:37
|
minutes
|
|
2024-08-07 11:13:59
|
for a few MBs JPG and `-b 3 -t 16`
|
|
|
|
JendaLinda
|
2024-08-07 11:14:27
|
Mine are usually under 2MB
|
|
|
Fox Wizard
If you do then use this version. The new one bugged for me on Windows
|
|
2024-08-07 11:37:52
|
Huh? That's atrange. The Github version is different but the date and version number didn't change. You're right, the Github version doesn't work at all, it just dies.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 11:41:40
|
works for me on Linux
skill issueโข๏ธ
|
|
|
|
JendaLinda
|
2024-08-07 11:51:29
|
Yeah, I'm using perl for the first time.
`perl jpegultrascan.pl input.jpg ouput.jpg`
and it immediately dies.
The Fox Wizard's version is doing something, not done yet.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
Yeah, I'm using perl for the first time.
`perl jpegultrascan.pl input.jpg ouput.jpg`
and it immediately dies.
The Fox Wizard's version is doing something, not done yet.
|
|
2024-08-07 11:53:12
|
I really recommand to use `-t 16` or whatever number of cpu cores you have
otherwise jpegultrascan will only use one by default
|
|
|
|
JendaLinda
|
2024-08-07 11:54:03
|
I know. I went with no options for now.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 11:54:17
|
oh perhaps you used that command only for the version that dies not work for you
|
|
|
|
JendaLinda
|
2024-08-07 11:54:44
|
Tried to avoid the skill issue ๐
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
Fox Wizard
Usually this one
|
|
2024-08-07 12:06:31
|
just tested, I have the same issue if I use your jpegtran.exe and the latest jpegultrascan (while mozjpeg's jpegtran works fine)
perhaps we should open an issue
|
|
2024-08-07 12:10:16
|
where did you get your jpegtran ?
|
|
|
|
JendaLinda
|
2024-08-07 12:12:40
|
http://sylvana.net/jpeg-bin/
linked from
https://jpegclub.org/jpegtran/
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 12:14:48
|
is it different from the one provided by libjpeg-turbo package ? [โ ](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&quality=lossless&name=av1_Hmmm)
|
|
|
|
JendaLinda
|
2024-08-07 12:16:33
|
I'm not that familiar with different versions of libjpeg. This is the Windows build I could find.
|
|
2024-08-07 12:17:13
|
It's the IJG version.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 12:19:42
|
just tested and no, IJG and libjpeg-turbo provides different jpegtran
|
|
|
|
JendaLinda
|
2024-08-07 12:21:54
|
I thought so, IJG has some additional, non standard features.
|
|
2024-08-07 12:23:32
|
I found a mozjpeg build, so I will try it:
https://mozjpeg.codelove.de/binaries.html
|
|
2024-08-07 12:24:46
|
The first run using IJG is not that impressive, less than 1% gain over ECT.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
The first run using IJG is not that impressive, less than 1% gain over ECT.
|
|
2024-08-07 12:31:02
|
yeah you should not expect great gains
see this benchmark I made
https://github.com/T-3B/compresssion_benchmarks/tree/main/JPG%20(encoders%20%2B%20optimizers)
|
|
|
JendaLinda
http://sylvana.net/jpeg-bin/
linked from
https://jpegclub.org/jpegtran/
|
|
2024-08-07 12:31:50
|
apparently no Linux build nor source ?
<:PepeHands:808829977608323112>
|
|
2024-08-07 12:34:11
|
nevermind found the source
|
|
|
|
JendaLinda
|
2024-08-07 12:36:01
|
It's kinda all over the place. This could be it
https://www.ijg.org/files/
|
|
2024-08-07 12:38:16
|
Yay so jpegultrascan using mozjpeg is worse. I will try the newest script version for giggles.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 12:39:18
|
newest jpegultrascan script without a different version number was just refinement, nothing really has changed
|
|
|
|
JendaLinda
|
2024-08-07 12:39:49
|
It didn't crash at least.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 12:40:54
|
I hate it when there are dozen version of the same binary name but different implementations [โ ](https://cdn.discordapp.com/emojis/854024330832117792.webp?size=48&quality=lossless&name=reee)
|
|
|
|
JendaLinda
|
2024-08-07 12:41:11
|
So do I
|
|
2024-08-07 12:41:24
|
Itยจs so confusing.
|
|
2024-08-07 12:42:27
|
Anyway, I think I will go with Pingo for jpegs. Same as ECT but without APP0.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 12:45:55
|
fuck, their IJG is so fucking weird to compile
the `configure` file is 17k lines long <:monkaMega:809252622900789269>
|
|
2024-08-07 12:50:15
|
<@219525188818042881> the jpegultrascan version you are using, is it the one just before the latest commit ?
|
|
2024-08-07 12:50:21
|
gonna report the issue
|
|
|
|
jonnyawsom3
|
|
TheBigBadBoy - ๐ธ๐
yeah you should not expect great gains
see this benchmark I made
https://github.com/T-3B/compresssion_benchmarks/tree/main/JPG%20(encoders%20%2B%20optimizers)
|
|
2024-08-07 12:53:28
|
Looking at that reminded me of the requests to have jpegli auto subsample based on quality settings
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
Fox Wizard
Usually this one
|
|
2024-08-07 01:49:21
|
hehe I now know what you used to beat me [โ ](https://cdn.discordapp.com/emojis/800293019785494578.webp?size=48&quality=lossless&name=teehee)
|
|
|
|
JendaLinda
|
|
TheBigBadBoy - ๐ธ๐
hehe I now know what you used to beat me [โ ](https://cdn.discordapp.com/emojis/800293019785494578.webp?size=48&quality=lossless&name=teehee)
|
|
2024-08-07 02:12:54
|
This seems to be slightly newer version than the one I have but gives the same results.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 02:13:43
|
I was using mozjpeg one
that's why my outputs were bigger
|
|
|
|
JendaLinda
|
2024-08-07 02:16:32
|
Yeah, jpegultrascan recommends using IJG as `-p` and mozjpeg as `-o`, I will try this combination.
|
|
2024-08-07 02:22:33
|
And it didn't do anything different.
|
|
2024-08-07 02:30:57
|
IJG does strange thing, it uses separate DQT marker for each quantization table for no reason.
|
|
|
KKT
|
2024-08-07 03:50:49
|
https://webflow.com/updates/avif-image-support-conversion-tool
|
|
|
|
JendaLinda
|
2024-08-07 03:59:28
|
There are still websites that permit uploads only in JPEG and PNG formats, so I'm stuck with these.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
IJG does strange thing, it uses separate DQT marker for each quantization table for no reason.
|
|
2024-08-07 09:19:16
|
yeah but it manages to compress better and losslessly, so I don't really care <:KekDog:805390049033191445>
|
|
|
|
JendaLinda
|
2024-08-07 09:27:21
|
It bothers me.
|
|
2024-08-07 09:35:53
|
There are also jpegs in the wild using two identical quantization tables instead of one. None of the jpegtran versions can address that.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 09:36:34
|
could you send a sample please ?
|
|
|
|
JendaLinda
|
|
TheBigBadBoy - ๐ธ๐
could you send a sample please ?
|
|
2024-08-07 09:39:47
|
|
|
2024-08-07 09:40:31
|
As a bonus, cjxl is unable to lossless transcode it and djpegli can't decode it.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
There are also jpegs in the wild using two identical quantization tables instead of one. None of the jpegtran versions can address that.
|
|
2024-08-07 09:42:11
|
I don't have problem with mozjpeg's jpegtran [โ ](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&quality=lossless&name=av1_Hmmm)
|
|
2024-08-07 09:43:02
|
from `282576` bytes to `281635`
|
|
|
|
JendaLinda
|
2024-08-07 09:44:34
|
I thought it could figure out to drop one copy of the quantization table.
|
|
2024-08-07 09:45:09
|
There are two identical copies.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 09:45:19
|
oh ok
|
|
|
|
JendaLinda
|
2024-08-07 09:47:45
|
There is something else wrong with the file as well, but jpegtran will fix that and both cjxl and djpegli will be able to process it.
|
|
2024-08-07 09:52:41
|
The only way to get rid of the redundant quantization table is to manually edit SOF so only one copy is used and then jpegtran will drop the unused copy.
|
|
2024-08-07 09:54:21
|
Just a quick surgery in hex editor <:KekDog:805390049033191445>
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 10:06:47
|
<:FeelsReadingMan:808827102278451241>
|
|
2024-08-07 10:09:08
|
do you happen to have the corrected version ? <:CatSmile:805382488293244929>
|
|
|
|
JendaLinda
|
|
TheBigBadBoy - ๐ธ๐
do you happen to have the corrected version ? <:CatSmile:805382488293244929>
|
|
2024-08-07 10:32:17
|
Sure
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-07 10:33:11
|
yay thank you very much
|
|
2024-08-07 10:33:30
|
[โ ](https://cdn.discordapp.com/emojis/1216720664980099206.gif?size=48&quality=lossless&name=p_damdamlove)
|
|
|
|
KKT
|
|
TheBigBadBoy - ๐ธ๐
yeah but it manages to compress better and losslessly, so I don't really care <:KekDog:805390049033191445>
|
|
2024-08-07 10:37:32
|
It wouldn't be so bad if Webflow wasn't openly hostile to images it doesn't understand. It won't even let you upload a JPEG XL file. And it won't let you upload an SVG with a colour specified with oklch. So annoying.
|
|
|
|
JendaLinda
|
|
TheBigBadBoy - ๐ธ๐
yay thank you very much
|
|
2024-08-07 10:38:33
|
I figured out that the redundant quantization table can be removed and the jpeg will decode the same way. The only thing that matters is that table of the correct numbers has to be assigned to each of the channels.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
Sure
|
|
2024-08-07 10:39:13
|
ECT reached just 65 bytes heavier file than fixed.jpg with the unfixed input
|
|
|
|
JendaLinda
|
2024-08-07 10:39:46
|
Yes, that's one copy of quantization table.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
I figured out that the redundant quantization table can be removed and the jpeg will decode the same way. The only thing that matters is that table of the correct numbers has to be assigned to each of the channels.
|
|
2024-08-07 10:40:42
|
I might one day write an automated script for "detecting and removing duplicate quantization table" <:KekDog:805390049033191445>
|
|
|
|
JendaLinda
|
|
TheBigBadBoy - ๐ธ๐
I might one day write an automated script for "detecting and removing duplicate quantization table" <:KekDog:805390049033191445>
|
|
2024-08-07 10:49:29
|
Another curiosity, if both versions of the jpeg file, with one and two quantization tables, are losslessly transcoded to jxl, the jxl files differ only in the jbrd data.
|
|
|
|
A homosapien
|
|
Fox Wizard
Oh lol, forgot to upload the most efficient result, so have one that's a few bytes smaller than <@693503208726986763> <:KekDog:884736660376535040>
|
|
2024-08-08 07:44:39
|
I went against my own advice and did 200 iterations, saved 69 bytes. Then did 1000 iterations and saved 0 bytes ๐ฅฒ
|
|
2024-08-08 07:45:43
|
Sunk-cost fallacy strikes again ๐ญ I spent like a hour encoding that png
|
|
|
DZgas ะ
|
2024-08-08 07:46:48
|
bruteforce jpeg when?
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
DZgas ะ
bruteforce jpeg when?
|
|
2024-08-08 07:47:54
|
already exists...
https://github.com/MegaByte/jpegultrascan/blob/master/jpegultrascan.md
|
|
|
|
DZgas ะ
|
|
TheBigBadBoy - ๐ธ๐
already exists...
https://github.com/MegaByte/jpegultrascan/blob/master/jpegultrascan.md
|
|
2024-08-08 07:50:39
|
Jpeg loseless ๐
|
|
2024-08-08 07:50:56
|
jpeg lossy bruteforce when?
|
|
2024-08-08 07:51:44
|
like Guetzli
|
|
2024-08-08 07:51:56
|
(not like jpegli)
|
|
2024-08-08 07:56:13
|
it's just strange that no one is doing any sort of iteration of Huffman tables and building "pixel content"(dct) for these tables. all algorithms come to an ideal result in a linear way... But that's not true.
|
|
2024-08-08 07:57:00
|
png bruteforce demonstrates this.
|
|
2024-08-08 07:57:15
|
like pngout
|
|
|
|
A homosapien
|
2024-08-08 07:57:24
|
sounds like a waste of time to me
|
|
|
|
DZgas ะ
|
|
A homosapien
sounds like a waste of time to me
|
|
2024-08-08 07:57:41
|
Lets go <:YEP:808828808127971399>
|
|
|
|
A homosapien
|
|
DZgas ะ
Lets go <:YEP:808828808127971399>
|
|
2024-08-08 07:58:33
|
I love killing time for the most minuscule gains in quality <:Hypers:808826266060193874>
|
|
|
|
JendaLinda
|
2024-08-08 08:14:05
|
Still strange how IJG is better in bruteforce than mozjpeg.
|
|
|
|
CrushedAsian255
|
2024-08-08 08:18:34
|
`jpegultrascan` took 2.5 minutes to bruteforce a 60kb jpeg
|
|
2024-08-08 08:18:41
|
with 8 cores
|
|
|
|
DZgas ะ
|
|
JendaLinda
Still strange how IJG is better in bruteforce than mozjpeg.
|
|
2024-08-08 10:35:09
|
has MozJPEG bruteforce ??
|
|
2024-08-08 10:37:08
|
oh ok
|
|
2024-08-08 10:37:40
|
still lossless
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-08 10:52:53
|
lossless ftw
|
|
2024-08-08 10:54:30
|
<@219525188818042881> or <@688076786525143117> could one of you try to compile from source IJG jpegtran to see if the problem persists ?
Download `jpegsr9f.zip` from https://www.ijg.org
Just opened an issue: https://github.com/MegaByte/jpegultrascan/issues/8
|
|
|
|
JendaLinda
|
2024-08-08 02:55:50
|
I'm trying to compile it using Visual Studio and nothing worked for me so far. Probably skill issue, I don't really know what I'm doing.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-08 03:20:40
|
no prob, thanks for trying
|
|
|
|
JendaLinda
|
2024-08-08 07:23:53
|
How bad is using the `-i` option in `jpegultrascan`?
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
How bad is using the `-i` option in `jpegultrascan`?
|
|
2024-08-08 08:13:39
|
> -i generates files that are incompatible with some software such as Photoshop and Opera <= 11.61. -i -1 generates files that are compatible with IPP JPEG.
|
|
|
|
JendaLinda
|
2024-08-08 08:36:21
|
I was hoping people who are regularly using jpegultrascan did some more testing. Does it mean such jpegs don't work in Photoshop at all? I don't have access to Photoshop to test it.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
I was hoping people who are regularly using jpegultrascan did some more testing. Does it mean such jpegs don't work in Photoshop at all? I don't have access to Photoshop to test it.
|
|
2024-08-08 08:54:38
|
> Does -i create files with the first scan being black and white? fun software bugs with that one...
The first scan could be monochrome (luminance) or it could be full color depending on whichever combination is smaller. What -i does is allow for DC scans that include more than one but less than the full number of channels. Conversely, -i -1 disallows single channel DC scans, so monochrome wouldn't be possible in that case.
If you want more info or ask other users about it, there's a thread here: https://encode.su/threads/2489-jpegultrascan-an-exhaustive-JPEG-scan-optimizer
|
|
|
|
A homosapien
|
|
JendaLinda
I was hoping people who are regularly using jpegultrascan did some more testing. Does it mean such jpegs don't work in Photoshop at all? I don't have access to Photoshop to test it.
|
|
2024-08-08 09:02:32
|
When I had access to Photoshop it worked with newer versions
|
|
2024-08-08 09:02:45
|
Older versions of Photoshop had an outdated jpeg decoder so it would result in a garbled mess.
|
|
2024-08-08 09:03:18
|
I can't remember the version number specifically but I think it's CC2021 and newer
|
|
2024-08-08 09:05:08
|
It's funny how regular image viewers have a more updated version of libjpeg than Photoshop ๐
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-08 09:06:30
|
I'm also surprised by Discord support for arithmetic JPGs
|
|
2024-08-08 09:06:50
|
even FFmpeg doesn't support it
|
|
|
|
A homosapien
|
2024-08-08 09:08:20
|
Considering discord killed support for animated png/webp, I'm surprised they even support arithmetic jpegs.
|
|
|
|
JendaLinda
|
2024-08-08 09:17:34
|
Still doesn't say how widespread the incompatibility is. Are you using the `-i` option or should I avoid it just to be safe?
|
|
|
|
A homosapien
|
2024-08-08 09:20:46
|
It works with all devices/software I tested, old Photoshop was the only exception. So for me I think it's pretty safe.
|
|
|
|
JendaLinda
|
2024-08-08 09:23:53
|
I'm also concerned about mobile devices.
|
|
2024-08-08 09:25:39
|
Old phones could be kinda quirky sometimes.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-08 09:35:42
|
I always use `-i` for quite a few months now
never got any problem, tested on Android 11
|
|
|
|
A homosapien
|
2024-08-08 09:36:45
|
I have Android devices from 6+ years ago and the jpegs decode fine
|
|
|
|
JendaLinda
|
2024-08-08 09:41:42
|
Alright. Hopefully iOS will be OK too.
I might try some old PC software for curiosity.
|
|
2024-08-08 09:59:40
|
Any idea what is `-o` supposed to do? They're suggesting to put mozjpeg jpegtran there but it doesn't seem to do anything different.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
Any idea what is `-o` supposed to do? They're suggesting to put mozjpeg jpegtran there but it doesn't seem to do anything different.
|
|
2024-08-08 10:19:30
|
if `-o` and `-p` are different, both are tested and only the one with the smallest output is kept
see line 480 of the Perl script
|
|
2024-08-08 10:22:35
|
but one error during encode with `jpegultrascan` is it will not work if at one iteration `jpegtran` says "too many scans"
but really uncommon
|
|
|
|
JendaLinda
|
2024-08-09 06:11:46
|
So I guess mozjpeg just did worse than IJG.
|
|
|
A homosapien
I should mention ECT jpegs also didn't work with that old version of photoshop, so I don't think it was absence of the JFIF marker
|
|
2024-08-09 06:45:46
|
Was that the same Photoshop version that couldn't handle `jpegultrascan -i` ?
|
|
|
|
A homosapien
|
|
JendaLinda
Was that the same Photoshop version that couldn't handle `jpegultrascan -i` ?
|
|
2024-08-09 07:07:31
|
Yup
|
|
|
|
JendaLinda
|
2024-08-09 07:32:05
|
So I guess as I'm already using ECT, the compatiblity should stay at the same level.
ECT is using mozjpegtran without any fancy settings so I guess Photoshop was just buggy.
|
|
|
|
A homosapien
|
2024-08-09 09:23:39
|
iirc it wasn't buggy, libjpeg for old PS was just super old
|
|
|
|
JendaLinda
|
2024-08-09 11:31:40
|
MS Internet Explorer 5 from 1999 can decode these jpegs.
|
|
2024-08-09 01:35:49
|
Even Internet Explorer 3 can handle every jpeg I throw at it.
|
|
2024-08-09 01:46:06
|
That's 1996.
How old the libraries used by Adobe must have been ๐
|
|
2024-08-09 01:52:33
|
IE3 doesn't even support PNG yet.
|
|
|
|
A homosapien
|
2024-08-09 05:27:59
|
I guess it was buggy after all ๐
|
|
|
|
JendaLinda
|
2024-08-09 06:10:23
|
What's interesting, Internet Explorer decodes progressive jpegs but doesn't seem to support progressive rendering. The progressive jpeg is displayed after all pixels are decoded.
|
|
|
|
username
|
2024-08-09 07:02:46
|
it's looking like the next release of libwebp might have some minor improvements to lossless encoding size https://github.com/webmproject/libwebp/commit/f2d6dc1eefdae4056de4ae0dfa513f2857d91693
LATE EDIT:
there's also this commit https://github.com/webmproject/libwebp/commit/1bf198a22bd11b15ce74085939757b3361404d89
|
|
|
|
A homosapien
|
2024-08-09 08:23:20
|
I find it so cool how competitive lossless webp is. In some cases it still beats jxl.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
So I guess as I'm already using ECT, the compatiblity should stay at the same level.
ECT is using mozjpegtran without any fancy settings so I guess Photoshop was just buggy.
|
|
2024-08-09 08:43:10
|
ECT does more than mozjpegtran
see here: https://encode.su/threads/3987-Jpeg-Optimizer-testing
|
|
2024-08-09 08:54:38
|
from ECT's author
> ECT uses mozjpeg, so its approach is very similar. The only differences are using a different DC scan optimization mode by default and some performance/compression improvements for the huffman encoding inspired by changes in libjpeg.
> The huffman changes produce better results most of the time, but not always, hence there are some files where mozjpeg performs better.
|
|
|
|
JendaLinda
|
|
TheBigBadBoy - ๐ธ๐
from ECT's author
> ECT uses mozjpeg, so its approach is very similar. The only differences are using a different DC scan optimization mode by default and some performance/compression improvements for the huffman encoding inspired by changes in libjpeg.
> The huffman changes produce better results most of the time, but not always, hence there are some files where mozjpeg performs better.
|
|
2024-08-09 09:33:29
|
I've probably overlooked something, the mozjpegtran function calls looked quite basic.
|
|
2024-08-10 06:30:08
|
JXL provides more flexibility but lossless WebP is still great.
|
|
2024-08-11 12:40:09
|
ECT is still good compared to jpegultrascan.
jpegultrascan sometimes achieves improvement by less than 18 bytes which is the size of APP0 marker. If ECT allowed removing APP0, ECT would be the winner.
|
|
|
|
A homosapien
|
2024-08-11 12:43:40
|
Can you post an example?
|
|
|
|
JendaLinda
|
2024-08-11 12:54:57
|
`ect -9 -progressive` 432208 bytes
`jpegultrascan.pl -i -j -t` 432194 bytes
|
|
|
A homosapien
Can you post an example?
|
|
2024-08-11 01:03:42
|
And I'm using IJG jpegtran. It gave better results during testing.
|
|
|
|
jonnyawsom3
|
|
A homosapien
I find it so cool how competitive lossless webp is. In some cases it still beats jxl.
|
|
2024-08-11 06:52:32
|
If I recall, JXL has all the features WebP Lossless has, it's just a matter or recreating the heuristics and including the new coding tools too
|
|
|
|
_wb_
|
2024-08-11 07:00:45
|
Some things are different, e.g. WebP is hardcoded for RGBA and does interleaved (one pixel at a time), while JXL can do an arbitrary number of components and does things in a planar way (e.g. first all R, then all G, then all B, if there is no RCT applied to decorrelate the components)
|
|
2024-08-11 07:01:51
|
But generally when there are differences, the JXL coding tools are either superior or more generic, so in principle JXL should be able to match lossless WebP.
|
|
2024-08-11 07:03:05
|
It's mostly a matter of refining encoder heuristics and finding a good balance of when to use heuristics and when to do actual search.
|
|
2024-08-11 07:11:36
|
In a way, lossless WebP is closer to PNG, and it seems like the main target was to just consistently improve upon PNG (at least within the WebP limitations regarding dimensions and precision). In jxl, things are more different, there are more features, coding tools that are diverging more from what PNG does, generally a much more expressive bitstream but that also means it is more challenging to make full use of the codec capabilities in an encoder.
|
|
2024-08-11 07:18:02
|
The main goal for the WebP project was to make a single unified format that could replace JPEG, PNG and GIF as they are used on the web.
The main goal for the JXL project was to make a worthy successor for JPEG and PNG that could replace them in _all_ their use cases, not just web but also capture, authoring, archival, etc. It's a somewhat more ambitious goal than that of WebP.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
JendaLinda
`ect -9 -progressive` 432208 bytes
`jpegultrascan.pl -i -j -t` 432194 bytes
|
|
2024-08-11 09:33:34
|
god damn you're right
jpegultrascan could only reach 432212 bytes with IJG jpegtran (mozjpegtran was larger)
|
|
|
|
A homosapien
|
|
JendaLinda
`ect -9 -progressive` 432208 bytes
`jpegultrascan.pl -i -j -t` 432194 bytes
|
|
2024-08-12 12:58:50
|
`pingo -s4 -l` 432190 bytes
4 bytes less than brute forcing it and 18 bytes less than ECT
|
|
2024-08-12 12:58:59
|
what an interesting edge-case
|
|
|
|
JendaLinda
|
2024-08-12 07:06:57
|
Pingo seems to be borrowing jpeg implementation from ECT. The difference is that Pingo removes APP0/JFIF marker and ECT does not. If I manually remove APP0/JFIF from the ECT result, the files are identical.
|
|
2024-08-12 07:13:37
|
Perhaps brute force is not very efficient for non-photo content at q=95? jpegultrascan gains about 1% or less on my images.
|
|
|
|
CrushedAsian255
|
|
JendaLinda
Perhaps brute force is not very efficient for non-photo content at q=95? jpegultrascan gains about 1% or less on my images.
|
|
2024-08-12 07:36:45
|
perhaps jpeg is not very efficient for non-photo content at any quality, png is usually going to be better (and obviously jxl)
|
|
|
|
JendaLinda
|
2024-08-12 08:25:28
|
In this particular case, the source PNG was 1 MB (after oxipng). More than double the size of JPEG. If the application requires using legacy image formats, JPEG helps keeping the file size manageable.
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-12 11:19:11
|
but jpegultrascan is an exhaustive search of the best scan optimizatiln to take
so what ECT did better than JUS+IJG_jpegtran ? Better Huffman coding ?
|
|
|
|
A homosapien
|
2024-08-12 06:07:16
|
Yup better Huffman
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2024-08-12 07:30:45
|
<:FeelsReadingMan:808827102278451241>
|
|
|
gb82
|
2024-08-13 12:59:08
|
<@794205442175402004> We've been able to produce a stillimage tune (currently implemented as `--tune 4`) based on some research done through CID22. Let me know if any of this is of interest to Cloudinary - currently very much in development on our side so nothing final yet, but these early results are extremely promising & promise to yield good results beyond CID22 as far as I am aware
|
|
|
|
username
|
2024-08-14 05:36:05
|
https://discord.com/channels/794206087879852103/806898911091753051/1273149209113001986
|
|
|
username
https://discord.com/channels/794206087879852103/806898911091753051/1273149209113001986
|
|
2024-08-14 05:42:10
|
<@171626409398108170> `-mt -m 6 -af -sharp_yuv -alpha_filter best -metadata icc -progress -v` with cwebp, the only parameter I didn't include was `-q` since I don't really know the best quality value to use and it kinda depends on your use-case (late-ish edit: I would recommend messing around with `-q`). also all of these are documented here: https://developers.google.com/speed/webp/docs/cwebp
|
|
|
fOld^free
|
|
username
<@171626409398108170> `-mt -m 6 -af -sharp_yuv -alpha_filter best -metadata icc -progress -v` with cwebp, the only parameter I didn't include was `-q` since I don't really know the best quality value to use and it kinda depends on your use-case (late-ish edit: I would recommend messing around with `-q`). also all of these are documented here: https://developers.google.com/speed/webp/docs/cwebp
|
|
2024-08-14 05:42:47
|
amazing thanks
|
|
|
|
_wb_
|
|
gb82
<@794205442175402004> We've been able to produce a stillimage tune (currently implemented as `--tune 4`) based on some research done through CID22. Let me know if any of this is of interest to Cloudinary - currently very much in development on our side so nothing final yet, but these early results are extremely promising & promise to yield good results beyond CID22 as far as I am aware
|
|
2024-08-14 07:17:56
|
Looks interesting! Is this 4:2:0 only?
|
|
|
|
gb82
|
|
_wb_
Looks interesting! Is this 4:2:0 only?
|
|
2024-08-14 10:52:03
|
Yeah, unfortunately. Thatโs a big limitation weโre working with here
|
|
|
|
_wb_
|
2024-08-14 10:54:03
|
How deeply is svt hardcoded for 420? Could they be convinced to also support 444 or is this unlikely to happen?
|
|
2024-08-14 10:58:54
|
The annoying thing about 420 vs 444 is that in about 80-90% of the cases, for web quality, 420 is fine. But there is that 10-20% of images where the artifacts of subsampling are too strong even for web quality (at least for typical web quality; for the lowest end of web quality, 420 is kind of always ok).
|
|
|
|
CrushedAsian255
|
2024-08-14 10:59:50
|
is around `-d 2` to `-d 5` considered web-quality?
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
2024-08-14 11:00:49
|
Web quality is that bad?
|
|
|
|
_wb_
|
2024-08-14 11:02:49
|
I would say typical web quality is around d2, "social media quality" is around d2.5-d3, the higher end of web quality is around d1.5, the lowest end is around d3.5-4.
|
|
|
|
CrushedAsian255
|
2024-08-14 11:03:10
|
and "good quality" is d1 or less?
|
|
|
|
_wb_
|
2024-08-14 11:05:40
|
"camera quality" is around d0.5, I would say. For consumer-grade cameras or phone cameras I think d1 is ok, for "lossy raw" I would use d0.3 or better (maybe even d0.1)
|
|
|
|
gb82
|
|
_wb_
How deeply is svt hardcoded for 420? Could they be convinced to also support 444 or is this unlikely to happen?
|
|
2024-08-14 02:53:53
|
The mainline team is amenable to changes like that given sufficient interest. But currently mainline is outperformed by aomenc - our PSY fork is the leader. Obviously if mainline implements 444, we benefit too, but weโre maybe interested in implementing it ourselves
|
|
|
|
A homosapien
|
|
_wb_
How deeply is svt hardcoded for 420? Could they be convinced to also support 444 or is this unlikely to happen?
|
|
2024-08-14 07:04:34
|
It seems to be pretty deeply hard-coded, it's been 3 years since an issue has been opened and no progress has been made whatsoever. It's been marked as low priority and every year since then they say, "we don't have enough bandwidth" to work on the issue.
https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1433
|
|
2024-08-14 07:07:42
|
So I don't think 444 is coming anytime soon. ๐
|
|
|
LMP88959
|
2024-08-14 07:47:33
|
<@703028154431832094> what is it about the encoder architecture that makes it hard to add anything other than 4:2:0?
|
|
2024-08-14 07:48:06
|
i found it quite easy to have my encoder support 4:4:4, 4:2:2, and even 4:1:1
|
|
2024-08-14 07:48:35
|
i can understand having a bunch of hard coded / 2 being annoying
|
|
2024-08-14 07:48:46
|
or fixed sized loops
|
|
|
|
_wb_
|
2024-08-14 09:08:37
|
I can imagine that if you want to focus on speed, only dealing with one case is easier than dealing with more than one case.
|
|
|
|
LMP88959
|
2024-08-14 09:12:15
|
sure, but even in that case it would be a matter of replacing some hardcoded numbers with variables
|
|
2024-08-14 09:12:49
|
for 99% of things you dont need special cases for different chroma resolutions
|
|
2024-08-14 09:13:06
|
you just treat it as a block/image with a different size and stride
|
|
2024-08-14 09:13:54
|
and if you had functions that accepted block sizes/strides as arguments then it would be pretty simple to just pass in the right dimensions for the chroma version
|
|
|
|
gb82
|
|
LMP88959
<@703028154431832094> what is it about the encoder architecture that makes it hard to add anything other than 4:2:0?
|
|
2024-08-14 10:21:48
|
My personal skill issue of not having looked yet :P
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
A homosapien
Yup better Huffman
|
|
2024-08-15 06:33:15
|
just thought of this:
we could have a better compression using jpegultrascan, but could have better Huffman coding using ECT
But with some cases we can't (rn) have both
|
|
|
|
JendaLinda
|
2024-08-15 07:05:12
|
I found more jpegs, where jpegultrascan is exactly 4 bytes larger than Pingo or ECT (without APP0). These are exactly the 4 bytes that are wasted by IJG by using separate markers for quantiuzation tables.
|
|
2024-08-15 07:35:49
|
So if I manually concatenate the DQTs, I will get the same file size as the "better" Huffman.
|
|
2024-08-15 08:54:40
|
jpegultrascan could just concatenate the qunatization tables as the final step and compensate for the edge cases.
|
|
|
Kagamiin~ Saphri
|
|
Demiurge
I see palette images used a lot on commerce websites
|
|
2024-08-20 11:53:40
|
in terms of photographic content, other than for output devices with a limited color palette or for artistic purposes, I don't see a good reason to prefer palette reduction over frequency-domain compression
|
|
2024-08-20 11:58:06
|
sure, you won't get overshoot/ringing artifacts, but in return for that you'll get high-frequency noise and you'll still get loss of high frequency detail (especially if you're using error diffusion dithering)
|
|
|
|
JendaLinda
|
2024-08-21 11:09:46
|
I think this is practical only for small images. Those have small number of pixels and thus relatively low variety of colors.
Also useful if transparent background is required. Another option would be WebP.
|
|
|
|
DZgas ะ
|
2024-08-22 03:26:38
|
I found a bug on(possibly all existing) Nvidia graphics card AVC hardware encoder. Named by me "vector bounce" is when the real movement has stopped, by the vectors still make blocks movements. I noticed it on source twitch streams. It is most noticeable in the minecraft game.
|
|
2024-08-22 03:41:53
|
This also means that this problem should be on all streams, for everyone who uses Nvidia (i.e. everyone) for at least the last 6 years.
|
|
|
|
JendaLinda
|
2024-08-22 04:29:20
|
Isn't it some kind of low latency optimization?
|
|
|
|
DZgas ะ
|
|
JendaLinda
Isn't it some kind of low latency optimization?
|
|
2024-08-22 07:38:21
|
how can this be an optimization if it happens within 2-3 frames. And also it is always at the moment when the movement stops. Obviously, the NVenc codec just does not check for movement vector in some frames
"optimization" lol, No, it's broken, it shouldn't work like that.
|
|
|
|
JendaLinda
|
2024-08-22 07:42:04
|
I don't know, maybe it uses very small time frame to detect the movement and tries to predict it instead.
|
|
|
|
DZgas ะ
|
2024-08-22 07:42:19
|
Well, Nvidia hardware drivers are completely proprietary. can't do anything at all <:H264_AVC:805854162079842314>
|
|
2024-08-23 08:05:21
|
the "big slow" people who use nvidia for twitch streaming... they don't use Linux at all.
|
|
2024-08-23 08:07:44
|
and well, I can't check it myself, I don't have nvidia nvenc
|
|
|
|
Quackdoc
|
2024-08-23 09:19:32
|
yup, and they are quite good, it's a shame that NVK doesn't support this driver, if it did it would allow you to at run time swap between using nvidia's vulkan driver and NVK, and not sacrifice things like cuda and nvenc
|
|
|
RaveSteel
|
2024-08-23 05:38:14
|
The default nvidia userspace driver and firmware are still proprietary, only the kernel modules are open source
|
|
|
DZgas ะ
and well, I can't check it myself, I don't have nvidia nvenc
|
|
2024-08-23 05:38:39
|
x264 looks much better thank nvenc anyhow
|
|
|
|
DZgas ะ
|
|
RaveSteel
x264 looks much better thank nvenc anyhow
|
|
2024-08-23 05:41:59
|
x264 can search for block movement at the maximum block move vector limit according to the documentation (511.25 px). If, in essence, x264 in 2024 does almost the impossible - at a resolution like 640x360, avc Better HEVC in quality
|
|
2024-08-23 05:42:43
|
<:H264_AVC:805854162079842314> according to tests with identical encoding speed.
|
|