JPEG XL

under Linux, too

Windows as well

I'm sure I remember seeing jpeg screenshots from my phone, but I think they reverted it in a firmware update

mpv is the only exception

in my experience

what AOSP does is it will always capture the image in PNG then send it to the exporter function, which AOSP supports jpeg png webp. but whether or not it does PNG WEBP or JPG is up to the rom itself since they will usually implement their own screenshot utility or modify AOSP

Ah, scrollshots were always jpeg at least

yeah that would be using a custom screenshot util probably.

Discord recompress jpeg again. Yep. But not upscaled

Isn't scrollshots an extremely new feature?

Android 12 or 13

back in, I want to say kitkat, AOSP only supported png

for aosp iirc it was introduced a11? but roms have had it for a very long time

🤣👉mpv

my axon 7 had it too

I think the number of roms that use AOSP's screenshot util is actually in the minority, not the majority

I think it must be Android 12...

my friend recommended mpv to me once. then I made this meme

I just checked at android11 did introduce the scroll screenshot

oh

ofc that does not mean all a11 phones have it, it depends on what a11 tag they based on

there have quite a few tags an A11 rom can be based on

I've already forgotten why different versions of android exist. After Android 6, it didn't make any sense.

the screen is there, the buttons are pressed, the application is working.

all I see is that applications size now 200+ megabytes each..... because. because Google play allowed it

yeah, and except for the UI, changes are rather incremental, it's like the switch from Windows 10 to 11

well there have been some major under the hood changes for things like project mainline.

hmm, yes...

Android versions are mostly a way to break compatibility

but not between all Android versions is that necessary

<@184373105588699137> why does Aosp not support jxl for screenshots? mm?

unlike for Windows, which cares a lot abut backwards compatibility

probably because skia for some reason still uses the gitlab for jxl xD

which is why it's such a bloated OS

android does try to maintain a degree of backwards compatibility, but not as significant as windows for sure. but the major thing for them is migrating as much as they can to mainline stuff so they can get rid of the years of tech debt they incurred. it's hard to keep in mind just how much is put into android to keep it somewhat functioning

yes, I put it wrong

well, it's a lot better then gnu distros xD

Android is quite backwards compatible, but they allow devs to use new Android system features at the cost of breaking compatibility with older versions

I remember Google made own core to replace android... haha.

the version scehem is supposed to keep that ordered

Google Fuchsia

indeed, they do try to encourage some backwards compatibility via ways of telling devs to use the minimum supported api for google play store, but at some point they do break compatibility, all because users refuses to stop shooting themselves in the foot, At the very least, it's not like you need to use these APIs if you dont target gplay store

this happens in the same way as application compatibility between win xp and win 11. the more independent the program was originally, the more likely it is that it will work. android 2.3 programs that just can't install

there is no problem with this in general. except for the memories. Current programs are supported by developers and just work.

I guess Android apps usually make much more use of system libraries, compared to Windows

<:BanHammer:805396864639565834> <:Android:806136610642853898>

well windows does also just have a killer legacy emulation system

Bad guys 👉x86 x86_64 armv8

https://readabilitylab.xyz/results?type=FAVORITE&idUserExternal=30020&user1=Lexend%20Deca&user2=Helvetica&user3=EB%20Garamond&user4=Noto%20Sans&user5=Avant%20Garde&top1=Noto%20Sans&top2=Times&top3=Avenir%20Next&top4=Helvetica&top5=Calibri&sentence=In%20our%20studies%20users%20read%20in%20their%20preferred%20font%20at%20an%20average%20words%20per%20minute.%20Also,%20they%20do%20not%20read%20faster%20or%20slower,%20on%20average,%20by%20reading%20in%20the%20commonly%20preferred%20fonts%20(Noto%20Sans%20and%20Times).

do you agree

i fixed the design

not metrics

i have the list of the font i did this summer

i have a font on my xiaomi with 20000 chactes

once is eapiued i tell the name of it

watching nsw videos esults it

https://readabilitylab.xyz/results?type=FAVORITE&idUserExternal=30020&user1=Noto%20Sans&user2=Roboto&user3=Arial&user4=Poynter%20Gothic%20Text&user5=Helvetica&top1=Noto%20Sans&top2=Times&top3=Avenir%20Next&top4=Helvetica&top5=Calibri&sentence=In%20our%20studies%20users%20read%20in%20their%20preferred%20font%20at%20an%20average%20words%20per%20minute.%20Also,%20they%20do%20not%20read%20faster%20or%20slower,%20on%20average,%20by%20reading%20in%20the%20commonly%20preferred%20fonts%20(Noto%20Sans%20and%20Times).

wuufwebuwfub

mpv doesn't use system screenshot feature

it dumps the video frame buffer

yes, I know

it's not really an exception

but encoding to JPEG is a choice

since we're referring to the system screenshot feature

well, mpv can also do actuall screenshots of itself with Ctrl + S

yes that's a VO_CTRL screenshot

on many android phones the system screenshot encoder is also a choice

true

my phone lets me pick between jpg and png, for example

but I've also only ever seen PNG as default (didn't really use the screenshot feature on my first phones)

and yes I'm very familiar with how mpv screenshots work, both with regard to hardware and software screenshots

use hi ocr screenshot

i'd like to have words with whoever decided pfms should be upside down

get in line

bmp does the same thing, right?

they can go both ways, depending on the sign of the height

well that's even worse

it's the TIFF philosophy: make it so that an encoder can just write some header and then dump memory. Nice for writing, very annoying for reading.

is/was bottom-to-top image data in memory that common?

Hi ocr screenshots has been lately slow

isn’t OpenGL also upside down?

opengl screen space coordinates are like the upper right quadrant of your typical math xy plane, IIRC. So origin in the lower left and +y going up and +x going right.

I thought I remembered the origin being in the top left, but I have very little experience with this so I might very well be wrong

It is, opengl is mirrored vertically from convention but origin is in the lower left so the whole image has positive coords

