Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
JyrkiAlakuijala
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
61.
▲
by
JyrkiAlakuijala
3y ago
MozJPEG not being more precise than Jpegli at mid or lower qualities also matches with our experiments, both internal uncontrolled experiments and the rater study we published. There was an earlier version which was not very good at medium
62.
▲
by
JyrkiAlakuijala
3y ago
I got this wrong. We actually did the implementation in the libjxl/libjxl repo. There is no physical reuse of the jpeg xl code, however. It would have been clearer to make it its own repo.
63.
▲
by
JyrkiAlakuijala
3y ago
I think technically it is it's own github repo, just under libjxl user. I could be mistaken, I'm still learning git and GitHub.
64.
▲
by
JyrkiAlakuijala
3y ago
JPEGinen or JPEGli in Finnish
65.
▲
by
JyrkiAlakuijala
3y ago
Haha. Thank you!
66.
▲
by
JyrkiAlakuijala
3y ago
It's not a new JPEG++. It creates old JPEGs, fully 100% compatible. (Of course JXL is better still.)
67.
▲
by
JyrkiAlakuijala
3y ago
I don't see any downsides with Jpegli. Your Linux distro admin exchanges the lib for you, you never need to think about it, only get smaller and more beautiful files. If you use commercial software (Apple, Adobe, mobile phone cameras,
68.
▲
by
JyrkiAlakuijala
3y ago
It can be a question when your uncle's/daughter's/etc phone is full of photos and they asks for advice on how to make more space. It can be a question of if the photo fits as an email attachment etc. 'Zillions'
69.
▲
by
JyrkiAlakuijala
3y ago
I tried to reach to their devrel person Jen Simmons here: https://twitter.com/jyzg/status/1763141558042243470 I didn't follow up and I don't know if she read it or understood the proposal.
70.
▲
by
JyrkiAlakuijala
3y ago
The main idea why Ultra HDR is done like that is that the content creator (photographer) can control the local tone mapping. I think.
71.
▲
by
JyrkiAlakuijala
3y ago
What happens if you recompress them losslessly manually to JPEG XL?
72.
▲
by
JyrkiAlakuijala
3y ago
That would give additional savings.
73.
▲
by
JyrkiAlakuijala
3y ago
You can always use JPEG XL lossless JPEG1 recompression to get some savings in the high end quality, too — if you trust the quality decision heuristics in jpegli/guetzli/other jpeg encoder more than the JPEG XL encoder itself. We
74.
▲
by
JyrkiAlakuijala
3y ago
I decided to call it 10.5 bits based on rather fuzzy theoretical analysis and a small amount of practical experiments with using jpegli in HDR use where more bits is good to have. My thinking is that in the slowest smoothest gradients (wher
75.
▲
by
JyrkiAlakuijala
3y ago
Thank you for such a well-informed report! With guetzli I added manually overprovisioning for slow smooth gradients. If you have an example where guetzli is better with gradients you could post an issue with a sample image. That would help
76.
▲
by
JyrkiAlakuijala
3y ago
The output will be smaller after replacing libjpeg-turbo or mozjpeg with jpegli. You don't need to do any code changes.
77.
▲
by
JyrkiAlakuijala
3y ago
Moritz, the author of that improvement, implemented the same for jpegli. I believe the standard does not specify what the intermediate progressive renderings should look like. I developed that interpolation mechanism originally for Pik, and
78.
▲
by
JyrkiAlakuijala
3y ago
I believe that they should be roughly the same in a photography corpus density at quality 60. Consider filing an issue if some image is worse with jpegli.
79.
▲
by
JyrkiAlakuijala
3y ago
Brotli:11 gets within 0.6 % of LZMA density but decodes 3–5x faster.
80.
▲
by
JyrkiAlakuijala
3y ago
Ultra HDR can have two jpegs inside, one for the usual image and another for the gain-map. Hypothetically, both jpegs can be created with jpegli. Hypothetically, both Ultra HDR jpegs can be decoded with jpegli. In theory jpegli would remove
81.
▲
by
JyrkiAlakuijala
3y ago
Multi-corporate effort would likely need to start by first agreeing what is image quality. Image quality folks are more cautious and tradition-centric than codec devs, so quite an initial effort would be needed to use something as advanced
82.
▲
by
JyrkiAlakuijala
3y ago
Through non-standard API extensions you can provide a 16 bit data buffer to jpegli. The data is carefully encoded in the dct-coefficients. They are 12 bits so in some situations you can get even 12 bit precision. Quantization errors however
83.
▲
by
JyrkiAlakuijala
3y ago
I consider codec to mean a pair of encoder and decoder programs. I don't consider it to necessarily mean a new data format. One data format can be implemented by multiple codecs. Semantics and nomenclature within our field is likely un
84.
▲
by
JyrkiAlakuijala
3y ago
I thought clarity was more important. Otherwise it would be called ... Pumpernikkeli.
85.
▲
by
JyrkiAlakuijala
3y ago
It is approximately correct. The rendering is standards compliant without pixel perfection and most decoders make different compromises and render slightly different pixels.
86.
▲
by
JyrkiAlakuijala
3y ago
https://twitter.com/jyzg/status/1622890389068718080 Some earlier results. Perhaps these were with XYB color space, I don't remember ...
87.
▲
by
JyrkiAlakuijala
3y ago
Chrome advised and inspired this work in their position about JPEG XL. Here: https://www.mail-archive.com/blink-dev@chromium.org/msg04351... "can we optimize existing formats to meet any new use-cases, rather than
88.
▲
by
JyrkiAlakuijala
3y ago
No denoising or deartifacting was used. They are an option for future improvements at low quality JPEG decoding.
89.
▲
by
JyrkiAlakuijala
3y ago
From a purely theoretical viewpoint 10+ bits encoding will lead into slightly better results even if rendered using a traditional 8 bit decoder. One source of error has been removed from the pipeline.
90.
▲
by
JyrkiAlakuijala
3y ago
I designed WebP lossless and implemented the first encoder for it. Zoltan who did most of the implementation work for jpegli wrote the first decoder.
More ›