JPEG XL

a cow is an animal but not all animals are cows

ok, they seem to be in the right headspace now. Im trying to now nudge away from the HDR and SDR stuff entirely

Wait, isn't the topic a feature request to set SDR whitepoint?

Without changing HDR whitepoint.

It's very straightforward...

Which is why I don't understand how the discussion got so long.

Only read a fraction of it.

not whitepoint, more or less its about how to map luminance

but the discussion quickly became "what is hdr vs sdr" with snippets of the original topic here and there

and yeah, it is actually a relativity complicated topic for a compositor, but the main issue is that people arent on common ground here to begin with

same thing if you assume linear luminance scaling...

Well, what actually does the conversion of SDR content to PQ? Not the compositor? Otherwise it should be very straightforward.

it is the compositor, the issue is that it isnt that straight forwards

mapping to a specific brightness is unreliable

kwin HDR is dead https://zamundaaa.github.io/colormanagement/2025/03/31/about-brightness.html

this is exactly my experience with 8K (on a 32" monitor) – I found that my distance to the screen was much more “dynamic”

the issue I have with the article in question is the broad generalizations and missasumptions. for instance he states that sRGB specifies a display transfer of 2.2 which is not exactly true, it simply states that the reference display has a transfer of 2.2 but does not specify an eotf. likewise, he also assumes displays all use 2.2 but a video by filmlight proves that only about 25-50% of displays use a pure 2.2 for decoding sRGB, some use the inverse eotf... how windows does it is the "least offensive way" of doing it as if you use a pure 2.2 decode on content crafted on a piecewise sRGB display, it looks worse then the other way around, at least in my experience

which is fine because when you have colormanaged content, you are getting the proper transforms anyways

the entire article is just insanely frustrating because now we will have a bunch of KDE fanboys parroting everything in this article as true

also, doesn’t ICC color management effectively mean that an image with the sRGB profile will be shown using the sRGB TRC (with the linear bit)?

whether that was the intent of the sRGB authors or not

I cant quite remeber but I think so? its been a while, I have mostly forgot most ICC related stuff lol

do they propose to treat sRGB specially there?

at least, wayland specification specification does explicitly denote using piecewise sRGB https://wayland.app/protocols/color-management-v1#wp_color_manager_v1:enum:transfer_function as to whether or not KDE uses this at all for SDR on HDR, I have had previous conversation with zaamunda that led me to believe the answer is no, even for managed content

I could make a shim to test I guess

unreliable?

yes, because not only is content is all mastered differently, but displays are different too

adjusting all sdr content to one, even if adjustable range of nits is not great

Sure, some SDR content is mastered to 100 nits, others to 160 or 200 nits, but you hve the same issue with SDR screens?

That's how it is with SDR screens, though?

What would even be the alternative?

the alternative is having proper transfer awareness

thats the first step, the second would be having per application adjustments

???

well, per application adjustments would be neat of course, but quite a bit of work for how sparsely that would be used

there are a lot of issues in general, its a complex beast with no real right answer

The feature request was to be able to set white level for SDR mapping, which is very simple.

203 nits is just the default

or 100 nits in many other applications

no

the issue ticket is asking about how it should be handled

not a feature request

well, it's a complaint that the 203 nits mapping is too dark, and that he would like to have the option to map SDR content as bright as his SDR monitor (or his monitor in SDR mode), which is ~400 nits

to some extent

Everything is relative to ambient light anyway. 203 nits is enough for an HDR experience in a cinema theater, while 300 nits is insufficient for SDR when outside on a sunny day.

Very true. But that's a separate issue, as this is about SDR brightness relative to HDR brightness, how I understand the issue anyway...

As it is now, at least in macOS, adjusting the display brightness slider (or letting it auto adjust according to ambient light) has the effect of adjusting the SDR brightness, and HDR brightness adjusts accordingly, such that SDR white maps to HDR signal level 203 nits. The amount of HDR headroom is variable and capped at 4: display peak brightness is always 1600 nits on a MacBook Pro screen, while SDR white is 500 nits at the brightest setting but it can go much lower. The best point is setting SDR white at 100 nits so you get 4 stops of headroom (1600 = 100 * 2^4).

do you remember which brightness setting (as in, how many bars in the overlay) corresponds to that?

if not, I can probably investigate later

We measured it and turns out it is not an integer number of bars, but one bar below the middle gets close. You can create a custom display setting though where you can set fixed values for SDR white and HDR peak brightness, this is what we did in a recent lab experiment.

if you click the '+' in the 'Customize Presets...' dialog, you can adjust things and set specific nits values.

useful to make a controlled lab environment (where the ambient light is also controlled, in the experiment we did recently it was fixed to 5 lux)

in daily use I prefer to enable auto adjust brightness and the 'true tone' thing whatever it does (auto white point adjustment?)

yes

I use true tone but manual brightness

https://www.threads.net/@kosovolt/post/DIKPQ3do7Lb

seems it lets you increment or decrement by quarters of a bar

if you then press the button without shift+option, it rounds up or down to the next integer number of bars

(it doesn’t take you from 4.25 bars to 5.25)

Yes, we figured that out too. But to configure the lab conditions, we set it to 100 nits SDR white, 1000 nits HDR. I am not sure if that could be reached exactly with even quarters of a bar.

anyone know if this dataset (or maybe something similar) can be found for free anywhere? https://www.iso.org/standard/37358.html

Second result on a Google search is this: https://cdn.standards.iteh.ai/samples/37358/ee4004f3cd394b63b825fa385d2735dc/ISO-TR-16066-2003.pdf

i did find the full pdf somewhere but not the actual dataset

> included as electronic attachments to this Technical Report

Ah right

The zip file behind the paywall

https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/43

if they really wanted a generic method of checking HDR, they really should have just made a flag :/

<@604964375924834314> I extended/modified the local_tone_map tool a bit to produce output suitable for producing gain maps jpegs. Please take a look at the PR to check that I didn't forget something or mess something up: https://github.com/libjxl/libjxl/pull/4210

Does anyone happen to know any image viewer capable of rendering to a 10bit display natively? Everything i tried except for mpv, photoshop in 30bit mode and davinci resolve, renders high bit depth images in 8bit and sends that to the display

I think if ur on macOS, Preview should be 10-bit

i'm on windows <:PepeHands:808829977608323112>

i wonder if windows supports 10-bit outside of HDR

maybe MPV?

Windows does however applications need to be fullscreen (or at least borderless fullscreen with FSO) to actually send/display 10bit colors. maybe the situation is better in Win11?

Windows supports 12-bit too but you need a monitor witk 10k nits of brightness 😁

😭 oh windows...

MPO also works

the desktop is normally composited in 8 bpp srgb, but with advanced color (windows hdr, or w11's sdr auto color management) it's 16 bit half float scrgb

i don't think windows itself supports 12 bit for anything, you can set the gpu output to 12 bit but windows (directx) only lets you render to 10 bit int or 16 bit scrgb, no 12 bit option

I always found window's documentation around MPO funny, as if gpus haven't been doing that for decades already

it will composite in 16bit then truncate to 12bit at display time

but there's also multiple conversions from 16 bit linear half float with srgb primaries and linear transfer to... whatever the gpu's internal format is, with pq transfer function and bt.2020 primaries

that does not map nicely

having actual 12 bit int support would probably be better

GPUs don't work in 12bit really. GPUs typically work at 16 and 32bit for stuff like that, truncating down to 12bit is fine

the round trip conversion from 12 bit bt.2100 pq to 16 bit half float scRGB and back is lossy

you can display 10 bit bt.2100 pq perfectly because directflip/mpo/whatever makes it possible to bypass the scRGB conversion

you could also just do 16bit PQ if you wanted to, windows doesn't do this since there is no appreciable reason for doing so

hdr

yes, it does

Is this the new fab acc

fab plague

There seem to be two flavors of ProPhoto and I'm a bit unsure as to what should be considered *the* ProPhoto

I have this one in `/System/Library/ColorSync/Profiles/ROMM RGB.icc` that has a gamma-with-linear-segment transfer function like what is described on Wikipedia (https://en.wikipedia.org/wiki/ProPhoto_RGB_color_space)

and then I have this one in `/Library/Application Support/Adobe/Color/Profiles/Recommended/ProPhoto.icm` which has a simple gamma transfer function

the Adobe one has a copyright string saying `Copyright (c) Eastman Kodak Company, 1999, all rights reserved.`

It would be nice if the Adobe one is "the" ProPhoto because then it can be represented in the jxl colorspace enum

This is what RawTherapee and Krita have as "ProPhoto Like", I don't have the tools to inspect them properly, but they seem to match with the Adobe one

Your ROMM file is v4, but Adobe and both editing programs are v2, with Krita even excluding a v4 version unlike other profiles

I think the easiest way would be to find some ProPhoto images online and see what profile they're using

well that will depend on what software people used — if anything by Adobe, chances are it will be that Adobe profile since that's what will be suggested

The title isn't clear, but this was asking about a ProPhoto enum for clearer jxlinfo output about the colorspace https://github.com/libjxl/libjxl/issues/4270

yeah I know

that's what I'm working on

the thing is there doesn't seem to be much agreement on what transfer curve ProPhoto has

Ah nice

so all of them do agree on the primaries, or at least more or less

you shared one with a gamma2.2 and one with the sRGB transfer curve (in lookup table form)

the Apple one and the Adobe one are both very close to a gamma 1.8

ugh why are colorspace definitions such a mess of arbitrary rounding

The Apple one is considered by libjxl to be equivalent to `RGB_0.345669;0.358502_0.734698;0.265298;0.159585;0.840432;0.03665;0.000126_Per_g0.555555` The Adobe one is considered equivalent to `RGB_0.345705;0.35854_0.734699;0.265302;0.1596;0.840399;0.036597;0.000106_Per_g0.555315` Your Krita one is this: `RGB_0.345699;0.3585_0.734689;0.265304;0.159603;0.840389;0.036604;0.000105_Per_g0.454707` and your RawTherapee one is this: `RGB_0.3457;0.3585_0.734693;0.265304;0.1596;0.840398;0.036607;9.9e-05_Per_SRG`

The Wikipedia definition of ProPhoto would be this (hypothetically): `RGB_0.345704;0.358540_0.734699;0.265301;0.159597;0.840403;0.036598;0.000105_whatever_something-close-tog0.555555`

I'm going to pretty much arbitrarily define ProPhoto to correspond to this: `RGB_0.345672;0.358494_0.7347;0.265296;0.1596;0.84042;0.036651;0.000127_Rel_g0.555555`

and I'll make it call anything that is "close enough" to that "ProPhoto"

(which would be the Apple, Adobe, and Wikipedia ones but not the Krita and RawTherapee since they have a way different transfer function)

I know lossy JXL can use "close enough" versions of input profiles, so ignoring the sRGB and 2.2 transfers, are all of those be close enough to 'fit' into the ProPhoto enum?

to be clear, there is no such thing as ProPhoto in the jxl color enum, only custom whitepoint and primaries and custom gamma transfer function

this is just for the function that gives it a nice name when synthesizing an ICC profile

and the other way around, what you get if you use the string `ProPhoto` in a colorspace description string (e.g. when using `icc_simplify` to produce a profile)

hm, actually the Apple one is too far from gamma1.8 to be considered close enough, so it cannot be expressed as an enum anymore — but this used to be different in cjxl 0.11, so something must have gotten more strict? <@604964375924834314> do you know?

Reminded me of this too, though not sure if it still applies https://github.com/libjxl/libjxl/issues/3966

sorry, what do you mean? how was it in 0.11?

In 0.11 it treats that profile `ROMM RGB.icc` as close enough to gamma 1.8, current head no longer does that

I don’t remember a significant recent change to this part of the code and don’t see one in the git history for `lib/jxl/cms`

Or maybe that depends on LCMS/skcms version, I am comparing homebrew 0.11 to my own build of git head

ah, right, and in the past, it has also depended on lcms vs. skcms on occasion

Since this is about giving information to user maybe outputting like "Apple ProPhoto", "Krita ProPhoto" etc. would be useful

If the values for Apple / Adobe and/or others are certain

I found a photo that contains an ICC profile which lossy JXL seems unable to reproduce (0.11.1 on Arch Linux). Particularly the red parts are most affected. Viewing both with `mpv --vo=gpu-next`. Original: https://files.catbox.moe/yk73pe.jpg JXL `cjxl -j 0 -d 2.75 motocross.{jpg,jxl}` : https://files.catbox.moe/5yeryv.jxl When I ran the original through exiftool this was the part of the output that seemed relevant: `Profile Description : Nikon Adobe RGB 4.0.0.3001 Red Matrix Column : 0.60976 0.31113 0.01947 Green Matrix Column : 0.20525 0.62566 0.06087 Blue Matrix Column : 0.1492 0.06322 0.74463 Red Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract) Green Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract) Blue Tone Reproduction Curve : (Binary data 14 bytes, use -b option to extract) Media White Point : 0.9505 1 1.0891 Profile Copyright : Nikon Inc. & Nikon Corporation 2009` And jxlinfo output: `JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 4681x2409, lossy, 8-bit RGB Color space: RGB, D65, Custom primaries: red(x=0.639994,y=0.330001), green(x=0.210000,y=0.710007), blue(x=0.150000,y=0.059999)gamma(0.454707) transfer function, rendering intent: Perceptual Brotli-compressed Exif metadata: 5009 compressed bytes`

What does the PNG you get from djxl look like?

The colors seem fine now when decoded to PNG.

then it's not a problem with jxl but with the viewer application

I'll let them know, thanks.

is it just me or does HDR kinda suck? Got my iPad set to a comfortable level of brightness, accidentally open an HDR video on YouTube and BAM like a flashbomb right into my eyes.

a lot of HDR is not mastered well and apple devices have a tendency to amplyify contrast

One of the issues with HDR is how to prevent people from intentionally or by accident making everything way too bright. In principle well-mastered HDR should not really be brighter than SDR. But some people will just tag SDR content as BT2100 HLG or PQ without conversion, which makes it way brighter and more saturated. It's the color equivalent of ads that have the audio volume way higher than the main content.

See also: https://github.com/w3c/csswg-drafts/issues/12096

I haven't had the chance to actually read and digest this but after a quick skim I noticed > This whole issue feels similar to the issue of audio loudness normalization. which gets practically brought up in the exact same way here, and perhaps this video would be a good point on that thread https://www.youtube.com/watch?v=bYS-P2bF2TQ

Is it normal for yellow to look desaturated on jxl or is it image viewer issue?

-d 1 -e10 --noise=1

since the decoded JXL you posted doesn't seem to have that issue, it must be an image viewer issue, no?

Zoom into yellow flowers. I used some browser based image comparison. Diffchecker dot com

yeah, they are desaturated, but I think the yellow just got blurred into the surrounding grass...

Is it expected on using d1?

Idk, but it's definitely not transparent

especially on the small flowers it's quite noticeable without zooming in.

Hmmm. I used latest jxl

0.11.1 794a5dc

Okay d 0.5 looks better

It also looks desaturated when zooming 16x

looking at butteraugli distmap, I think it might be an issue inherited from butteraugli

https://discord.com/channels/794206087879852103/794206170445119489/1376443605220065292

it looks pink color also has desaturation problem.

Unfortunately yes, I made an issue about it a year ago https://github.com/libjxl/libjxl/issues/3616

avif looks better in your github issue

Regular jpeg looks better tbh

when plotting a 3D chromaticity diagram in Wolfram (formerly known as Mathematica), there’s an option to include the spectral locus

it’s quite fascinating to see it in 3D

What if DCT is actually better suited for luma channels and not chroma channels?

DCT is good at preserving grit and texture but that's not necessarily desirable with chroma channels, where blurring isn't very perceptible compared to luma.

Mosquito noise and ringing is very noticeable in chroma channels but smoothing and blurring isn't. So isn't DCT actually the worst method to use for chroma channels?

Wouldn't a compression method that's optimized for cartoons and diagrams be better?

So VarDCT Y, Modular XB? I mean you could construct a file like that using layers

I'm not talking about specifically jxl. I mean just in general, is DCT even an appropriate tool for chroma channels?

Downsampling is commonly used because blurring is harder to notice than traditional DCT artifacts.

For chroma channel only

For a more advanced codec like jxl, special techniques could be used instead like pre-processing filters to reduce entropy before compression, and special dct quant tables that emphasize more blurring and less ringing.

While the luma channel is tuned for less blurring and more grit

https://blog.sebastianwick.net/posts/blender-hdr-reference-white/

Different quant tables are already used for luma than for chroma, both in regular JPEG and in JXL. Chroma does get more smoothing/blurring than luma, i.e. the quant tables are steeper, leading to zeroing of mid/high frequency coefficients. Probably a bit too steep, in case of the libjxl chroma quantization — I think it's what causes the slight desaturation problem.

Well that just seems kind of strange though since if it's done correctly it should not cause desaturation. Resampling, averaging, blurring... It would only cause desaturation if it's done naively without considering gamma for example.

If gamma is taken into account for the calculations then it should look like the same color

I think that's the problem. It's done in gamma space rather than linear space

without compensating for the bias

That's why it consistently shifts in one direction only, always biased toward desaturation

All DCT operations happen in a gamma compressed space, you cannot really do anything else. The whole point is to make the transfer function more perceptual, if it would be linear then the darks would get way more visible artifacts than the brights...

Yes but if you have a steep curve that chops/blurs the HF then it will shift/bias the results to a different brightness or intensity

If you don't take into account that bias then you will get desaturated colors and darker images

It's like resizing an image in gamma space instead of linear space

It's exactly the same thing

Blurring chroma causes desaturation on average, if you have high frequency in the chroma (say a checkerboard of highly saturated pixels and totally achromatic black pixels) it will get replaced by a smoothed out less saturated chroma value...

It's corrupting the appearance of the image because it's not actually factoring the resulting appearance into account

Yeah but if it's blurred based on objective intensity of light then the result should look the same...

The result should be roughly the same number and spectral distribution of photons

Possibly encoder side improvements are possible that correct for gamma effects, but it's not easy.

Yes, of course.

It's not easy, but I think that's the main problem

It might be possible to do something like doing the DCT in linear XYB, then somehow apply the transfer function to the DCT coeffs, or something.

It kind of makes my head hurt to think about it right now but I know some really clever people have done something similar before...

I know there are some really, really clever people who are good at this exact sort of problem

Maybe it could also be mitigated by some kind of pre-processing step that removes HF noise from chroma channels.

Since the color shift is caused by chopping the HF without taking gamma into account

This actually sounds like probably the simplest and most elegant solution

But... I don't think that's really possible... except for the LF image

The quant table isn't just about blurring, it's about accuracy and rounding. The B channel is being rounded too harshly, causing blue to bleed into saturated colors and making them shift towards white instead

Calculating the LF image in linear light would still probably make a really nice difference.

It's most noticeable in places that are anti-blue getting shifted closer to blue, aka closer to zero

Well yeah, adding blue to blue is less noticeable than adding blue to yellow :P

Is there any evidence that it causes blue or any other color to become MORE saturated and not less?

I think it consistently shifts toward zero

Which makes sense, since rounding was tweaked to go towards 0 due to negative floats

Because it's the same as when you down-sample an image in gamma space instead of linear space.

Any kind of consistent bias that doesn't average itself out is going to be very noticeable to the human eye

I think the main problem is the interaction between luma and chroma. E.g. take a checkerboard of red and black. In luma that is a checkerboard of black and gray, in X or Cr that is a checkerboard of 0 and some positive value. When doing chroma subsampling, or quantizing the high frequency coefficients, the X or Cb becomes a constant positive value that is the same for all pixels. That means the red gets desaturated, but the black will remain black; the saturation of those pixels doesn't change. So the overall saturation goes down. It would probably be better to take into account the effect of luma and pretend all pixels have a more saturated value, which might keep the overall saturation more constant after converting back to RGB...

You could try using a moderately saturated blue checkerboard. We meant to test it with yellow to confirm it's the HF, but never got round to it

I know I was doing tests with Oxide, to see the XYB passes progressively load in to see what they were doing to the image

I also separated the AC from the DC to examine where the desaturation was taking place. It was mostly the AC, but very slightly in the DC too

On an unrelated note, human eyes are much less sensitive to color in the dark... I wonder if there's a way in practice to take advantage of that fact to get even more data savings from shaving off color precision in dark areas.

Haven't you seen how harshly libjxl compresses dark areas?

Yeah but libjxl stupidly compresses luma too much in dark areas.

Our eyes are actually MORE sensitive to changes in luma in dark areas

It's at a point most people have to use intensity target to get reasonable results for editing workflows

but LESS sensitive to chroma

Not to mention because there's drastically fewer values for dark colors

Yeah but I'm talking about whether there is a practical method to shave bits off chroma precision in the dark.

Sounds more like we just need to feed more bits to luma and then it's already done

Do you always have to use the same amount of chroma precision across dark and light image regions or can you vary the bit cost so dark pixel chroma is cheaper?

Again, it already is cheaper, and there's less values in the dark already so there's inherently less entropy and quantizaion needed

How is chroma cheaper in dark pixels?

Dark pixels sometimes have a lot of chroma variance and entropy

But it's completely wasteful to preserve that chroma information accurately

Lots of variance and entropy, but only in a small range of values, so quantizing them to a single value has much less impact than in bright regions

It can be heavily rounded and quantized and if the pixel is dark we will never tell the difference

Would the CHROMA channels really have a small range of values and less noise/variance?

the X and B channels

Unless you're looking at a red dwarf through a telescope, there's not usually vibrant colors in dark photos

Well I haven't seen what the channels look like when they're separated... For all I know X and B might look really noisy and chaotic as it gets darker.

Sometimes when you postprocess and over-expose photos you get a lot of multi-colored static

And then it's no longer dark :P

Also encoding and decoding complexity

Mainly because it's a cheap and easy and usually imperceptible way to improve bitrate.

Yes, and I assume making a video format really well-suited for both 4:4:4 and 4:2:0, including decoding complexity, would increase not only encoder but also format complexity... So I assume even future video formats will likely be about twice as hard to decode with 4:4:4 compared to 4:2:0...

DCT artifacts are a lot more noticeable in the chroma channels than in the luma channels. Blurring is a lot less noticeable in the chroma channels and a lot more noticeable in the luma channels. So it begs the question: is it really appropriate to use DCT for both?

If they are so fundamentally different the way the human eye perceives them

has science gone too far?

(the ICC profile)

raw vs. corrected screenshot

I am effected by confliction

so... the second one is color-graded to look like on the device display I assume?

yes

basically `magick raw.png -set profile 'New 2DS XL.icc' -profile .../sRGB.icc -strip corrected.png`

(just attaching the profile would also have worked as long as it stays attached and the viewer uses it)

(and I can confirm that the version on the right is much closer to how I remember it looking while I was playing)

So the screen is extra blue then

~~is it bad that it just looks like a color temp shift to me?~~

pretty much

(this shows it “in reverse”: you need to send less blue to the device to get the neutral tone of a given lightness)

I believe this should give an idea of “how wrong” it is to assume sRGB instead of using the profile

this is fascinating, thank you for sharing ! How did you take the screenshot ? Was it with the 2DS functionnality?

I installed a custom firmware on my New 2DS XL and it came with this feature, but I took this screenshot a long time ago and I don’t actually remember how to trigger the feature 😅 if I had to take a new screenshot, I would probably do it in an emulator like Citra

I am in the middle of doing some kind of color calibration, and maybe these kind of profiles are what we need. it's basically a big LUT that associates the level of the uncalibrated R,G or B color a new level ?

pretty much – it says how to map RGB triplets from the device to absolute XYZ values (and from there, one can use another ICC profile to map those XYZ values to another RGB colorspace)

(software for doing this often hides the intermediary XYZ step)

Oh I see it's not RGB to RGB

in this operation, XYZ serves as the so-called “PCS” (profile connection space)

That makes sense

indeed, not on its own – but what I showed with my example screenshot was “2DS profile” -> “sRGB”

Oh I see, the intermediate step is skipped

indeed

if you were to profile your screen and find that it basically behaves like a Display-P3 screen, and you wanted to display “2DS red (255, 0, 0)” on it, what would happen would be something like this: “what absolute colour is (255, 0, 0) when displayed on a 2DS?” [read and apply 2DS.icc and find that it’s X=40.9027 Y=23.3734 Z=2.9388] “how do I display X=40.9027 Y=23.3734 Z=2.9388 on the target device?” [read the target profile, display.icc, and find that you need to send (223.3, 78.1, 52.0)]

but often, on the web (and elsewhere), instead of images in various colourspaces with the right profile attached, what one often finds is untagged images that are assumed to be in the sRGB colourspace by convention

so converting to sRGB is a way to conform to that convention, at the cost of potentially clipping saturated colours that are outside of sRGB’s gamut

(and then it should ideally still be converted to the destination profile correctly)

Oh I see !

very nice way to explain it

Does the issue show up when the image is encoded for 2DS but there's not an colorspace tagged so (255,0,0) is just sent directly to the display (lets say the display is sRGB), showing sRGB red instead of 2DS red?

the first screenshot I posted is basically that (untagged 2DS screenshot, which the Discord client will likely interpret as sRGB)

if you attach to it the ICC profile I posted, it should start looking like the second screenshot if the second screenshot is interpreted as sRGB

my next “victim” is going to be a Game Boy Color

my previous attempt with a spectrophotometer failed, probably because of the GBC’s reflective glass in front of the screen

this time, I’ll try taking photos of it with an X-Rite calibration target in the frame

(the target should arrive tomorrow evening; I’m not yet sure when I’ll do the actual “profiling”)

I wish I had a GBC with a working original screen [cheems](https://cdn.discordapp.com/emojis/720670067091570719.webp?size=48&name=cheems) that would be interesting, I wonder if the ICC could be applied to common screen mods, that would be really cool

it’s very hard to see anything

you need light (since it doesn’t have a backlight), but it will also reflect most of it

so it’s very tricky to light properly

I’m not fully sure how I’ll approach this for the profiling

You could take it apart and put the screen behind a white light

I'm intrigued :p

but instead, I tried to use it to "calibrate" the screens via CFW before vs. after

hyprland let's you directly modify its colormanagement shaders without recompiling. this means we can implement our own inverse tonemappers as well as fix weird decisions. There's also means that a single see command, we an swap between using the inverse sRGB oetf and a pure 2.2 for decoding which is just as nice as I thought it would be

https://android-developers.googleblog.com/2025/08/what-is-hdr.html

AHHHHHHHHHH

I was liking it but they forgot white point in color space definition

other then that ita good until the ultrahdr shilling comes in

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

really wish this article wasn't for shilling ultraHDR cause it's actually good otherwise T.T

but now its gonna be dismissed as crap

It's a valid point that the 10-bit Rec2020 PQ space has unused volume and does not use the full capabilities of a 10-bit P3 display with gamma 2.2 at 2000 nits. It's not mentioned in the article but this is made worse if the image space is 10-bit YCbCr and the display space is 10-bit RGB.

They somewhat imply that HLG suffers from the same issue though

P3 HLG would be a better match, but the main issue here is with the video codecs (like AVIF) using fixed precision uint YCbCr. They need to do that to avoid cumulative errors when potentially there are lots of inter frames. But this inherently limited precision does cause banding issues.

For JXL, there is no such precision issue since (at least for lossy), both the color space and the bit depth is just informative and the actual image data uses an absolute color space without quantization to some uint bitdepth, so when decoding you can keep more precision before converting to display space. This is not possible in video codecs where the codec is only defined as a black box to encode frames that are 2D arrays of uints and colorspace is considered "application level metadata" used to interpret the uints.

It's quite a stretch to use the precision limits of the video codec approach as an argument in favor of UltraHDR. Sure, doing 8-bit base + 8-bit gain can be more precise than just 10-bit base. But only if the gain map is a 3-component, 4:4:4 one. In practice often single-component, subsampled gain maps are used, which introduces artifacts that dwarf precision artifacts. Also even when using a video codec, you could always just use 12-bit P3 HLG instead of 10-bit Rec2020 PQ. Or you could just use JXL which doesn't have these precision issues at all.

yeah, it's a shame that they made it just an ultraHDR marketing piece, because the core guts are there

De-Googled HDR Guide

I've been thinking about it

tldr is HDR is a marketing term and here is my own definition lol

Well it's about time, now if only it had JXL support 😔 https://youtu.be/maaz1caS3zc

Jyrki predicting proLab/PCS23-UCS/Iapbp in 2021

but yeah I've been reading some papers and people are making projective/homogeneous colour spaces which is neat

(<https://doi.org/10.1007/978-3-031-72845-7_3>, <https://doi.org/10.1364/OE.530213>)

PatienC++

what I found when doing jxlatte is there was an awkward issue where modular lossless was basically ints, but lossy worked best in float but the flexibility of the format made it hard

so I had an ImagePlane class that is either a float or an int array and can be cast as necessary

ooh

WDYT? https://www.science.org/doi/10.1126/sciadv.adu1052

very cool stuff, also very creepy to be stimulating cone cells individually, they call it "a new principle for displaying color" but I'd argue that this is no longer a display but something that is hacking directly into the human visual system — almost as if you're directly connecting to the optic nerve

https://github.com/LMP88959/Digital-Subband-Video-2/blob/main/bc2.h https://github.com/LMP88959/Digital-Subband-Video-2/blob/main/bc2.c nothing crazy but I made a simple lossy perceptual color space similar to XYB that prioritizes speed over accuracy

Crossposted from <#794206170445119489>; Linear sRGB gamut in OkLab and XYB side-by-side, with considerable rotation and scaling to XYB to make them comparable

And a turnaround of XYB, with X scaled 14x

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/442#note_3186754

truly an eternal argument

seems to be like that IEC standard basically totally failed to understand sRGB and thus fucked it up, but only for print

tbf everyone fucked that up

My understanding is as follows: - what they (rec601/709, sRGB) actually wanted to use were just gamma curves - (1/255)^2.2 * 65535 = 0.3327, (2/255)^2.2 * 65535 = 1.5288, etc, so when converting 8-bit nonlinear to 16-bit linear, rounding errors will be pretty problematic for those first few dark steps, and it doesn't roundtrip (1/255 nonlinear -> 0/65535 linear -> 0/255 nonlinear) - adding a linear segment solves that issue, so things get defined with a compound piecewise function and implementations can use 16-bit linear intermediate representations (this was the late 1980s, early 1990s when float32 was still not very available and memory was limited) - this was basically an approximation useful for doing nonlinear 8-bit for storage and display -> linear 16-bit -> image processing -> back to nonlinear 8-bit for storage and display - somehow the approximation became spec - now we are stuck with this messed up transfer function and it's ambiguous what the actual intended way of displaying images is

At least now we're starting to head in a right direction in both how we treat SRGB and also just not using SRGB.

I read this related article once; sRGB usage is so woefully inconsistent and out-of-spec among developers https://ninedegreesbelow.com/photography/srgb-profile-comparison.html

I'm pretty sure Krita now uses the icc developed by this author for a well behaved sRGB profile

I am of the opinion that sRGB had been so bastardized that its no longer possible to actually implement properly

Even with accurate spec usage it would later be interpreted in a myriad of ways by nonspec software, unless you always embed your profile I guess

But even then, not everything is colour managed, and those that are still may make errors in their graphics pipeline

Nightmare

sRGB probably shouldn't be implemented as the spec says since it just doesn't make sense anymore.

We aren't using crts anymore, but it still has nice detail for darks

If I was making color managed software, I would program it to treat any sRGB ICC as gamma2.2

If I was producing color content, I would make sure that none of it is in sRGB

I wonder how the gamma value of 2.2 (or is it 1/0.45? that's not quite the same thing) was determined. Is it an approximation of something perceptually relevant, or is it an approximation of how CRTs happened to behave?

I'm pretty sure it was to fit for crts

Perhaps a bigger issue is that different srgb profiles use different primary chromaticies, different white points, and sometimes even different black points, on top of their transfer functions

And don't forget spec srgb is piecewise, with a linear section and 2.4 gamma section, which is often approximated with builtin tables with different amounts of data points

yeah, CRTs https://www.w3.org/Graphics/Color/sRGB

more specifically, essentially a good median of various CRTs in common use

I think it's also for dim viewing conditions, but I don't know how conditions should translate to transfer functions

darker surroundings -> higher gamma to also push the shadows further down

it was designed to encode content in a way that both fits a good amount of PC display characteristics while remaining compatible with rec709

> It is not ambiguous. > You are conflating *encoded colourimetry*. sRGB, like BT.709, does not encode the colourimetry presented. > The presented colourimetry, *precisely* like BT.709 to BT.1886, is yielded when presented on the reference display, and measured at the faceplate. 🫠

wait, so the "solution" is having a golden display that's deemed "the one"? I can't think of anything else they mean by "reference display"

it’s not exactly a physical display, but more so a definition that is deemed to be the reference

so if the reference display is defined as “a 80cd/m² display with such and such primaries and a gamma of 2.2” then the rendering you get on that hypothetical display is the presented colourimetry

at least that’s my understanding

and if the quote and my understanding are both accurate, that would indeed mean that the piecewise sRGB TF is only meant to be used as the OETF and that the EOTF is gamma 2.2

That is my understanding

that does kind of raise the question of when an sRGB OETF would ever be used, though

video games?

ah:

> The advantages of optimising encoding outweigh the disadvantages of this mismatch. so it does take it for granted that there will be a mismatch, and that the goal is specifically to optimise encoding

hm… what does it mean for Display-P3

this is the general understanding people are leaning to

no, only in extremely old video processing pipelines, IE. Old 16-bit pipelines, i'm not even convinced that rgb888 is a good fit for SRGB.

||3 × fp8||

Glare and all those other excuses are I think just explanations people came up with to rationalize the weirdness of the piecewise TF as being a really desirable TF, while all it was really — as far as I understand — was an engineering compromise to make 8-bit nonlinear to 16-bit linear and back roundtrip losslessly while using a TF that approximates gamma 2.2, which I'll admit is a nice property to have in a processing pipeline in the 1990s, but it doesn't mean we should keep doing that today.

Can an ICC profile represent that kind of asymmetrical conversion? Piecewise one way and gamma in the other?

exactly!

strictly speaking, there is one “PCS to colourspace” transform and one “colourspace to PCS”, but I’m not sure of the implications of not making them symmetrical

(PCS = profile connection space, usually XYZ but can be Lab)

You would expect that colorspace to PCS back to colorspace (or PCS to colorspace back to PCS) would be the identity, but this doesn't appear to be a requirement in ICC, or at least, I've seen profiles in the wild where colorspace to PCS isn't even a bijection so it doesn't even have an inverse that could be used to roundtrip. Not sure if those profiles are technically conforming or not, but they exist so at least there's nothing syntactically preventing this.

The problem is that piecewise sRGB exists

so like, while it was intended to be a fast approximation to gamma22

what should we actually do now

pretend sRGB is gamma22? cause they are not identical

but they are, because the actual monitors targetted by sRGB were gamma2.2 (on average)

so gamma2.2 is what people were actually seeing

There is no real consensus on this.

Let's be clear here. SRGB, as a specification, really defines one thing. It is a camera encoding function designed to be compatible with Rec709, and look good on the average CRT monitor at the time.

well optical encoding function

The SRGB specification explicitly acknowledges that there will be a mismatch in the encoding and decoding of an SRGB content stream, If we had an accurate system, the real question would be, when you're working with SRGB content, should you invert the transfer to retain as much of the original data as possible, or retain the artist's intent and use Appear 2.2? However, many monitors use the inverse piecewise 2.2 function while many monitors use a pure 2.2 function. The real issue becomes we don't actually know whether content that is marked as sRGB is actually graded for a pure 2.2 or piecewise. IMO The proper thing to do is to default to a pure 2.2 function, which is the most accurate to the spec while giving a proper flag/setting to change to the two-part function. This will be the most correct while also giving the flexibility for wrongfully mastered content. Without that flag, I recommend using the Inverse 2.2 personally because I find it produces the least worst results across myriad of content graded for both 2.2 and peicewise displays, it is safe, but not good

it gets extra complicated though when you have, say, encoders/decoders. like, JPEG XL just decodes to linear RGB, so what do you do when you want to convert that to sRGB? should it assume gamma22? what if I have a JXL *encoder* so I have to linearize content tagged as sRGB. what do?

where there's a roundtrip but the other side of the roundtrip is possibly by someone else

so much for "standard" in sRGB when there's no agreement on how to interpret it

I’m still wondering which interpretation Display P3 really intends to use

when ingesting linear, encoding with a pure 2.2 and tagging as pure 2.2 is ideal. With Color Managed Software, it's not ambiguous at all, and with Non Color Managed Software, you're going to be right 50% of the time. When you are ingesting content tagged as sRGB, there's no winning. This is literally a decade old problem now. And the only winning move is to not play the game. Since we don't live in that world, we can just do the next best thing. And that's giving a toggle between the two. This is one defaulting with a pure 2.2 but giving an override is the best solution you can do and the second best is just to use the piecewise 2.2 because it produces the least offensive results when wrong.

Whisper has some really weird capitalization tendencies.

except for software that assumes gamma2.2 is "supposed" to be sRGB 🤣

yeah... well, as I said the only winning move is not to play lol

for example a lot of software will interpret 0.45gamma PNGs with 709 primaries as though they are sRGB

at the very least, its 50:50 whether or not that software interprets sRGB as pure2.2 lmao

If you only specify a gamma and no primaries, which primaries ought to be used?

rec709/srgb is by far the most common for untagged content

well, apparently “This page is the primary documentation source” https://www.color.org/chardata/rgb/DisplayP3.xalter and it only says “Color component transfer function: [piecewise formula]”

so I guess Display P3 unambiguously uses the piecewise-linear TF

even more unambiguously: > **Encoding** > […] > Image state: Output referred

its nice that it's not ambiguous

if anyone has comments they wanna make about sRGB handling that will likely influence Wayland, now would be the time https://gitlab.freedesktop.org/pq/color-and-hdr/-/merge_requests/66

I wish I knew enough about color management to comment. I hope they don't screw it up

its going good so far

Can anyone recommend some kind of monitor color / brightness checker? Ideally that can give me useful information under Linux.

Some kind of proper color calibration tool would work though I msotly only care about measuring nits, so I can tune my monitor brightness script to give the same brightness across my multiple different brands of monitor.

not what you asked, but in my case I found an ICC profile posted by someone that measured my display model. useful for calibrating without buying or renting an expensive tool. I don't know if that contains brightness information, but if so you might be able to find an ICC profile for your display and use that

depending on where you live you might be able to pick up a used colormunki display/i1display studio for very cheap

like in germany on kleinanzeigen those are like 50€ sometimes

well would you look at that https://www.kleinanzeigen.de/s-anzeige/x-rite-colormunki-display/3073533075-225-22278

I'm in Sweden but perhaps this seller will ship here

that model is the i1d3 variant with the speed restricted by firmware, right?

yes https://www.argyllcms.com/doc/instruments.html#i1d3 > The ColorMunki Display is a less expensive package with more limited software from the manufacture, and has hardware that takes a noticeably longer time to make most measurements (a minimum of 1 second), but both instruments will take longer for very dark samples, and under these conditions the speed difference is less significant. Because of the measurement speed limitation, the measurement of display refresh rate and synchronization of its measurements to a refresh display is not possible with the ColorMunki Display. > > The i1Display Pro package comes with i1Profiler, and the instrument is generally faster than the ColorMunki Display, but other than this and the software package, the instruments appear to be virtually identical. (Note though that the ColorMunki Display is unable to measure the refresh period, so is less repeatable in this mode than the i1Display Pro).

better than the older “ColorMunki Smile”

for that amount of money you should be able to get a better variant i think...

not a great deal rn but this goes up to 2k nits and is faster https://www.ebay.com/itm/156371256804

sometimes these go for less than $100

👀

same thing new, but with unclear manufacturing date (needs to be 2017+ to do 2k nits): <https://www.ebay.com/itm/177515819473>

beware though that those variants with higher max luminance often (always?) achieve this by effectively having an integrated ND filter, which makes them worse for dark readings

(at least from what I remember reading)

iirc the 1k and 2k ones are basically the same with revision b, only the very old revision a (1k only) ones are substantially better near black

yeah, this might be more of an issue with the more recent “HL” models which go even higher

I don’t remember wich revision I have

04/2018 Rev B-02

oem or retail? only the oem one got the upgrade

retail

https://www.displaycalibrations.com/x-rite_i1_measurement_solutions_info.html has some interesting info

> Being certified to a specific nits level doesn't mean that the any revision of i1Display PRO will stop reading above that, just they are not certified to be accurate beyond its official certified luminance range capability.

my best monitor only goes to 300 nits anyhow 😄