Nice job!!!
I am trying to convert a 16bit tiff to jpegli, and I got the warning "The picture will be converted to RGB with 8bits per component", is it possible to convert it to 10bit or above?
Thank you very much!
jpegli - new and clever jpeg encoder
Moderators: helmut, XnTriq, xnview, Dreamer
Re: jpegli - new and clever jpeg encoder
no only 8bitsbarrykwok wrote: Thu Apr 11, 2024 8:08 am Nice job!!!
I am trying to convert a 16bit tiff to jpegli, and I got the warning "The picture will be converted to RGB with 8bits per component", is it possible to convert it to 10bit or above?
Thank you very much!
Pierre.
Re: jpegli - new and clever jpeg encoder
I'm surprised that there is next to no apparent color smearing with the XYB output, which by default has chroma subsampling. I picked the nastiest blue and red combination I could find, and I only saw a faint white glow. I wouldn't use this format because it relies on ICC to fix up the colors afterwards. This requires a recent version of an ICC engine. Old software like Photoshop CS2 or old FastStone show wrong colors. When it works, ICC (any) is sometimes an order of magitude slower to load. Irfan is very slow.
The benefit of this encoder is supposedly extra bit depth because it does intermediate calculations at a higher precision. So it an encode artifical gradients better. However, I don't see it. A 16-bit input gradient has significant banding. The cjpegli.exe doesn't seem to apply any dithering (jpeg output is very small). Dithered 8-bit input has the same overall banding in cjpegLI, Irfan and Photoshop. So saving from 16-bit directly seems to be a bad idea.
They have an EXE encoder on Git, which can be used from an audio frontend. In only supports PNG and Linux PNM image formats for input. No BMP, TGA or EXR.
gradient_16.png gradient_16_LI.jpg gradient_8_dither_photoshop.jpg gradient_8_dither_LI.jpg gradient_8_dither_irfan.jpg 512_16_srgb_LI.jpg 512_16_xyb_ss_LI.jpg 512_16_horrible_chromass_jpegturbo.jpg
The benefit of this encoder is supposedly extra bit depth because it does intermediate calculations at a higher precision. So it an encode artifical gradients better. However, I don't see it. A 16-bit input gradient has significant banding. The cjpegli.exe doesn't seem to apply any dithering (jpeg output is very small). Dithered 8-bit input has the same overall banding in cjpegLI, Irfan and Photoshop. So saving from 16-bit directly seems to be a bad idea.
They have an EXE encoder on Git, which can be used from an audio frontend. In only supports PNG and Linux PNM image formats for input. No BMP, TGA or EXR.
gradient_16.png gradient_16_LI.jpg gradient_8_dither_photoshop.jpg gradient_8_dither_LI.jpg gradient_8_dither_irfan.jpg 512_16_srgb_LI.jpg 512_16_xyb_ss_LI.jpg 512_16_horrible_chromass_jpegturbo.jpg
Re: jpegli - new and clever jpeg encoder
I'm looking forward to fixing this issue.xnview wrote: Wed Apr 10, 2024 7:01 amright, i'll update itKadet wrote: Tue Apr 09, 2024 8:13 pm I did one more test — In XnView I turned off the Progressive option, which should result in a file that is a few kilos larger. It wasn't bigger. Therefore, I conclude that the selected Progressive option does not translate into jpegli parameters in XnView.
In cjpegli this is the "-p N" parameter N = 0..2.
When I added "-p 0" to cjpegli, the file grew to the size produced by XnView,
Pierre, can you release version 1.7.2 or beta?
Thank you.
Re: jpegli - new and clever jpeg encoder
Progressive work OK like in cjpegli.
XYB work OK like in cjpegli.
XYB work OK like in cjpegli.
Re: jpegli - new and clever jpeg encoder
Having trouble finding a binary. Gone? Need Ubuntu binary for another project. Thxpokuly wrote: Sat Mar 16, 2024 2:29 pm In libjxl v0.10.2 is a cjpegli.exe that produces 100% valid jpg files.
https://github.com/libjxl/libjxl/releases/tag/v0.10.2