JPEG XL

oh yes, it's heavy

Yea, I am thinking it might very might well be

though video encoding in general is a slow process and requires hardware

unless you use medium+ presets (meaning faster speeds) with x264

Yea I remember trying to make h255 years ago to replace my h254 and get some storrage benefits, although gave up on it - but it did do like 20 to 25% of less storage.

But of cause h255 never got much support because of..... well close stuff...

Both my video players, probably 3 can't play it.

but they can play AV1

funny enough....

maybe it is a browser thing not sure.

on support.

browsers can't play HEVC (H.265, X265)

mostly because of the licensing issues

yea, probably the issue then.

so we pass over that format for sure.

AV1 seems to be a new sweet spot.

It's the main format used in the blu-ray spec

ahh okay.

though both blu-rays and the format itself have royalties 😁

yea not really followed along these lines so much.

But I must say this AVIF when fixed to small files are amazing on my webpage compared to originals.

like it runs so much faster on loading times, much more snappy for sure.

And still on quality I have not really seen a biggie big difference..... Although it surely are there but they are pretty good images for the size for sure.

casually encoding 526k images to jxl

Does AV1 go with Opus?

Yeah

Great so 2 open media then can be connected together.

That is how YouTube operates

so you can have both AV1 and Opus in a MP4 container?

ahhh cool, I guess they are doing something good then.

There have been zero significant RDO changes/improvements in libjxl since... basically the earliest versions you can find on github. Barely any change in the quantizer. Still the same ancient chroma bugs and overaggressive shadow compression

Whatever the case I can see the appeal from web creators to use AVIF.

It's kind of unusual for a codec library to have such little quantizer changes in such a long period of time

For a new one I mean

overall, that seems to be a growing thing that will continue to be used - and it would be understandable as far as I can see and what it can do.

I can understand for a really old one like libjxl-turbo

Like I am kinda liking this AVIF and seeing what it can do is amazing.

But not a brand new codec lib like libjxl

2.2GB of images down to 217MB.... and that is with max speed. Now with slow mode, that should compress it and make it more beautiful.

that is 2 GB right out the window slimming it down.

It's in a good enough spot to be considered for adoption, but better lossy compression won't convince google to adopt JXL. It's a political problem, not a technical one. Also I think the devs responsible for tuning libjxl are just working on other things.

I remember Jyrki saying he was working with audio recently

Don't get me wrong, I would LOVE to see the codec be pushed forward, but like JXL could have the best compression beating AVIF a thousandfold and Google will still say no.

Well you still have Apple using it. So it is not all done for, for those supporting JXL.

But yea as a sorta web newb homepage maker, AVIF will be my choice for sure. At this moment.

Like all the browsers near seem to support it.

and it is amazing to see how small of files it can do and still look good.

like I did JPEG on the same level of size.....

and it is horrible compared to AVIF.

Well of course JPEG is worse, it's 26 years older than AVIF. That's like comparing a horse and buggy to a modern car.

I understand..... just still amazing.

of cause the greenish thing is not the fault of the jpeg..... so the right colors would be there.

but the pixelation can easily be seen.

it does remind you of the 90's 😛

so..... if anyone wanna make a website like that and have the spirit of it.

I know. It's true, it's not a technical issue at hand here but purely office politics. Still, the lack of changes is somewhat unusual or unexpected, and it does make it somewhat more awkward than it needs to be when these flaws show up in the press and get publicity.

libjxl generally has pretty miraculous performance for a modern codec but when those 3 flaws show their head in lossy comparisons it's embarrassing and hard to explain

I still use progressive JPEGs rather than avif on my website

loads faster with a slow connection

I would doubt that..... Clearly you can compress AVIF a lot more with same quality.

because of progressive loading

okay, but with progressive loading..... like.....

jpegs will render a partial image with partial data

avif cannot do this

yea, I guess I don't need that on my website as the image gallery loader, loads all of them before showing.

but overall..... bandwith is a lot faster then it was in the past.

and as I understand progressive loading just needs more processing power to be done and used, or graphic.

in that regard jpeg images are more responsive because the time to initial preview is faster

But really. who has such a slow connection these days.... maybe in some third nations maybe....

progressive rendering a jpeg does require more cpu, but less cpu than avif decoding.

jpeg1 is very computationally simple

Yes actually, I was in Brazil last year and I really did benefit from progressive loading

Yea, I'll keep to AVIF 😛 even without progressive loading, like I am loading around 200 AVIF images in the gallery loader each time in one go - and it does it very quickly.

