JPEG XL

at least that is how HLG is supposed to work, i've never confirmed this

wonder if there is a desmos that could show "ideal" tonemapping/scaling based on 99th/95th/avg luminance of a display for PQ and HLG

some displays follow bt.2390, which works quite nicely

was designed to be easy to implement, happens all on PQ

2390 has a lot of issues though

the current state on windows is that applications are expected to do their own tonemapping to the reported capabilities of the display, so the display should ideally just track pq and hard clip

not sure if/what hdr metadata windows sends to the display for MaxCLL and stuff, but applications shouldn't set that themselves anymore

and that's competely horrid

why?

because compositors should be the one to handle mapping, since it allows you to have multiple applications side by side without looking like trash

why would it look like trash?

if you have a 1000 nit display, SDR apps are being displayed at 203 nits, but you have a bright HDR image, it will completely wash out the SDR app

you need the compositor to handle normalization for this

this talk briefly talks about similar concepts but it largely applies here https://www.youtube.com/watch?v=bYS-P2bF2TQ

phenomenal talk btw, highly reccomended watch for anyone

normalize it according to the current luminance of the hdr content that's on screen? or its hdr metadata

normalize it in however way is best for the current situation, being contextual aware, and allowing the user to have input is very important

do you have an example of a platform that does something like this?

nope. Wayland will eventually allow this though

but I also don't know of any platform that actually does HDR good

well, KDE gives you rudimentary control over whitepoint for SDR applications which is at least a step in the right direction to align with windows

<@604964375924834314> <@532010383041363969> do you remember where the values in https://github.com/libjxl/libjxl/blob/main/lib/jxl/cms/opsin_params.h are coming from?

I think they originated fom some optimisation process, and then there was the tweak to make X=B for grayscale

in the white paper on JPEG XL and also in the spec itself we make it look like it's LMS

but there are different LMS-ish color spaces, basically one for each color appearance model

https://en.wikipedia.org/wiki/LMS_color_space

if you use the Hunt–Pointer–Estevez (von Kries) matrix, for D65, then the matrix you get for going from linear sRGB to LMS looks like this: ``` L = 0.31399022f*R + 0.63951294f*G + 0.04649755f*B; M = 0.15537241f*R + 0.75789446f*G + 0.08670142f*B; S = 0.01775239f*R + 0.10944209f*G + 0.87256922f*B; ```

which seems like a much "sharper" LMS matrix than the one we use in XYB, especially our S has way bigger weights for R and G

(but also the L and M of XYB are closer to one another than in the HPE LMS)

I for sure tweaked the matrix so that grayscale has X=0, Y=B

otherwise you get interesting color artefacts

anyonr know how I can apply ICC profile to raw pixels data ? e.g. when making a screenshot with MPV, it writes a PNG with ICC but some programs don't support it :/

if they assume sRGB, then that means you would want to convert from that profile to sRGB

you can do that using imagemagick: ```console $ magick input.png -profile .../sRGB.icc output.png ```

you can optionally also add `+profile '*'` to not include that sRGB profile in the output PNG (although it seems to cause trouble on Windows because it tries to interpret the * as a wildcard…)

`-strip` might also work

thanks

You can produce an sRGB profile if you need one with `icc_simplify sRGB sRGB.icc`

where do I get `icc_simplify`?

It's one of the tools in libjxl

that's pretty neat

Wouldn't any matrix where each row sums to 1 (or to whatever other same number) have the property that R=G=B implies L=M=S, which implies X=0, Y=B? Did we originally have a matrix where the rows didn't sum to the same value?

Anyway, I'm wondering why the HPE matrix for LMS looks so different from the one XYB uses. It looks like the XYB one is closer to the actual cone responses...

made a little plot to see the sensitivity curves in comparison to the RGB primaries according to Rec2020 (where the primaries are spectral colors; in sRGB they are not)

Correct, originally we did not 😛

The usual definitions of LMS like HPE and Bradford do have matrices that have rows summing to one, but they make L, M and S much more distinct and closer to R, G and B

<@532010383041363969> do you remember what the LMS matrix of XYB was based on?

Also: is kOpsinAbsorbanceBias a term meant to model spontaneous opsin activation, or is it just something to make the cube root transfer function better fit the actual psychovisual transfer function? (or both?)

If I recall, weren't there discussions about if displays can even hit 10K nits currently? https://youtu.be/SV4F3v3TekU

I think they just min-maxed the tests. Real world performance seems to be more "reasonable".

Is there an article or form thread covering this phenomenon?

The image compression gods are talking in their own language again

color science is another can of worms where I don't understand a single word said

It might as well be magic

Does anyone know more about this HDR vivid? Was introduced on phoronix and can't find much info about it but what I can find, it actually looks dope https://www.phoronix.com/news/Vulkan-1.3.301-HDR-Vivid https://www.abu.org.my/wp-content/uploads/2012/04/T-22-22-2-Introduction-of-HDR-Vivid-Standard.pdf https://www.hisilicon.com/en/techtalk/hdr-vivid

unforunately it seems everthing is mostly just fluff aside from this which actually looks great as it allows you to define tonemapping curve params, like a HDR10 extended

is 1000:1 a good contrast ratio

for a non-old display

it’s somewhat typical of an IPS or TN panel

maybe slightly on the low end for IPS (some are closer to 1500:1)

but closer to the high end for TN

It’s ips

Samsung s9 27 inch 5k

https://www.reddit.com/r/Monitors/comments/1dmxal5/best_5k_thunderboltusbc_monitor_for_macs_spoiler/

Can’t find the lg ultrafine selling in Australia

It says discontinued on lg site https://www.lg.com/au/monitors/ultrafine-uhd-4k-5k/27md5ka-b/

I have a colorspace related question, I hope you guys don't mind me asking it here.

