JPEG XL

on discord preview? it's only a basic 8bits, smooth with my 6bit+frc ips

no no, on the original

I spent too much time doing image compression

now I see artefacts everywhere

Ok it's not perfect, i see banding on my 8bits ips smartphone. ^^ photoshop is a bad gradient maker 😄

It's good here.

nah, still has banding

I see aliasing more than anything

It's a good intensity according to the luminance.

great to hear, thanks

size of noise is fixed? if i have a high resolution, noise become "smaller" than the same resize picture?

yes, it’s finer, however the calculation I am using for the intensity vs. brightness relationship should scale the intensity accordingly

so if displayed at the same physical size, the resampled image should look like it has the same amount if everything goes correctly

Same amount but "bigger" grain size?

yep, for the image with fewer pixels

Ok, and you have several noise levels, or only one?

the interface I’m thinking of is something like `--photon_noise=ISO51200`

assuming a 36mm×24mm sensor

Ok cool, so we can choose it with an encoder option? 🙂

I think that would be the plan 🙂

And try to detect the picture amond of noise? picture_noise = 1600 if d<=1 --photon_noise=0 else if d<=3 --photon_noise = picture_noise/2 else --photon_noise = picture_noise An algo like that to equibrate with the denoising level of the encoder? 😄

that sounds sensible

detecting the amount in the image may be tricky but we’ll see 😁

let’s maybe start with manual settings and go from there