Or just me on mobile walking near a stadium that has a game

internet slows to a crawl

Ahhh okay.

well, you could just make the files smaller, you can make them much smaller then JPEG

with the same quality.

like.... it is insane.

like I use q50, and it is still very nice

like.... try it out BRB.

https://jesusgod-pope666.info/images.php#(grid|album)=/A--PC%20Screenshots%202014%20AVIFq50s444s10FAST%20XnC; Copy the whole thing, you need the ; at the end.

like this is made with FAST speed.

loading 200 files each folder.

and it does it pretty quick.

I'm not pulling up your website

1-3 sec maybe

We are not talking about the same thing. You are talking about density (which we are well acquainted with) versus loading images progressively

Why not, it is cleaner then most websites out there - and you would not have a problem with those who are full of spyware.

why do you make assumptions about me

well.... there must be a reason you do not wanna go there.

and see things for yourself.

Yea, I don't want you knowing my IP address

But for the most times, people are afraid of my website because of this and that - and have no issue with all those other websites that are full of crap.

use a vpn?

Like.... I have 20.000 people or so coming to it - I think your IP is pretty safe 😉

each month, or bots.... who knows.

im not going to spin up a vpn just to have the luxury of visiting his poop site

whatever.

but anyone else can see the test results and see how quick it loads 200 images

quick loading is not the same as progressive decoding

we are talking past each other

Like I go from 12-26 sec from the originals to 1-3 seconds of loading.

3 seconds is a very long time to load an image

I understand, but the AVIF files can be made so much smaller so..... they would load quicker anyway.

200 images

1-3 sec for loading 200 images.

why do you have so many image on one page?

without lazy load?

Lazy load is set to 200.

I hate lazy load.

although it could be tuned to work better, but for the most time it sucks on websites.

So I rather have 200 image in each folder.

200 images seems pretty good.

It's not about speed... It's about responsiveness... Go ahead and use AVIF. We are just pointing out that AVIF (and most modern image formats) have no progressive decoding at ALL. Which is a real tangible downside.

3 seconds is still a very long time to load a webpage

There is a reason many websites still use JPEG to this day, progressive loading is a really nice feature to have.

Of course compatibility is the main one.

Again the image itself could be made smaller and thereby very quick to load. You just compress it some more.

I'm talking to a wall...

https://tenor.com/view/dono-wall-gif-24048347

That is me!

it is just called an oppinion whether

correct or not.

anyway lets go and have a swim

I will say something that really bothers me about AVIF is not that it specifically doesn't have progressive decoding, it's that it doesn't even have *incremental* loading/decoding (aka the top to bottom style loading) meaning you won't see a single pixel of the image until it's 100% downloaded or you do hacky stuff with frames or something. This is a limitation that as far as I know isn't a thing with any other image format supported by web browsers (even BMP and GIF support incremental decoding for example).

argh, bicycle is flat

I wonder where my bike stuff is.

oh also for your website (and any other one as well I guess) you can test/emulate what the loading experience is like on slower internet connections using built-in devs tools that browsers come with. It may be in a slightly different spot depending between web browsers but once ya find the spot it's luckily pretty simple to mess/test around with

Well at least 13 to 22 second to around 1-3 seconds is fine.

And overall loading time is expected, it does says loading so.

I rather have it like that then this smart loading nonsense.

I could make folders with 100 images each but 200 seemed fitting on the scrollbar.

Good old loading screen 😉

Just some commodore colors and it would be fitting.

And some commodore text.... Anyway.

Scrolling is perfect with 200 images

You could make it smaller 150 or maybe 100 images but.... I don't think 200 is to much for the scroll and size of the page

But more then 200 gets to much.

takes a little time

although can't test real 3G as it was closed down in Denmark some years ago.

I usually used 3G as there was less radiation then 4G.

But yea, that took a lot longer to load for sure.

But then again when it is finish loading there should not be much a problem for looking around

But I could if anything fix them to 100 images or 150 per folder.

if anything, but really, I don't think it is that big of a problem.

But overall Not even sure you can see movies with 3G, although it seems strange that it would be so slow - as I had my mobile to 3G until they stopped it and was using it for my website as well I am sure.

I guess.....

I guess this would be why it would be important with mp4 that are web complient for streaming, although not sure if all my videos have that sorted.

AV1 has some tech on that?

I guess it has, maybe by default making it web complient?