I always thought that lossy WebP's quality ceiling is entirely due to it always doing chrome subsampling, but in this article (https://giannirosato.com/blog/post/jpegli/) I saw that cjpegli 4:2:0 seems to consistently reach a higher quality level than WebP.

Does anyone have any insight on this?

after checking the parameters used it seems like for WebP `-sharp_yuv` was not specified in those tests which could have had an effect maybe? https://www.ctrl.blog/entry/webp-sharp-yuv.html

oh and also `-af` could have had a positive effect on the results as well

I might try to replicate the author's tests using those options tomorrow, then.

also iirc the author is in this server. **EDIT**: I meant for giannirosato.com not ctrl.blog (been awake too long and my reading comprehension is a bit low right now, apologies).

just double checked and yeah, their username is "gb82"

ah, yeah

just ping him <@703028154431832094>

yo

people have qestions about webp

what exactly?

> I always thought that lossy WebP's quality ceiling is entirely due to it always doing chrome subsampling, but in this article (https://giannirosato.com/blog/post/jpegli/) I saw that cjpegli 4:2:0 seems to consistently reach a higher quality level than WebP. > Does anyone have any insight on this?

I'd be willing to believe that lossy WebP does some sort of aggressive filtering to remove artifacts that helps at med/low quality but not at higher fidelity. kind of characteristic of video codecs that are repurposed as image codecs

also speaking of your site, I tried using jxl-oxide for the corpus page, and it works way better, but much slower, for some reason chrome and firefox wont render the image while another image is decoding though which causes it to look like its taking way longer then it is

3 images are done decoding in jxl, and sent to the browser for rendering but since browser is stupid it stops rendering them LOL

this is literally the stupidest thing ever and the only reason why jxl-wasm isn't a good idea

its still better then firefox though which will just give up for some reason, on chrome based, only 10 fail to load

also apparently one of the images is kinda busted

😭

<@703028154431832094> could you send me the original images you used in that blog post? I want to replicate your tests.

Oh boy, I'll see if I can find them tonight

Jxl sucks

https://www.youtube.com/watch?v=oIQWsQNW20Q

<@245794734788837387> with the image I tested (cathedral from imagecompression.info), af makes no difference at the highest qualities, but sharp yuv lets it reach a very slightly higher score:

Next I suppose I'll test jpegli 420 and see how it goes

Still only testing one image, but here's mozjpeg vs jpegli vs webp

larger range and logarithmic x axis:

and does anyone here have any good pointers on the correct way to average the results of comparisons like this across several images?

I have recently been researching several image formats for storing personal photos. Initially, I was familiar with webp, as it has broad support. There is also avif, which is considered better than webp. At first, I thought it was a good choice until I encountered a concern raised in the comments of an issuehttps://github.com/AOMediaCodec/av1-avif/issues/111#issuecomment-717710961 > Not only that, but AVIF lossless isn't even true lossless, since it requires the image be converted to yuv4:4:4 or yuv4:2:0, which means if your image is originally RGB, you're incurring a lossy conversion just by changing from RGB to YUV. I've heard of ways in which the image can be losslessly converted between RGB and YUV, but that is unorthodox and I do not recommend it. Consequently, I turned to JXL. In fact, I was initially aware of the JXL format, but the inclusion of 'JPEG' in its name made me perceive it as somewhat outdated. However, I later discovered that my assumption was incorrect.

AVIF sucks

avif isn't designed for lossless (it's video codec anyway)

webp lossy is based on video codec, but webp lossless is completely different codec designed for lossless

yes, but I don't know why they made this decision... > it requires the image be converted to yuv4:4:4 or yuv4:2:0, which means if your image is originally RGB, you're incurring a lossy conversion just by changing from RGB to YUV

I guess it's not a problem if it's lossy video

storing RGB video is kinda not fun unless you have specific needs like a mezzanine. and for images, well the current av1 encoders really isn't superb at higher fidelities anyways, at least in terms of single images. JXL and avif are quite complimentary IMO

that's actually not true, you can store RGB444 AVIF

but tbh I'd rather use PNG

it is, AVIF can store RGB444 but it must convert to YUV first

cant aomenc encode RGB directly? if so that sounds like a limitation of whatever tool that is no?

No no, you don't have to - of course that makes the already abysmal compression rate even worse, so I can't see a single reason why anybody *would*, but you can

cavif-rs can encode to rgb but files will end larger

isnt cavif just a encoder + muxer for rav1e?

So can avifenc, if you pass the correct cicp parameters

you are right, it's bug in imagemagick.

❯ avifenc -l d.png -o output_image.avif ❯ magick compare -metric MAE d.png output_image.avif null: 0 (0) ❯ magick -quality 100 d.png d.avif ❯ magick compare -metric MAE d.png d.avif null: 289.032 (0.00441035)

I just noticed that it took 10s to encode a 560KB PNG to a lossless avif. JXL fantastic!

lossless avif is a waste of everyone's mental energies to even think about 😛 just use pretty much any other lossless format, it will be better

One difference between webp and jpeg is that webp uses tv range ycbcr while jpeg uses full range. Also I think the minimum dct coeff dequantization constants in webp are not 1 like in jpeg but 4, not sure if the dct scaling compensates for that or not...

