JPEG XL

\*cough\* xargs \*cough\*

or parallel

I'm on windows, and that script does not only what I described, so no, I believe there is no general solution for my requirements

I think GNU parallel works on windows

I think it does too, but i've had better luck using mmsticks parallel or fd

it does

`pacman -S parallel` in msys2 and you’re good to go

If it does more, than you described, sounds like general solution to me

Pacman on windows? I'm lost 😅

It seems that msys2 is a modified version of cygwin, I thought apt would be the package manager of choice

nah, it’s pacman

(or shall I say `pacman.exe`)

https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-libjxl/PKGBUILD

I'll have a try, next time I boot on win

nah, cygwin provides a translation layer for unix APIs, so code that makes calls to POSIX-specific code can be compiled directly for windows, with cygwin providing the translation layer

msys2 is different - it provides a posix-like environment with all the tools, but the focus is about building native software with windows APIs

that’s mingw, but msys2 does also have a cygwin-like environment

the non-prefixed packages, like `parallel`, `pacman` itself, etc. run under that layer

but yeah, the focus is on the prefixed (mingw64-[…], etc.) packages which do let you build native windows binaries

discord files moment. I wrote small script that reads the first bytes of the image to determine

Show it or it doesn't exist 🙂

why? it's easy to do

`file --mime-type` is the easiest way

I'm just joking

this is turning out ok https://media.discordapp.net/attachments/615105639567589376/1143156986318430238/image.png

🙂

I don't know why you'd need a script to do it

reinventing the wheel

well

why do the files have the wrong file extension in the first place

discord files moment.

?

what does that mean

such an expression of words is extremely contagious and carries the wrong message in any sphere. and of course it doesn't make sense

what

it means "there's no reason to try to invent something that has already been around for a very long time"

this means that a file with any extension can have a different extension.

discord preserves the file name of the file that was uploaded to it

why was a file uploaded with the wrong extension in the first place

no, it means, "why are you programming if you can find something ready, you're wasting your time"

Yes, it also means that in this context

I do not know, but about 20% of all files in discord have the wrong extension

that is definitely not true

perhaps the figure is over. but it's definitely a problem

in either case, you can just do something like: ```sh mv -vn "$input" "${input%.*}.$(file --brief --extension -- "$input")" ```

> linux

I'm sure an equivalent oneliner exists in Batch

because I'm a python programmer and I know how to use neural networks that generate code for me that I can read. so yes. it's definitely faster than searching for anything on the internet

>I know how to use neural networks that generate code for me so you're not a programmer, ok

I am definitely a programmer who makes python code, Or do you want to say that using a neural network makes my working code that solves problems -- bad?

oh mb I thought you generate code with a bot

if you're actually a programmer writing code yourself that's different, mb

this doesn't look like a python script to batch rename files

I wrote the imageboard from scratch, in one self-written line database, without any other files or programs -- use gpt, and yet I worked for days for about a month. figuring out how best to write it in order stick to super-minimalism

this is just a flask script

for a web server Application

this doesn't batch rename images

pure python

for flask server

python flask server

You read the entire file into memory in order to check the first few bytes? why?

why not

if you can't answer that yourself then I cannot help you

read the BYTES so fast

so fast!

I really can’t answer this question, this code was completely written by the neural network and it has already done its job and is completely unnecessary, I didn’t care about this line at all. Why do you ask such questions about the code that goes to the trash, I can not understand. data = open('file').read(10)

maybe that's a clue

maybe i am OmegaClueless

$80 fell out of my pocket today, but all I to do tell myself - money comes and goes. All the best to whoever finds them. -- this made me think that the collection of porn that I have been collecting for 4 years is much more important than any money

what

🙂

This looks like a conversation between two chat bots X D

with any luck, I might have a build of aves with working jxl for android, it will be pretty rudimentary, and I won't support it for very long since aves doesn't accept PRs, and aves might treat it as an video, but it will with luck, work

Hey, anyone know how I could encode the color profile (ICC profile) directly into the png?

what do you mean?

what do you have in input, and what output do you want?

1st image: has the colour profile: "Colour LCD". 2nd image: has the colour profile embedded into the png. 3rd image: is stripped colour profile and has a discoloration effect. 1st img is the input image, the 2nd is the output I want and the 3rd is the output I get 😢 Exif between the 1st and 2nd: https://gist.githubusercontent.com/taosx/08d7cba93780dd47a829bbc9db87657e/raw/b571ed74a471268ba40c68d116f7805bbb5f6e81/md

you want to convert it to srgb

good luck

that would be something like this then: ```bash convert test-in-1.png -profile /usr/share/color/icc/colord/sRGB.icc -strip out.png ```

(and then `optipng` or `advpng` or whatever)

Thank you w, spider-mario. I'm suspecting my decoder doesn't read the icc-profile info but at least I know what I need to do. Edit: Solved it, basically I had to read and decode the icc profile of the current image and then transform it using sRGB.icc. The library I used was: https://github.com/kornelski/rust-lcms2 in case someone needs something similar in rust.

Saw a combined metric in some jpegli commits butteraugli 3-norm + (100 - SSIMU2) x 0.04 How useful is it for things other than optimizing jpegli's quant tables?

https://entropymine.com/imageworsener/ interesting stuff

surprised you haven't seen this before

oh boy, an srgb page

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

yeah it is a good trove for anyone working with images

I only have one comment for this: https://entropymine.com/imageworsener/slowpow/

> I am aware that transcendental functions like pow() are hard to calculate, but I find it difficult to believe that _this_ is the state of the art.

unfortunately this is the SOTA. a correctly rounded math function is still an open problem. the actual problem is that we don't need a correctly rounded result for those cases and yet have to rely on the correct and slow `pow`!