You should mesure the surface of the picture with a very high frequency, more surface seem equal to high noise. An idea like that? (i don't know if it's easy 😄

Or searching in av1 codec to find how they do that 😄

`The proposed film grain modeling and synthesis framework is shown in Fig. 1. The film grain is removed from the video by a denoising process, and the grain parameters are estimated from the flat regions of the difference between the noisy and de-noised versions of the video sequence; these parameters are sent along with the compressed video bitstream. ` `The details of the algorithm are as follows. When the film grain/noise parameters are estimated, it is important to make sure that only smooth regions of the picture are used in estimation, since edges and textures can affect estimation of the film grain strength and pattern. To determine smooth areas of the picture, the Canny edge detector [7] is applied to the denoised image at different scales, followed by the dilation operation. The thresholds in Canny detector are proportional to the local intensity of the signal and are therefore adapted to the luminance. Figure 2 shows an example of the image that is produced by applying Canny edge detection at three scales to the denoised video followed by dilation. The low luminance areas are also excluded from film grain pattern estimation` https://norkin.org/pdf/DCC_2018_AV1_film_grain.pdf

It's complicated because they need to analyse the texture of grain to simulate the exact same noise.

I believe we might need some more noise in the black area

does anyone have experience with black and white photography?

are the darkest areas there still noisy?

I like the overall look of Sami's new LUT and think it can be merged as it and is likely a big improvmeent

what about X and B?

We don't add noise B

we had a version where we added X noise, I don't think we add X noise today -- not completely sure

I saw that quite a few photography guides shot how to remove the chromacity noise from images but leave the intensity noise

I suspect that it is artistically and aesthetically a good solution to have the noise added to Y only

In Renata's original work we added in both X and Y, but I believe we moved to Y only

Sami knows better

> we had a version where we added X noise Was it before the format freeze?

we had that 2-3 years ago

I don't know if the format supports X noise

Wow, that's quite ancient

had there been a question about it, I would have advised to drop it (and probably did, but don't remember)

B noise we never built, I didn't see the need for it

How did X noise look like? Just curious. (And yes, I know myself that chroma noise is awful.)

it looks a bit like debeyering gone wrong

or raw images that try to be too raw

typically it is not a pleasant experience

Did any example images of that survive?

I guess he wouldn't be allowed to show them even if they did still exist. 😄

Somehow Jon *could* show his glitch art from FUIF era...

no, but perhaps pik codebase would still be able to generate some 😛

it is not worth looking into

<@!532010383041363969> <@!604964375924834314> i share you raw png from a full frame sensor @3200iso 24mpx (this noise i near equal to low iso from smarphone) to see what is look like. I do also a nr reduction from chroma only, a real nr and a black and white. https://1drv.ms/u/s!Aui4LBt66-MmlF2ATk1sffHvORGM?e=DPHnNf

<@!532010383041363969> <@!604964375924834314> sorry to say that, but I think there's excess noise in highlights. Here's the original image, a result of HDR merging of 3 photos. Noise ends where channels start to clip (at least before HDR tone mapping). When there's clipping, there should be no noise, right?

But here's that photo encoded with `--noise=1`. Here highlights *have* noise despite almost nobody expecting them to be there 🙁

Actually I've checked it now with Paint's probe and there *is* clipping in the original. There should be no noise at all in the JXL version, but it is.

yeah, `--noise=1` is the “old” method, which indeed has that defect

does it also occur with the new experimental photon noise?

`--photon_noise=ISO6400` for example

(not sure what amount would be appropriate here and it needs to be specified manually for now)

it was merged recently so may need a git pull

Wait a sec, I have to recompile

By the way since compiling is quite RAM-intensive, is it possible to do a "differential" compilation (recompile only the files that changed and reuse the rest)?

it’s what should happen if you go to the build directory and run `ninja`

do you use `ci.sh` every time?

No, I'm using original GitHub instructions: ```bash cmake -DCMAKE_BUILD_TYPE=Release -DJPEGXL_ENABLE_DEVTOOLS=ON -DBUILD_TESTING=OFF .. cmake --build . -- -j$(nproc) ```

ah, I think this should be incremental too, however it’s not so rare that a header included by many files gets changed and so they need to be rebuilt anyway

Can I run just the `cmake --build . -- -j$(nproc)` line or do I have to run the first one, too?

I think the `cmake --build` should be enough

or you can probably just invoke `ninja` directly instead

When using `./ci.sh` I was running out of RAM quite quickly

ah, but if the first CMake command is the full one, then it may have generated a Makefile, not ninja files

you can maybe balance ram usage vs. parallelism by adjusting the `-j` parameter to something a bit less than your number of cores

if you know how much RAM one process tends to use, you could divide your amount of free RAM by that and pass that to `-j` instead of `$(nproc)` for example

OK, it worked. I don't know why it didn't work when I tried it a few months ago... ¯\_(ツ)_/¯

Nope. Still too much grain in the highlights...

If there's visible clipping, there should be no grain at all.

But that idea with "ISO"-dependent noise is a great starting point. That's gonna be interesting...

oh, true, at the moment it doesn’t try to detect clipping

It's not just clipping, more like bright areas in general

it’s normal for even bright areas to have at least a little bit of noise due to photo response non-uniformity: https://www.photonstophotos.net/Emil%20Martinec/noise.html#prnu

(but also, at high ISO settings, even areas that are “bright” in the processed output may not have been made from much light)

I do some test with noise synthesis, and it's very good ! The amount of noise is good even in high light. https://1drv.ms/u/s!Aui4LBt66-MmlF2ATk1sffHvORGM?e=DPHnNf For this picture 3200iso in full resolution, for d3 the good noise is ISO400 For resize picture in fullhd in d3 the good noise is ISO3200 and it's AMAZING. (good choice of noise level in high compression ratio is game changing for noisy picture) look at here: https://slow.pics/c/8bPWqGsq

see the red it looks noisier

did you really elaborate a raw with jpeg xl

Ah yes it's the ISO1600 best choice, you are right <@456226577798135808> noise in mid light is too important against black area.

please explain why you need noise

is not better a vardct improvement

do you have a build

ah seen

what is the command

commands

The same comparison with ISO1600 https://slow.pics/c/NcAu8EHC

basically it does the same things as webp2 but faster

no super research

here's a sample when you can see what quality it is

for %i in (D:\Documents\jULY\doc\a10\*.jpg) do cjxl -j -d 8.687 -s 7 --photon_noise=ISO6400 %i %i.jxl

this is raysar build download

https://onedrive.live.com/?authkey=%21AI1UqLiYRHX4%5Fqg&id=26E3EB7A1B2CB8E8%212660&cid=26E3EB7A1B2CB8E8

which i used

....

i'll stop with this girl or someone will be tired

i'd advice to use max iso 506

or the encoder will be perceived worse than original

use iso 506 exactly

on modular it doesn't work

so for %i in (C:\Users\User\Documents\modul2\*.png) do cjxl -I 0.439 -s 4 -q 87.922 --photon_noise=ISO506 -m %i %i.jxl

isn't valid

but -I 0.439 fortunately is valid

basically what this command does is redistibute grain a more pleasant way but the encoding quality is the same

obviously you need a raw png

high quality shoots with many colours

also you need to encode with speed 9

so outside of encoding test i don't think squoosh.app will implement this

people will get confused

https://twitter.com/GeraldRTamayo1/status/1411986767268311040?s=19

Who is that person? He claims to be the genius behind just about everything

next thing to do is speed up the decoder when noise is on 🙂 and maybe have proper detection/denoising in the encoder...

Looks like a troll or a joke account

that person has been communicating on encode.su, too

after some posts that I observed, I couldn't make any conclusions about their intentions

This is the kind of noise that we need!

Yeah! Now it is working as intended. Thank you Spider-Mario and Raysar!

getting the noise level correctly modulated with the intensity level is a huge thing for me aesthetically

it creates a feeling of realism/fragility/smoke/noise/dust etc. instead of bits and artefacts

I suspect we still want to modulate the noise by compression distance, too

when we compress at d0.5, the noise is already included -- adding more isn't the greatest idea

in every intensity level the noise should be less than the quantization from the dct

also, I can take it into account in psychovisual modeling -- the noise is a masking element that changes the ideal distribution of bits to be slightly more uniform than without noise

I'd like to get feedback from actual photographers on the ISO1600 etc. based definition of noise -- whatever creates the most comfortable control parametrization

the noise is also related to the shutter speed and aperture

and to the f-number of the lense

could you show us a comparison of jxl vs. webp2 here?

That's the main aim, choose the best function to link distance and noise intensity. Max is the mesure of noise of the the picture.

Raysar, I saw that you posted on <#803950138795622455>

are you are hobbyist or a (semi-)professional photographer?

(btw, I really appreciate the feedback and guidance you are giving on this)

Hobbist, but i'm technically very good in photography and technology, not artistically :p

the reference material (like the color calibration sheet) you posted was very useful for me

I think we have some excessive noise in middle grays in jxl

but also our look-up-table only has eight values, it may be that we are not able to fix that

it is a very very subtle thing

Uh, I don't remember h.264 being started designed in the 1980s <:kekw:808717074305122316>

cool 🙂 I'm looking for silver picture that i do when i was a kid and i see the noise distribution is more visible in white than black <:YEP:808828808127971399>

Ooooh.

It looks like an AI actually on Twitter.

could you send a copy?

supposedly some pixels can get hotter than other pixels and provide consistently more thermal noise

it does in the sense that the combination of scene luminance + shutter speed + f-number determines the focal plane exposure, and an ISO value is more or less another way to convey that information (but without having to know the actual scene luminance)

I briefly considered basing the interface on exposure values but eventually decided against it

I mean like “EV -4” and so on

from my point of view we finally have a solution that works in the main use case (for d2 to d8 or so)

we probably need some more adjustments to make it work in every case ideally

thermal noise is sort of negligible at the shutter speeds that are typically hand-held but can be more of a problem at longer exposure times

roughly those where one would start considering the use of a tripod

makes me wonder if the iso value should remain a pseudo iso value for noise level control -- or if we should try to extract the imaging parameters from the original and take the timing and aperture from there

my intuition is the former -- just fix the noise in usual conditions (fixed aperture, f-value and shutter time), modulate noise with iso value

perhaps photography has existing culture (stronger than just defining 'iso' of the film) that we could build on

like expressing intent "if I use iso1600 value I attempt to capture images with this much film grain"

thermal noise may be a boost on the noise at the very lowest levels -- at least on xyb I consider that the bias values are due to thermal noise in the eye

<@!532010383041363969> look at the picture 23, i'm not sure about the quality of the film scanner, but i don't think there is sensor noise. You need to download files. https://1drv.ms/u/s!Aui4LBt66-MmlF2ATk1sffHvORGM?e=p6QH1H

I add also 4 smartphone raw picture (very recent sensor) from darktable, only unbayer and white balance, 100-400-1600-4000 iso There are also jpg version (low quality jpg setting) There is huge contrast apply on jpeg, and noise reduction on smartphone is horrible, + there are ALWAYS sharpen filter !

But in realty there is no high frequency noise in recent jpg, smarphone and dslr, only medium strange noise.

yes, I have come to associate strong sharpening with “the smartphone look”

I barely sharpen my own images if at all

it quickly becomes too much, too “flat”

smartphones often obliterate everything with noise reduction, reducing any texture to mush

and then bring back the edges with sharpening

Sharpen will become forbidden EVERYWHERE, it always decrease visual quality and psnr quality.

If we have a rooted smartphone there is solution to tune picture and remove sharpen and excessive denoising before jpg. Apple are less stupid and have better tune for their jpg.

I do not think he is a human.

He is clearly a GPT based AI.

It has sentence level understanding, but nothing about context.

You telling me half the people I met are AI? <a:ThinkingSphere:821038590091329557>

don't think is the same; but -s 8 -d 0.291 --photon_noise=ISO731 looks good don't know the difference in file size

probably i don't understood what is the purpose of this

This is very interesting. What is the actual detailed process used in the 'Silver' category?

If you use -d 0.291 you don't need to add noise, -d 0.291 can store the original noise. JPEG XL's noise synthesis is not an image processing tool, there are better image processing tools around. Just post the great looking webp2 image and the problematic looking jpeg xl from the same original so that I can learn about the problem.

It's the defaud scan from nikon silver photographic film scanner. (I don't know how we speak about analogic photography in english)

the silver grain has indeed very different characteristics from shot noise

I'm somehow more used to the shot noise aesthetic and it is more pleasing to me than the silver grain noise, but we could consider developing other noise parameters to create silver grain noise, too

what are the iso i can use

for %i in (C:\Users\User\Documents\8\*.png) do cjxl -s 6 -p -q 85 --photon_noise=ISO636 %i %i.jxl

with iso 638 is the same

ah with progressive it doesn't work

that, and also, there are only 0.20 stops between ISO 636 and ISO 731

you can try higher values if you want to check whether it’s applied in a given mode

it doesn't work more

for %i in (C:\Users\User\Documents\8\*.png) do cjxl -s 7 -q 85 --photon_noise=ISO1600 %i %i.jxl

quality is always same file size

maybe i should use distance

no it doesn't change anything

ah it works only on speed 8

don't do at speed 7

<@!416586441058025472> I'm not sure you already know, but you can also use decimals. Like: --photon_noise=ISO731.936284001

Image viewers like gwenview crash when opening images encoded with --photon_noise= . Is it normal? Does qt plugin needs update to fix that?

imageglass works just fine also firefox nightly

I think so, it's the same with xnviewmp, it only support basic jxl.

I can view photon_noise with XnViewMP. <:WTF:805391680538148936>

Xnview doesn't support never basic jpeg xl.

no support at all

what chrome can open xnview cannot.

including modular, animation, lossless transcode e 1 e 2

i have not tried

Yes low resolution with noise works but crash with high resolution picture 😄

it shouldn’t, it’s the same format as before

just with a specially-constructed LUT

They maybe also crash on the old --noise=1

IIRC an old version of libjxl has a bug in noise reconstruction

Which reminds me that we should really do a new release and encourage applications to update to avoid stuff like that

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

Uh, it shouldn't crash...

https://spie.org/Publications/Proceedings/Paper/10.1117/12.2529237?SSO=1 50 % claim was done with extreme care, I stand behind that claim 🙂

(in psychovisually lossless quality)

https://zpl.fi/exif-orientation-in-different-formats/ this is pretty cool

interesting

in jxl we made the clear design decision that anything that has render impact goes into the codestream so the decoder can do the right thing. Metadata is only **meta**-data, info about the image but not needed to show the image itself. So orientation, color profile, etc are not metadata in jxl, but part of the image data.

with the old formats like JPEG that wasn't possible because color profiles and orientation were things that weren't invented yet when the JPEG codestream was invented, so there was no other option than to do a "glue and duct tape" thing

in video world they are used to putting render critical stuff as 'metadata' in the container and using the codestream only to represent pixel values but not how to interpret the values

so WebP, HEIF, AVIF are also "glue and duct tape" approaches when it comes to render impacting 'metadata' like color profile or orientation

AVIF has designated headers (irot & imir) and they do work but it seems like EXIF metadata doesn't affect it in chromium

probably for the better tbh

huh wow

in canary it is fine though:

yes i tested canary

in current stable chrome it's not yet ok

tbh they pushed it in too soon

on firefox avif is id say quite reasonably not yet supported

the thing with these headers is that they leave it up to the application to look for them and apply the orientation, which makes it likely that some applications do stuff wrong

that's true for all of those fancy HEIF container features

like cropping, grids, overlays, etc

all nice on paper, but it's only as usable as the lowest common denominator of what is correctly supported in all applications, and that is likely going to remain very little

by not defining hell knows how many container features

we see it as a decoder responsibility, not an application responsibility

we also have cropping, overlays, etc, but at the codestream level, not the container level

so it only needs to be implemented in libjxl

not in all applications

so overall jxl has about the same fancy format feature set? I though it was kinda more coherent and more well defined

maybe it's kinda from impression that HEIF is big kitchen sink kind of format

I think functionally jxl can do the same as heif, but in a more elegant and coherent way

In jxl there are just frames that can have a width,height,x0,y0, duration and blend mode, no separate notions of grid, overlay, cropping

oh so that's kinda more integrated

yeah i kinda feel difference better

instead of heif the format using av1 keyframes and making up avif, it's kinda less split up

the video-derived codecs need a container anyway because video codecs are typically hardcoded for 3 channels, so if you want to have alpha transparency (or a depth map), you need multiple codestreams and link them together at the container level

also video codecs don't support icc profiles, video uses enums

basically containers are necessary hackery needed to make video codecs work as image formats

but if the codestream is designed from the start as an image codec, the container becomes optional

<@!532010383041363969> <@!604964375924834314> Noise synthesis is not greyscale (here -d 0.1 --photon_noise ISO128000) It's a choice? The aim is a luma noise only? An other question, noise synthesis is not possible in modular now, you can enable it?

what do you mean by not grayscale?

re: modular, I think it would still only work in XYB

at least work as expected, let’s say

ah, never mind

from what I understand, the aim was to properly balance the color of the noise as a function of the underlying color

using --colortransform=0 do not enable noise synthesis

Ok so a monochrome image with noise, lost his monochrome propriety?

right, it currently doesn’t, but I mean that if we enabled it, it’s likely only with XYB that it would make sense

apparently a little bit, I don’t know if it was an explicit design goal to avoid it completely

(empirically, I would guess it was not)

128000 iso in sepia style, blue and red pixel are visible. If i have choice i prefer monochromatic noise.

I'm disappointed, max iso seem to be ISO543316 😄

too bright

Thanks for testing it. In Renata's noise synthesis we chose to put ~10 % of the noise energy in Y to the Y channel -- looks like that is still reflected in the noise generation. I didn't know we still did that.

I don't know if Y only is better than having both X and Y

probably safer by default to have Y only

to have a very slight amount of X noise does make the photographs look better, but that needs to very very moderate

Aren't all kind of AV1 frames supported in AVIF -- not just keyframes?

yes, for animated stuff it's i think all frame types but i haven't looked how different it's from still avif

I heard that any four AV1 frames can create a single AVIF frame -- didn't read the spec myself

there is no distinction afaik between still and animated AVIF — it used to be called AVIFS for animated but they dropped that distinction

which means that if you want to support `image/avif`, you need to support all of AV1, not only the intra frame stuff

It's not clear for me <:Thonk:805904896879493180> https://en.wikipedia.org/wiki/LMS_color_space There is no luma axis in XYB, how do you change only luma of one color? <:FeelsReadingMan:808827102278451241> Is there a picture video of a cube for XYB color space? 😄 like that: https://www.youtube.com/watch?v=3dET-EoIMM8 I prefer a full luma noise with --photon_noise and an --photon_noise_chroma=1 to enable color noise 😄 I'm fighting all the time with color noise of sensor camera.<:ReeCat:806087208678588437>

(0, 1, 1) is just luma in XYB

IIRC the format will always add chroma noise

Did we define what happens in monochrome images or monochrome layers?

I think if the image says it's grayscale (although I don't think you can say that for an XYB image) it will in the end just read one channel