Avif can do lossless and progressive just like jxl can do animation: the feature is there, box can be checked (but it wasn't designed for that)

makes sense, thank you

right, the j in ffmpeg's legacy pix_fmts (yuvj444) stands for jpeg iirc

Now to figure out the correct way to make this make this easier to look at...

like, what's the correct notion of average here?

for each tool and settings combination, I essentially have a tuple of (quality setting, score, bpp). I think gb82 simple took the arithmetic mean of both the score and the bpp for each quality setting, which seems useful for figuring out which quality option to pick when putting something into production, but I don't think its' the only option. I was thinking it might be good to go by iso-score instead of quality option, to find the average bpp needed to achieve some particular score, but that has the issue that the images don't have the same ranges of scores, and of course that no two datapoints have exactly the same score.

if you're plotting on a log scale then would geo mean be better?

Based

for those who do not know, I repeat: webp has a separate algorithm for lossless compression. jxl has a separate algorithm for lossless compression. avif does not have this. it uses the same algorithms as for lossy compression. avif lossless is a complete analogue of jpeg loseless

but it's funny that the webp lossless algorithm is called VP8L

what if, instead of a score, you plotted the difference of score between the contender and the reference (ex: reference would always be jpegli yuv444 or jpegxl -e6), as such, if you have more than one image to plot, we could hope that the deviation of score relative to the reference would show some patterns easier to interpret

such a comparison could make sense, yeah

Here's what I'm thinking. For every theoretical ssimulacra2 score, I check which test images have at least one score bigger and smaller than that, then I compute a theoretical bpp for the current score I'm plotting, by first linearly interpolating between the real scores for each relevant image, and then taking the arithmetic mean of those values.

I don't think so? Arithmetic average for bpp means that you could in principle take that value and multiply it by the total number of pixels in all your photos to get a good idea of how much space they will take up, if they are average-ish.

actually, not a good idea because shap jumps are introduced whenever a new image joins the average

what I can do, is limit it so that it only takes the average for values defined for all images

that does result in some of them being rather cut short. might be OK at the high end of quality, but I think I need to regenerate my data down to q=0 for all the tools. (I used q=30 as the lowest quality setting when I generated this data)

worked pretty well, I'd say.

the curve is nice, the average is computed on what ?

isn't median more meaningful ?

Bits per pixel at the given ssimulacra2 score

Median would tell you that half the images are bigger and half are smaller, mean tells you how much space each image takes on average. Both are meaningful.

i think median is more meaningful

mean can be heavily skewed by outliers

JPEGli 420 was with xyb

How you got 40% reduction in the second slide

It seems 22% to 4,004 better than mozjpeg

Like always there's no news in that

I did not use 420 with XYB, because the results were very terrible.

that was just the result

I just re-ran the tests this time down to quality setting 1 in all the tools, to get better coverage at lower qualities

will do median later

oh, and the combined average of all the images instead of the group split:

How is q 66.17 444

Vs q 84 420

And 76.92 444

I don't know. I only tested whole integer quality options

would you mind to share the array of your results ? like in a google sheet ? so we could play with the way to represent them 🙂

why didn't you included jpegxl also ?

didn't get around to it yet. I run a script to do it and avif over night.

I think it should be like ' to convert existing jpeg to jxl losslessly' for other formats add -d 0 or -q 100.

yea, the Arch wiki page isn't the best... but it's a start

I’ve reworded it slightly

c'est mieux 🙂

It will improve with the blessings of <@416586441058025472>

please no

optimal settings: -d 0.1458934

`-d 3.14159265359`

-d 2.7182818284590452353602874713527 is also good.

what about `-d 1.61803398875` ?

sqrt(2) for a distance would be very appropriate 😄

what about negative distance

i want better than lossless

-d √(-1)

imaginary quality ? would it be enough for you <@167023260574154752> ?

hmmm

don't do it man, you'll avtivate the skynet

Complex Qualities are incomparably good!

I'd like to use surreal qualities. -d 1/inf, not lossless, but the differences are smaller than any positive real

<@853026420792360980> is libplacebo integration in ffmpeg have access to full settings? `extra_opts` has a very unclear description e.g. how can I set mpv-like settings `--dscale=ewa_robidoux --dscale-param1=0 --dscale-param2=0` for fffmpeg? `downscaler_param1=0` etc doesn't seem to work

I don't know, I'd have to read the manpage

~~just encode using mpv itself~~

mpv encoding was a mistake

I don't think very many people will contest that lol

yeah, but there's only this and it's not really clear which options actually work

you can use anything from libplacebos options.c in it

how encode this

I can't open it with absolutely nothing, but I want to note that Windows calmly decoded the png line by line in streaming mode and created preview (in a minute) **mozjpeg-v4.1.1 Insufficient memory (case 4)** **cwebp.exe Decoding failed.Status: 3(BITSTREAM_ERROR)**

libjxl ate 5 gb of RAM, thought for 20 seconds, and died

but but who drew the image that big?

neural network

oh ok

hm.

I was able to encode jpeg, but not jxl

visp mozjpeg takes the same memory error as mozjpeg when using the optimize_coding parameter. So I decided to try to encode the image via mozjpeg.... And... And how to turn it off?? there is no parameter here

🙄

you have to use `-revert`

That's great! jpeg encoding now takes up 2 megabytes of RAM

hmm... it's a curious jpeg file, it's very compressible with general purpose compression algorithm

because disabling huffman is what I did. therefore, huffman compression in zip is to do it instead of huffman in jpeg

Mac people - can someone open this in Preview & tell me if there are a bunch of green and black lines that show up after waiting a second or zooming in?

In Preview only, yes, eventually the green lines show up (opens fine at first). Opened in Safari the green lines never show up even after extensive zooming. MacBook Pro, M2 chip, 16GB RAM, Sonoma 14.2.1

I wonder why... So strange

I'm gonna do a feedback report

https://youtu.be/DMQ_HcNSOAI

this happens when I try to build libjxl-metrics-git from the AUR... ``` a2x: ERROR: "xmllint" --nonet --noout --valid "/home/damian101/.cache/yay/libjxl-metrics-git/src/build/djxl.xml" returned non-zero exit status 4 a2x: ERROR: "xmllint" --nonet --noout --valid "/home/damian101/.cache/yay/libjxl-metrics-git/src/build/cjxl.xml" returned non-zero exit status 4 make[2]: *** [CMakeFiles/manpages.dir/build.make:78: djxl.1] Error 1 make[2]: *** Waiting for unfinished jobs.... [ 4%] Building CXX object lib/CMakeFiles/jxl_extras_codec-obj.dir/extras/exif.cc.o make[2]: *** [CMakeFiles/manpages.dir/build.make:74: cjxl.1] Error 1 make[1]: *** [CMakeFiles/Makefile2:393: CMakeFiles/manpages.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... ```

Does anyone have any experience with machine learning? I want to use the butteraugli, and perhaps another, broader, psychovisual metric as a way to train a neural network to emulate the jpeg processing processing my camera does on raw files, so that I can use its look in a lossless format (probably jxl). I know there's software out there that will do this, but most of it is proprietary and I want to get in to neural network programming and have a command line solution available.

I have thousands of raw files and thousands of jpegs to train from, though now that I think about it I might need to preprocess the jpegs so that it doesn't end up just emulating the lossy compression as well

that's a lot of effort just to end up with reduced image quality <:thinkies:895863009820414004>

also, butteraugli is really slow for such a thing

better use the original ssimulacra2 implementation if you want something robust and reasonably fast

You're right. Since I have the original raw files I should start with removing the compression artifacts before I continue. I'm just less clear on how to do that, as the visual difference between raw and in camera processed jpeg can be quite high

oh

it's not about the JPEG compression artifacts

but the processing that happens before the JPEG encoding

It's about copying the image processing over

was confused, haha

Yeah

This should be more than adequate for what I want to do

yeah

It's a bit of a chicken and the egg situation, though. Do I attempt to copy the look, first, and then use that to remove the artifacts so that my model can be retrained to not copy over the artifacts, or do I attempt to remove the artifacts some how

And then the look

I wish cameras weren't such black boxes, but there's no custom firmware solution to figure out what it looks like before being sent to the jpeg

a large part is probably simple per-pixel operations that are the same throughout the image

Yes, it has to be mostly a LUT and then some very non computationally intensive additional changes

right

I've tried emulating the look, myself, and it's surprisingly difficult. The exact processing steps are definitely something companies invest a lot of money into

Many camera makers provide their proprietary raw converters that can convert exactly as camera does, and these converters for sure can save tiffs

Yes, this is definitely the best option at the moment to get better training data. I'm going to see what's available for Panasonic

Hmm. I was able to find a proprietary solution that's exactly this, but it's only available for canon cameras. I can at least start there with my old canon raws

For Panasonic the "native" raw converter is SILKYPIX Developer Studio SE, unfortunately 😦

is it that terrible?

It is just "generic" converter, not native to Panasonic. But yes, in my opinion it is terrible in terms of usability. But idk how it is in terms of mimicking Panasonic in-camera jpeg look

I wanted to know the correct way to resize sRGB images with ImageMagick, in linear RGB, and this is what I got from the docs... ``` magick portrait.jpg -gamma .45455 -resize 25% -gamma 2.2 \ -quality 92 passport.jpg ``` >.>

*triggered*

ok, it seems what you should do, mentioned in a more obscrure part of the docs, is ``` magick foo.png -colorspace RGB -resize 25% \ -colorspace sRGB foo.png ``` unless you're using an older version of IM in which case the the colorspace options should be swapped around, as the sRGB option converted FROM sRGB and the RGB option converted TO sRGB.

``` ffmpeg -i input.png -vf libplacebo output.png ``` :D

scales in linear light by default if the input is tagged properly

nice. If it isn't tagged at all, does it assume sRGB? And where can I read about how to pass the right options to libplacebo?

if it's not tagged I don't know if it assumes sRGB or if it scales in the previous space

you can always test it

aye

doesn't seem to like my computer, hm ``` [libplacebo @ 0x7fdaad9a8080] Missing vulkan hwdevice for vf_libplacebo. ```

sounds like you're missing the vulkan headers

or the vulkan driver

what GPU? amd? intel? nvidia?

Intel iGPU from 2015, but I do have Vulkan and a properly functioning driver

are you using git master FFmpeg?

nope

what version?

I ask cause vf_libplacebo currently automatically initializes a vulkan hwcontext if one is not provided

but this didn't always used to be the case

I ran `ffmpeg -init_hw_device vulkan ...` and got the message ``` [libplacebo @ 0x7f0e50e79b00] Missing device feature: hostQueryReset``` Versions are ``` ffmpeg version 6.0.1 libplacebo-6.338.1```

looks newer than the last fixed issue I found when googling that error

that's a bug in older FFmpeg

ah, fixed in 6.1?

yea, Lynne's fixes were merged in 6.1

TY

``` Apr 30 13:00:44 <Traneptora> Lynne: where's your branch so I can test it? Apr 30 13:02:26 <Lynne> https://github.com/cyanreg/FFmpeg/tree/vulkan Apr 30 13:03:00 <Traneptora> ty Apr 30 13:03:46 <Traneptora> shouldn't be this hard for a girl to scale in linear light up in here Apr 30 13:11:05 <Traneptora> Lynne: [libplacebo @ 0x55ccd473f540] Missing device feature: dynamicRendering, what does this mean? Apr 30 13:11:39 <Traneptora> I have an nvidia GTX 1070, is that actually missing or is this some driver/bug/etc. issue Apr 30 13:14:05 <Lynne> it's my fault Apr 30 13:14:30 <Traneptora> would you like a log? Apr 30 13:14:33 <Traneptora> or do you know what's up Apr 30 13:15:29 <Lynne> fixed Apr 30 13:17:37 <Traneptora> thanks, now it's missing hostQueryReset Apr 30 13:17:41 <Traneptora> [libplacebo @ 0x5620635d9e00] Missing device feature: hostQueryReset Apr 30 13:20:03 <Lynne> thanks, fixed Apr 30 13:21:33 <Traneptora> looks like that did it, thanks ```

here's an IRC log

for context

6.0 was released Feb 28

mm

6.1.1 was just released

try that

apparently my distro upgraded to 6.1 several weeks ago, so I just need to update my computer

noice

a number of nice libjxl fixes are in 6.1 as well

notably the jpegxl parser

nice

hooray it's working ``` MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:794: FINISHME: support more multi-planar formats with DRM modifiers ```

hooray `ffmpeg -i foo.png -vf "libplacebo=w=iw*0.5:h=-1" bar.png`

drivers 😔

glad it works tho

now to test how it does with the color spaces and stuff

wdym?

^

o that

yea

alright, it seems my file is indeed untagged. So I guess I'll tag it and see if there's a difference 🤔

lol, when you write a file using ImageMagick and specify sRGB, ffprobe finds the following information in it: ``` color_transfer=unknown color_primaries=bt709 ``` color_transfer is what should tell it whether it's linear or sRGB, right?

-color_trc before the -i

danke

if libplacebo gets an unknown transfer function itll leave it untouched if possible but otherwise assumes gamma22 afaik

at least for (de)linearizing and sigmoidization

>gamma 2.2

https://cdn.discordapp.com/emojis/657641202945884160.webp?size=48&name=SweatingTowelGuy&quality=lossless

`-color_trc srgb`, right?

oh, `iec61966-2-1` seems to work

yes, or 13

for PQ, I generally write “smpte2084”, but for sRGB and HLG, usually just 13 and 18 respectively

can’t be bothered to look up their ffmpeg names

ffmpegs input color options are such a pain to look up (google never finds them somehow) that i just ffinfo or ffmpeg -f null - a file that has the curve / colorspace / matrix that i want and just copy it from there

come to think of it, I think part of why I remember that PQ and HLG are 16 and 18 is `avifenc`

`--cicp 9/16/9` for Rec. 2020 primaries, PQ TRC and Rec. 2020 non-constant luminance matrix

it does not

check the chunks, I'm guessing it has `cHRM` and `gAMA`

avcodec compares `cHRM` to the values in H.273 and if it matches a known tag, it uses that (provided `iCCP`, `cICP`, or `sRGB` are absent)

however, it doesn't attempt to interpret `gAMA`

I could fix that, tbh

it means you’ll have to deal with the broken PNGs from ImageMagick

those meant to be sRGB but with a gAMA=0.45455 and no sRGB chunk

no, I mean, there's an H.273 entry for gamma22

or rather, gamma22, gamma28, gamma26, and gamma1 have H.273 entries

right, but then, PNGs that were intended to be sRGB will be interpreted as gamma 2.2

(although in fairness, that’s already happening in Chrome)

wait, I lied

```c /* these chunks override gAMA */ if (s->iccp_data || s->have_srgb || s->have_cicp) { av_dict_set(&s->frame_metadata, "gamma", NULL, 0); } else if (s->gamma) { /* * These values are 100000/2.2, 100000/2.8, 100000/2.6, and * 100000/1.0 respectively. 45455, 35714, and 38462, and 100000. * There's a 0.001 gamma tolerance here in case of floating * point issues when the PNG was written. * * None of the other enums have a pure gamma curve so it makes * sense to leave those to sRGB and cICP. */ if (s->gamma > 45355 && s->gamma < 45555) avctx->color_trc = frame->color_trc = AVCOL_TRC_GAMMA22; else if (s->gamma > 35614 && s->gamma < 35814) avctx->color_trc = frame->color_trc = AVCOL_TRC_GAMMA28; else if (s->gamma > 38362 && s->gamma < 38562) avctx->color_trc = frame->color_trc = AVCOL_TRC_SMPTE428; else if (s->gamma > 99900 && s->gamma < 100100) avctx->color_trc = frame->color_trc = AVCOL_TRC_LINEAR; } ``` pngdec.c line 698

<@167023260574154752> can you produce a quick sample and attach it?

theoretically if it's tagged as `gAMA=45455` it should report the TRC as GAMMA22, not unknown

how disappointing, they haven’t reopened the bug even after you pointed out that it was still present

https://github.com/ImageMagick/ImageMagick/issues/4375

nvm, I figured it out

it's leaving out `gAMA`

yea, it leaves it untouched if possible

iirc it doesn't scale in gamma22 light

it just leaves it untouched

yea thats what i said does nothing if possible but assumes gamma22 for (de)linearizing if the curve is unknown

oic

I misread

by default it downscales sdr in linear and upscales sdr in sigmoid (which passes through linear). so if it cant figure out the curve it undoes a gamma of 2.2 even if thats not what the real input has

hdr scaling is always just done in whatever curve it has afaik

sigmoidization doesnt apply since it clips to 0..1 and linear apparently looks bad according to comments in the code. ive thankfully never really had to deal with hdr so i dont know

I left another comment with more explicit evidence to bump it

cHRM, yep

(sorry I was away preparing a dough for baking)

oh, is imagemagick not writing a gAMA chunk anymore?

or is umbrielpng just not displaying it?

looks like it's writing cHRM only

umbrielpng would display it if it were being written, since it prints all chunks

here's an example from an older file

``` leo@gauss ~/Pictures/test_images :) $ umbrielpng granite.png PNG signature found: granite.png Chunk: IHDR, Size: 25, Offset: 8, CRC32: 31107cf8 Chunk: gAMA, Size: 16, Offset: 33, CRC32: 0bfc6105 Chunk: cHRM, Size: 44, Offset: 49, CRC32: 9cba513c Chunk: PLTE, Size: 48, Offset: 93, CRC32: f475ecb5 Chunk: bKGD, Size: 13, Offset: 141, CRC32: 68d0f456 Chunk: tIME, Size: 19, Offset: 154, CRC32: 2b92ca26 Chunk: IDAT, Size: 5959, Offset: 173, CRC32: 5485769b Chunk: tEXt, Size: 61, Offset: 6132, CRC32: ef51a8ef Chunk: tEXt, Size: 49, Offset: 6193, CRC32: 7b1043ba Chunk: tEXt, Size: 49, Offset: 6242, CRC32: 0a4dfb06 Chunk: IEND, Size: 12, Offset: 6291, CRC32: ae426082 Size: 128x128, Color: 4-bit Indexed cHRM matches sRGB space ```

the only thing it *doesn't* print is every IDAT chunk, instead it prints a message that more IDATs occur consecutively

e.g.

``` $ umbrielpng test.png PNG signature found: test.png Chunk: IHDR, Size: 25, Offset: 8, CRC32: fab5570d Chunk: pHYs, Size: 21, Offset: 33, CRC32: 84791773 Chunk: sRGB, Size: 13, Offset: 54, CRC32: d9c92c7f Chunk: cHRM, Size: 44, Offset: 67, CRC32: 9cba513c Chunk: gAMA, Size: 16, Offset: 111, CRC32: 0bfc6105 Chunk: IDAT, Size: 4108, Offset: 127, CRC32: e4c005e2 Chunk: 492 more IDAT chunks Chunk: IEND, Size: 12, Offset: 2022977, CRC32: ae426082 Size: 1080x720, Color: 8-bit RGB cHRM matches sRGB space ```

right, I just retested with the images I originally attached to the bug report, and it seems imagemagick is dropping the gAMA chunks now, even when originally present

```shell $ pngcheck -v output/image-sRGB-cHRM-gAMA.png File: output/image-sRGB-cHRM-gAMA.png (81293 bytes) chunk IHDR at offset 0x0000c, length 13 256 x 192 image, 24-bit RGB, non-interlaced chunk cHRM at offset 0x00025, length 32 White x = 0.3127 y = 0.329, Red x = 0.64 y = 0.33 Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.06 chunk bKGD at offset 0x00051, length 6 red = 0x00ff, green = 0x00ff, blue = 0x00ff chunk IDAT at offset 0x00063, length 32768 zlib: deflated, 32K window, maximum compression chunk IDAT at offset 0x0806f, length 32768 chunk IDAT at offset 0x1007b, length 15464 chunk tEXt at offset 0x13cef, length 37, keyword: date:create chunk tEXt at offset 0x13d20, length 37, keyword: date:modify chunk tEXt at offset 0x13d51, length 40, keyword: date:timestamp chunk IEND at offset 0x13d85, length 0 No errors detected in output/image-sRGB-cHRM-gAMA.png (10 chunks, 44.9% compression). ```

oo, what's pngcheck?

why did I write my own program to do that

~~the answer is cause --fix is an argument~~

umbrielpng has a `--fix` argument or `-o` which lets it do things I personally like to do to PNG files

the main annoyance with pngcheck is that it errors out on new chunks like cICP / cLLi / etc.

Umbrielpng's primary purpose is to normalize PNG files

```shell $ pngcheck -v .../ClassE_507.png File: .../ClassE_507.png (3235710 bytes) chunk IHDR at offset 0x0000c, length 13 944 x 1080 image, 48-bit RGB, non-interlaced chunk iCCP at offset 0x00025, length 2181 profile name = 1, compression method = 0 (deflate) compressed profile = 2178 bytes chunk cHRM at offset 0x008b6, length 32 White x = 0.3127 y = 0.329, Red x = 0.708 y = 0.292 Green x = 0.17 y = 0.797, Blue x = 0.131 y = 0.046 chunk cICP at offset 0x008e2, length 4: illegal (unless recently approved) unknown, public chunk ERRORS DETECTED in .../ClassE_507.png ```

Now I've actually done the test I talked about earlier. All of these produce files which ImageMagick says have a PAE of 0 against each other: ``` ffmpeg -i Untagged.png -vf "libplacebo=w=1000:-1" TestUntagged.png ffmpeg -i TaggedPrimaries.png -vf "libplacebo=w=1000:-1" TestTagged.png ffmpeg -color_trc iec61966-2-1 -i TaggedPrimaries.png -vf "libplacebo=w=1000:-1" TestTagged+TRC.png ```

It does the following changes with `--fix`: - strips all of the following chunks unconditionally: `bKGD, eXIf, pHYs, sPLT, tIME, tEXt, zTXt, iTXt` - strips `sBIT` if it matches the depth of the image data - strips `hIST` if `PLTE` is not present - strips `tRNS` if the image has no alpha - normalizes color space chunks\* - combines all `IDAT`s into one

off topic but what is up with the capitalization of PNG chunks?

eXIf

> A sequence of four bytes defining the chunk type. Each byte of a chunk type is restricted to the hexadecimal values 41 to 5A and 61 to 7A. These correspond to the uppercase and lowercase ISO 646 [ISO646] letters (A-Z and a-z) respectively for convenience in description and examination of PNG datastreams. Encoders and decoders shall treat the chunk types as fixed binary values, not character strings. For example, it would not be correct to represent the chunk type IDAT by the equivalents of those letters in the UCS 2 character set. Additional naming conventions for chunk types are discussed in 5.4 Chunk naming conventions.

here's a direct link to section 5.4

https://www.w3.org/TR/png-3/#5Chunk-naming-conventions

ahhh

the whole thing is a single C file 🤔

basically: first letter uppercase = Critical first letter lowercase = Ancillary second letter uppercase = public i.e. specified second letter lowercase = private i.e. implementation-dependent third letter uppercase = required third letter lowercase = reserved fourth letter uppercase = unsafe-to-copy fourth letter lowercase = safe-to-copy

it's like 1k lines, that's perfectly acceptible

yeah

oh no it depends on glibc so I can't build it

by *normalizes colors* here's the logic: - If the input contains cICP, and it's not actually just sRGB, then forward it, and strip any other color chunks. - Otherwise, if the input contains iCCP (and not cICP), and it's not actually sRGB, then forward it, and strip any other color chunks. - Otherwise, determine if the input is actually sRGB. This means cICP that just specifies sRGB, an iCCP that's actually sRGB, an sRGB chunk, an entirely untagged file, or a file that's tagged only with cHRM which matches the bt709 primaries. If the input is sRGB, then write an sRGB chunk and strip any other color chunks. - Othewrise, forward all color chunks as-is.

```c default_srgb = data.cicp_is_srgb || (!data.have_cicp && (data.icc_is_srgb || (!data.have_iccp && !data.have_srgb && !data.have_gama && (!data.have_chrm || data.chrm_is_srgb)))); ```

it does what?

pretty sure I follow the C spec

I just went thru it. The only problem is that it includes error.h

That's a glibc header

But you don't seem to be using any functions or variables from it

perror

I thought perror was in error.h

that's in stdio.h

oh, then I'll just remove error.h

👍

error.h has the functions `error()` and `error_at_line()`

is strings.h a problem?

I don't think so

I use strcasecmp

I think that's POSIX so should be fine. Compiles without error after I remove error.h.

need `-lz` but ye

yep it's working

though that caused me to notice something annoying

hm?

I must've done something wrong here because those output files didn't actually get resized

did you do `w=1000:h=-1`?

guessing the `-1` is treated as an arg and not a kwarg and overrides w=1000 which is the first arg

d'oh I messed it up when editing it

so you end up with `-1:-1` which is the input

alright, now I did it correctly

output from untagged input compares as equal to output from primaries tagged input. Tagged input with the `-color_trc` option has a slight difference.

this is what umbrielpng does to the default rose

``` leo@gauss ~ :) $ magick convert rose: -colorspace sRGB rose.png leo@gauss ~ :) $ umbrielpng --fix rose.png PNG signature found: rose.png Chunk: IHDR, Size: 25, Offset: 8, CRC32: 1aebf8e4 Chunk: cHRM, Size: 44, Offset: 33, CRC32: 9cba513c Chunk: bKGD, Size: 18, Offset: 77, CRC32: a0bda793 Chunk: IDAT, Size: 6754, Offset: 95, CRC32: 113ce85f Chunk: tEXt, Size: 49, Offset: 6849, CRC32: abf2b86c Chunk: tEXt, Size: 49, Offset: 6898, CRC32: daaf00d0 Chunk: tEXt, Size: 52, Offset: 6947, CRC32: 8dba210f Chunk: IEND, Size: 12, Offset: 6999, CRC32: ae426082 Size: 70x46, Color: 8-bit RGB cHRM matches sRGB space Writing chunk: IHDR Inserting default sRGB chunk Stripping chunk: cHRM Stripping chunk: bKGD Writing chunk: IDAT Stripping chunk: tEXt Stripping chunk: tEXt Stripping chunk: tEXt Writing chunk: IEND leo@gauss ~ :) $ umbrielpng rose.png PNG signature found: rose.png Chunk: IHDR, Size: 25, Offset: 8, CRC32: 1aebf8e4 Chunk: sRGB, Size: 13, Offset: 33, CRC32: d9c92c7f Chunk: IDAT, Size: 6754, Offset: 46, CRC32: 113ce85f Chunk: IEND, Size: 12, Offset: 6800, CRC32: ae426082 Size: 70x46, Color: 8-bit RGB leo@gauss ~ :) $ ```

the primary reason I wrote this honestly was to normalize output from GIMP

since it writes a lot of crap and I personally cba to uncheck all the boxes all the time

laziness breeds productivity

the way it checks if `iCCP` is actually sRGB is that it checks the tags for `rTRC` `gTRC` `bTRC` `wtpt` `rXYZ` etc.

and they all have to match

it ignores other parts of the profile like black point specification because those are irrelevant for SDR

it was the best I had for working without a CMS

it returns a negative for ICC profiles with a LUT TRC, it only works with `para` tags

I notice that on the images that got output by ffmpeg, the one from untagged input has untagged output and thus gets an sRGB chunk. For the one whose input had a cHRM only, it sees that it matches sRGB, and writes both an sRGB chunk and the cHRM. And finally the one produced by telling ffmpeg about the transfer function has umbrielpng remove both the cHRM and the gAMA, and writing an sRGB chunk.

umbrielpng should not replace cHRM and gAMA together with sRGB

since that's incorrect

it assumes sRGB for anything that isn't tagged, but it doesn't assume sRGB TRC if gAMA is explicitly present

unless it's overridden by another chunk like the sRGB chunk

only cHRM: ``` cHRM matches sRGB space Writing chunk: IHDR Inserting default sRGB chunk Stripping chunk: pHYs Writing chunk: cHRM Writing chunk: IDAT Writing chunk: IEND ``` cHRM and gAMA: ``` cHRM matches sRGB space Writing chunk: IHDR Stripping chunk: pHYs Writing chunk: sRGB Stripping chunk: cHRM Stripping chunk: gAMA Writing chunk: IDAT Writing chunk: IEND ```

first instance is a bug I fixed an hour ago

ah

second one is cause the input also had sRGB

talk about bleeding edge software

so the gAMA is ignored

oh, yeah, didn't notice that

alright excellent I have the latest and greatest version

<@178524721023811584> update, apparently the line you linked in src/shaders/colorspace.c is only if they use really low level APIs

for higher level api users e.g. vf_libplacebo it defaults untagged to bt.1886

it linearlizes it assuming bt.1886 and then unlinearizes it with the inverse

roundtripping, and scaling in linear light

notable lines: https://github.com/haasn/libplacebo/blob/master/src/colorspace.c#L599-L600

then it falls through here and roundtrips https://github.com/haasn/libplacebo/blob/master/src/colorspace.c#L635-L640

a few months ago there also was a bug where if you upscaled linear input w sigmoidization enabled, the input got interpreted as gamma22 no matter what

i think thats fixed now though

(i found that through the shader output, where it printed the line i linked earlier)

I turned out that when encoding a static image for x264 video, it is better to use Ultrafast, because other modes that include various algorithms do not give any better, but very actively use service information clogging the stream <:H264_AVC:805854162079842314>

For x265?

what's the sense if discord doesn't support <:H265_HEVC:805856045347242016>🧐

Oh

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

What about Opus?

AAC-HE is just better than OPUS at bitrates of 8-16 kbps

Ah, I thought it was closer to 32 at least

even VORBIS is better than OPUS at bitrates of 8-16

what ! you say they lied to me ?!

I'll never understand opus authors decision to force 48 kHz sampling rate and absence of "quality level" encoding. I believe that giving the only possibility to encode to target bitrate is absolutely stupid - not handling different sampling frequencies, not handling different material complexity, nothing. The same goes to 48 kHz. They claim that opus is better than other audio codecs, but with this inevitable useless resampling - how can it be better?

perhaps because you can always convert to 48kHz with a noise floor under the perceptible level

But for what reason? Why just not add native 44.1 kHz encoding, if there are SO many records with this sampling frequency?

it simplifies things and resampling is cheap and effective

ive yet to meet anyone who can tell the difference between 44.1 and 48 when resampled with sox or pipewire

Well, let it be. I'm just avoiding opus because of these two flaws. Yes, probably the result of resampling is imperceptible, but it just annoys me too much 🤷‍♂️

in the end, opus is a distribution codec, its laser focused on distribution, and thats why they made the choices they did and in the end it works great for it

Opus can technically speaking handle 44.1 kHz is you *really* want it to, it just won't give as good results.

> I believe that giving the only possibility to encode to target bitrate is absolutely stupid - not handling different sampling frequencies, not handling different material complexity, nothing. well, the target bitrate isn't actually a target bitrate. For more complex material, the real bitrate will be higher than the target, and for simpler material, it will be lower.

and live transmission. When you're encoding a voice call, the input is probably already 48kHz anyway.

I think I've asked before, but I'll ask again in case someone has an answer now: is there any way to go from gainmap JPEG -> HDR JXL?

as far as I can tell, that would involve recompression from pixels to JPEG XL

something interesting, FIUF-like scalable lossy/lossless compression comparisons plots only with psnr, but anyway, as some concept ```SQZ provides very competitive image quality on a very tight byte budget, and even though it eventually gets outclassed, it does so providing best-in-class scalability at much lower complexity and easy integration. The same SQZ image can be decompressed at each of these quality levels by simply choosing how many bytes to use for decompression, there is no need for reencoding.``` https://github.com/MarcioPais/SQZ

I did little test earlier of making a jpeg, then encoding the difference to the original in a PNG. Couldn't find the right blend mode to get the lossless image back in Krita, but was fun to try and vaguely similar to that

like wavpack but for images

Simple, just use the same JPEG decoder.

At first I was like you. Then I learned a bit more how a ressampler works and started to trust the math behind. And about the bitrate, opus doesn't operate as CBR but interpret the bitrate requested as an optimal target size, but the real size varies depending on the complexity. What I love about opus is how it performs on blind tests and the fact it is modern yet well supported on browsers

I compressed my whole library in 160 kbps and serve it directly in the browser via a custom server

I don't trust the math, I don't even understand it, what I do trust though is the various blind testing I have personally conducted on myself and others, as well as lots of other testing everyone else has done :D

I remember trying to cut down on archival stereo audio recordings, before I was using the default AAC 128kb/s, managed 96kb/s before severe degredation in the high frequency range. Switching to Opus I got 64kb/s (the minimum in the program) and it had no noticeable degredation for my untrained ears

Yeah, it was purely a fun little test I wanted to do using only Krita to keep it fast, tried every blend mode but none seemed to correct the image properly

Everything below 96 kbps Opus often has quite obvious artifacts imo.

I remember trying sox’s resampler going from 44.1 kHz to 48 kHz and then back, for maybe 10 roundtrips or so, and then subtracting for the original to see the nature of the difference

result: pretty much low-level broadband noise

its results on https://src.infinitewave.ca/ are reassuring as well

I have zero concern about resampling, at least if sox is the one doing it

Both of these statements are false, btw, Opus does support other sample rates other than exactly 48 kHz, it just deliberately doesn't support 44.1 kHz The reason for this decision is that all digital audio hardware in existence converts 44.1 kHz audio to 48 kHz before feeding it to a DAC. The resampling *will* happen, so the Opus devs decided it made more sense for it to happen on encode, rather than decode.

Also, 44.1 kHz -> 48 kHz is a perfect reconstruction because of the Shannon sampling theorem

at least within the 0 -> 20 kHz band, and Opus has a hard 20 kHz lowpass because anything higher than 20 kHz is entirely inaudible

Also, the statement about not having true VBR is also false. The `--bitrate` mode in opusenc is actually VBR, where the bitrate you pass is actually a quality setting which roughly correlates with bitrate for the output file. If you pass it something with extremely low complexity, for example speech or silence, it will wildly undershoot the target, as you'd expect for true VBR.

People who complain about the difference between 44.1 kHz and 48 kHz don't realize that they're functionally identical because of the Sampling theorem

It totally supports 44.1 kHz

It just isn't supported by default because the modelling isn't tuned for it.

I'm not complaining about not having true VBR, I talking about the only possibility to set vbr bitrate, not quality and let encoder to choose bitrate. Just did a quick test - encoded 44.1 kHz file with --bitrate 256, got 46 MB file. Downsampled 44.1 -> 11, encoded with the same --bitrate 256, and got 47 MB file. Encoding the same files to vorbis with q 8.0 resulted in 42 and 14 MB files respectively. That is what I'm complaining about.

originally it did not

it was a later decision to add it

For me it does not mean "supports"

that's literally how VBR works though, the quality setting is called "bitrate" but it's a quality setting

it takes the setting passed to bitrate, divides it by the sample rate, and then uses that as the quality setting of the encoder

it adjusts the passed argument by the sample rate of the input because the idea is that it's supposed to produce a file with that bitrate, but in a VBR sense

Why not to give possibility to specify this quality manually? For me this VBR looks like ABR

for most audio files it's pretty close to the provided value because the model is very good

it's not actually ABR

I don't want to specify bitrate. I want to specify some level of losses, let's call it so, and let encoder decide what bitrate it requires for such level

> for most audio files it's pretty close to the provided value because the model is very good No. For a typical music library, the average across all files will usually be close to the specified VBR, but different files can have wildly different rates depending on how complex the data is.

ye, that's true, but the model is quite good

what do you mean by that?

but I'm aware that it's true VBR