This is from [wikipedia](https://en.wikipedia.org/w/index.php?title=SRGB#From_CIE_XYZ_to_sRGB), and given that I don't have access to that standard I'm wondering how did they get the numbers in the matrix. These numbers can also be found in ["How to interpret the sRGB color space"](https://color.org/chardata/rgb/sRGB.pdf) and as mentioned in the article, they differ from the ones in the original publication. I also calculated the matrix on my own, and I got the exact same results that the erroneous one from the original publication. Does anyone has an idea of what's going on here? Here is my Python's code to calculate the values: ``` # http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html import numpy as np ## sRGB srgb_r_chromacity = np.array([0.640, 0.330]) srgb_g_chromacity = np.array([0.300, 0.600]) srgb_b_chromacity = np.array([0.150, 0.060]) # ## White points white_point_d65 = np.array([0.312700, 0.329000]) # r_chromacity = srgb_r_chromacity g_chromacity = srgb_g_chromacity b_chromacity = srgb_b_chromacity white_point = white_point_d65 def tristmimulus_vector(chromacity): return np.array([chromacity[0] /chromacity[1], 1, (1 - chromacity[0] - chromacity[1]) / chromacity[1]]) tristmimulus_matrix = np.hstack(( tristmimulus_vector(r_chromacity).reshape(3, 1), tristmimulus_vector(g_chromacity).reshape(3, 1), tristmimulus_vector(b_chromacity).reshape(3, 1), )) white_correction = np.linalg.inv(tristmimulus_matrix) @ tristmimulus_vector(white_point) M = tristmimulus_matrix * white_correction np.set_printoptions(formatter={'float_kind':'{:.4f}'.format}) # print(M) print(np.linalg.inv(M)) ```

I think they might be referring to the rounding of D65

the values you are using are rounded versions of (0.31272, 0.32903)

this then propagates throughout the calculation

wait, no, that’s not it

I’m not sure either, because I still get similar results when I tweak your program to use arbitrary precision arithmetic using SymPy

(if you simply remove the `.applyfunc(...)`, it will print the exact fractions)

First time I see these values 😅

Oh using Sympy is a nice idea, I haven't used that in years

I don't know if you shed some light or made it worse because it's _again_ a different set of values lol. But thanks for your answer!

For the record: while I took the formula from there, the results are also slightly different on that website. <http://www.brucelindbloom.com/Eqn_RGB_XYZ_Matrix.html>

And at the same time, the values from the JavaScript code in the css-color spec are the same as my initial results.

if you do the exact math with the chromaticity xy values specified in the spec, you get these matrices <https://www.avsforum.com/threads/ground-truth-re-bt-709-rgb-cie-xyz.1115923/?post_id=34070242#post-34070242>

not entirely sure if that's technically correct to use, since the spec does specify a slightly different matrix

but IMO treating the xy values as the ground truth makes the most sense

I would say the same but I actually don't know how to get the values in another way than from the xy values.

i mean as opposed to just using the weirdly rounded matrix from the spec

AFAICT, it is what everyone uses so it's probably ok

I understood, but now I'm quite curious to know how they got these numbers in the spec.

paywalled spec pain

well, i have a copy of it from a torrent, but it just specifies the same xy values as bt.709 anyway

neat

i think this answers that question https://photosauce.net/blog/post/making-a-minimal-srgb-icc-profile-part-3-choose-your-colors-carefully

That blog is on my list of things to read 😅

I'll read that tonight, thanks for the link!

it seems https://photosauce.net/blog/post/what-makes-srgb-a-special-color-space is relevant too

https://x.com/DSCCRoss/status/1857208745014776215

It's nice to see further improvements in what was already a pretty good display to begin with.

ugh, something changed in Chrome?

https://sneyers.info/hdr/stimuli/sources/alps-sunset.png

https://sneyers.info/hdr/stimuli/distorted/alps-sunset.png/alps-sunset.png-jxl-d1.png

these two images used to look identical in Chrome, and now the second one looks quite noticeably darker than the first

if I strip that `cICP` chunk from the second PNG (so only the ICC profile remains, which is equivalent to the cICP chunk), then the problem disappears

darker, but also less clipped

maybe it has to do with the highlight headroom that Chrome decides to give it

<@794205442175402004> the second image has not just a `cICP` chunk but also a `cLLi` one

ah, is that what is causing the difference?

I guess the jxl was compressed with intensity_target=10000, and so it’s what gets written to the cLLi chunk and it leaves more headroom than necessary?

yes, the second one is just what you get if you do default cjxl/djxl on the first one

it's not great that doing default cjxl/djxl produces an image that looks different from the original

I’m not sure what Chrome does with the first image that leads it to use a < 10 000 source peak for its tone mapping

it might be that it just defaults to a lower value

I guess we should match our defaults then

it’s 1000 https://source.chromium.org/chromium/chromium/src/+/main:ui/gfx/hdr_metadata.cc;l=56-57;drc=277f4ab48eb85f7441f78aed191c31068ce89814

which seems a bit low as default

(in fact, for me, the first image has visible clipping)

ah, unless I reduce my screen brightness enough (to a somewhat ridiculous extent)

maybe we could just not write the `cLLi` chunk if the intensity_target is the PQ maximum anyway

then we just leave it up to whatever is reading the PNG to use an appropriate value

we don’t have to lie about it

Makes sense. And that solves the discrepancy too.

seems like the wayland protocol for colormanagement is starting to get close to the end, protocol in it's current state is here If anyone has questions or suggestions for the wayland devs, better start raising them https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/8ac0dc6108b826614b20d5a037175cba0d3006cc/staging/color-management/color-management-v1.xml

Ideally tonemapping an image to an sdr screen should be no different than to an hdr screen, so I wonder why it goes wrong...

I think on an hdr screen more is done in hardware than software and because an sdr screen lacks the same hardware it's often not done at all, not in software either since it's not thought of?

may want to bring this up in #mpv-devel on libera

or #libplacebo

i believe they are already aware

then nvm

Is sRGB distance closer to perceptual distance than linear RGB?

yes

Hi, sorry for bothering you I was implementing an ssimu2 for vapoursynth on GPU and for that I needed to implement the RGBS to positive XYB I wanted to know if my output seemed coherent with what you saw by the past, I tried copying the code of an existing ssimu2 vapoursynth implementationhttps://cdn.discordapp.com/attachments/1168620680850456696/1320084010625405010/image.png?ex=67684f8a&is=6766fe0a&hm=ee34098cef0ab8f8a9d82d8d15db558e1ad1bbc39641edd9d3294e002ceed469&

Haven't checked but those values do make sense

is there a document with the various xyb info and transforms and stuff? or is it just go code spelunking?

I’m afraid it’s probably mostly the latter

The forward transform is given in the white paper (https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf). I started working on a long "definitive" paper describing jxl which will of course also discuss XYB, but it will take a while before I have a sharable draft...

the default inverse matrix is in the spec 18181-1, as is forward iirc in annex O

https://youtube.com/shorts/GxdYYlss2bg

https://hyprland.org/news/update46/ > Color handling has been moved to OkLab from sRGB. This means gradients and color transitions will now look more natural.

I never knew that there was a compositor that did this. That is really cool though I can't assume this would be great for performance

I wonder If other compositor will follow suit

Which compositors generate gradients...?

I think niri does, but this is also going to help them a lot when it comes to color management

Why would you need OkLab for color management?

you dont need oklab specifically, but doing management in these type of colorspaces makes dealing with gamut and transfers a lot less painful

well, it makes a lot of things more simple

Hi, I come here in search of help I am trying to put 🧈 on GPU so I go through the code but some functions are just... not inside the code but with some random image lib linking so I am not sure about what s in the "rgb to xyb" thing I currently use the implementation of rgb to xyb from my SSIMU2 GPU thingy. Problem is that inside, there is an opsin absorbance and if I follow this code with my function, I ll get 2 opsin absorbance..

do you think that I should remove the opsinabs from my rgb to xyb and apply it there

or the 2 opsin abs are fine

iirc butter and ssimu2/jxl use different xyb functions don't they? I think this was a <@532010383041363969> thing?

IIRC butteraugli uses a logarithmic transfer function while jxl/ssimu2 uses a cubic one (with a bias term in both cases so the cubic is not exactly a gamma curve).

mmh.. do you have a link for an implementation of the butter version?

so I can see if the opsin is also made the same way

here's the original butteraugli: https://github.com/google/butteraugli

Current butteraugli is here: https://github.com/libjxl/libjxl/tree/main/lib/jxl/butteraugli

what is DF ?

I feel like I can ignore it but just in case I ll ask

feel free to ignore it

it's a marker for which set of SIMD instructions to use

Just to double check, XYB is Luminance, Green-Magenta and Blue-Yellow, correct?

that'd be YXB 😉

I've been wondering, the luminance in XYB, what is it's relationship to nits? is it like XYZ where a Y=10000.0 == 10000 nits / y=0.1 == 0.1% of # nits?

it's a little bit complicated. at least in jxl, it's normalized so that (1, 1, 1) is `intensity_target` nits *after* coverting to sRGB gamut

X and Y are mixed during conversion and gamma is applied with bias, so...

now that we have X=B=0 for greyscale, there should be a relationship at least in that case, although it might have a slightly funny expression

but yeah, it becomes much trickier once you throw chroma into the mix

(well, okay, maybe not _that_ much trickier)

As a sanity check X = Green-Magenta Y = Luminance B = Blue-Yellow Right? It took me 5 minutes to shuffle them around, running on 4 hours of sleep xP

yup

Thanks

Though... Why put Y in the middle instead of the start to match YCbCr? Surely then graceful degredation would've been easier for subsampled images and pipelines

(I ask because Telegram is subsampling jpegs assuming YCbCr causing chroma noise and much lower quality Luma)

something something XYZ

idk in hindsight I think YXB would have been better too

not my decision though

I thought we did do YXB in jpegli?

don't we?

You do

Are YXB and XYB the different spaces?

YXB = [0, 1, 0; 1, 0, 0; 0, 0, 1] × XYB

(in the case of jpegli, not quite, because there’s also some rescaling going on, but that’s the gist of it)

The attached ICC is labelled XYB_Per

Yes this "XYB_Per" is what would be shown on a viewer

Yeah, but apparently it's meant to be YXB on regular JPEGs

Yep, YXB isn't mentioned a single time on the libjxl repo

It's always called xyb

720 bytes is pretty good but I wonder how much further it could be shrunk down using manual hex editing...

The iccv4 profiles here are typically 480 bytes. https://github.com/saucecontrol/Compact-ICC-Profiles

found an interesting Chromium issue regarding BT.709 transfer https://issues.chromium.org/issues/40539111

so it's just doing sRGB EOTF now

Is chrome doing the color transfer wrong?

that is actually horrid lol

Firefox seems to do so as well https://github.com/mozilla/gecko-dev/blame/9621af264d4cc734ce10d59eaf41ceccc125270f/modules/libpref/init/StaticPrefList.yaml#L6333

firefox in general is horrid tho so at least that is expected from them

I tried to find the date of when Firefox started doing it like that because I thought it might have been to follow chrome however git blame locks up on that file so idk

[av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

It's using the wrong transfer curve on purpose...??

I thought this very obvious color banding on the gray background was YouTube's compression reducing the precision, but no, the eyedropper revealed that every band is actually 1 R,G,B value apart, wtf. This is the first time I realize how bad color banding is on 8 bits per channel without dithering

The banding *is* 8-bit per channel, but it's also still Youtube's fault. It was most likely either a solid color or was dithered

There was definitely an intended gradient in the video. If YouTube's compression un-ditheres videos that's kind of cursed

I mean dithering itself is cursed, ideally people upload higher bit depth videos and the decoder/renderer dithers them only when necessary I guess?

If av1 is anything like JXL in that higher bit depth images don't really increase the file size it wouldn't even cost them anything

Well, dithering is awful for compression usually, so it gets 'smoothed' into banding... Which then doesn't get dithered again

Right, yeah

There's been talk for the past decade about encoding 8-bit source as 10-bit since h.264. Don't think anyone's actually benchmarked the results, other than this paper from 2013 citing a 5% density improvement https://www.researchgate.net/publication/269326380_Comparison_of_compression_performance_of_10-bit_vs_8-bit_depth_under_H264_Hi422_profile

Wow, savings even

thoughts on this, in general? i think if most media were for example 10 bit, then on 10-bit displays they would render as is, and on 8-bit displays the decoder or renderer could choose to map to 8-bit (resulting in banding) or dither it, (potentially resulting in visible artifacts on low resolution displays), and the user could even choose which mode they'd want to use if they have a lower bit depth display, but critically the media itself is never dithered so you don't blow up file sizes

outputting files that are already dithered sounds like something that shouldn't really be necessary in basically any case, unless you want to be perfectly sure how your content looks exactly as dithered 8-bit

There are some bands in your example that are 2 sRGB values apart, but most are only 1 apart indeed. Probably the Y values in YUV are one value apart.

It demonstrates that 8-bit is not really enough even for SDR images (though of course with dithering you can make it look good enough)

Ah, yeah I didn't check every one of them, I checked a few and extrapolated, I shouldn't have confidently said 'every band' 😅

having more precision helps compression for such slow gradients since instead of sudden jumps at hard to to predict spots, you get a smooth gradient that can be predicted well

Makes sense, I bet with how many pixels apart the edges of the bands are, the gradient predictor isn't actually even good on gradients like that

It's counter-intuitive to me that higher bit depth images compress to smaller files, but when you consider predictors it makes perfect sense

well in VarDCT mode most of the gradient would likely be fully captured in the LF coefficients, which is at 1:8 scale. If the input is smooth then using relatively large block sizes and just the LF would probably suffice to capture the gradient pretty much completely. If the input is banded though, then preserving those bands will require HF and compression will suffer.

in codecs like avif/av1, the prediction modes will probably do most of the job for such gradients, and they will work better if they have more precision bits to work with. In 8-bit, a slow gradient is too slow for prediction to help much since it becomes bands of solid color rather than a real gradient, while in 12-bit the values keep changing and you have a real gradient that can be predicted very well

I decided to create a 1920 x 1080 16-bit per channel gradient image to experiment with this, decided to encode at effort 11 as well out of curiosity, forgot about it, came back 5 hours later, and it's still going <:KekDog:805390049033191445>

Effort 11 should add a warning when trying it on images larger than an icon

At least it doesn't outright kill your system anymore. Chunked encoding really took down the memory usage of it (Storing the image once for every encoding thread?)

Oh yeah I remember that

Also, I found this nice image for testing. Unfortunately it seems to be scaled from 10-bit to 16-bit for the PNG or something, because overriding it to 10-bit with cjxl results in a Ssimulacra2 score of 90

https://discord.com/channels/794206087879852103/804324493420920833/1286228923520127058 but that was also a big ass image, so not exactly fair

Oh, neat thing about that... https://discord.com/channels/794206087879852103/804324493420920833/1330127476403343360

Oh neat

Thing is, the JXL is actually larger, unless you use effort 10. Probably because the gradients are repeating rows that groups can't fully enclose

Also patch detection will not work when the background is not solid, while in PNG probably that repetitive text can still benefit from deflate...

Surprisingly... It actually did use Patches for the numbered scale

Oh, yeah that didn't seem right... ```ssimulacra2 10-bitGradientTest.png Test.jxl 95.77740192```

`-d 0` naturally, so might have to fix that

Ssimulacra2 is a bit excessively allergic to floating point shenanigans

This is 16bit int though

Well

The first one is

The jxl will be loaded as a float32 image

Riiight, yeah. decoding back to PNG is back to 100

I know I made sure it didn't dither inside Ssimulacra2 earilier today, but never checked what format it *does* use

The 16 bit gradient I made in GIMP is a 15.4 kB PNG and a 1.9 KB lossless JXL

effort 9 gets it down to 1064 bytes

https://embed.moe/https://cdn.discordapp.com/attachments/1288790874016190505/1330672692084609025/gradient-16-bit-e9.jxl?ex=678ed504&is=678d8384&hm=df427e4951ccb797b868c5f19672479b629ae3edb5fcf3944619d6e3e86aefd9&

I mean, I did make these. 16-bit and 32-bit

https://embed.moe/https://cdn.discordapp.com/attachments/1288790874016190505/1330673333049626674/Gradient.jxl?ex=678ed59d&is=678d841d&hm=a2975fea874ff218f7d471271d6e5516062da9d4e4b130f4c9a1ad0a29e2d3f9& https://embed.moe/https://cdn.discordapp.com/attachments/1288790874016190505/1330673333460664400/32Bit-Gradient.jxl?ex=678ed59d&is=678d841d&hm=b372fba03f711259a9b71a7a7f5c2e908e67415e682234bf9917d5aabe72e16c&

Interesting

Nevermin, they're both f32, no clue what colorspace I was using....

The main thing I wanted to experiment with was comparing the same gradient in 8-bit and 16-bit, but I got distracted and completely forgot

gradient.jxl seems dithered?

hang on, maybe it's embed.moe doing that

Yeah, it sent a WebP which naturally doesn't support 32-bit float, so libjxl dithered it

It seems like it's just Waterfox doing some weird dithering, the jxl looks fine on Thorium

If Thorium does dithering, it's doing it a lot better

It almost seems like Waterfox is doing dithering on the image level instead of display level?

Probably an outdated libjxl version without dithering at all

I've mentioned it a lot before but the dithering can sometimes trigger when there wasn't any gradients before

I don't get it, is Thorium doing any dithering at all? I don't see any banding

Okay now on my gradient image Thorium is clearly not doing dithering because I see banding but Waterfox is doing that same dithering that appears to be on the image pixel level, just like it did in your in your gradient, interesting

Waterfox's dithering feels... wrong? I guess it's relying on libjxl to do it, but the the result of that is that it gets more noticeable the more you zoom in. I feel like it would be better if instead the browser requested the high bit depth color values as they are and then the renderer in the browser dithered what is displayed in real time, so that the dither pattern doesn't become visible or less effective as you zoom in

Well regardless I'm just glad that what I said earlier > I mean dithering itself is cursed, ideally people upload higher bit depth videos [and images] and the decoder/renderer dithers them only when necessary I guess? is apparently a thing that works at least on some browsers, because I know that from now on I'm going to be disappointed every time I see <:banding:804346788982030337>

https://github.com/libjxl/libjxl/issues/3926#issuecomment-2572001006

My previous testing https://discord.com/channels/794206087879852103/804324493420920833/1301726853123276851

+1 for blue noise for sure, but I think the issue here is more that it's going "dither these pixels *of the image*" rather than "dither these pixels *of the screen*". If you dither on the screen pixel level, or the frame buffer rather, then if you somehow zoomed in on just one 16-bit pixel of the image that single pixel would still be dithered perfectly in the frame buffer instead of being an 8-bit pixel that it itself part of a dither pattern

That's way outside of libjxl's territory. That's browser/viewer level, maybe even OS level since you'd need the high bitdepth buffer anyway to do the dithering

No I know, hence: > [...] I feel like it would be better if instead the browser requested the high bit depth color values as they are and then the renderer in the browser dithered what is displayed in real time, so that the dither pattern doesn't become visible or less effective as you zoom in

I think it's great that libjxl can do this, but I don't think it's what browsers should be hooking in to

7/10 times libjxl dithers things nicely, but when there's a dark patch in an image or you want to zoom in, it'll dither unnecessarily and cause distracting patterns

256x256 blue noise dither matrix would help... 👀

In our testing a 64x64 LUT that we swapped out looked pretty good

there are other smaller issues we need to iron out but we could just make a PR and tweak it later 😛

Using Gaussian Blue Noise, making sure it's scaled properly, finding the best size/quality tradeoff after those

Speaking of, here's the one used in Source 2 and Half Life: Alyx

Surprised there's a square in the top left

Was watching a video and noticed it during a transition, then remembered I have both the game and an asset viewer installed, so just plucked it from the engine. Thankfully stored as RGBA8888 so it is actually lossless

Dithering on the screen level is not app's job, it's OS' job. Windows ACM's documentation hinted that it's possible down the line.

does it even have an alpha channel? RGBA8888 is wasteful if there's no alpha present and it would be better as RGB888

Reminded me of this https://youtu.be/T3KjeNHF8Y0?t=1223

The first and only time I've ever seen or heard of Windows outputting '8-bit with dithering'

A lot of GPUs and engines internally remap RGB to RGBA so that's probably what happened. You either get raw RGBA or one of the compressed formats

Hmm... I wonder if I could swap out that texture with my own dithering pattern

gpu formats are weird

Hmm that's fair. Dare I even ask if there's any chance something like that would work on Linux with Wayland in the near future <:KekDog:805390049033191445>

Time to pester Jeremy Soller

for all I know it's already a thing, I just don't expect it to be

how can i produce a HALD image or LUT with all colors of the 32 bits per channel this format supports like this: https://allrgb.com/jxls-amazing-3 or this: http://www.brucelindbloom.com/index.html?RGB16Million.html i think this software can do it in few clicks https://lightillusion.com/reshade_guide.html but it costs thousand of dollars to buy...

well not really 32 bits per channel since that requires alien hardware maybe maximum of 16,777,216 colors

16,777,216 *is* the first link you sent. Not sure if <@794558394219626547> still has the JXL file or I'm missing a download button on the site though

I wanted to do the same thing in the past but with 16-bit, then realised the image would be so huge and require so much memory, I wouldn't be able to view it

you can download it from the link

yeah but it's only at 24-bit i wanted to produce a better one at 32 or 48 or more

like this one: https://3dlutcreator.com/downloads/materials/Hald/HALD_256.png

it's possible in davinci resolve so i'm buying that soon to test it

I think you underestimate how quickly the size grows. Every bit is multiplicative, so the image grows exponentially. 24-bit is 8bpc and 16 Million colors 48 MB (Megabytes) 48-bit is 16bpc and already 280 Trillion colors 1.5 PB (Petabytes) JXL can do 32bpc, or 80 Octillion Colors 7 ZiB (Zebibytes) So you physically won't be able to reach the limits of the format with current technology

yeah i figured that already but how did they produce 281 trillion colors in this png file

wait this is 68,719,476,736 not 281 trillion

so 12 bits per channel

Are you sure? That image is only 4096 x 4096, so it can only hold 24-bit

yeah but look at the depth

48 bits per pixel

at least according to wiki

The channels increment in values of 257, meaning 255 total in 16-bits

Either someone didn't understand saving as 48-bit doesn't magically *make* it 48-bit or the LUT is meant to be interpolated

oh totally forgot about interpolation

i'm a noob lol

But... That still doesn't explain the exact 257 values, so I think they just saved it in the wrong bitdepth...

maybe to avoid quantization errors

Quantization errors from what though? It's a PNG

importing and exporting over and over i guess (yes adobe sucks)

GPU drivers could also offer this, so the OS would see for example a 12-bit screen while the display itself is only 8-bit, dithered down by the GPU.

AFAIK, they do

`nvidia-settings` exposes some related, well, settings

Just tried applying my monitor's manufacturer ICC profile to see if it made any difference... It turned grey into cream...

lmao

For whatever reason, it had deeply saturated reds, and caused Irfanview to decode JXLs differently to JPEGs *or* PNGs with ICC profiles. Usually it just ignores them

normally they are only worth a damn with pre calibrated displays

sounds like an intriguing profile

Go wild https://aoc.com/api/download/12660

… what

it’s not normalised so that (255, 255, 255) is L*=100?

That'd explain some things

ah, I think the “absolute colorimetric” curve sheds some further light

ah, wait, that’s what it shows even for relative now

just what is going on with this profile, exactly

the light that just got shedded needs to be better colour managed

Has anyone noticed XYB JPEGs seem to be noticeably darker than the source image? Or is that just me and a Linux thing

If I had to guess something on Linux is not colormanged properly.

Would you mind sharing the original and converted image? I'd like to verify myself

Sure, I'll try to send an example later today

ok, here's an example of what I mean.

the PNG is the original, it has a color profile attached so there's hopefully no ambiguity about how to view and interpret the file, and I transcoded it to jxl and jpg using cjxl and cjpegli obtained from the latest libjxl commit on github

the jpeg was made with `cjpegli --xyb --chroma_subsampling=444 -d 1.5` flags

It looks massively darker to me compared to the other two files.

oddly enough they look identical in firefox.

but using gwenview or lximage-qt it looks much much darker...

The JXL is in the bt2020 colourrange

How did you encode the JXL? If I use cjxl on the PNG I get a bt709 image as expected

I just did `cjxl pngfile jxlfile`

with 0.11 it simplifies the icc to an enum sRGB color profile

but with the latest git it preserves the icc for some reason

even though it's lossy

also it's annoying how the version suffix in the .so filename keeps getting renamed all the time even when the abi hasn't changed

it breaks all the dynamically linked software on my system that expects the library to be called `libjxl.so.0.11`

maybe the `y` in `x.y.z` should stop getting incremented unless changes are made to the existing abi.

I did the same

But I get a proper bt709 image, not a bt2020 image like you

But it's not a bt2020 image...

It has an embedded icc profile.

and like I said with 0.11 I get an enum srgb image

with the newer version it just preserves the profile for some reason instead of simplifying it.

Where does it say bt2020?

those are completely different color primaries with a wider gamut

indeed it is

This is your JXL ``` Input #0, jpegxl_pipe, from 'malekithally.jxl': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpegxl (libjxl), rgb24(pc, gbr/bt2020/iec61966-2-1), 1920x1200, 25 fps, 25 tbr, 25 tbn JPEG XL image, 1920x1200, lossy, 8-bit RGB Color space: 410-byte ICC profile, CMM type: "lcms", color space: "RGB ", rendering intent: 0 ``` This is mine ``` Input #0, jpegxl_pipe, from 'malekithally_o.jxl': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpegxl (libjxl), rgb24(pc, gbr/bt709/iec61966-2-1), 1920x1200, 25 fps, 25 tbr, 25 tbn JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 1920x1200, lossy, 8-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual Brotli-compressed Exif metadata: 32 compressed bytes ```

I jut encoded from the PNG you posted earlier

Maybe Discord stripped the PNG, which is why I have a diferent result?

Unlikely, discord should keep ICC profiles

the icc is 410 bytes...

That looks like ffmpeg. it says mine has an ICC profile and yours has an enum color space. bt2020 is what ffmpeg is decoding it to I guess.

It indeed seems like discord stripped the ICC profile from the PNG

But the ICC profile is...

Oh that's weird

It looks like the color profile is still there

but they changed other things about the png

`Warning: [minor] Text/EXIF chunk(s) found after PNG IDAT (may be ignored by some readers)`

Wayland color management protocol has been merged https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14#note_7cbf668a65db5e91fd4e81c2c5493d42c92ccbef

YAY

I wonder what Graeme Gill thinks about it. I remember she was critical of the wayland people allegedly not taking color management seriously or asking for advice from anyone who will be forced to use the API

ideally I should also be able to unplug my monitor and plug in a different one while my machine is still on... and not have my apps crash

the API is ok for a v1. They had consulted troy for a good amount of the stuff here https://gitlab.freedesktop.org/pq/color-and-hdr/

in the end, I don't super duper like it, but well, it will do the job

Well the best way to find out how to improve a system is to be forced to use it 😿

I don't suppose you could make a test image using that instead if it's not a huge hassle? I'm curious if it'll fix the color bleeding and quality issues with Discord previews and Telegram mobile

https://bsky.app/profile/hsivonen.mastodon.social.ap.brid.gy/post/3lic3kaabfat2

looks like the linked chrome document was written before windows hdr had a brightness slider? didn't even know that was a thing at some point

there's also this https://docs.google.com/document/d/1_lJarjXlrYNq4cy0WB4BMTUrPpurNpcPPhp4xBtX5LY/edit

JXL files don't report primaries if there's an embedded ICC profile and the image is XYB encoded (like most of them). ffmpeg falls back on bt2020 because it is the widest gamut it supports

Ah, good to know

Thanks

Which is then the best way to show possible differences?

Just decoding to PNG?

The way to determine the actual gamut is with a filter

forget which one. I think iccdetect but but idk

I'll look it up, thank you for pointing me in the right direction

If you know the original gamut you can just tonemap it down

er, gamut map

vf_libplacebo with relative gamut mapping mode

you can also just view JXLs color-accurately with mpv

Does it report gamut correctly?

mpv? it's a video player

it also can just view still images

Yes, but the advanced stats I mean

Does it show up there correctly

ye, somehow

Nice

idk how to make the gpu debug mode visualization turn on

but you can iirc

this is so unbelievably true, wow

tbf, numerous android phones can how capture in displayP3

as for videos... I dunno. There are numerous phones that can now record log 10bit if you wanted to edit it into HDR tho

and ofc, using "professional" camera apps like filmic or mcpro can help out a lot too

if anyone in EU is interested in picking up a colorimeter, you can get the Calibrite Display Plus HL (i.e. X-Rite i1Display Pro, except it goes up to 10k nits) for 50% off: https://mailchi.mp/calibrite/calibrite-display-plus-hl-upgrade-unknowns-feb25 (cranking up the maximum luminance made the near-black performance worse, so it's not ideal for measuring OLED displays, but other than that it's the best consumer option)

here is some quantification of the light levels at which the HL models appear to lose precision https://hub.displaycal.net/forums/topic/is-it-wise-to-buy-x-rite-i1-display-pro-plus-now-in-2022/page/2/#post-139718

> The new meters use the same L2F sensor as the old meters. But now the peak nits is rated for 3000 or 10,000 rather than 2000. So they reduced the sensitivity with some filter, meaning it’s less sensitive to low light patterns. And indeed in testing this has shown to be the case. > > If calibrating things like projectors and OLEDs, You are better off with e Calibrite Plus.

I’ll probably stick to my good old i1Display Pro myself

Is there a recommended order for checking `JXL_COLOR_PROFILE_TARGET_ORIGINAL` and `JXL_COLOR_PROFILE_TARGET_DATA`?

I am in the process of updating my Paint.NET plugin to handle `JXL_COLOR_PROFILE_TARGET_ORIGINAL`. libjxl appears to only check `JXL_COLOR_PROFILE_TARGET_ORIGINAL` after `JXL_COLOR_PROFILE_TARGET_DATA`, but I think it makes more sense to check for `JXL_COLOR_PROFILE_TARGET_ORIGINAL` first and ignore the target data in that case.

Krita appears to do some kind of conversion from `JXL_COLOR_PROFILE_TARGET_DATA` to `JXL_COLOR_PROFILE_TARGET_ORIGINAL` with a float32 intermediate. But I don't plan to implement something like that due to the complexity.

target_original is what's tagged in the file. target_data can be whatever you want for xyb

a lot of the time you want whatvis tagged so you request data in the original space

So it sounds like ignoring target_data when target_original is present is a reasonable approach?

not always no

there's the tagged space and there's the space you're requesting the pixels in

that second one is target_data

ultimately it's what you're getting pixels in

this is how I do it in ffmpeg, fwiw

https://github.com/FFmpeg/FFmpeg/blob/99e2af4e7837ca09b97d93a562dc12947179fc48/libavcodec/libjxldec.c#L241

Thanks. I was looking for that code in ffmpeg, but I only fount the code stream parsing.

in hindsight I'm very glad I left a bunch of comments here

Target_data should never be ignored since that's the space the decoded image buffer is in.

I find the target_original and target_data scheme to be complicated and confusing. The libjxl GIMP plugin appears to set the color profile twice, once for the [internal profile](<https://github.com/libjxl/libjxl/blob/9961fb4b15bc9ecc64d0d803fea2868f24a176e7/plugins/gimp/file-jxl-load.cc#L353>) and then overwriting that profile with the [ICC profile](<https://github.com/libjxl/libjxl/blob/9961fb4b15bc9ecc64d0d803fea2868f24a176e7/plugins/gimp/file-jxl-load.cc#L477>) (if present).

I am not familiar with GIMP's API but that behavior seems strange, unless its set profile method is performing a conversion from the internal profile to the original profile.

These questions were prompted by a [bug report](https://github.com/0xC0000054/pdn-jpegxl/issues/8) in my Paint.NET plugin.

A lossless JXL image that uses a "DisplayP3" profile with a custom white point gets converted to linear sRGB when saving as lossy/XYB.

I would have expected JxlEncoderSetICCProfile to use a color space with P3 primaries and a custom white point in that case, but for whatever reason it does not.

In recent versions of libjxl, there is `JxlDecoderSetOutputColorProfile` that should simplify things. First you have to do `JxlDecoderSetCms(dec, *JxlGetDefaultCms())` and then you can set the output color profile to the JXL_COLOR_PROFILE_TARGET_ORIGINAL space. If that doesn't return error then the target_data space should always end up being the same as the target_original space.

I don't know why JxlEncoderSetICCProfile wouldn't produce an equivalent enum space for that particular icc profile, maybe the equivalence check is too strict for some reason. <@604964375924834314> any idea?

FYI, that white point tag is D65 (https://en.wikipedia.org/wiki/Standard_illuminant#D65_values); the one you call D65 is D50

(but indeed, for display profiles, the encoded white point should always be D50, along with a chromatic adaptation matrix that converts the actual white point to D50 https://www.color.org/whyd50.xalter)

for lossy jxl encoding, the image will be converted to linear sRGB whether libjxl turns the ICC profile into an enum or not; the latter only affects whether decoding will be able to return it to the original colorspace or not

if it doesn’t (TARGET_DATA ≠ TARGET_ORIGINAL), you would have to convert it yourself

why this specific ICC profile is not identified as an enum profile is a separate question (I’ll try to look into it), but I would anyway advise against assuming that it will always happen

My code currently ignores TARGET_ORIGINAL, which is probably the source of that bug. If I am understanding things correctly, TARGET_DATA and TARGET_ORIGINAL are intended to be treated as two ICC profiles, with TARGET_ORIGINAL being optional. The calling app is expected to perform a conversion from TARGET_DATA to TARGET_ORIGINAL when the the two profile do not match.

As far as I can tell, Krita does what I described above.

yes (if the app wants the image in the original profile, which seems to be what the author of that bug report expects)

it seems that indeed, since that ICC profile erroneously encodes D65 instead of D50, libjxl then infers a different white point (0.28057, 0.295832) when undoing the chromatic adaptation

ICC profiles are complex. For one project I wrote a parser that gets the profile description, that was a lot of code. Even the header has a lot of nested types that makes it verbose to parse. My Jpeg XL plugin does ICC profile header parsing to ensure that the profile color space matches the image. Assigning a Grayscale profile to a RGB image would probably cause issues.

yep, using a third-party library like lcms2 might be preferable over dealing with ICC profiles and colour conversions directly, if that’s an option

I am using [Windows Imaging Component](<https://learn.microsoft.com/en-us/windows/win32/wic/-wic-about-windows-imaging-codec>) (Microsoft's imaging API) for the color conversions, but it doesn't provide a way to get profile info without parsing the raw data. And at the time I wrote that code, I didn't want to pull in a lcms2 dependency for just the header parsing.

ah, you might want WCS (Windows Color System)

https://learn.microsoft.com/en-us/windows/win32/api/icm/nf-icm-opencolorprofilea

https://learn.microsoft.com/en-us/windows/win32/api/icm/nf-icm-getcolorprofileheader

After implementing the target data (linear sRGB) to original ("DisplayP3") conversion for [this](<https://discord.com/channels/794206087879852103/1288790874016190505/1344600443879161908>) image. I get this mess of a result:

Converting the uint8_t data to float for the color conversion doesn't change the result. The original code that only used the target data looked closer.

The above images were using a manual color conversion, after switching to `JxlDecoderSetOutputColorProfile` the output is correct. That is also much less code.

So that's a win for the new api then?

What program is this?

[Paint.NET](<https://www.getpaint.net/index.html>) the [5.1.5 beta](<https://forums.getpaint.net/topic/133371-paintnet-515-beta-build-9191/>) included JXL support by default.

https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/40#note_2838289

I think I got my point across reasonably well here?

<@184373105588699137> maybe https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-7-2023-PDF-E.pdf is relevant > (2) The signal level of “HDR Reference White” is not directly related to the signal level of SDR “peak white”.

oops, that’s not the latest version

https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-8-2024-PDF-E.pdf here

that quote is still almost intact, they just changed the double quotes “” to simple quotes ‘’

also, the guidance is only suggested now

yeah, I thought it would be best to go back to the basics and filed this ticket https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/42 which just reads as > HDR and SDR are vague terms that are subject to interpretation and confusing at best with many users across the internet having different interpretations of the terms. > > color-and-hdr should either point towards, or create a solid definition for the terms HDR and SDR, or failing that actively dissuade users and developers from using it, and only use it to provide historical or technical context and not in itself a technical capacity. > > The current status quo is confusing to say the least. the glossary entries for HDR and SDR provide no info other then the expanded name.

to at least try to get on common ground

> Pekka Paalanen > Pekka Paalanen > @pq > · 1 month ago > Owner > FWIW, the way to tell the difference between "SDR" and "HDR" is to compare the reference white level to the peak white level. If they are the same, it's SDR. If peak white is higher, it's HDR. is stated earlier which is a bit odd to me as it leaves out a ton of information

for instance, sRGB technically has a reference level of around 80 nits but is commonly graded to 120 or so nits, does this make the typical sRGB grade HDR?

obviously not what he was getting at, but it's just so weird of a statement to me

he does elaborate more on "there is no fundemental difference between HDR and SDR" but there is no citation for this I can find

this feels like a case of them perpetuating confusion based on half understandings and self found understandings of terms that have no real definition

as far as I am concerned, HDR is a marketing term that is being used as a technical term, and not an actual technical term

The actual technical term has 11 different definitions

thats the thing, does it? I have seen it used plenty in technical documentation, but never once have I actually seen a real definition for it

I think there is a very valid quote from troy sobotka in his hitchhikers guide to digital color, https://hg2dc.com/2020/01/08/question-17/ > 2 Remember folks, friends don’t let friends say that wretchedly useless word “gamma”. Always remember that the actual specification of sRGB itself, which is referenced in Question #6, written over two decades ago, has a very important annex solely dedicated to destroying the term. The last sentence from that annex is:

I believe this should apply to the terms HDR and SDR as well

> FWIW, the way to tell the difference between "SDR" and "HDR" is to compare the reference white level to the peak white level. If they are the same, it's SDR. If peak white is higher, it's HDR. BT.2390: > In traditional imaging, the range allocated to these highlights was fairly low and the majority of the image range was allocated to the diffuse reflective regions of objects. For example, in hardcopy print the highlights would be 1.1x higher luminance than the diffuse white maximum. In traditional video, the highlights were generally set to be no higher than 1.25x the diffuse white. Of the various display applications, cinema allocated the highest range to the highlights, up to 2.7x the diffuse white.

<@184373105588699137> “reference white” doesn’t mean the peak luminance of the reference display

> In video, the system white is often referred to as reference white, and is neither the maximum white level of the signal nor that of the display. When calibration cards are used to set the reference white, it is a diffuse white (also called matte) that is placed on the card, and measured.

reference/diffuse white is basically “how bright is a sheet of white paper?”

hmm, I dont think I articulated myself well, I don't believe that is what pekka was referencing, then again, Im not entirely sure *what* he was referencing. as to me, his interpetation doesn't make sense if he was talking about paper white, as that wont really match any commonly agreed upon definition of HDR

edited above graphics/paper

to some extent, arguably a defining feature of HDR is the larger headroom between diffuse white and peak white (as BT.2390 implies)

but not to the point that they would be identical in SDR

yeah, I dunno how HDR could be defined, especially considering as I stated in the issue ticket, People all have different interpetations of what HDR means, some people state that it requires a transfer + gamut that are both larger then sRGB colorspace for instance. to me, it seems like the "minimum agreed upon definition of HDR" is "a transfer function specification that is intended to display at least 1000nits while being perceptually smooth across the luminance range at a defined bitdepth" which is... not really accurate to say the least

(the relevant excerpt there is probably: > The misconception about HDR being simply brighter¹ pictures arises from the fact that the maximum luminance capability is indeed much higher than standard dynamic range (SDR) television. However, this higher maximum is primarily used by the highlight regions of images. While the highlights will indeed appear brighter [1], they are nearly always small in region, and the overall image may not necessarily appear brighter. This is because the overall appearance of an image’s brightness is dominated by the average brightness, not the small regions usually occupied by highlights. One type of highlight is the specular reflection. The advantages of having more accurate specular reflections enabled by HDR include better surface material identification [2] as well as in depth perception, even with 2D imagery [3] [4]. > […] > The more accurate presentation of specular highlights, (assuming the entire video pathway is also HDR), is one of the key distinctions of HDR. )

yeah, HDR is for sure better in the lower lows as well.

this is why I am desperate for anyone to give us a defintion, or to simply stop using the term HDR

I think one of the problems in the discussion above is the continuum fallacy (https://www.logicallyfallacious.com/logicalfallacies/Argument-of-the-Beard)

Yes! I didnt realize there was a specific term for this. but this seems exactly to be the case

that being said, if the range is SDR <----> HDR, simply knowing what SDR and HDR even are is still important as there are some strong conflictions of it. we can see "ah yes this is for sure HDR" other people cannot and as color-and-hdr is intended to be a technical guidelines for developers, this ambiguioty is IMO unacceptable for this documents purpose

to the extent that while this fallacy does apply at least partially, it does not wholly

The brighter picture thing I notice when I open an image on my computer, it starts as sdr and becomes hdr. Most of the image stays the same , it looks like the brightest parts of the image go from being clipped to actually having colour, while the darker parts stay the same

> it starts as sdr and becomes hdr. can you elaborate on what you mean, are you talking about your eyes adjusting?

no, when loading hdr image, the screen starts rendering it as sdr during the open animation, then once the animation finsishes the screen slowly increases its peak brightness

For android I think it tonemaps HDR to SDR for preview images/thumbnails

Might be the same for apple idk

thats the weirdest shit ever, what platform + viewer is this?

yeah, tho with A16 or A17 android is likely going to be going for an always on HDR experience

macos

when pressing spacebar to (pre)view an image

thats so weird, i mean, I guess it's better then just jumping straight over

I mean I get why, its likely related to the same issues presented here https://www.youtube.com/watch?v=bYS-P2bF2TQ

phenomenal talk btw, anyone interested in HDR mastering should watch

the dude is also pretty entertaining, well woven fiction based on reality for the first part to explain concepts, then goes into actual HDR content in the second

Chrome does fade from SDR mode to HDR mode smoothly, I think <@604964375924834314> and/or <@179701849576833024> made it do that.

I certainly didn't 🙂

I did most of the implementation of the `dynamic-range-limit` CSS property, including making it transitionable, but as far as I know, that’s unrelated to whatever Chrome does when directly displaying an HDR image without that property (which predates its implementation, iirc)

Maybe it was <@795684063032901642> then?

interesting, I think I like that but honestly, im not sure lol

I give up after my latest reply on this. Like, if a user says they're having issues with HDR content and your thing is, well, HDR can have SDR content and it perfectly fine, so there's not a real meaningful distinction between HDR and SDR. you've lost the plot.

I don't understand how one is the logical conclusion of the other?

I mean, yes, HDR formats can have SDR content. But how is the logical conclusion from that that there is no meaningful distinction between HDR and SDR?