but otherwise no

Ok, it's a bitstream limitation?

yeah, I think so - we add 1/128 chroma noise and 127/128 luma noise

it would be interesting to learn more if this is an acceptable aesthetic solution

I acknowledge that most photography guides focus on removing the chromacity noise altogether

If it is just wrong we might have some ways to fix it, file an erratum, etc. Jon and Luca know how and if this can be done.

In av1 they are estimating and generating color grain. `There are other characteristics of the film grain that need to be modeled, such as correlation of grain between color channels. In film, grain is often said to be independent between R,G, and B channels and proportional to the linear light intensity. After a YCbCr color transformation, grain between the channels is typically correlated. Application of the film grain in AV1 is made in the coding (e.g. YCbCr) domain to make processing feasible in the decoders. Correlation of grain between color components has to be captured during the film grain estimation.` https://norkin.org/research/film_grain/index.html

well, not sure how we'd modify that without either an extension or just entirely getting rid of chroma noise

Ah yes, i see the jxl specifications:

imagemagick won't do avifs at all but works with avif just fine

iirc it's related to libheif dep not handling that

<https://github.com/strukturag/libheif/issues/377> and devs don't seem to be very enthusiastic about it

(which is one of reasons why I'm pushing for jxl animation to be taken seriously, half-baked support is very annoying)

Yes.

I think it would be easy to add jxl support to Pix - qt based gallery app.

Request for image compression consulting or referrals for hire Inbox jg@projectn.co Jul 12, 2021, 9:49 PM (13 hours ago) to me Hi Dr. Sneyers, I work at Project N, a fast growing stealth startup where we develop large scale compression algorithms for all kinds of data for large customers like Atlassian and Tesla. We are impressed by your work on FLIF and JPEG XL so I wanted to reach out for you. I know your work on JPEG XL is crucial but are you available for a quick chat for us to pick your brain? Also, are you interested in consulting or could you refer us to someone who is available for hire to work on compression algorithms? Here is some background on us for you or any good people you know that could be interested: -------- We are based in Mountain View, California. Compression is not new. What is new is doing it at this scale. We use machine learning to continually improve as more files are added until the model reaches its capacity which is informally the maximum amount of information our model can learn. Since we will run on petabytes of data, we need a model that is very fast while having extraordinarily large capacity. We have plenty of hard problems and plenty of funding so hiring great people is a top priority for us. We still have less than 30 people at the company so this is an amazing opportunity to join early and help lay the foundations. -- Joseph Gardi ML lead, Project N

https://tenor.com/view/robert-downey-jr-face-palm-iron-man-rdj-why-gif-10994785

So infinite data for your research

I sometimes feel like I live in Silicon Valley, the TV series

that series is way too accurate

I got one too

same

they must have run `git clone .../libjxl.git; cd libjxl; git shortlog -se`

Sounds way too much like a buzzword-based VC money churning operation.

probably not, they didn't email me on my personal account

maybe some paper?

I have seen some invitations to a compression startup, but possibly not this one (correction, they sent that to me, too)

much more common are invitations fo high frequency trading companies

There were claims on encode.su that someone managed to get a lot of money by having a claim of being able to compress everything to 4 kB, including movies etc.

compression and hf trading used to be the same -- fast algorithms that process through a lot of data while applying primitive statistics

since neural nets became an easy to deploy thing they stopped asking me, I guess statistics were replaced by neural nets

I think my corp e-mail is only public through git repositories (mainly the libjxl one)

I guess not for general use but if you have certain specific kind of moving content p sure you could

perhaps if you could run a full-blown simulation of the universe and just record the time and position when the data existed 😛

that would make the U in URL more of a U

there's always the hoaxes about breakthrough recursive compression schemes that can compress anything down to nothing — of course they're all fake, there's no way to avoid the pigeonhole principle. But occasionally people manage to convince venture capitalists that they really have something great now. The right combination of buzzwords can unlock big money if you're lucky and in a position to pitch your thing to the right person at the right time.

with modern technology decompression would be somewhat slow and expensive

it seems likely that such a decompressor doesn't fit in our universe

surely just a temporary practical problem, you shouldn't dismiss promising new technology based on that, hardware becomes better exponentially so soon enough it will be just fine

people would be willing to try to solve it for 20 million

if you cool that system down with liquid helium, you can overclock it and see tomorrows stock market prices -- it would quickly pay for itself

we need to think outside the box, we're not going to limit our thinking by focusing on minor details like the size of the universe, are we?

ops, I'm on on-topic, no matter

on-topic is compression-related off-topic so i think it's fitting

for prediction stuff id say one needs more inputs, and not smarter algorithms at this point

big data hoarding and filtering. to see thru social cues which lead to moves

Yes actually.

The problem is that it will look like the biggest piece of garbage in existence.

But yes, it was a complete scam.

lol I upgraded from a may build of cjxl and now the file I was playing around with encodes bigger with the same effort and distance settings

F

It might also be slightly better

indeed

I wasn't expecting such a jump in size, so I didn't bother to keep the old file for comparison. I could check out and build the older commit, but whatever.

png: 29M 3-norm 1.21 jpeg (mozjpg q=90): 3.7M 3-norm 1.08 jxl (cjxl d=1.0): 1.7M Man, this shit feels good.

The distance estimation has changed?

It is likely the rate control has gotten more accurate and better.

someone explain me what HDR is. ive been trying to read about it but i dont think im getting it yet. so far seems to be about usage of 10~12bit colors with DCI-P3 color profiles but then there's also stuff about transfer functions, additional metadata and signaling of it which i don't exactly get yet

from my understanding, it is mainly a combination of light level + wide gamut. And higher bit depth is only required for higher gamut since banding.

in current year / generation of displays, it is dci-p3 contained in the rec 2020

and is still a meme because no display can do 100% coverage of dci p3 (not volume. bigger volume = bad)

so all it does it burn your eyes

HDR is about dynamic range: how bright you go, basically. In SDR, the brightest white is 200 nits or so, while in HDR it goes to 1000+ nits.

You need more bit depth for HDR because otherwise you would get extreme banding, since the steps between subsequent shades would get much bigger.

Wide gamut is an orthogonal thing: it is about where the RGB primaries are positioned, which determines the shape/volume of colors that can be reproduced (more saturated colors if the primaries are more extreme). This also requires more bit depth.

You can have HDR with just the regular sRGB gamut, and you can have SDR with a very wide gamut like ProPhoto.

But typically current HDR would be Rec.2100, which is both higher dynamic range and wider gamut.

Yes. Also to do it right, you need good contrast. Better shades of dark is also considered a form of HDR

hence why "hdr true black" is a thing

(basically for OLED displays only, although I hear mini-LED is getting close)

"traditional" LED does HDR by reaching $high nits, and also potentially using $a_lot of energy 😛

https://i.ytimg.com/vi/1WOqTReFDdI/maxresdefault.jpg left: HDR on | right: HDR off

youtube?

or just a microsoft windows 11 demostration

is the video in av1

could you send link of the video

JPEG is not suitable for HDR, since it is limited to 8-bit. What you are showing is likely tone-mapped to SDR, not actual HDR.

if it’s DisplayHDR certified, you can get an idea of how bright it gets from the number: https://displayhdr.org/#:~:text=DisplayHDR%20Performance%20Levels

Well, but Oblivion calls it HDR despite 8 bpc. ^^

8 bit = 256 shades. The dynamic range depends on the transfer curve, not on the bit depth, so theoretically you could do HDR in 8-bit, but even SDR can already have some banding in 8-bit if you don't dither, so if you significantly stretch the dynamic range while still only having 256 shades, banding will become a problem even with dithering.

Oblivion might be rendering with higher precision internally and then tonemapping. Games have been doing that for a while (long before HDR monitors were a thing).

I consider it a misunderstanding that JPEG is limited to 8 bits. I believe I can get 10.5 bits out of it easily.

the stretching needed for equal perception is something like 30-60 % ... it is log(target_intensity)/log(source_intensity)

log(600)/log(80) = ~1.45

if rec 2100 is used (which has asymptotically logarithmic gamma)

situation is a bit worse with cubic root, but can be partially compensated for in adaptive quantization

Sure, JPEG DCT coefficients are basically 12-bit so there is more effective bit depth than 8 if you dequant with higher precision. But in practice all JPEG decoders will decode to 8-bit YCbCr, at least atm.

We could do high-precision JPEG with libjxl though (either directly or via jxl recompression, or both)

I consider 8 bit HDR okeyish, if done very carefully ... 600 nits is only 15 % larger psychovisual steps than 250 nits (and many monitors go to 250 when brightness is set to full)

yes, please 🙂

Before

After

d16

this is an irritating change because it is quite a bit slower

probably only to be activated for turtle

possibly second slowest, too

it makes things look better though :<

yes, I need to find something similar that is faster

I have a jxl file. I made it with gimp. It doesn't open properly on gwenview, djxl and on squoosh.app but it works fine on gimp

weird

looks like the pixel data is there, but the alpha is all zeroes

I'm using git builds

perhaps the gimp plugin just didn't implement alpha properly, and ignores it when loading images and forgets to set it when saving them?

these plugins and integrations really need some more love, it's kind of embarrassing if they mess up like that

🤔 <https://forum.doom9.org/showpost.php?p=1947660&postcount=53> > **benwaggoner** > Any codec, video, audio, or still, needs to gracefully degrade when out of its sweet spot. The sheer variety of content out there is mind-boggling, and all the common image test libraries lack sufficient representation of important content categories. > > The original sin of JPEG is that it was only intended for continuous tone images like photographs, and a pure DCT implementation runs into severe issues with discreet tone images like text, line art, traditional GIF animations, and anything else where sharp edges are the most psychovisually important element. > > A great thing about HEIC as an image format is that a HEVC IDR can incorporate the best of JPEG and PNG style compression, using iDCT-like transforms for natural image areas, but switch to transform skip or even lossless CUs for discreet tone areas. That makes for much more graceful degradation for weird kinds of content, and finally made it possible to compress mixed continuous/discreet tone content efficiently and in high quality. > > The quality of a codec is reflected in both in where it operates best and where it operates worse.

HEVC and AV1 do have some PNG-like options but not quite as good as PNG, imo. JXL has stronger options.

also doesn't jpeg xl handily beat png in lossless mode?

jxl destroyes everything in lossless mode

Even worse. Here is how lossless stacks up for most encoders we use: CJXL > CWebP >= aomenc > x265 > HM

Decoding speed in lossless <:kekw:808717074305122316> JXL > WebP >> AVIF >> HEVC

is this typo intentional?

yes

is it a reference to a paper by Schnorr?

indeed. p pointless reference but i like doing these

JXL lossless decoding is not that fast 😛 (yet?)

Yeah, I think I sympathise and agree with a gist of it. This is also why I take a slight issue with the _tractors versus race cars_ analogy. These modern vehicles are advertised as being able to run on any terrain (quality 0–100, or whatever scale they use). Nobody, rightly, is giving any warnings that you should choose one modern vehicle over the other for this or that terrain (like we had to in JPEG vs. PNG days). Myself, I don’t have the luxury to get where I wanna go by driving exclusively over German autobahns (actually, two summers ago, I found Serbian are much more modern) or muddy tracks. I have to (and enjoy) driving wherever I want or need to. So I’m utterly uninterested in a race car. Heck, I’m from Poland and good luck driving one even in the city. I much prefer a vehicle that will give me freedom and will perform well in any landscape. Tractors and Formula cars both look very cool, but they are tools of narrow trade, not my one, though. Mine is having to deal with what I’ve been dealt with: any terrain. Any image.

Yes, I agree that a codec should aim at universal applicability and being pareto-optimal across the quality spectrum

I don't think measuring performance in the low quality range of the spectrum is a good proxy for measuring performance in the entire spectrum though.

It would be utterly sad if I would have to use JXL for hero images and AVIF for tiny ones, because AVIF takes ages to show anything and JXL looks worse than WebP on small thumbnails.

> measuring performance in the low quality range of the spectrum is [not] a good proxy for measuring performance in the entire spectrum though Yep, it isn’t, agreed. My cheeky, naive, and slightly disrespectful (apologies – only to make a point!), view on that is: codec’s fault. It should adjust.

I think jxl has a bigger gain on previous codecs like jpeg/webp/avif in the medium-high end, but it is not worse than them in the low end, except if you go into the ridiculously low end where probably lowering the resolution would be a significantly better approach than lowering the quality.

And yes, encoders should "make the best of it" at that point; cjxl has been improving on it but there are still things to be done. For example, it should probably by default use --resampling=2 below a certain quality.

thinking about this, a modification to preflate plus lossless jxl might be a good way to recompress PNGs

it's technically not hard to do on top of jxl lossless, you can use stuff like https://github.com/google/grittibanzli for the lz77ing and a bit of extra metadata

yeah, but before JXL was a thing I believe 😛

yes, all reflate, preflate, precomp (which AFAIK uses preflate) and grittibanzli are aimed at exact deflate stream reconstruction

the thing is that normally such tools give you an uncompressed data (say, raw RGB) and reconstruction data, but the former can be replaced with lossless jxl for the maximal usability

since as long as you can get raw RGB the exact format doesn't matter

I guess it's a good experiment to try this night

if you can fit all the non-rgb data into a box and send a PR to the JXL repo it might be interesting... 😄

(can't promise we'll integrate it immediately, or that it will go in the standard, but it could make a good starting point)

oh, I realized that the JPEG1 recons mode of JXL is a whole separate project (Brunsli) merged into the spec with a completely different signature and internal format

it was

I wondered why there is no arbitrary data section in the main spec while the recons mode is seemingly able to reconstruct JPEG comments

I don't think it applies anymore

ah

was there a big change since the committee draft? since there seems no other up-to-date spec available...

iirc the way JPEG1 reconstruction works is that it uses VarDCT mode, but only with 8x8 DCT blocks, and it puts a special "JPEG bitstream reconstruction data" box in the container, along with the JXL codestream

that sounds sensible

yeah... that sucks

from what I've heard, there are significant changes between the committee draft and the FDIS

Very significant changes, yes

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

yup, correct

it took all the night but my crappy python script does seem to work: ``` $ time pypy3 ~/git/jxl-preflate/jxl-preflate.py sample-iccp.png JPEG XL encoder v0.3.7 [AVX2,SSE4,Scalar] Read 1761x2500 image, 23.0 MP/s Encoding [Modular, lossless, squirrel], 1 threads. Compressed to 2011602 bytes (3.655 bpp). 1761 x 2500, 0.43 MP/s [0.43, 0.43], 1 reps, 1 threads. preflate v0.3.4 splitting /tmp/tmp89sblnr5 successful (3269337 -> 13210000 + 139892) All ok original data: size 13210000, hash a67185809d99d8a297ad3b6ba03fde3d4580647110729ebe7bad9f452c236ff9 original 3272114 -> jxl 2011602 + recons 142885 = compressed 2154487 (34.2% smaller) real 0m30.425s user 0m28.438s sys 0m1.375s $ time pypy3 ~/git/jxl-preflate/jxl-preflate.py sample-iccp.png.{jxl,recons} JPEG XL decoder v0.3.7 [AVX2,SSE4,Scalar] Read 2011602 compressed bytes. Decoded to pixels. 1761 x 2500, 3.39 MP/s [3.39, 3.39], 1 reps, 1 threads. Allocations: 606 (max bytes in use: 1.687282E+08) reconstructed original data: size 13210000, hash a67185809d99d8a297ad3b6ba03fde3d4580647110729ebe7bad9f452c236ff9 preflate v0.3.4 recombining /tmp/tmpfpcvm1kw.x successful (13210000 + 139892 -> 3269337) All ok real 0m23.886s user 0m22.766s sys 0m0.703s $ sha1sum sample-iccp.png{,.jxl.png} a9a3eeb42d8836ceca810d9f660da53eef0506d3 sample-iccp.png a9a3eeb42d8836ceca810d9f660da53eef0506d3 sample-iccp.png.jxl.png ```

I've just finished to add Adam7 reconstruction (the only missing bit is probably the indexed color) and running a test

I have some large image to test (30MB, 42.3MP) and jxl's slow like the heck

that's definitely a thing to tweak, but for now I want to check the compression ratio

for some file jxl + recons was 60% smaller than png for example

okay the large-scale test is working, `original 31279328 -> jxl 17504059 + recons 1490500 = compressed 18994559 (39.3% smaller)` (and took 6 mins lol)

is `-s 4` significantly slower than `-s 3` than lower levels btw? (for the lossless mode)

my current test set is definitely biased 😉

s3 should be absurdly fast though, even lossless.

1. Can you give the image to test? 2. What processor are you using for that test?

https://gist.github.com/lifthrasiir/5c24058f21ce6fba231cf1bfba45bf28

as you can see, no optimization at all (it does all PNG parsing in Python, PyPy strongly recommended), so consider it to be a proof of concept

there are tons to do with non-preflate reconstruction data (e.g. iCCP can be probably entirely reconstructed from JXL?) but that's enough for me right now XD

I don't know what do you mean by 1 (is _my own_ test set important here?), but for 2: preflate.

for 1, sure (I had a weak reason for not wanting this, but yeah), but it seems that discord supports up to 8 MB of attachments...

the 30MB file in question was on pixiv, https://i.pximg.net/img-original/img/2018/10/22/20/20/34/71302422_p0.png (requires pixiv.net referer so I won't censor this here)

the reason I didn't want to post that was, it turns out that the image in question is okay but the artist profile has nsfw images

for 2: i7-7700 @ 3.60 GHz

I actually think that the main culprit is preflate and not jxl; preflate seems not configurable to me

aaaand it turns out that I've mistakenly built preflate in debug mode. ;_;

(preflate does not build in linux out of the box, so I had tweaked some header files and forgot to turn it back...)

i have em followed already lol

for that 30MB file compression now takes 74 secs and reconstruction takes 120 secs

Python overhead exists but effectively negligible, since preflate takes >60s

time to feed an 102MP image...

(for the reference, this is https://commons.wikimedia.org/wiki/File:Home_in_Relation_to_Everything.png)

kinda unreal how one can just do full recompression with this

now if we'd put it in metadata header...

or rather, optional block

if you don't model every bit of headeres then it seemed not difficult, so I gave a try

Is PNG recompression even useful if you keep the metadata?

normally no (not even JPEG), but you might want that for archival purposes

btw my 102MP test (-s 4) resulted in: ``` original 79390558 -> jxl 46407388 + recons 4491215 = compressed 50898603 (35.9% smaller) real 6m43.237s [snip for decoding] (jxl decoder finished in 89.5 secs.) (preflate reconstruction finished in 240.3 secs.) real 7m22.926s ```

the problem is, apparently preflate should run 8 worker tasks in my computer but it doesn't seem so

https://encode.su/threads/3223-precomp-further-compress-already-compressed-files?p=70019&viewfull=1#post70019 seems that it's already on the way

Ubuntu on WSL1 :p

it does try to use `std::future`, so it might be a C++ library issue

(why have I written `std::worker`, I should sleep)

Cool stuff, promising POC, if it can be refined a bit to do something specific for the chunks that are already described in other ways (icc, xmp, exif) then we basically have a `pbrd` (png bitstream reconstruction data) box that could be added to the part 2 spec in a future edition.

Why would it use all threads? Software is single-threaded by default unless you figure out ways to parallelize it.

So, about compression: since Brotli was added as another optional dependency, does it currently do anything in cjxl?

Brotli is only used for jbrd

We should also implement it for exif/xmp compression (`brob` versions of those boxes in the file format, as specified in part 2)

What is jrbd?

JPEG bitstream reconstruction data

Oh yeah 😅

I should use that acronym more often.

It's the fourcc code of the isobmf box that stores it

create a jxl with both jbrd and pbrd records, confuse everything?

If you have a jpeg and converted it to png, in principle it could make sense to have both jbrd and pbrd

yes, that was why I chose brotli (technically can be replaced, but its 2nd order model is apt for reconstruction data)

unfortunately brotli preset data didn't contain IDAT or any other PNG chunk names though 😛

That we can fix by defining common chunk names and crc computation in the pbrd spec

agreed

for the standardization the hardest bit will be specifying preflate

will be slower than s 9 q 100 e 3

is jxl to png

or png to jxl

what's the purpose

the ability to reconstruct the bit-perfect JPEG/PNG is useful from time to time

ah it doesn't improve lossless compression

like png to jxl

as precomp demonstrates this ability has some merits, but the resulting "compressed" (low-entropy) data is not readily usable as an image format

so it could only function as a preprocessor for compression formats and not by itself

JXL + reconstruction data approach can allow both uses (you can always go back to the original data, while you can use this recompressed format as is)

ah so it inflates jxl lossless modular file size

for no reason

it's useful only for developers to to test compression

how many

few kb or even 1 mb

Fabian probably meant that: i) since JPEG1 normally suffers generation loss but PNG doesn't, so this does has less merits (I agree) ii) the addition of PNG reconstruction data does increase the file size of JXL files converted from PNG

and the jxl how weights