I guess if I recode all the videos on my website, I will just need to keep in mind to have them web complient checked. If AV1 does not just have it by default.

But I think you had to activate it for H264

Well, I guess it shows another world of..... the internet.

I guess it is not all places they have 4G or fast internet.

clearly 3G is not nice for running my website..... I just don't recall having issues with it on my mobile when I was running it.

at least the way the Browser is doing it.

clearly it is not running fluently with emulating 3G, but again I just don't recall my mobile having issues with it.

But as they closed down 3G I can't further test it. But if I had a problem with it I am sure I have taken notice of it in the past.

How do I kinda know if an MP4 file is web complient?

Anyone who knows about tech stuff who wanna check out my website for things?

media stuff and such.

But really... how many are running on a 3G connection these days....

clearly the website is running fine on my 4G.

And I don't recall it was running badly on my 3G either....

although slower of cause.

okay so I was looking at a new Laptop started some weeks ago.... Now with AV1, I wonder if I need a specific graphic card in regards of support for encoding to help out.

Anyone knows anything about that?

4060 4070 and some others for Laptop.

4060 was the one I was looking at when nearly buying a new laptop.

But now I am wondering in recards of encoding.

Hardware encoding is faster than software encoding but will look much worse

Like what....

oh you gotta be kidding me.

Unusably worse in my opinion, but I am a sucker for high quality

because it is hardware sorted and have some default settings?

and cannot be change or?

Different optimization, for speed. Also a hard cap to 420 chroma subsampling, which may be fine depending on the source material.

so, software encoding uses the CPU to do? or the GPU?

CPU

okay, so the graphic card is not really that important then.... but then what about playing and decoding?

hardware accelerated video decoding is good stuff, should be more efficient than software decode, although I cannot say for certain with AV1. dav1d is a pretty good software decoder, but hwaccel should still be better. Maybe someone has more experience in that regard

kinda looking at these kind of laptops.

Why Nicky jam hiekka has a bitrate of 1,2mbps for av1?

So if you encode with software and then decode with hardware that is the way to go?

Pretty much, yes

But again, hw accelerated encode may be finde depending on your source material

I would recommend you encode yourself and compare

Whats the appeal of av1

To save 300kbps

Software encoders are at lower level

Maybe I am not looking for a gaming laptop..... maybe I don't need the Graphic card overall...... I am not sure.

You end with file twice as big with cpu used 1

sigh... what a jungle to go wild in 😛

With avif there's more appeal

But av1 on video what we should do?

I just don't want a crapbar again

Even jxl performs better given the time

Like gaming is not what I wanna use the computer for, at least not for the main point.

I want something low resource watts yet fast.

For YouTube av1 is just use as an excuse for audio normalization

was pretty easy choice when they had it on sale....

well I guess they will get someone on sale again at some point.

I tried to improve both Audio and video on yt

Yt is going to improve

A laptop with external water cooling......

Okay....

So I guess 10 bit is the same on Video on AV1 that would be the best setting like on AVIF?

is there a way to test visual thing as well on video like on AVIF?

that weird number thing that is seen here and there?

ffmetrics seems to be someone suggesting.

Anyone knows?

""Most importantly, hardware encoders are optimised for speed, software you can sacrifice speed for bitrate savings. If you want the absolute best saving in storage space, you need a beefy CPU and to use software encoding. AV1 is mostly a benefit right now if you need the most efficient real-time encoder, such as live streaming or in my case when I'm doing AI upscaling and will do a final encode using software once I'm sure the result looks good.""

I have already sent you image based tests

ffmetrics use older metrics. We generally rely on SSIMULACRA2 and Butteraugli for video/image quality assessment

Yea I do recall you sent some data on images..... This is for video.

You apparently put the original in and can have up to 12 recoded videos to compare with the original.

I think it was 12 you could do.

it is only because on this discord, we mainly speak about jxl which is an image codec

but on other discord

emre did faaaaar more video comparisons than image ones

using butter, ssimu2

ffmetrics is outdated and the code is still not opensource <:KekDog:805390049033191445>

so no one can add things

it s a nice gui though

Yea, dunno. I am just looking around.

av1 hwenc isnt bad but av1 is in it's infancy

very happy with live encoding results from my a380

oh just realized this is not other codecs

Just need to half my space on my website, would be nice.

and it is open format so that is nice. Anyway, still working on testing the pictues for now.

if you don't need live, swenc will wind up saving you way more space

I have also sent video tests

😁

?