No-one's stopped me so now I'm running a lot of libplacebo scalers through this (again)

Unlike when I used just SSIMU2 the highest-scoring result no longer has obvious light halos, which is good

about ios 17 current betas, can apps embed jxl images (like for interface, textures) that will then be viewable in-app without needing extra libraries ?

as far as I'm aware, yes, anything that relies on system libraries to decode should work

in my experience it is safer to optimize against butteraugli if one has substantial interest for quality -- mixing in ssimulacra is imho more for the numbers than for eyes -- also nothing matches with human eyes, so it is good to look at the results by oneself, too

You make it look like ssimulacra2 was useless...

ssimulacra2 matches better with human raters at lower quality, but it may have corners that are not covered

butteraugli I co-developed with guetzli, pik and jpeg xl (and some neural compression work)

when the compressor found new ways to cheat butteraugli, I added those into the test corpus and hardened butteraugli against cheating compressors

there are still issues, but much less than any other complex human vision inspired metric -- I think

initially, butteraugli was answering one question only: can a human see a difference from a distance of 900 pixels or not (when in office conditions using a photo-editing quality monitor)

the softer quality has been a bit of an after-thought

I believe it is a valid use of ssimulacra2 to evaluate quality of compression systems, but possibly not equally valid to use it for making a lot of microlevel decisions -- there I'd rather use butteraugli

in jpegli we wanted to improve performance around quality 70 -- there ssimulacra2 works possibly better than butteraugli

also, in jpegli there cannot be a lot of microlevel trickery -- the format is too simple for optimizations to find such opportunity -- so the use of ssimulacra2 was both justified and relatively safe there

agreed

ssimulacra2 could also be useful for d>3 jxl and/or for tweaking low-effort jxl encoding (including hw encoders). But to guide higher-effort encoding (which has more "microlevel trickery"), especially around d1, I think it's better to stick to butteraugli

thank you for your feedback, and the comprehensive answers. I perfectly understood the difference

well apparently there's a way to test webkit on Windows: https://james.darpinian.com/blog/safari-on-windows

it seems as though JXL progressive rendering is partially working?

JPEG progressive rendering works just fine but not JXL in webkit

does it work fine in Safari on Mac?

unsure, however HDR is also messing up and I know that works on Mac

