JPEG XL

I generally agree that PNG reconstruction should be an optional feature at best, only added upon request due to ii)

preflate does a great job but for non-zlib streams it seems to incur a few percents of overhead

and the png that you can optimize the best how it weights

versus the original png reconstructed

tell me file size with same file

that's an interesting take, let me check with pngcrush

do you are on windows

yes, though I have an access to linux (I has several boxes as well)

https://css-ig.net/pinga

and the 30MB image in question didn't recompress with pngcrush (no `--brute`)

can this reduce more than 1,6 mb a 4000x3000

so the biggest problem I see with this is that preflate *de*compression seems to be incredibly slow

I'll try that

with the slowest it has there

this is from a french developer

totally agreed, decompression was generally slower than compression

use only that image mai minase said

and slowest lossless drag and drop

and at the end check file size in bytes and copy there

is very fast

i'm trying also

30546.22 -> 20856.60 in about 1 minute (haven't accurately timed)

so it did

with slowest pingo/Pinga

jxl is 19,2 mb with included reconstruction data or only the bitstream

it seems that when I turn the lossy transform off (in settings) it only results in 29112.56 KB in 40s

so it clearly does some lossy (but visually imperceptible) transformation by default, which is not a fair comparison

any reason for just trying `-s 3`? 😛

it does png 16 bit vs 8 bit

so it deletes blue information

don't know

i could try

I think the file is in 8-bit RGB?

I can run a `-s 9` or something if I can get my hands on the PNG

https://discord.com/channels/794206087879852103/806898911091753051/866255686940491796

it doesn't compress good, worse than before

(pinga by the way seems to have a good interface, thank you for the pointer)

that was way more complicated than I thought it would be xD

well, it started compressing, so there's that - will take a while...

at some point I need to make a "webp mode" en/decoder

I'm out :P I'll let you know when I'm back

Lode did something like that with https://github.com/google/grittibanzli for deflate streams

thank's for the clarification -- I haven't been following preflate

I'm perfectly happy in either one winning 😄

I think it took 2-3 weeks from Lode to develop grittibanzli -- this technology is not amazingly difficult and we could afford to have a rethink and a new architecture there if we wanted to build something

I consider that all dense approaches need to do something similar to compression at decompression time, so none of it is going to be fast to decompress

usually one would have layering where there is an efficient algorithm actually compressing the data, and another representation on how to rebuild it into deflate (and png)

it might be possible to get faster-to-decompress solution by breaking the layering, but then it becomes a 100x more difficult problem -- it would include the problem of building a real new compression format and engine

likely the result still being slightly worse in compression to current approaches (but decompression possibly 3x faster)

Dense compression might be useful for compressing DNGs. Decoding time doesn't matter for such files.

Compressed to 16734613 bytes (3.167 bpp).

can somebody measure how fast decompression with preflate is? say in MP/s

in my latest log with the aforementioned 30MB image, 0.76 MP/s 😦

right, that's pretty slow

I think the slowest single-core pixel decoding in modular is still 3x that or so

6x likely on reasonable settings

practical image decompression speeds are around 20 megapixels/second and upwards

that's about 60-160 megabytes per second

if the speeds get to 100 megapixels/second range it may give additional system complexity reductions (such as less need for caching the next image, etc.) for viewers

I don't know, I believe it is in the 5-10 megapixels/second currently

there is a secret plan to make the decoding speed more similar to webp lossless

hasn't been prioritized yet, so somewhat unlikely to happen in 2021

perhaps something like 5 % more density than webp lossless, but 30 % slower

matching speed exactly would mean to build a specialized 8 bit decoding pipeline -- I think we'd rather keep things working with 16 bits per channel by default implementation and optimize that

this hasn't been discusses in detail in our team and is just wild guesses based on my experience with WebP lossless and JPEG XL lossless

one of the main differences is the context tree vs. context LUTs

it is possible to formulate the context trees in a way that they are representable by a LUT

that approach will solve the main problem

the entropy coding is very similar in both (context clustering)

I developed it first for WebP lossless, reused it in Brotli, from there to Brunsli, from there to Pik, and it found its way to JPEG XL

the performance characteristics are very similar for that

in WebP lossless we cannot have pixel based contexts, i.e., previous pixel doesn't affect the context of the next pixel -- only its x,y position, and the context is just explicitly written out in a subresolution image

it is more like defining blocks of entropy coding, just in 2d and having the ability to reuse entropy codes

in JPEG XL you can do that by building a very complex decision tree -- possibly at better resolutions it becomes excessively expensive to code

but currently we are not using fine resolutions for that in webp lossless either

(going down to 4x4 resolutions in that would improve webp density but that wouldn't work with the context tree -- then again, being able to have some of the context based on the previous pixels improves things a lot)

the predictors are similar -- jpeg xl predictors use a 5x5 neighbourhood, webp only 3x3 neighbourhood, so there webp is going to be worse in density but slightly faster

I noticed some simple structure png image, if I do some png palette optimize before jxl lossless, jxl can compress better.

but I still like use jxl lossy mode, except some not suitable DCT image, vardct d1.0, 0.8, 0.5(near-lossless) should very useful for every scenes, hope we can get another quality improve implement in this month. 🙂

(I noticed png pal8-Indexed grayscale sample have some strange situation.) > - 675,839 > 1.0_s7 389,969 > 1.0_s8 916,688

So 0.5 d good enough for animu?

Lee, could you post here a VarDCT example that demonstrates a weakness -- at lowest possible d-value?

like d0.5 or d0.8

also if you have any anecdotal observations on when it happens most or is most visible -- I'd love to learn about it

Thank you for your reply, <@!532010383041363969> 🙂 I'm nitpicking a little bit out there, but I still hope d0.5 quality can near webp near-lossless 60, d1.0 quality can near webp near-lossless 40, https://discord.com/channels/794206087879852103/803645746661425173/865301723015020544 For this issue sample, I can see some tiny ringing spread on red area, (for older jxl blue area also can see same issue, but newer jxl blue area is better for now), I guess red, blue, purple area and gradient area probably have chance happen this issue. ​ And I guess high contrast sharp edges probably implement strong reduce ringing features, can let quality better. For now d1.0 probably too risk for some complex structure anime image(color), For manga and comic image(black and white, sharp edges) d1.0 is good, (implement strong reduce ringing features, can let d1.0 quality better)

For now I think d0.5 is good enough, but some edge case probably give you some unexpected quality.

I tried to convert a svg to jxl. 0.5d vardct is bigger than lossless modular.

I think svg image not suitable lossy vardct mode, lossless modular is better.

They have lot of sharp edges. So I thought it would be better to use them for testing high contrast, sharper edges.

Probably comic or manga content is more suitable for vardct mode.

Someone should write an svg to jxl encoder that encodes shapes that can be represented as splines directly as splines and only leaves what cannot be done with splines for modular.

#easy

Yes yes yes !!!!!

#notreallybutwouldbecool

is there something what one cannot represent with splines?

vector stuff wise

i should look into what params they actually are capable of having

but i imagine one can just draw fat lines for filling stuff, and use straight lines for a lot of primitive shapes

except maybe text which would work better with patches ig

of note is that splines are additive, they cannot occlude stuff

in their initial design, they could (there were two options: additive, or alpha blending), but we decided to scrape it

can still do spline frames and then use patches I guess

They can occlude/overlap if they're black, it will just get clamped after decode

why they ended up non-occlusive? curious about tradeoffs what led to that

I don’t remember the details but I think it was a combination of speed and complexity

(the removal was two years ago already)

As long as the lines don't cross/overlap, it should be ok. In most svgs they would cross/overlap though, I suppose

https://www.reddit.com/r/compression/comments/ooh8cs/random_data_and_lossless_compression/

Again one of those...

compress dream topic 😛

https://twitter.com/bummzack/status/1417900398858416128

wait, what??

oh, so Bing does immediately index gists...

never thought about that possibility though

I want convert some bmp, webp to png(pixel) and compress to jxl, Could anyone can teach me which cli tool suitable for this job(windows)? ImageMagick-convert have some strange behavior... > 1. (original)=> png Chunks: iCCP > 2. (pingo webp)=> webp keep iCCP > 3. (ImageMagick-convert)=> png Chunks: bKGD, cHRM, iCCP, tEXt(3), zTXt

you could maybe use `convert` to convert to PPM, and pass that to JXL?

maybe with `-x icc_pathname=….icc` if the profile is not sRGB

it completely sidesteps the issue of metadata coming from ImageMagick

ok, I will try it, thank you very much 🙂

color management is vital, it’s how we ensure that `(255, 0, 0)` is the right shade of red

without it, all bets are off

Lee, right now I'm exploring changing adaptive quantization to have some more bits for higher chromacity values -- and I have promising initial results at least in butteraugli scores

Currently I'm having success with adding some more bits when B > 1.4 * Y, and for high X values in general

optimization is still running, but likely I'll send a PR today or in a few days

it is like 2.5 % reduction of maximum butteraugli error, and ~0.02 % on bpp * pnorm

it will improve quality in highly saturated blue and red parts -- naturally at the cost of quality elsewhere

Thank you for your work 🙂

No, Thank You for the guidance 😄

It does mean that green will suffer, yes?

We are indeed more sensitive from green compared to any other color.

it is a 3 % improvement and a 0.1 % loss -- i.e., better balance

all colors become the same when you zoom in enough

or at least more similar

Looks good at 100-200% ?

Zoom

Zooming more than 500 % is forbidden, doesn't exist

and zooming more than 200-300 % is dubious 🙂

more seriously, I believe that people do zoom when they care about the image quality the most

when their grandchild sends for example a group photo where they appear small, etc.

> zooming more than 200-300 % is dubious That’s an indirect argument for lowering quality on a HiDPI display 😉

yes I strongly believe that 8k monitors deserve less information per physical pixel

it can be delivered by lower quality and/or upsampling

where the best compromises are is still an unknown

my laptop has a 239 ppi, 400 nit display

I suspect that a large 8k monitor has roughly the same ppi

it would be delightful to have all images at d1 at this resolution

I’m a simple folk and my brain switches off when it sees a graph, but there may be not much (nothing?) to gain over certain density: https://observablehq.com/@eeeps/visual-acuity-and-device-pixel-ratio#cell-220

> my laptop (…) my monitor I guess, without considering using loupe (and forgetting proper UI-aided zooming in for web lightboxes in galleries etc.), there is some argument to be made about phones being different to watches, to laptops, to monitors, to tvs and to home and cinema projectors (viewing distance).

currently phones have more pixels-per-degree than computers I believe

but I believe it is quickly going where it is just 'enough' everywhere

I collect some grayscale comic sample from web, original file is jpg grayscale q90 444 4441x6213, but I convert to png grayscale can reduce all file size, > Image: 4441x6213 pixels | 8 bits/sample | Grayscale | 256 color(s) > jpg grayscale 228MB => png grayscale 145MB I try to using cjxl -d 1.0 -s 7 compress png grayscale comic file, but look like -d 1.0 ~ 1.6 on those distance will increase file size, How to correct lossy compress grayscale image file? could anyone can teach me about this? Also I find another grayscale comic sample, and have some strange behavior. > comic 20-gray 659KB > Input file: 20-gray.png | 675839 bytes > Image: 1115x1600 pixels | 8 bits/sample | Indexed grayscale | 256 color(s) jxl m lossless s9 531KB > -m -q 100 -s 9 -g 2 -E 3 -I 1 jxl vardct s7 390KB > -d 1.0 -s 7 jxl vardct s8 900KB(Issue) > -d 1.0 -s 8

indeed, sometimes increasing `-s` results in a larger file

-d 1.0 -s 7 vs. -d 1.0 -s 8 being a 390 kB vs. 900 kB difference is a bug

what goes wrong there

does it make resulting image much more quality

do we know what is the target intensity

or how the colorspace was defined

could be something exotic in an ICC profile (if any)

I'd like us to investigate in any case -- please file an issue

Grayscale itself can also be the issue, there can be a bug in a codepath specifically for grayscale

Grayscale comics might behave quite non-photographically, so lossless or semi-lossless could work a lot better than DCT, depending on the image contents

Especially if it's not a scan but a digital original

yes, an improvement possibility

vardct should be like an unsurprising work horse -- you get the work done without 2x file size surprise

perhaps 10% might be acceptable

maybe grayscale image can use lossy palette?

vardct doesn't have palettes

Nah, that's better for color

Vardct has patches though, it should do more with them when it makes sense

Patches can use palette or whatever

vardct still has several improvement possibilities

I wouldn't be surprised if a 10 % improvement was possible overall

I don't have copyright for this sample, but I think I can upload some sample in this channel?(for private use)

Yes, that should be fair use

comic grayscale sample collect from anime discuss site.

001

002

003 // grayscale-png and grayscale-jpg is same image, grayscale-jpg convert to grayscale-png.

ok

one good smoke test is to take a screenshot of the image when displayed 1:1

then compress the screenshot with vardct d1 -s7 and -s8

that gets rid of some ICC or gamma issues as well as possibly 'grayscaleness', too

I tried another png and jpg grayscale comic sample in the last month, but I don't get issue on cjxl d 1.0 s 7, those image can correct reduce size, maybe some specific grayscale pattern will happen some strange behavior ?

I did reduce masking recently and that would increase slightly filesizes os s8 and s9

(a change in butteraugli)

Look like avifenc can correct reduce grayscale-jpg and grayscale-png file size for this sample, I guess maybe jxl vardct have some grayscale issue? > --min 24 --max 26 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=24 -a color:enable-chroma-deltaq=1 > --min 20 --max 22 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=20 -a color:enable-chroma-deltaq=1 > // grayscale-png and grayscale-jpg is same image, grayscale-jpg convert to grayscale-png. > // avifenc > grayscale-jpg-7,449,514 => avif-q24-26-3,602,081 > grayscale-jpg-7,449,514 => avif-q20-22-4,030,022 > grayscale-png-4,553,432 => avif-q24-26-3,602,081

> // cjxl -d 1 -s 7 > grayscale-jpg-7,449,514 => jxl-j-d1.0-s7-6,365,980 > grayscale-png-4,553,432 => jxl-d1.0-s7-6,365,983

> // cjxl -d 2 -s 7 > grayscale-jpg-7,449,514 => jxl-j-d2.0-s7-4,563,677 > grayscale-png-4,553,432 => jxl-d2.0-s7-4,563,680

WebP had a bug for grayscale images where they tooks about 70 % more bytes than necessary -- there an failed and overly optimistic early-out mechanism resulted gray scale to be changed into color by its color cross-decorrelation (similar to CfL) techniques

I fixed that somewhere between 2015-2017 or so

That was also the main secret why FLIF was so much better than WebP lossless at that time -- many of the test corpora FLIF used were gray scale

I hope we don't have the same mistake again 🙂

https://discord.com/channels/794206087879852103/803645746661425173/843757478603784222

what is a cbz file

what is a comic

i read that is a group of images

but can't jxl should do that

what is the need of such format?

i want to make a images pdf

https://en.wikipedia.org/wiki/Comic_book_archive

It's basically just a zip file containing images

I would assume that if a viewer supports jxl and it supports cbz, it will also support cbz containing jxl (instead of png/jpg)

Kde okular w/ qt plugin supports jxl images in cbz

Seems like YACReader too

Well, but this shouldn't be necessary since JXL supports multiple pages and browsers/viewers/Cloudinary already offer functions to view a specific page or go forward/backwards. <@!794205442175402004> Am I right? ;P

uh, at the moment not really 🙂

could make that work though, just use max duration frames and call it pages

but browsers/viewers typically don't have buttons to go to next/previous frames in animations

XnView and IrfanView do have those buttons (I don't have other viewers but it shouldn't be too uncommon). Browsers show navigation buttons for PDFs, so why shouldn't they just reuse them when a multipage JXL is opened.

yes, it makes sense to me — but at the moment they'll just show the first page and billions of years later they will show the second page.

But I thought it was possible to do true multipage files without animation duration?

no, we don't have that concept - but we could have a convention "max frame duration means multipage"

the max duration of a frame that can be signaled is 146 billion years

I think it's safe to assume that such a convention wouldn't limit the possibilities of actual animations, and if a viewer doesn't know about the convention the worst that will happen is that it will automatically go to the next page after 146 billion years

👌

2 bytes in the global header and 4 bytes per frame (duration is signaled per frame, expressed in ticks of a duration specified globally)

actually I miscalculated, max frame duration is only 139000 years

1024 seconds is the max tick duration, 2^32 is the max number of ticks per frame

merely 139000 years :<

max fps is 2^30, but that's the minimum tick duration (1/2^30 seconds), hence my confusion

but if it's en route to the blackhole? :p

hm, that makes it tricky to represent multiple animated pages

like a Harry Potter newspaper or something like that

right

let's say the tick duration can be whatever

but if the frame duration is 2^32 ticks, it's considered a new page

if you want to do 30 fps animation on your Harry Potter pages, that's only 4.5 years per page then

still probably enough in practice to not really have accidental page flips 🙂

one thing that cannot be done this way though is looping animation on a page

Cbz is simple and good enough.

It's a bit overkill imo, to use general-purpose compression on top of special-purpose compression

I mean it works (zip will just fallback to no-op compression and be a glorified tar)

and it has the advantage of being easy to use with existing tools (I mean extracting or inserting pages, etc)

but imo it would be nice if it would also work in browsers, basically as a PDF alternative when you don't need vector stuff

(for comics or photo series)

i doubt controls for flipping pages are going to be added anytime soon

to browsers i mean

meanwhile, custom js viewers or PDFs work good enough i guess

i guess - at least when PDF supports jxl 🙂

I like to have multilayered jxl on comics / Mangas. One language per layer!

That's an interesting idea

The layers would have to be invisible frames, otherwise a viewer would just show all languages on top of eachother

(or they could be visible frames but underneath the comics themselves, so you see blank comics in a dumb viewer)

(or probably best to have one language above the comic and the rest underneath, so you see a default language by default)

Layers can have names, so the best way to do this would be to come up with a naming convention, and then have a viewer that does smart things when it sees layers with such names.

https://www.reddit.com/r/programming/comments/osj2i8/for_developers_apples_safari_is_crap_and_outdated/

> The HandBrake Team is pleased to announce the release of HandBrake 1.4.0. > > This is a significant feature release that focuses on: > - Further refining the HandBrake engine to support native 10 and 12-bit encodes, including HDR10 metadata passthru. https://handbrake.fr/news.php

noice

https://handbrake.fr/docs/en/latest/technical/hdr10.html > For x265 encodings, HandBrake will also set the hdr-opt flag for you. I don’t know what the hdr-opt flag does but that sounds nice too

Still not SVT-AV1 support in Handbrake SMH.

https://www.reddit.com/r/programming/comments/osj2i8/comment/h6st21y/

Does anyone know a good application for comparing images?

Does GIMP on Linux support jpeg-xl?

Yes with plugin

But it's buggy right now

k thanks

Yes, but lossless JXL recompression is currently borked with it.

Mostly due to the container format.

👍

how would gimp do lossless jxl recompression? unless you open a jpeg and don't modify it at all, but in that case you don't need gimp

The problem is actually decoding the jxl recompressed jpg.

The plugin can't actually open them.

<:WTF:805391680538148936>

hope they get that fixed soon

don’t know if you’d consider it “good” but we have one in the jxl repo

needs building with `cmake -DJPEGXL_ENABLE_VIEWERS=YES`, then it’s `tools/comparison_viewer/compare_images <left> <right> [<optional middle>]` (that is, it supports 3-way comparisons)

you can move the line with the mouse, or use the left/up/right arrow keys to show just one of the images at a time

I'll try it

oh this is great

My d0.5 jxl is much smaller than my q95 mozjpeg, and has way less artefacting :)

less ringing https://github.com/libjxl/libjxl/pull/403

d16 before

d16 after

(((of course I hope that no one actually compresses at d16 ever)))

those images are 0.19 and 0.20 bpp

I wanted to improve a bit on this since this is one of the two cases where JPEG XL performs worse than AVIF

You can choose this optim only for high distance, an old optim for low distance?

it is always on by default

I have made it such that it ramps down for low distances and barely changes things there

.... I have more ideas on how to reduce ringing, next in line would be small ringing artefacts that are very close to the edge

madonna

I observe sometimes there is a spiky pixel pointing out close to an edge and it looks weird

super

but it happens rarely -- so it is possible to handle by adaptive quantization if I can figure out how to detect it

thank you 😄

should i execute that command

for %i in (D:\BDS\jpg\*.jpg) do cjxl -j -s 2 -d 1.238 --use_new_heuristics --gaborish==0 --epf=2 --patches=0 --dots=1 %i %i.jxl

or wait for better automatic quality conversion tool?

AVIF (10-bit 8,461)

what is the file size of both in bytes?

640×400 pixels × 0.2 bpp ≈ 6.4 kB

AVIF (10-bit 5,661)

Some of the image is no longer readable, but AVIF is still strong in this sort of thing So the gap is still quite large, but the improvement in JXL ringing is pretty noticeable

I think for an image like this we need to have the equivalent of palette blocks, i.e. do the hard edge regions with no-dct techniques. I am on holidays atm but afterwards I might give it a try to extend Patches into extracting regions where dct is a bad idea and doing something modular instead there (delta palette, or quantize colors and subtract).

only i i think that the jxl image is perfectly legible in 80% of image?

I don't expect to fully catch up for this kind of content against speed 0 AVIF

perhaps if they are run with similar encoding speeds

perhaps a 2x upsampling might make jpeg xl more competitive

The palette codes we have deal with pixels -- VarDCT and AVIF deal with pretty large chunks of the image and approximate wildly there

I don't think palette will bring us there

layers and 2x subresolution might help a bit

...

classic palette coding tends to operate in 3-4 bpp

with delta palette we can drop it to 2 bpp

when we approximate a lot, we can go to 1 bpp -- but it will usually be ugly

... our delta palette defaults currently to about 2 bpp for a large photographic corpus with lots of visual activity

the AVIF image looks palettized

AVIF (10-bit 6,462) - Speed 6 I haven't measured the exact encoding speed, but the latest versions of Avifenc (Aom) have got a significant improvement in speed, even on slower modes

Thank you Scope!

looks like AVIF polygonalizes some of the balls and letters and others it pixelizes

the polygonalization may be an emerging thing from the directional prediction

I'm not sure how the pixelization is modeled -- is it through the 8-color palette transform or something else

Why not release jxl codec on windows store? Jxl codec on windows store improves adoption. Waiting for Microsoft will take more time.

windows 11 is out in a month

in october surely out of stable

september first LICENSED GPU AND MOTHERBOARD

or at least driver in november/october

jpeg xl is a software

and should be treated as a software

if things were simple as this

i'm tired

I do not think that the Windows store will solve the problem of widespread distribution, moreover, at the moment it only accepts special UWP applications and for publishing and updates will require additional free hands of those who are familiar with the Windows store Also it makes no sense to release console coders in the store (besides they are not UWP), mass Windows users rarely use console applications, mostly they need support in popular GUI applications, also to create a more trusted release it is needed publication from Google itself as a company (not sure it will be easy) otherwise it will not differ from various third party, including junk/advertising and other applications which also happen to be in the store So, maintaining WIC decoder release on libjxl Github will be enough as an official decoder, until Microsoft releases its own version as it did with WebP and AVIF

Microsoft should release it Not Google

https://twitter.com/jonsneyers/status/1423037459009613826?s=19

I'm talking about releasing something like avif in windows store. Not the command line cjxl / djxl.

> maintaining WIC decoder release on libjxl Github will be enough as an official decoder Yep. As I mentioned before, the WIC codec for WebP became available very early in the Google WebP repo, and that was a good thing.

No install for all Windows 11 users at least in the Second update

It hasnt sense to make it available for only nerd people

Or only for browser

nek isn't spam. i should think it should be installed for all.

and all social should make it possible only to save jxl, as png you can save only png

why complicate things for me to make simpler for facebook mobile users

nek; facebook mobile users don't care about this program

Facebook mobile users don't care about format and saving images. They simply view images in the app.

i personally save images both on pc and mobile

and i don't want 2 extras compression

i want support in android 12 and windows 11

i'm requesting too much

you don't want those things?

you want to remain with jpg?

Personally, I already have jxl support on windows 10 with my usually used viewing apps: qimgv and yacreader. These apps will work fine on windows 11 as well. For android 10 I can wait.

Why people should Not have jxl is there a reason to not enable it

how do you read jlx with qimgv? i add qjpegxl.dll, but it not works

qimgv is built with msys2/mingw64, so qt plugins should also be built with it. Dll's from novomesk are built with the MS compiler, they work well with nomacs because it is built with the MS compiler too. So I had to build qt plugins myself with msys2/mingw64.

I ended up having to figure out how to build all these things with msys2/mingw64: qimgv, yacreader, and the qt plugins for avif and jxl. 😆

Ah yes the custom build is here 🙂 https://eddiezato.github.io/bin/

All of the scripts I wrote are here. If anyone finds it useful. https://github.com/eddiezato/builds

My compatibility jxl software is even bigger <:Hypers:808826266060193874> https://docs.google.com/spreadsheets/d/1bTeraUXIl-nGM8c53IdURxmJbabX9eXqPZwVSynoH9U

The official yacreader is also built with the MS compiler, so novomesk's appveyor dlls will work fine.

https://github.com/d2phap/ImageGlass/pull/1121

I don't see anything related to jxl

is on topic whatever else

Some images are 7000 bpp

(if you have a 1x1 pixel image with a color profile, it's easy to even go over 9000 bpp)

https://c.tenor.com/jkg42Y08bNAAAAAM/its-over9000-vegeta.gif

Anyone know any Linux image viewers with JPEG XL support on Debian Unstable? Or do I need to package libjxl for Debian instead to get support in the gpixbuf viewers?

You can compile for gpix buf

## Build + plugin ```bash sudo apt install -y cmake pkg-config libbrotli-dev libgif-dev libjpeg-dev libopenexr-dev libpng-dev libwebp-dev git libgdk-pixbuf2.0-dev clang-11 xdg-utils export CC=clang-11 CXX=clang++-11 git clone https://github.com/libjxl/libjxl.git --recursive cd libjxl mkdir build cd build cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_PLUGINS=ON .. cmake --build . -- -j$(nproc) sudo cmake --install . cd .. sudo xdg-mime install --novendor plugins/mime/image-jxl.xml sudo /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders --update-cache sudo update-desktop-database ```

eog will work

Thanks, I'll compile it up then.

Mostly seems to work, but the mime type doesn't seem to have been set up.

Ah, do I need to add image/jxl to eog's desktop file?

Yep. That seemed to fix it.

Added the mime type to eog's desktop file and ran `sudo update-desktop-database`

Need gimp 3 compatible jxl plugin 🥲

FWIW we do have the infrastructure in place for building debian packages, but my attempts to get some debian maintainers to consider libjxl for inclusion haven't gotten anywhere so far...

TBF, it might improve when bullseye ships on the 18th.

ehhhh, I'm pretty sure I wrote them in January or so 😛 but maybe...

As unstable has been in various stages of freeze for the past few months.

if you know people you can ping...

ah, it was in April

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948862

Yeah, unstable has been in soft freeze from Febuary.

https://release.debian.org/

So they wouldn't add any new packages.

fair enough

so you're saying next week is a good time to poke that thread

If you give it a week or two from the release of bullseye they might be a bit more responsive, as for the first week they will be flooded with updating all of the packages that have had updates in the past 6 months.

But yeah, after the new release of stable they will be much more willing to accept new packages.

https://redd.it/p2hkuz Noice

That guy makes good plugins. Probably it will work fine :p

You could download gimp 2.99 chaoutic aur repo. Gimp 2.99 doesn't crash. I have been using it for several months.

http://0x0.st/-J4e.jpg

I think it's better to use quality than distance parameter. People will get confused on seeing distance

https://twitter.com/arxiv/status/1426151552381702150

Is there a good way to detect is image grayscale/monochrome?

Only way I can imagine is checking all pixels and stopping when one pixel has `!(R==G==B)`

But it won't work for monochrome images? I tried to do this using the chroma threshold test on each pixel of resized image, but it doesn't work with monochrome images either or gives a lot of false-positives 😦

Oh, nvm, first google link, with the right query https://stackoverflow.com/questions/20068945/detect-if-image-is-color-grayscale-or-black-and-white-with-python-pil

I think there we should change -- quality value 30 in photoshop means 75 in libjpeg (or something similar)

distance values as multiples of 'just-noticeable-difference' values make more sense

even some professionals get trapped by the quality and many think that libjpeg quality 30 images are around in the internet because image processing guides (for photoshop) recommend it for the internet

as a consequence a huge amount of confusion in quality values

also, every new compressor inflates the quality values a little

webp quality 95 is perhaps quality 90 in libjpeg etc.

How input non-unicode support windows file path to cjxl? I using windows code page 950, If I pass japanese path(code page 932) to cjxl will happen some issue, this issue also happen some cli tools, and I guess windows 10 still don't have native utf-8 support. > // windows-code page 950 > cjxl -d 1 -e 7 D:\\テスト\\テスト-01.png

I thought Windows 10 used UTF-32 internally.

UTF-16

but there is now also beta support for making the local codepage (“ANSI”) UTF-8

in fact, as a possible alternative to the Unicode Win32 APIs (the functions ending with W), Microsoft now suggests using the old “ANSI” functions (those ending with A) + adding an app manifest to make the ANSI codepage UTF-8

https://docs.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

I used to have problems passing filenames with diacritics to ImageMagick before changing that setting, but now it works

(and yes, UTF-16 is the worst of both worlds, having the simultaneous drawbacks of UTF-8 and UTF-32 and the advantages of neither)

although in truth, thinking about it, there isn’t that much advantage to UTF-32 either

code points are a constant number of code units, but grapheme clusters can consist of several code points anyway

really, UTF-8 is probably all we should be using

Yep

I wonder if it would make sense to define a UTF-4 that is based on a smaller alphabet but still has the most common ascii symbols, like frequent lowercase latin letters and space, in a 4 bit direct code and uses an 8 bit code for the rarer ascii symbols. So you can often have two letters per byte...

As it is now, a lot of the utf-8 single-byte codes are wasted on stuff like control characters etc

I don't think that ASCII-incompatible encoding would go anywhere

For byte-based compression it is probably nice if common combinations of frequent letters become a single byte that way (though there would be aligned and non-aligned occurrences so maybe not)

I believe that just doing generic compression would bring better results

Yes, of course in practice too much stuff needs to be ascii-compatible

also, 4 bits is merely 0-15 values, what you'd even fit there

not to mention reserving at least one for escape

http://pi.math.cornell.edu/~mec/2003-2004/cryptography/subs/frequencies.html

etaionsrhd, space, and the remaining are escape plus 2 bits?

such coding would inevitably introduce complications for non-english users, because we all know that others like putting limitations on resulting byte lengths, and not runes

i don't really like such bias

Ascii is very biased towards english / latin alphabet languages without diacritics

that's like avif liking vector-ish stuff - not healthy

yeah, but the world has already mostly settled on incorporating ascii (not necessarily english) for encoding of a lot of meta info, so there's advantages beyond just english, even if this was result of history and is pretty backwards

that's why using utf-16 in html for japanese sites and such don't bring such a large advantage as one thing it would

it may seem like stagnation, suboptimal for some languages, and biased, but it's kinda thing what was worked around so much that at this point re-introducing more complexity by defining something else would be net degradation of utility

also it's not even that bad for latin-based langs, and there are quite a lot of them, outside of english

The cost of having multiple possible encodes generally outweighs the cost of UTF-8 being non-optimal for certain use cases.

<@!604964375924834314>, Thank you for your reply 🙂 Look like utf-8 code page manifest requirement Windows 10 1903, I using Windows 10 1809 right now, I will test this feature after update windows version. If I want use utf-8 code page fusion manifest feature, I need create a cjxl.manifest.xml and pass mt.exe -manifest "D:\\テスト\\cjxl.exe.manifest" -outputresource:"D:\\テスト\\cjxl.exe";1 this feature should work very well with this setting? 1. create a cjxl.exe.manifest <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1"> <assemblyIdentity type="win32" name="..." version="6.0.0.0"/> <application> <windowsSettings> <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage> </windowsSettings> </application> </assembly> 2. cjxl.exe and cjxl.exe.manifest in same path 3. mt.exe -manifest "D:\\テスト\\cjxl.exe.manifest" -outputresource:"D:\\テスト\\cjxl.exe";1 4. cjxl -d 1 -e 7 "D:\\テスト\\テスト-01.png"

I try windows 10 old UTF-8 codepage feature before, but that feature happen a lot of issue. 😢 > (previously was only available in control panel region-administrative as a Beta feature and affected all processes) > https://tedwvc.wordpress.com/2019/09/09/new-utf-8-features-in-windows-10-1903/

I recommend libvips, ImageMagick gamma issue is very annoying. > https://github.com/libvips/libvips

Brotli compression in utf-8 mode makes utf-8 more tolerable for other languages

When thinking more about image quality I believe that Photoshop is doing it better than libjpeg. Quality 5 photoshop should not be available to the users. The range available in a GUI should only include values that are actually useful (like done in Photoshop). I believe normal photoshop quality settings are libjpeg-like-quality 85-100 [photoshop quality 0..12], and then there is special casing for the web use case for roughly libjpeg-like-quality 60-100 [photoshop save-for-web-quality 10..100].

Making qualities less than 60 available is like leaving loaded shotguns lying around in a community center

> https://docs.microsoft.com/en-us/cpp/build/how-to-embed-a-manifest-inside-a-c-cpp-application?view=msvc-160 Finally I got it, how to use manifest feature...

does it seem to solve the problem?

I haven't test right now, because I not ready update to Windows 10 1903, but I want make clear this feature how to work, I only need create a cjxl.exe.manifest and pass mt.exe -manifest "D:\\テスト\\cjxl.exe.manifest" -outputresource:"D:\\テスト\\cjxl.exe";1 windows will pass utf-8 path to cjxl?

I still have confused about windows manifest setting.

I personally use the "windows terminal". There is no problem at all.

``` Microsoft Windows [Version 10.0.19043.1165] (c) Microsoft Corporation. All rights reserved. D:\Downloads>cjxl "テスト.jpg" "テスト.jxl" JPEG XL encoder v0.6.0 2ebc6ec [SSE4] Read 1920x1080 image, 270.8 MP/s Encoding [Container | JPEG, lossless transcode, squirrel | JPEG reconstruction data | 94-byte Exif], 4 threads. Compressed to 267431 bytes (1.032 bpp). 1920 x 1080, 41.22 MP/s [41.22, 41.22], 1 reps, 4 threads. Including container: 268060 bytes (1.034 bpp). ```

Look like microsoft want user use newer windows. 😢 > Note: Windows Terminal requires Windows 10 1903 (build 18362) or later

But I think I find some dirty method to handle japanese path for older windows.😛

8.3 names?

yes, 8.3 filename not a good method, but can avoid this issue.

use windows terminal and utf-8 manifest is better, but requires newer windows 10 version.

<@!604964375924834314> sorry for ping, I got some issues, I already update to windows 10 2004, but I can't find mt.exe, maybe I missing some setting? Could you teach me about manifest setting? And if I using 8.3 filename on windows 10 ntfs, I will get some trouble? > mt.exe -manifest "C:\Users\jpegxl_v0.5\cjxl.exe.manifest" -outputresource:"C:\Users\jpegxl_v0.5\cjxl.exe";#1

apparently, it’s from the Windows SDK, so you might have to install that

and as far as I know, no issue with using 8.3 names

(in fact I had to explicitly disable the generation of 8.3 names for a drive because of the performance degradation that it caused)

yes, I find some 8.3 filename performance issue, but windows terminal and utf-8 manifest need other depend component, I don't want my jxl tools have much depend, still can't find a perfect method to handle this.

why microsoft does not implement a better utf-8 support.😢

spider-mario, Thank you for your help 🙂

does anyone who's used hugo (static site generator, <https://gohugo.io/>) know if there's a plugin or something that does really good image optimization? it has some support built in (https://gohugo.io/content-management/image-processing/), but it seems like you basically have to manually ask for all the variants. i'd really like if it would automatically create all the different formats at different pixel densities, and make a `<picture>` element with them all.

so they might be waiting for a native go avif encoder <:monkaMega:809252622900789269>

I use Gatsbyjs. It's easy to configure image types. (Has avif support)

native go avif encoder is unlikely anytime soon

yeah, i've heard of gatsby. the person i'm helping is using hugo and in general i'd like everyone to get good images without a lot of trouble.

or.. probably ever actually tbh

yeah that seems like it'd be a waste of time

decoder could b useful but im doubtful even that would happen soon

I used hugo, but I don't know of any such thing 😛

https://news.ycombinator.com/item?id=28215939

How difficult is it to implement jxl's photon noise synthesis on a GPU? Photon noise removes banding in blurry areas and blends well to the image compared to KDE's noise synthesis.

what app is that

Telegram / nekogram

lol got reposted

Arun, just wait a while, I can probably give you a patch for high quality blur implementation in sacrifice of some performance

Oh you're here. Nice

to answer that question, the hardest part is likely the RNG... if you are OK with slightly less good-looking noise patterns, it should be dead simple 😛

(more precisely, slightly more repetitive)

It may sound stupid but is it possible to use a pre-generated noise PNG? Windows 7 uses a png to simulate glassy effect. I even tried replacing glassy png with noisy one in windows7 msstyles to simulate a frosty effect.

The problem is not the noise

The problem is how you apply to it

I see

With sRGB framebuffer 1+1 may be 2 but 10+1 may be 10.5

professional photographers use a tiled texture for adding film grain -- that seems to me like something a GPU is able to compute if RND is too complicated -- could also be that some mixture of RND and texture tile could work (again if RND is too difficult)

I don't think see why sufficient RND would be difficult though, but I'm not a GPU expert

The rng we are using is sequential in 256*256 tiles which is not GPU ideal IIRC, you'd rather want one that is mostly pixel-independent

it's not the rng, it's the blending

when srgb blending is disabled (noise values are added as-is) it looks like this https://discord.com/channels/794206087879852103/806898911091753051/878278827695038484

ah sure, but colorspace conversions are as GPU friendly as anything gets I think 🙂

toggling sRGB conversion requires at least one barrier on Vulkan, and on OpenGL it's nearly impossible

well idk, maybe one can just use glDisable(GL_FRAMEBUFFER_SRGB) but it's quite tricky to get right

just wondering, is JXL's noise added in linear space or perceptual space?

perceptual 🙂

good, sounds like I can make an easy fix for the noise

tbh I have no idea about opengl, I was mostly speaking about GPGPU

(I only ever wrote CUDA code for the GPU)

colorspaces conversions involve trascedentals so they can easily become very slow

for this reason the gamma curve is often handled with a dedicated piece of hardware in the texture sampler, and that limits the API a lot

for sRGB the only thing you really need is a decently-precise pow function, you can easily get one of those in ~10-20 flops or so (especially if you stick to 2.4 as your exponent)

and, if you just want to be roughly perceptual... you can cheat and change the transfer function to something like `(x+a)^3-x^3` 😄

Hello, do you know if there is a lower limit to bits per channel? I have a bunch of 16bit images (ARGB1555) and I wondered if they could be stored loselessly without conversion to ARGB8888

Jxl will end up doing channel palette

You have to input the image as argb8888, because there is no input format for argb1555