swenc will take longer to encode but save a lot more space. but its to slow for many people if you need a live feed

Wuhuuu

Probably won't work in my player. Only supports mp4 format.

Which player?

Well my website players.

Any way to test if files are 10bit or 8 bit?

http://jesusgod-pope666.info/uvpf.php#/?playlistId=12&videoId=2

And...

ah

And https://am.jesusgod-pope666.info

And I have one more.....

They primary only do mp3 and mp4

But do not know further on swenc

But AV1 seems to be a good choice overall.

And maybe some opus as well.

Don't use a website, use a proper media player. For audio I hear foobar2000 great. For video MPV is solid as well.

Like... The point is using a website is to share information.

Basically every modern browser can play AV1 and opus fine

XnConvert: speed 10 vs speed 0 - quality 50.

Kinda seems to be a fluke still in the best. But the original do have some strange thing at the eye although better on the original.

But still.... Pretty good.

mp4 supports AV1

I know

That is kinda why I am looking into using it.

although working on the images at the moment, that will take a week or so with my slow computers.

but..... should get something together 🙂

and then the video and hopefully there will be sale on a good computer.

so I can begin video encoding.

But for now I am looking into the images.

https://github.com/gianni-rosato/photodetect2 C impl is linked in README

A match made in heaven (Posting it again for context) https://github.com/libjxl/libjxl/pull/1395

<@794205442175402004> do you think it could help revive a new revision of that PR?

Maybe. The tricky thing though is not detecting where to use patches, but to do it in a way that avoids seams and actually saves bits...

darkijah@Darkijah-USBSSD:/media/darkijah/USB-SSD1.75TN/Screenshots/2014_01-TEST$ for i in *.png; do ((current++)); echo "Processing the image: ${i} [$current/$total]"; avifenc "${i}" "new_${i%%.*avif}" -a tune=iq -d "10" -y "444" -s "0" -q 50 --ignore-xmp --ignore-exif; echo "Processing completed: ${i} [$current/$total]"; done Processing the image: Screenshot 2014-02-28 23.18.53.png [214/] WARNING: -a is applying to all inputs. Use -a:u to apply only to inputs after it, or move it before first input to avoid ambiguity. WARNING: -q is applying to all inputs. Use -q:u to apply only to inputs after it, or move it before first input to avoid ambiguity. Successfully loaded: Screenshot 2014-02-28 23.18.53.png

Have some minor issues here

for i in *.png; do ((current++)); echo "Processing the image: ${i} [$current/$total]"; avifenc -a tune=iq -q 50 "${i}" "new_${i%%.*avif}" -d "10" -y "444" -s "0" --ignore-xmp --ignore-exif; echo "Processing completed: ${i} [$current/$total]"; done I think this sorted it.

Maybe I can put the file stuff at the end.... maybe that works better

I don't see any information about tune=iq in the help file

what do you need to know about tune=iq specifically?