reminds me; on the jxl test page for android ffox nightly I got errors with transparency, but better support for 16 bit colour depth than with png (and i don't have any idea how this screenshot would accurately capture that, but i think it does?). and the css dynamic range media query *doesn't* flag my device/UA as hdr... i understand the three tests are tenuously, if at all, related in the backend. but it's still intrigued me

That's actually firefox incorrectly turning the HDR image into a normal one, the others are working correctly but your display can't show them

yeah on an sRGB display it's supposed to look just solid red

(this is not HDR but just wide gamut)

I'm using the RealSRv3 dataset (HR-LR image pairs obtained through analogue means and then digitally aligned), because with synthetic LR images the results seemed to pretty easily flip based on the downscaling method used Does result in much higher scores though (butteraugli 3-norm mean around 5.5, p95 around 8)

were these SSIMU2 tests done on the latest SSIMU2?

reportedly, Apple has tuned the sharpening way down on the new iPhone 15 {,Pro,Plus,Pro Max}, and on the iPhone 14 Pro with the iOS 17 update, in “HEIF Max” (48MP) mode: https://9to5mac.com/wp-content/uploads/sites/6/2023/09/HEIF-iPhone.jpg

Nice. The unsharp masking on that image on the right is indeed quite heavy, can always do that later if you like it but I prefer captured images to be as unprocessed as possible — any baked-in 'enhancements' can only lose information...

to me, excessive sharpening is the hallmark of the “smartphone look”, maybe even more so than excessive denoising

yeah, median blur and oversharpening - and sometimes also funky oversaturation

Holy crap that extreme ringing around the lettering...

How is that ever acceptable?

That looks like the world's crappiest sinc filter

philosophically, i think it's accepted for the same reason i was surprised other people could see better than me when i had my first optometrist appointment

Is there any nomacs build for windows which supports jpegxl viewing? The one frtom github releases does not work.

People have different tastes. What is an extreme ringing artifact to one person, is a nice edge contrast enhancement to another person. What is a blurry mess to one person, is a nice noise-free image to another person. To some extent image quality is a matter of personal taste...

Did you try this one? https://github.com/nomacs/nomacs/releases/tag/3.17.2285

no. i used stable release by downloading 3.16 from project page.

beta works. thanks

I'm interested in encoding all sRGB colors into a 16 bit space where the remaining 8 bits can be used to store information, looking just like a very mild amount of noise to the end user. To do this, I'd like to use a look up table that contains 2^16 values in it. How would I go about sorting all 2^24 sRGB colors into a 2^16 space where each color contains the most spread out sample range possible?

Originally I considered using a 3 dimensional LAB grid to organize colors and then to find where the best boundaries were, but now I'm considering a XYB grid

how about just using 5-6-5 encoding and mapping that to the corresponding 8-8-8 triplets?

should be a decent first attempt

That's a possibility, but I was wondering if there would be a more sophisticated way of doing it

in first approximation, you could take xyb and intersect it with a grid of appropriate coarseness

issue is that if you use stuff like XYB you end up with roundoff errors as it's not bitexact

which could be an issue if the lower-order bits matter to be bitexact

I'd also just do RGB565, to keep it simple. If you use CIELab or XYB, you have to take into account that these spaces are not just cubes like RGB, but have a pretty irregular shape.

Ah, so it's the same as the libwebp vunerability from a few weeks ago, but reclassed

Is there a "linear light XYB" (for resampling)? As in, if you average _n_ pixels together, the average luminance remains the same

No, but for that you can just use linear RGB...

The point of a perceptual space like XYB is to model the HVS, which is very much not linear...

For ssimulacra2, I do the resampling in linear RGB while evaluating the SSIM heatmap in XYB. Means doing 33% more RGB2XYB conversions but I think it's worth it - for resampling the physics of light matters while for distortion perception matters...

I know, was just wondering if it existed to avoid going all the way back to linear RGB (though tbf that's not very intensive)

I'm downsampling in linear and upsampling in sigmoid

(iirc Robidoux was investigating replacing sigmoidization by resampling in 2 opposing gamma spaces and blending the results, I'll check that out too at some point)

https://www.reddit.com/r/jpegxl/comments/16wwqwn/comment/k33y37d this guy says his photos are not converted properly due to different color profiles. Is it a cjxl bug?

Bit of a weird question, but is it possible for jpegxl to run a mixture of lossy and lossless layers? <@794205442175402004>

Yes, this is possible. VarDCT and Modular mode is a frame (layer) header choice, so you can mix VarDCT and Modular frames.

XYB is a global choice though, so that's a bit of a limitation...

Is it also possible to apply a transform of some kind with modular mode on VarDCT data?

VarDCT data consists of the DC data which is modular encoded and the AC data which has its own specific encoding

for the DC data you can apply any modular transforms, for the AC data you have to use the specific thing

Oh! Nice

It's kind of weird to call jpeg frequency bin coefficients DC and AC

one's constant the the others wobble like sine waves so it's apt

In the spec we call it LF and HF (low freq / high freq) since the DC/LF image also included some of the low freq wobbly coeffs when transforms bigger than 8x8 are used — e.g. when an 8x16 transform is used, it gives 1x2 pixels in the DC/LF image, based on the DC coefficient and the lowest freq AC coefficient (the one with the big vertical wobble)...

But in the code we still call it DC and AC (which is technically only correct if only 8x8 is used)

https://tenor.com/view/acdc-lightning-gif-acdc-acdc-white-lightning-gif-12034088

it’s just DC from a not very stable source

(say, a discharging battery)

Is that better than full HDR?

no its actually worse lol

this is dead on arrival and a one-way vendorlock trap

i doubt it will be vendor lock, the spec seems open and easy to implement.

HDR -> HDR+ --> HDR Ultra

HDR10, HDR10+, Dolby Vision

so many HDRs

So are MS Office formats, and yet nothing supports them fully.

and psd

the spec for MS Office formats is thousands of pages long

and has you reimplement bugs from 25-year-old Excel versions

and HDR+ just being a bracketing technique to create SDR JPGs... lol it is a mess

https://link.springer.com/article/10.1007/s11042-019-08371-w

Has anyone read anything about RDgRb? It seems like a promising color space on paper, but I'm curious as to why it's so obscure

there hasn’t always been bracketing: https://blog.research.google/2021/04/hdr-with-bracketing-on-pixel-phones.html

I don't understand why they decided to call the SDR images (with nice local tone mapping) HDR. Marketing is difficult to understand. Engineering is easier.

Maintaining clarity about consumer-facing terminology will help a field of technology in the future.

vivid on by default

actually I think google might have stopped doing that

but people still pick vivid

HDR in general is a mess and a terrible term

the “merging several shots and tone-mapping them” approach to HDR has focused more on the capture side, in a sense

it does allow the capture of scenes with a greater dynamic range

but dedicating the term to that approach was a bit short-sighted in that it didn’t anticipate that the reproduction side would gain greater DR as well

I actually like terms like Apple's "Deep Fusion" that don't necessarily illicit the imagery of any engineering terminology but are just a generic marketing term for what essentially just means "better photos by combining images"

Do any of you know how flawed XPSNR is as a metric?

quick question, how does progressive/streamed decoding work and can a decoder override its focus priority?

curious about how jxl would fare with comics using really tall images (think 12000 pixels tall, 700width) and meant to be read scrolling down from top to bottom like youd do on a touch device. see webtoons for an idea about the use case

That's actually the default order of images encoded with cjxl, left to right, top to bottom in between 128 to 1024 pixel blocks depending on setting. The order is decided by the encoder, changing what block of pixels is received first by the decoder. If you already have the entire file, then you can choose what area of the image to decode without touching the rest, also known as cropped decode

question that's again going to reveal how little i know: everything I read only stresses the importance of linear light for resampling. In a colourspace where that's just a single channel, is there a property the chroma channels should have that'd be beneficial (like is done for gradient creation, which seems to be a similar problem), or should the entire space just be a linear transform of XYZ?

For gradient creation you should use a perceptual colorspace (XYB or Lab, for example), since you want the gradient to be perceptually nice. For resampling, you basically want to simulate what would happen if the same photons would be captured from a further distance or with physically larger pixel buckets — and for that you need a linear colorspace or else you're doing the photon counting math wrong.

> For gradient creation you should use a perceptual colorspace (XYB or Lab, for example), since you want the gradient to be perceptually nice. I never thought of this, I wonder if this could be used for sophisticated debanding

It seems that sRGB, Adobe RGB and Display P3 are all using the same response curve. So these color profiles should not make any difference in grayscale images, right? There is no color to begin with, so only the response curve is meaningful.

gray is a whole other thing

I'm considering RGB encoded grayscale images, where RGB samples are equal, so could be reduced to single gray channel. I've came across such images with attached color profiles. After the reduction to gray the attached RGB profile becomes invalid. But that should not be a problem because the correct response curve would be used anyway.

i think you'd still want to tag it

especially if it's gray

nothing can agree what default grayscale should be

white is also a color, so basically grayscale profile has two components: transfer function, and white point

iirc sRGB, Adobe RGB and Display P3 all have same white point (D65)

mfw compression artifacts add color

Untagged images are generally considered to be sRGB, so tagging an image as sRGB seems redundant.

if its srgb it should be tagged as such, it reduces the chance of it being treated as a pure 2.2 transfer... a bit

Where can I come accross color compression artifacts? PNGs with equal RGB samples and JPEGs with blank CbCr channels have no color artifacts.

Adobe RGB's tone curve is different

Does have RGB encoded JPEG any disadvantages compared to YCbCr other than less efficient compression? The main concern is support in web browsers and image editing software.

I would tend to expect compatibility to be better for YCbCr than RGB JPEG

probably the overwhelming majority of JPEGs are YCbCr so that’s what most software would have been tested with

Modern software seems to be fine. The thing is that RGB encoding is not covered by JFIF standard, so the support is not guaranteed.

YCbCr conversion may introduce some rounding errors so I can see where RGB encoding can be useful.

MSIE 6 can read RGB encoded JPEG, so I can assume it should be supported pretty much everywhere.

<@604964375924834314> remember the question about tagging av1 with yuv444p and matrix=GBR?

https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libdav1d.c#L150

and I said there was probably casework?

it's here

internally, av1 uses I444 and Matrix=GBR to flag itself as RGB (per spec)

so if you set that explicitly at the container level things will get confused

ooh

thanks for the investigation

so overall less trouble if I just use the Rec. 2020 matrix? 😁

I wasn’t using av1, though

but maybe there are similar shenanigans with whatever I was using (maybe h.264)

wasn't this avif?

I was outputting y4m from my program and piping it into ffmpeg for compression with (I think) libx264

never mind then

``` [2023-10-17_10:36:47] <Traneptora> Daemon404: so if the transfer isn't SRGB but the matrix is identity, and the pixel format is I444, it's an illegal file? [2023-10-17_10:37:01] <Traneptora> and is this also true about H.264? [2023-10-17_10:37:07] <Daemon404> it's not illegal but things wont pick it up as h264 [2023-10-17_10:37:10] <Daemon404> er [2023-10-17_10:37:12] <Daemon404> brainfart [2023-10-17_10:37:18] <Daemon404> things wont pick it up as rgb*** ```

Daemon404 is Derek Buitenhuis if you're familiar with him

https://vimeo.com/554448617

here he goes over reversible YCgCo

Huh, could've sworn I've seen him on this discord before, but I suppose not

hello, I'm trying to run these commands cd libjxl mkdir build cd build cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF .. cmake --build . -- -j$(nproc)

I got these errors

how can I solve these issues?

if you're on system which ships lcms2 (LITTLE CMS) you can try using it - add `-DJPEGXL_ENABLE_SKCMS=false -DJPEGXL_FORCE_SYSTEM_LCMS2=true` to the to first cmake command ie. `cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_SKCMS=false -DJPEGXL_FORCE_SYSTEM_LCMS2=true ..`

pext is very very slow on my 3960x

I just woke up and it seems like Discord is using this now: https://blurha.sh/

FYI it's a simple DCT-based encoding, originally devised for Mastodon. https://github.com/woltapp/blurhash/blob/master/Algorithm.md

the algorithm is fine, but I don't like how it is specified (for example, what happens when the "average color" exceeds 2^24 - 1? 😉

jpeg xl would be better blurhash than blurhash

https://discord.com/channels/794206087879852103/1065165415598272582/1167390454715777046

speaking of blurhash I just found this: https://evanw.github.io/thumbhash/

is it even possible? the maximum size of blurhash is less than 100 bytes (in terms of information entropy) and typically around 10 bytes (or <20 characters). unless jxl introduces a special headerless mode just for this use case I don't think it can do that.

yeah, there are lots of ways to improve upon this

I'm quite sure that every such solution would have to be a separate format besides from the "mainline" format due to severe constraints

from a pure data/file size per encoded thumbnail/placeholder standpoint JXL would not win however I do think JXL is a better solution complexity and performance wise since with something like blurhash or thumbhash from my understanding work with a javascript library that decodes their custom format and paints it to a canvas element then switches it out with the actual full image file once it's done downloading while with JXL everything would just be handled natively by the browser

any such blurred thumbnail lacks high frequency contents so only a small canvas is needed, which can be enlarged by browsers.

I think the nuance is that things like blurhash are included in the initial request for the content. So it is always going to beat an image format because it can skip the initial network round trip.

But low res blurhash -> progressive JXL makes a lot of sense. Waiting for the full image before showing anything beyond the blurhash is a bit silly.

This is also why being encoded as text is important, as else it can't be included in the initial JSON or HTML.

Technically, JXL from tree would solve that, but trying to output such a simple version and the processing might be more overhead than it takes for the image to load

nothing stops you from using data URIs 🙂

True actually.

Hello, <@532010383041363969> Sorry to bother you, New encoder quality PR look really great, Thank you for your work, but I still have some questions about non-photo type image. I understand pixel peek isn't a fair compare method, so those sample just for explain my question, not for quality compare or benchmark. For those non-photo type image, I still can see some tiny artifacts, I understand specific type image is really hard for DCT, probably have better lossy strategy for non-photo type image? like separate image(Jon PR1395) or jxl lossy palette?

1395 is what I'd assume to be best, the issue is good heuristics to decide

whats the ressource cost of serving a jxl as a reconstructed jpeg in a browser, compared to serving a normal jpeg of the same filesize directly? assuming the server itself can decode everything but a user's browser cant

the bandwidth and storage savings need no further mention, wondering how ressource intensive itd be for say shared hosting, an imageboard or a website under slashdot effect to handle

IMO its too significant for people providing server themselves, better to use jxl wasm decoder probably.

I can't really see a use case for decoding back to JPEG outside of very niche archival purposes. Generally the compute requirements would outweight the storage savings.

Maybe in a world where 99% of clients can accept JXL, so its just done for out of data clients.

storing everything internally on server as jxl is one. for example, allow upload of jpgs that get internally converted to jxl. the ability to serve the original jpegs if needed or desired (some clients or old devices may prefer consuming that or only being able to) was touted as a huge selling point to boost adoption

depending on the website’s usage pattern, some caching could make sense

like, automatically store an already-decoded jpeg of the most popular images, dropping som of them as popularity shifts

id presume reconstructed jpeg present in some cache to be served at almost the same cost as regular jpeg, no surprise here. any idea what i should expect about uncached recjpegs, like for a page serving 30 ?

i thought generating reconstructed jpegs as new files was different from loading them in memory, or was that the same and files were just cached then discarded after viewing ?

I’m not fully sure I understand the question – when you say “loading them in memory”, do you mean loading them as pixels for displaying?

rendering them to pixels indeed sidesteps the generation of an actual JPEG bitstream

displaying in a webpage without generating any .jpg files

Makes you wonder when discord will finally ditch webp and switch to jpegxl

at the rate at which they update Electron, maybe 10 - 20 years?

officially a jxl contributor <-- committed a single character

now i can tell my grandchildren that for every character of code i submitted i averaged 644 characters describing it

i'm measuring a 1:1 ratio of characters of code written to CLAs signed. logically this trend will continue indefinitely if i ever submit more

The CLA requirement is unfortunate... More unnecessary barriers to contributing...

Would be a shame if someone forked libjxl and didn't require signing a contract with Google before accepting contributions... Maybe even refactoring the code in K&R C style along the way... That would be every developer's dream...

I worry about how many talented individuals were discouraged from contributing

https://xkcd.com/605/

Can't unsee.

> Maybe even refactoring the code in K&R C style along the way... That would be every developer's dream... I don't think that would be anyone's dream.

If I were to write a JXL library in C, it'd be C23 with ALL the new features.

K&R, as in, like this? ```c main(argc, argv) int argc; char** argv; { /* ... */ } ```

that's some ugly code 😄 Nevertheless, C remain the only language which is able to easily compile a function under a symbol which have the same name! which is nice

fun fact: while K&R syntax has been deprecated, it has stayed valid, but this changed with C23, which has completely removed K&R syntax.

'bout time too

did you know that k&r syntax functions are not actually checked for argument mistakes?

(well, perhaps they are, but they are not *required* to be)

That's nethack style!

Well they call that K&R style function declaration

I guess every developer's dream would be KNF style

https://man.openbsd.org/style

NetHack dropped K&R C support a while ago

In the unreleased development branch, they are currently in the process of rewriting the function definitions to be ANSI style.

On git. They haven't actually released a version of nethack that doesn't have k&r style functions yet. And it looks kind of quaint. :)

Lets you know you're working on a project from another era

Or, as they say, hacking

Still... Would be nice to have an openBSD-ified libjxl :)

do you actually do any programming?

I try to avoid it if I can. The best code seems to be no code at all.

when you have nothing to do, no code is perfect

<:YEP:808828808127971399> Nocode is perfect https://github.com/kelseyhightower/nocode

Hey, fewer LOC is less wasted time, and time is valuable...

Obviously that can be taken to an extreme but, I feel like if you need to implement software, you should keep it as obvious and straightforward as possible, and keep the time spent monkeying with it to a minimum. But that's just obvious common sense.

That's why I think C++ is such a terrible language. So much wasted time trying to understand the language itself rather than the actual thing you're working on.

I'd agree with it. I used to java/kotlin at Android, but month ago I finally decided to write small app for PC (actually rewrite my another python console app to GUI). The obvious choice for me was C#, and the prototype was ready soon, but it appeared much slower than the python version, because they used numpy (written in C, afaik) and .net analogue. So I decided to switch to QT and C++. And it is pain.. 😔

Btw, can someone suggest lib to read DNG metadata? Preferably not exiv2

https://www.reddit.com/r/photography/comments/17npmb4/tifu_shot_my_whole_vacation_in_jpg/

I'd be totally frustrated if this happened to me. Luckily my camera(s) don't have jpeg option, only raw, only hardcore 😅

What camera is that

Various old digital backs

personally I'm a fan of

```c int main(int argc, char **argv) { // foo } ```

but most people prefer the `{` on a separate line

Woooh, 3-space indendation?

well, no, 4

just made a typo there

do you think `{` on separate line is a relic from K&R syntax?

https://youtu.be/FdldD0-kEcc?t=2m14s well hello, 1931 xy chromaticity diagram, didn’t expect to see you there

(okay, the thumbnail should have given it away)

(although that looks more like the 1976 one)

it is, AFAIK

I use separate line for functions and same line for everything else.

i use one line per character and then just rotate my monitor sideways

av1 block copy is similar to jxl patches? https://youtu.be/Z4DS3jiZhfo?t=3749

and palette coding doesn't look very complicated and it seems to be enough for av1 to be so effective in lossy with lines and low-color images

Seems similar, although he mentions in AV1 it's restricted to I-frames and roughly 50% of the picture

Yes, patches and intra block copy is similar, main difference being that patches are always taken from a _previous_ frame, not the current one. So repetitive patterns have to be stored in a separate invisible patch frame (like a sprite sheet) and then they can be used in the 'real' frame. Main advantage of this approach is that you can e.g. use Modular for the patch frame and VarDCT for the 'real' frame. Probably there is room for generalizing our current patch detection by applying some of the tricks from video encoders...

Palette in AV1 is quite limited, max 8 colors and I dunno how they encode the palettized block but probably in a relatively simple way (compared to jxl modular). In VarDCT JXL, there is no notion of a palette block and libjxl is currently not doing anything like that, but it would be possible to use patches to do something like that, but with more options (not limited to 8 colors, could use delta palette, etc) and with better entropy coding...

Where is the av2 part on that video?

HE codec for h265 seems to do fuzzy block coding -- in one of the test images I had windows on a block building, one of the windows had a flower pot on the window sill before compression. Compression reused that window to another window, and another window got a flower, too. I just don't like this kind of stuff being done. Innocents will go to prison if such things are used as evidence.

Do you have the files?

Similar to Xerox scannersJBIG2 problem? I hope some JPEG XL encoder in the future won't end up with the same issue using patches.

btw running butteraugli on the cid22 validation set gets me loads of libpng warnings for "known incorrect sRGB profile", is that like. an issue

you can ignore it, I dunno how this happened but all the images are supposed to be just sRGB

Not sure if anyone is following the work on `png` v3 spec?

Just posted an open question: Why? https://github.com/w3c/PNG-spec/issues/370

There is a lot of work on color rendering, HDR, etc. .... all ultimately duplicating JXL ...!?

At the risk of upsetting people, would love to understand the reasoning behind this endeavour ...?

Wondered what the perspective is from the JXL side? 🤔

nice initiative

it state : with the enormous installed base of PNG images is considered paramount, so non-backwards-compatible changes such as a better compression method, are out of scope in the charter. https://github.com/w3c/PNG-spec/blob/main/Third_Edition_Explainer.md

I don't understand how they plan to add hdr with backward compatibility...

I assume cICP chunk that overrides ICC and an ICC that does tonemapping

that should give reasonable results

But... why? I 💙 png. But surely this is all covered by lossless JXL?...

Backwards compatibility is kinda useful though

As in, graceful degradation

Also it's a much smaller change

And it allows doing nice things such as decoding Jxl to an HDR png in a polyfill

Perhaps more philosophical... I personally see it as the 'gambler's fallacy'... at some point, we need to adopt the new tech. Would you also advocate adding HDR to GIF...?

Nah, one HDR format that is easy to use and generate is enough 😉

And png is the obvious choice as it supports 16 bits

And nothing else does

PAM ...?

😉

*format decoded by a browser 😉

and here I was about to say exr :D

As it stands, adding hdr-png support to chrome was a mostly uncontroversial 20 line change (or thereabouts)

And now you can use wasm to convert a Jxl to a (a)png and display it as HDR without too much pain

The only alternative IIRC would be HDR canvas, but that has its own problems - I believe they have been arguing on how to do that for a couple of years

well wasm will always be not fun, because browsers suck, just using the jxl wasm on a page that loads a lot of images is... well chrome will freeze the page, firefox will run willy nilly until it either crashes, or gets killed by something else

I wish they also went for a chunk to indicate the 16-bpc data in PNG being not integers but half-floats.

Although that would go against backwards compatibility.

there's not much difference imo between using integers + nonlinear transfer function and using floats + linear...

in some cases, we could possibly even get away with 16-bit linear integers

raw files typically have less than that

(although fixing the upper bound to be 10000 cd/m² kind of works against that)

PNG has ubquitous support and is extraordinarily simple to decode, so adding metadata like cICP is fantastic for testing JXL decoders and other things

since all the new additions are just extra metadata chunks

yes, it’s been quite useful for us

as a matter of fact, <@179701849576833024> and I have contributed to making Chrome read those metadata https://crrev.com/c/3705739 https://crrev.com/c/4748191

and I added cICP support to FFmpeg in part to test the libjxl plugin

would be nice if WebP had cICP, Is there anything preventing that from becoming a reality? unless I'm misunderstanding what RIFF is for or capable of?

I haven't actually read the RIFF spec is it capable of storing arbitrary chunks?

does WebP use RIFF?

oh so it does

if only cIPC would support XYB 🙂

I think now we need to some conversions between colorspaces, only for further conversions to happen later -- unnecessary (minor) delays

or have a full color ICC profile there

(I don't know colorspace management -- I could be completely off here -- I just love XYB and that's it :-D)

each cICP space is explicitly RGB or some matrix transform of RGB

so nonlinear transforms of RGB won't work

notably, XYB doesn't define primaries

tho you could always use sRGB primaries, a custom TRC and a custom matrix

but XYB explicitly defines how out of gamut colors behave

and H.273 does not

An interesting c++ DSL for image processing with separation of algorithm and schedule (order/vectorization/locality) https://halide-lang.org/

is there an online live comparator between formats that leverages recent jxl code? afaik Sqoosh and Eclipseo in particular still runs old jxl (0.3.7!) alongside other codecs and doesnt seem to be representative of current state and may contribute to misleading impressions about merits

<@794205442175402004> i saw a discussion about ssimulacra in OBS discord in 2.1 version should always be 100 for the identical images/frames or there may be some rounding errors or color conversion errors in tools or avs implementation?

<https://github.com/cloudinary/ssimulacra2/issues/10>

identical inputs should give a score of 100 in ssimulacra 2.1 — how are the inputs being passed and which implementation of ssimulacra 2.1 is this?

looks like this port `Updated SSIMULACRA2 to 2.1.` <https://github.com/Asd-g/AviSynthPlus-ssimulacra>

but, the default settings are weird, there's even a mix of the two versions

I answered in the issue — looks like there's some issue with the port then...

seems something is wrong only for avs implementation: ssimulacra2_rs ```ssimulacra2_rs image 284050535-1e1e600b-c154-40ca-8f07-acb1b628af9d.png 284050535-1e1e600b-c154-40ca-8f07-acb1b628af9d.png Score: 100.00000000 ssimulacra2_rs image 284050536-b464d209-8359-41da-9da5-b3679d2b1b9d.png 284050536-b464d209-8359-41da-9da5-b3679d2b1b9d.png Score: 100.00000000 ssimulacra2_rs image 284050537-441e867b-3a3c-4ff0-9cb0-7ca757a6b30c.png 284050537-441e867b-3a3c-4ff0-9cb0-7ca757a6b30c.png Score: 100.00000000```

vs users winning

ssimulacra2_rs has some inconsistencies with the C version. it's good to keep that in mind, however score is usually around an error of 1 or 2 points, worst case iirc was like 4 points

When some of the KDE apps are built for Windows, "Craft" build system is used ( https://community.kde.org/Craft#Setting_up_Craft ). This build system uses some python scripts to build individual libraries. Example of the build script: https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/libs/libidn/libidn.py So far nobody contributed script for libjxl, that's why kimageformats is built without JXL. Is someone with python (and/or Craft) knowledge willing to help to prepare the script?

Imagine JXL support being exclusive to Steam Deck devices, lol.

Sorry, I don't know how to handle missing dependencies (libhighway) in craft, and don't have an environment to play with craft. Maybe also libhighway package will need to be created The build options provided are minimal This is based on <https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/libs/exiv2/exiv2.py>

```python import info class subinfo(info.infoclass): def setTargets(self): for ver in ["0.8.2"]: self.targets[ver] = f"https://github.com/libjxl/libjxl/archive/refs/tags/v{ver}.tar.gz" self.archiveNames[ver] = f"v{ver}.tar.gz" self.targetInstSrc[ver] = f"libjxl-{ver}" self.targetDigests["0.8.2"] = (["c70916fb3ed43784eb840f82f05d390053a558e2da106e40863919238fa7b420"], CraftHash.HashAlgorithm.SHA256) self.svnTargets["master"] = "https://github.com/libjxl/libjxl.git" self.description = "a library for decoding/encoding JPEG XL (aka JXL) image format." self.defaultTarget = "0.8.2" def setDependencies(self): #self.buildDependencies["libs/libhwy"] = None ## FIXME: libhighway is not provided by KDE craft system self.runtimeDependencies["libs/brotli"] = None self.runtimeDependencies["libs/lcms2"] = None ## FIXME: libjxl-0.8.2 require at least lcms2-2.13 self.runtimeDependencies["virtual/base"] = None from Package.CMakePackageBase import * class Package(CMakePackageBase): def __init__(self, **args): CMakePackageBase.__init__(self) self.subinfo.options.configure.args += ["-DCMAKE_BUILD_TYPE=Release -DJPEGXL_FORCE_SYSTEM_LCMS2=1 -DJPEGXL_ENABLE_SKCMS=0 -DJPEGXL_ENABLE_SJPEG=0 -DJPEGXL_ENABLE_JPEGLI=0 -DJPEGXL_ENABLE_BENCHMARK=0 -DJPEGXL_ENABLE_DOXYGEN=0 -DJPEGXL_ENABLE_EXAMPLES=0 -DJPEGXL_ENABLE_JNI=0 -DJPEGXL_ENABLE_MANPAGES=0 -DJPEGXL_ENABLE_OPENEXR=0 -DJPEGXL_ENABLE_TOOLS=0 -DBUILD_TESTING=0"] ```

also I'm not sure how to specify minimal dependencies in craft

edit: added `self.runtimeDependencies["virtual/base"] = None` as many libraries seem to require it

I thought the primaries are supposed to be whatever your cone cells are supposed to respond to... but that probably varies from person to person...

XYB is based on a transform of linear BT.709 but it's an absolute space

since all linear RGB spaces are linear transforms of one another, it doesn't particularly matter that it uses the bt709 primaries

my point was tho unlike RGB spaces, absolute spaces like xyY, XYZ, and XYB don't define primaries

XYB isn't quite as absolute as XYZ though, as peak intensity must be defined separately

cone cell responses overlap...

it can be derived from the XYB signal

the same luminance is always mapped to the same XYB value

“the maximum ever in this image is 3000” is not strictly needed theoretically

if anything, it’s arguably more absolute than XYZ, which is often relative to SDR white

I was under the impression that 1.0f wasn't always mapped to the same number of nits

that’s true of the linear sRGB signal that comes back from decoding XYB in libjxl, but only because then we divide by intensity_target

XYB = (0, 1.0f, 0) has a fixed number of nits it represents? interesting

https://github.com/libjxl/libjxl/blob/ab5c248ff3127a2c9b623d15e3345684e85a9768/lib/jxl/opsin_params.cc#L42

I know we divide by intensity target but I was under the impression that's why intensity target has to be defined separately

iirc SDR white is typically 203 nits with a 1000:1 contrast ratio, so why do we use 255, anyway?

203 is HDR “reference white”

BT.2408 has a note that says: > The signal level of “HDR Reference White” is not directly related to the signal level of SDR “peak white”.

iirc, we use ~250 because that’s approximately the luminance of the monitor that was used to tune it? but <@532010383041363969> probably knows in more detail

and then, I think we used specifically 255 because we encoded the linear signal between 0 and 255 at the time (as if it was 8-bit values, but floating-point) instead of 0-1, and at some point we thought “it would be nice to make this coincide with nits”

around that time, I believe that we also had it not normalised by intensity_target, so it coincided with nits even with non-default intensity target

(otherwise there would have been little point)

I know...

The 2015 or so NEC photo monitor that I used to build butteraugli with had a max of 250 nits, so I used that for all experiments to have some coverage of HDR range

When Jan was working on it, he "corrected" the 250 to 255 and I didn't think it was that big of a discrepancy to need fixing so it grew automatically from 250 to 255

When Sami took over the responsibility for these things, I believe he returned the default to 250

Hi, is there any way to make windows 10 use jxl pics as wallpapers?

Nope.

Maybe it will support it if a WIC codec is installed (just a guess)

Yes there is a way, First make sure you have [jxl-winthumb](https://github.com/saschanaz/jxl-winthumb) setup/registered and then use this .reg file and the option "Set as desktop background" will appear on JXL files

You can't open it in Photos though.

Photos app is bad though it doesn't allow the use of any third party WIC codecs at all

I think it might also reject some first party WIC codecs as well but I don't remember

Also HDR images look dull.

*maybe only on non-hdr displays. I don't have one.

the photos app is the only app that supports windows advanced color

and also the only app that can do cross display color management

too bad windows advanced color isnt worth half a damn xD, there is a reason why people still rely on stuff like SDI cards for windows and linux. only osx has a platform level colormanagment solution that isnt a joke

windows advanced color is great

windows advanced color can handle colorspace conversion only when it's in the same luminance type, it can't do tone mapping worth half a damn, so using it to consume HDR on SDR or SDR on HDR is bad

even android can do tonemapping now lmao

well tone mapping is completely subjective

it's not correct

sure, but objectively any tonemapping is better then no tonemapping

even if it's a dumb 1:203 tonemap

umm sure

ofc we have standards like bt 2446a

a "white" srgb image designed for an 80 nit display, would blast 10000 nits of brightness at you without it on a "perfect" display

it's not an optional thing, it's a requirement

what are you talking about

SDR images on HDR display

Speaking of dull, I made a wrapper for jxl-oxide. Currently it looks like this (The colors are very off). What I did was applying saturation, exposure, and gamma to the decoded image. Any ideas on how to improve this? (Left is from the wrapper with applied saturation/exposure/gamma, Right is native apple jxl decoding)

can you elaborate a bit more?

your pipeline I mean

I can elaborate with a whole repository, if you want.

sure I guess but generally, what are you trying to accomplish, SDR on HDR? gamut mapping? etc

I have no idea about any of those, I just want to load HDR image on a non-HDR display, but make it so it doesn't look dull.

ah I see, I think jxl-oxide has tonemapping support, but im not sure color conversion stuff is availible in jxl-dec

are you working with jxl-oxide directly or jxl-dec?

just jxl-oxide

ah sorry, I mean using the crate or the binary. if it's using the crate iirc you can do the color correction directly from jxl-oxide, if it's the binary... Im not too sure atm

I'm using the crate currently, not sure what binary is, I'm very new to rust so, yeah that's that.

the crate means you are programming in rust and using jxl as a library, the binary means you compiled jxl-oxide directly and invoke it using jxl-dec

I see, yeah I'm using the crate.

cool [repo review](https://githubnext.com/projects/repo-visualization): https://mango-dune-07a8b7110.1.azurestaticapps.net/?repo=libjxl%2Flibjxl

continued from https://discord.com/channels/794206087879852103/804324493420920833/1180652506259411074: there does exist rapidgzip that works for virtually all reasonable deflate stream

https://github.com/mxmlnkn/rapidgzip

it doesn't support all possible streams, but it works for all streams that have been produced by reasonable or trivial compressors

the main limitation AFAIK is that it speculatively starts at all possible bit position, so intermediate huffman trees should be optimal to filter enough false positives to be effective

just make png the default ffs

I am not sure why anybody would ever use AVIF lossless mode

png writing is pretty slow, doesn't make sense to use it as the default

the default of legacy JPEG makes sense

Yesterday I noticed a friend uploaded a 50MB PNG to Discord, I asked them why they had it uncompressed and they said it was fast, I explained even a tiny bit would've massively decreased the size... An hour later they uploaded a 63MB PNG too...

~~what software are they using that's pumping out PNGs of that size?~~ fast in what way? if they mean to create the PNGs files then that hurts to hear because taking a extra second to make something noticeably smaller is pretty important to me since I have lived my whole life with awful internet and can't even pay for a better plan because it's just not provided where I live. Also I know that a lot of software exposes 9 levels of PNG compression and I have seen some people just move the slider in a random direction and then never touch it again without looking at how much it affects things

They were 4K 64bit, so uncompressed (or lowest compression) meant almost 64MB. I'll add there was no transparency in the image too... No clue, I tried to ask but they just got confused and eventually said they have 3TB free so it doesn't matter to them I even got the 64MB file down to 500KB by reducing it to 24bit, they said it was slightly brighter (As expected) but they couldn't tell the difference otherwise

Ah, looking back at my conversation with them, I think it's a bad habit from using lossy compression. They said they set it low because they wanted to edit it later

Oh, and they picked 64bit because they have a HDR display... Even though it's just a normal PNG, so it's actually the fact it's OLED and the background was black that did all the work

android has been using jpeg instead of png for a screenshot of the screen for a long time it is for the reason that for a large screen it turned out to be much more profitable to use jpeg both in encoding speed and decoding speed, it is better than png

🙂 especially I personally did tests for decoding giant images, and it turned out that the best solution is baseline jpeg

My phone still does PNG, though I noticed when directly sharing an image from telegram to discord via the apps, it seemed to re-compress Telegram's jpeg with nearest neighbour to 720p from 1080p and quality 40 encoding (Based on what Ssimulacra2 said comparing to the original)

This is something roms change, default is actually PNG in aosp

over all the years I have used Android, screenshots were always PNG