(I'm the author)

the tune is meant to "set and forget"

I don't know, I thought there would be something in the options about it, but I only see 2 options explained and I have a 3 setting, iq

So I am like, not sure if I have the right things fixed.

does look like the settings in this...... avifenc is making the images smaller, although not sure if it is better or worse quality.

with the tune=iq

not sure, there is a lot of settings in that line of command

Not sure how much effective it is, but it seems the files are smaller with this AVIF encoding terminal app.

okay.... Q50, ends up having some...... square issues.

So I think I will bump it up to 60 at least and see if that goes better.

By the way the Gweenview does not seem to read those AVIF files - at least not the one I have.

do you have kimageformats installed?

Wait, why do your AVIFs have a .png file extension?

Because I have had issues with renaming it without having it stop doing the images. So the PNG files are still AVIF

no idea, probably not.

although the other image viewer can see them.

I have the ability to changed png to avif afterwards with rename.

does it work with gwenview after adjusting the extension?

nope

as you can see I did one of each

try installing kimageformats, if it is not yet located on your system. Although I think it should be

avifenc might not have updated their help section yet, but if you're passing in `-a tune=iq`, and avifenc is built/linked to an up-to-date libaom then the setting is taking effect

Kinda weird the same image in Gimp and the viewnior

apparently one smoothes out the pixels or image.

check how each one scales images

dunno

whatever the case, I will push it to 60 in Quality.

I am thinking like you guys say 10 bit..... and was told it is not bigger, but still testing it, it seems might it might be bigger - but then I am thinking my screenshots.... like they might not be over 8 bit of colors....

although.... I recall we where using other kind of numbers in the old days for screens....

16 or 24 or something I think it was..... apparently I guess we use a new standard for colors....

Checking the old computer here it sahys color bit depth 8 bit

So if my screenshots are only 8 bit anyway.....

See.... why in the world do we now have some thing else that does not seem to match the old ways of writing?

16 colors 16 bit, 24 bit, 32 bit.

I guess 8 bit now what 16 was in the past?

Like.... I really don't know, seem ridiculous to just make up something new.

It's just the way bits are counted. 8 bits means 24 bits, 8 bits for each RGB channel. Most modern displays are 8 bit, so 24 bits RGB, with more high end displays being 10 bit, so 30 bits RGB

8 bits add up to 16.7 million colours, you may have seen this number before

The main confusing thing is that both bits per pixel and bits per color component are used. E.g. 8-bit can mean GIF-like 256-color or it can mean typical SDR rgb888 which has 2^24 = 16.7 million colors.

per same q, 10 bit AVIFs are a overall bit bigger, but they make it up by being significantly more efficient

there's significantly less banding artifacts

Yes, for the same filesize, 10-bit avif has better quality than 8-bit

It does come at the cost of slower encoding & decode speeds

indeed

that said, for encoding: the overall 10 bit gain is large enough that you can afford to use the next faster speed, and still come out ahead (s0 8 bit -> s1 10 bit)

for decoding: you'll end up with an image that's as complex as decoding a regular HDR image, and dav1d is so well optimized that it overall isn't a concern in practice

It doesn't matter. 10bit encoding is a HUGE improvement over 8-bit encoding. 10bit is what it was meant to be used for AV1, avif.

you can see an exaggarated output here: 8bit vs 10bit

Maybe not HUGE, but I would consider it significant

isn't some of this the the fault of AV1/AVIF implementations rather then 10bpc being better for 8bpc content/data?

for video, it is

I know, but we are talking about images here

~~firefox vs chrome with gradients~~

This is a large part of it, even if you only have 8bits of data, 10bit is just better in a lot of cases, though when you start to really crunch it, 8bit becomes better again depending on the encode settings and encoder

as far as I'm concerned encoding 8-bit data as 10-bit and getting better results doesn't make too much sense to me at face value but I guess in the video codec world it ends up working out that way because of low numerical precision being used for everything (likely to better facilitate hardware decoding) meaning that forcing 10-bit ends up helping 8-bit only data from getting messed with.

afaik JXL doesn't suffer from this since almost everything is handled as 32-bit floats internally

yeah, it's one of those things where designing for video first has a different set of priorities

this is one of the most striking examples I've found so far: https://github.com/webmproject/codec-compare/issues/17#issuecomment-2519192783

encoding as 10 bits makes banding completely gone

it's ultimately a workaround, but it is what it is

<:JXL:805850130203934781> is immune AFAICT though

also from what I've seen 8-bit AVIF ends up making some things way more red then they should be for some reason. mess around with the image attached to this message and you will see what I mean

hmm, I'm confused

source image appears to be a webp?

lossless

oh wait, is it lossless webp

yah

I didn't want to upload a giant PNG (my internet sucks)

no worries

something weird is going on with that image

I do get a color shift but even for lossless

probably colorimetry issues 😭

I may dig into it more tomorrow

colour issues 💀

humans should never have tried to replicate colour

banding

So if there is any banding on my 8 bit screenshots, it might smooth them out a little by default....

I guess....

Artists tend to add some dithering instead

this example is confusing to me looking at both avif files in gimp, the 10 bit encode doesn't even have any gradation in the bottom left corner. it's all just the same color but in the 8 bit encode it varies between 2 colors which are a fair distance apart, which is what causes the blocking surely the 8 bit encode could just make that region a single color too?

it's not a single color, but it's part of a very faint background gradient

if you look at the full images you'll be able to see it in context

ignore the actual colors in the video, just look at the rgb in the color picker first half is the 8 bit encode, second is 10 bit at least in that region there is just nothing in the 10 bit version

Ahhh, yea okay - but it anyone going to see it is the question on my website.

for i in *.png; do ((current++)); echo "Processing the image: ${i} [$current/$total]"; avifenc -a tune=iq -q 60 "${i}" "new_${i%^C*avif}" -d "8" -y "444" -s "0" --ignore-xmp --ignore-exif; echo "Processing completed: ${i} [$current/$total]"; done

This is the code I am using right now.

I will try to bump it up to 10 as well.

for i in *.png; do ((current++)); echo "Processing the image: ${i} [$current/$total]"; avifenc -a tune=iq -q 60 "${i}" "new_${i%^C*avif}" -d "10" -y "444" -s "0" --ignore-xmp --ignore-exif; echo "Processing completed: ${i} [$current/$total]"; done

Anything that needs to be adjusted?

not sure what ignore xmp and exif is

and some of the other as well.

8 bit would then be 24 bit and 10 bit would be 30 bit.....

8 8 8

10 10 10

XMP and EXiF are types of metadata. which is pretty much just like various types of text for information like copyright or what software exported the file or whatever else

those ignore commands will remove/strip the metadata out which personally I don't like doing but there's a lot of people who strip out metadata because they believe the information to be useless

I don't think I need any metadata

Yea, not sure there would be anything in them - where do I see the metadata in the original files?

you could use something like [ExifTool](https://exiftool.org/) to view metadata for files. although keep in mind that ExifTool will show more info then just what's embedded in the metadata which means it will always give printouts for files even if they don't have any metadata attached

Can Gimp see metadata?

You can also use `identify -verbose file.png` and `mediainfo file.png`

looks like you answered your own question

protip: \`\`\` block code \`\`\`

``` block code ```

Not just "useless", it can also be a devastating privacy problem.

There are many many people known to be identified (killed, raped, threatened, etc) on 4chan from the image metadata.

I think image metadata is a huge security & privacy problem (being useless can also be debated), especially for people who don't know what they are doing.

Meaning, the most people.

These can include: - Precise GPS coordinates of where a photo was taken - Date and time - Device information (camera/phone model) - Sometimes even your name or device owner information

Many people have been doxed just because they simply shared their iPhone pics.

metadata can be neat for your own personal memories through Google Photos or smth but for wider distribution metadata should be removed by default for privacy

At least most platforms strip metadata. The safest option, stripping it yourself before upload, is simply inaccessible to users, because they likely don't even know that their images have metadata

yeah, ~~stripping is always appreciated~~

I think you might be too zoomed in on one of the corners when color picking

there are smaller local sections that are indeed flat, but if you venture out of those local sections you can see the gradiation effect going

what can I use to transform scanned artworks into digital like? So instead of the little dots/circle, I would like a uniform color

maybe something like a median filter could do

is it some specific artbook or artist? fixed dpi ?

nope, just random scanned stuff from a BD box

unfortunately it is not really uniform, and it just blurs everything

I think for stuff like this AI-stuff might be good to use? But I just don't know any Waifu2x does not work ofc (even without `--noise 3`)

I know of a specific AI, but I don't have it on me atm

This is the best I can do using conventional methods

I just had this thought, curious what you guys think?

one way you might be able to do this for photon noise is to denoise the image, then synthesize luma-modulated noise back in at the intended scale, regardless of the scale of the image itself

https://github.com/cloudinary/ssimulacra2

I came up with this > 1. build a luma map of the image by denoising it and looking at the brightness of every part of the image. maybe use a filter to avoid bleeding between sudden changes in luma, like at object edges. > 2. trying to not capture non-photon-noise variance (global averaging? some sort of filtering?), find the global correlation between luma and photon noise for this particular image. > 3. build a photon noise map using that relationship and the luma map: for every part of the image, find out to which extent the variance in that part can be attributed to photon noise. > 4. using that metric, locally denoise the image proportoinally to how heavily photon noise contributes to the variance in that part. this avoids denoising fine textures that are not the result of photon noise. > 5. when viewing the image, using the photon noise map, synthesize photon noise back in at the intended viewing scale, so the noise is visible regardless of the scale of the image itself.

if you have a JXL that properly uses noise synthesis, the only step you'd need to do is step 5 by changing the default noise synthesis to a version that scales the noise to the UI scaling level of your OS

The encoder SHOULD try to measure how much noise was lost at the end of the encoding process, compared to the original. Then it could signal how much noise has to be added back to match the original image. Since smoothing out noise is a normal side effect of the lossy encoder...

oh right, I forgot to account for compression

Currently JXL does the opposite. You specify noise, it applies it and then subtracts it from the original image to improve compression

though you could also use the compressed image as original input

how I'm imagining it this would work on any existing image in a specialized viewer

At least, a side effect of the current version of libjxl. Not necessarily all lossy encoders

Yeah that's pretty bad...

does it actually? this would only improve compression if the synthesized noise happened to exactly match the original noise. or do you mean it denoises the image?

I actually thought there was no noise substitution logic at all currently, and noise synthesis was a purely additive step

Yes, it is purely added atm

How difficult would it be to add a diff at the end of compression and translate that diff into an iso number?

Bam, no more youtube videos of 2kliksphilip showing off smooth jxl next to grainy avif

it's surprising how little noise you actually lose with qualities above ~95%

at that point the data loss is more akin to slight changes in pixel values, not really removing the noise at all

even 90% has minimal loss of noise patterns, though it looks slightly smoothed out

Yes, there are still problems at d=1/q=90 though. And a lot more fidelity miracles can be squeezed out of much lower bitrates with the right techniques.

The problem with libjxl are superficial and correctable mistakes that undermine a very strong underlying core

(And a template-heavy spaghetti codebase in an incomprehensible folder structure that makes development harder)

Yea it does seem the 10 bit is smaller then the 8 bit for the most part of times. So I guess it is not a problem....

Yeah, it doesn't, it only uses the built-in photon noise. The `--noise` flag is meant to do the adaptive noise generation/subtraction, but currently it's broken/does nothing

```--photon_noise_iso=ISO_FILM_SPEED Add noise to the image emulating photographic film or sensor noise, default = 0. Higher values add more noise, e.g. 100 gives a low amount of noise, 3200 gives a lot of noise. --noise=0|1 Disable/enable adaptive noise generation, default = encoder chooses. 0 = disable. 1 = enable. It is recommended to use --photon_noise_iso instead.```

it could could probably really boost the apparent fidelity of very low quality JXL images too

it'll be harder to pick out compression artifacts among the noise that was already supposed to be there

Yes... that's called "noise masking"

:)

I knew about the phenomenon, didn't know it had a name

Yup! The whole theory of lossy compression is being able to hide or "mask" the distortion introduced by the quantization process, reducing precision and data in ways that are hard to notice by hiding it using techniques like this.

interesting 👀

Apparently I hallucinated that because I can't find anything about it now, but I'm sure either Jon or Mario said that photon noise does impact the underlying pixels to save some bits

I did, however, find the blog post I've been trying to find again for the past year. Turns out Kampidh had changed the URL so I thought I had already checked it before https://kampidh.com/whyjxl

Has a demo of photon-noise dithering, though only works on old browsers or with the Oxide extension since libjxl does dithering now

this code still stops from working on all the images: for i in *.png; do ((current++)); echo "Processing the image: ${i} [$current/$total]"; avifenc -a tune=iq -q 60 -d "10" -y "444" -s "0" "${i}" "new_${i%%.*}.avif"; echo "Processing completed: ${i} [$current/$total]"; done

Trying to make the files into avif makes it stop like halfway or so.

I have been working with Audio, on 'zimtohrli' full reference audio metric. My algorithmic work there is now complete, and only some productionization work left. I'll start the coming week to optimize quality of JPEG XL again, likely for 2-3 weeks to resolve the increased blurriness in 0.10 -- compared to 0.8

it is not clear if jpegli-JPEG is worse or better than AVIF for usual photography needs, i.e., relatively high quality

the pattern of the reduction in noise might not fit the curve of photon noise (but then, maybe it doesn’t need to be specifically photon noise that gets added)

the native mechanism to signal noise in jxl is the noise LUT; the `--photon_noise` parameter is just one way to generate a “natural-looking” LUT

in the context of making up for noise lost to compression, maybe a non-photon-noise LUT would be fine

Oh cool, I didn't know that noise can be flexibly signalled with different curves in jxl

it’s not perfect, because (in my view) we allocate too many LUT entries to high XYB values, so there is less precision in the values encountered in most images

The blurriness is a problem, yes... but I notice that compared to other state of the art codecs, libjxl actually is pretty amazing when it comes to preserving texture. The 3 big recurring problems in libjxl are excessive blurring/quantization in dark shadows in particular. Along with the 2 big chroma issues: excessive chroma ringing artifacts that look like colorful ripples across the whole image, plus a noticeable desaturation effect across the entire image (in the green-yellow and orange-red spectrums especially)

😃 I just had a bit of a panic moment, misinterpreting this comment https://github.com/libjxl/libjxl/blob/77cd542df9714955e35e4b1515682da651157cc7/lib/jxl/noise.h#L25 as a ratio rather than an “or” and trying to think through the implications / assessing the plausibility of that interpretation vs. the probability that I would have gotten photon noise to work despite overlooking something like that

Could always try testing an experimental bitstream format... 👀

these are the luminances that each LUT entry corresponds to

so, for a typical SDR image with intensity_target=255, slightly over half of the LUT is used

this is the code that fills the LUT for photon noise: https://github.com/libjxl/libjxl/blob/77cd542df9714955e35e4b1515682da651157cc7/lib/jxl/enc_photon_noise.cc#L62-L96

the actual computations are not super complicated (the reason for those specific computations may be less obvious), to the point that the first version of the port to libaom was a perl script

which I still have

Oh, so JXL had the noise first and it was ported to AVIF?

yes

9 July 2021: jxl https://github.com/libjxl/libjxl/pull/307 3 September 2021: aom https://aomedia-review.googlesource.com/c/aom/+/145301

(there as well, AV1 already had the underlying mechanism; the new code just generates tables of a certain kind)

embarrassingly, I have written a tool that can take a noisy image + a denoised version and return the likely `--photon_noise` parameter to use, but it returns values that correspond to the aom version, suggesting that this TODO https://github.com/libjxl/libjxl/blob/77cd542df9714955e35e4b1515682da651157cc7/lib/jxl/enc_photon_noise.cc#L85-L86 was warranted

So the chroma noise can be signaled independently of the luma noise? But what about the noise spectrum?

Can the spectral profile be signaled too?

I recently looked into it but there is no denominator that makes them match exactly, maybe because of the low-ish LUT precision

but I guess I could submit the value I found that seemed to get the closest to that

at the cost of disturbing existing users of the flag (by a constant factor, though, so easily adjusted)

no, the spectrum is whatever https://github.com/libjxl/libjxl/blob/77cd542df9714955e35e4b1515682da651157cc7/lib/jxl/dec_noise.cc generates, and it’s mostly achromatic

At least on the lower end of quality you see a pretty big difference of storage being used. Clearly AVIF is much mich better down on those levels.

Would it be scaling up or down? (Going up meaning ISO 250 is more like 300, ect)

would need higher values for the same amount of noise

current values would produce less

Previously encoded images will still look the same, only it would take higher cjxl parameter values to create those files now? I think that's fine for a relatively niche option like this

Wait, I thought SDR white corresponds to Y=0.85 or so?

hm, I should double-check that table

correct, it would only change “which value to pass to `--photon_noise` to get the same bitstream”

it wouldn’t affect the “bitstream -> decoded image” pathway

may I know what you did and the name of the "AI software" ?

No AI was used for that image, it's a Photoshop plug-in and some good old-fashioned elbow grease.

The AI was speaking of is a custom trained model, specifically for half tone images

I'm sure I can get an even better result but I forgot what it was called

The model somewhere on my computer I know it

Okay, this is the best result I could get with two AI models

the table matches what `enc_photon_noise.cc` calculates, so perhaps the latter needs fixing

(I wonder to what extent that explains the discrepancy with aom)

(that would be an interesting development)

Here ya go, I used this model: https://openmodeldb.info/models/1x-Bendel-Halftone With this software: https://github.com/chaiNNer-org/chaiNNer

thanks for all that information! [⠀](https://cdn.discordapp.com/emojis/674256399412363284.webp?size=48&name=av1_pepelove)

yeah I already have chaiNNer, so perfect

I had to downscale the image by 42% to get a good looking result

oh no ```diff diff --git a/lib/jxl/enc_photon_noise.cc b/lib/jxl/enc_photon_noise.cc index 75b21ca99..805238bf7 100644 --- a/lib/jxl/enc_photon_noise.cc +++ b/lib/jxl/enc_photon_noise.cc @@ -66,7 +66,7 @@ NoiseParams SimulatePhotonNoise(const size_t xsize, const size_t ysize, // scaled_index is used for XYB = (0, 2·scaled_index, 2·scaled_index) const float y = 2 * scaled_index; // 1 = default intensity target - const float linear = std::max(0.f, Cube(y - kOpsinAbsorbanceBiasCbrt) + + const float linear = std::max(0.f, Cube(y + kOpsinAbsorbanceBiasCbrt) - jxl::cms::kOpsinAbsorbanceBias[1]); const float electrons_per_pixel = electrons_per_pixel_18 * (linear / 0.18f); // Quadrature sum of read noise, photon shot noise (sqrt(S) so simply not ```

embarrassing

but if it fixes the discrepancy, I’ll feel more comfortable about submitting my estimation tool