JPEG XL

https://github.com/xiph/opus https://github.com/xiph/opus-tools https://github.com/xiph/opusfile https://github.com/xiph/ogg in 2023, I somehow managed to compile it on windows, but I didn't write how. And now I'm sitting here, I don't even understand.

opus tools 2018

i guess opus-tools doesn't need updates?

here it was impossible to do everything in one project, it was necessary to take everything apart so that later I would assemble everything like a matryoshka: ogg --> opusfile --> flac (for decode input) --> opus --> opus-tools

or just ffmpeg your way to victory

due to the availability of ready-made ffmpeg build tools, it is really easier to compile (only on Linux)

Still, I compiled it more than 100 times while doing my svt-av1 fork.

what? oh go fuck

C++ really needs a package manager

nah, screw it, rewrite it in Rust

I think I'm using opus 1.4, which I did from the past

I don't know what URL the page you linked has, but https://opus-codec.org/ lists the newest opus 1.5.2

Although no binary release

.

For windows users I recommend the binary releases by NetRanger https://hydrogenaud.io/index.php/topic,125801.0.html

All 32 bit builds should be i386 compatible. Only retro PC enthusiasts like me are using 32 bit systems at this point.

And if somebody is using a 32 bit system to do real work, they apparently don't care about speed. 😄

FINnALY thanks

true anti-capitalist people <:galaxybrain:821831336372338729>

my super-placebo fork work It took 9 hours to encode the full episode, but I want to share an excerpt with a bitrate of 447 kb/s (720p) (non-audio) ||I apologize in advance for the choice of content for tests and coding. But it is extremely indicative of the perfect color transfer and the complete absence of artifacts.|| I don't want to brag, but it seems like a simple increase in some encode parametersr, and disabling some parameters. At the moment, this is the best quality/bitrate that can be.

the MPC-HC windwos player makes the best 10 bit dithering I've ever seen

How large was the original?

using madvr or just the default renderer?

full episode with original audio 100 855 536 bytes

same resolution as output?

I cut a piece from the finished file because the discord is 25 megabytes

if you're talking about the original original. From which I was encoding, it is 235 mb of the same 7 min part

Not bad

that is, I compressed it 10 times

i wonder what it would be like if JPEG XL and JPEG AI were a combined format with modes for low fidelity and very low bpp and high fidelity and higher bpp so there would be no advantages for video based formats https://youtu.be/gA9s9CUHMDc

JXL bitstream is frozen and changing things would cause more adoption issues but could be interesting

Also AI would could actually cause problems with CPU so theo would have an argument

breaking backwards compatibility is AVIF's job \😉

i mean from the beginning, but yeah, it takes a lot longer for JPEG AI to be ready when JPEG XL was already available, but anyway

there's even a progressive mode

Looks interesting

hahah

Is this like an actual format with a defined bitstream or still experimentation?

super mega ultra Classic - use formats that were released 20+ years ago for comparison. Neither AVIF nor JXL

This usually means that the format is bullshit now

most likely, the development of the Jpeg AI format has been going on for so long, as far as I know, longer than Jpeg XL - that it managed to become outdated before its release

<https://gitlab.com/wg1/jpeg-ai/jpeg-ai-reference-software>

<:galaxybrain:821831336372338729>

Wdym outdated

Is it beaten by JXL ?

If they compare it to JPEG 2000. Probably not.

If JPEG AI is good for low bpp, you could put a JPEG AI bitstream in a box at the front of a JPEG XL? As a different form of progressive decoding?

Like a preview file

Although I’m guessing weight files are significantly bigger than normal image format libraries

though these are quite different directions for codecs, one has very low fidelity (maybe even mostly fake, but visually looks good) but is great for very high compression, the other for high fidelity and lossless but could compensate the weaknesses of each other and jpeg ai doesn't beat jpeg xl because it has different goals, jpeg ai is probably pretty bad for high fidelity, doesn't have lossless and has many other limitations

looks like scam

not a scam, just typical low fidelity ai compression visually looks good, but may have some generated fake details and bad for image credibility but it's enough for some previews or when high fidelity is not needed and most people compare and hype only at very low bitrates/bpp if they don't notice any artifacts

not a scam? They stupidly wrote Classic - WTF - what is it? Jpeg 1992 ? hevc key-frame? what? oh look this. AI better! look!

Classic is probably jpeg 1

Absolutely all tests are divorced from reality, VVC, hevc, jpeg2000, old jpeg what use Encoders - are not written. There is not a single relevant format. Even WEBP. This is definitely a scam. Because they don't show the advantages of quality. Show the speed advantage over the codec that no one has ever seen in their eyes.

because vvc currently is the strongest format for low bitrate compression of any non-experimental codecs

and dead

Yeah VVC sound DoA unless Apple leans heavily into it

They’re the only company I can think of who would care about it

no, but also it doesn't matter as it's just a reference point for comparison, other finalized formats are much worse for such strong compression

but apple is a AV1 dev too

not a dev, just a member

governing member

Has anyone here tested VVC against AV1?

"just a member", this is another list that just gave away their patents

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

I’m starting the Alliance for Closed Media pushing xHE-AAC and VVC

I did it. Yes. The quality of CRF 63 smoothes artifacts a little better than AV1.... That is all... In large tests, the test results were... um...... 1% superior

What about for high bitrate high quality?

Like iPhone 4k camera video

considering that VVC encoding takes about 5 times longer for the same quality, this is dead. The lack of a wide variety of encoders killed optimizations.

there is no point in switching from HEVC if it already exists.

I’m guessing is it even more of a patent mess than HEVC?

members mainly join for protection from patent claims and to use these formats without problems or to get some documentation and help for hw decoders/ encoders implementation etc.

Is there significant improvement over HEVC or is it like 12%

full VVC ... hw

av1 hw

and full series

There are hundreds of real devices individually

I don't think the overhead of encoding and decoding will be worth it. This is not as strong as in the case of AVC -- > HEVC And even more so AVC -- > AV1

50% is claimed as for any new formats, but that's with perfectly good encoders and only for specific cases, like low bitrates, very high resolution, etc.

av1 can 16k

hevc can 8k

Both can use all the technologies. 10 bit. HDR. I don't see the point in VVC at all. And I'm not the only one, as see.

In fact, it's hard for me to imagine how powerful the AV1 16k playback hardware should be. Even if the RTX 3090 IT can only AV1 8k

i'm only not happy that in each new format generation is very much suffering high fidelity because the industry is more focused on streaming low bitrate quality

yeah, not everything is a streaming service

there is also good reason to have high res video

hence the VVC, advertised as the codec of crappy videos 😄

VVC: Versatile Video Codec, as long as your videos are planned to be put on 8k streaming at 8 mbps

basically all the following codecs after avc are either worse for high fidelity and high bitrates or very marginally better, partly the fault is the encoders, but partly it's the format design because larger transform blocks are used, entropy encoder is more designed for smoother content, very heavy focus on filtering, etc

I’d say h265 is decent at high quality

But yeah, formats after that all do smoothing to the extreme

Like how AVIF smooths images

even hevc at sufficient bitrate loses to avc for noisy or grainy content, though mostly not bad with enough tuning and can use 10-bit not as an extension of the standard

Is it just me, or does this video have some horrible compression artifacts in the dark areas? I could've sworn it wasn't that bad when it was new https://youtu.be/FoSe_KAQEr8

It's hard to tell what is actually detail and what is a compression artifact faking detail. I downloaded all versions of the video: VP9 (both regular and premium bitrates), AV1, and H264. Here are my subjective opinions. The VP9 versions perceptually look worse in the shadowed areas. The AV1 version smooths the blockiness and H264 adds additional noise. In my opinion the H264 looks the best likely due to x264 being insanely cracked at handling dark areas <:H264_AVC:805854162079842314> <:Stonks:806137886726553651>. AV1 is easier on the eyes <:AV1:805851461774475316> <:avif:1280859209751334913> but might be smoothing some detail. And finally VP9 just looks awful in shadows <:VP9:981490623452430376> <:banding:804346788982030337>. It's also possible that since the 4 years after the video's release you became more preceptive to compression artifacts? And also you might be rewatching the same video on a larger/better screen which could exacerbate the artifacts.

Screens have become brighter, while video for some reason largely kept doing the 8-bit tv-range yuv thing, which basically gives you 6.5-bit precision _before_ compression...

Let's not forget that Youtube has been turning down video quality more and more for years now

I don't recall how I watched it all those years ago, but watching it on my phone and comparing to my desktop (Both the same for 8 years, so if anything should be dimmer and less noticeable) I think it's either screen technology or tonemapping. My OLED phone, the blacks are still completely black, with only faint blurring at max brightness My desktop has obvious artifacts at only half brightness (The default) but also looks much less saturated, as if it's been artificially brightened

Same image output between Android app and Desktop website, so it must just be the OLED screen cutting off the blacks before the artifacs can show

Guessing the 'High Bitrate' VP9 didn't help much? And yeah, it's possible since diving into all these image and video compression methods I've just gained an eye for the artifacts now, although the evidence is pointing that I watched it on my phone that hides almost all compression

The High Bitrate VP9 didn't make much of a difference, the orignal video is just that bad I guess ¯\_(ツ)_/¯

Yeah, maybe

That whole video looks like "Do I look like I know what a JPEG is?"

thanks, that's what I was looking for

https://www.reddit.com/r/programming/comments/1fb5pzh/webp_the_webpage_compression_format/

```Typically, Brotli is better than gzip, and gzip is better than nothing. gzip is so cheap everyone enables it by default, but Brotli is way slower.``` but, brotli also has faster modes and also <https://github.com/google/rbrotli-enc> `At the moment, quality 5 is the recommended setting. It achieves roughly the same compression ratio as quality 5 of the C Brotli encoder, but with 1.5-2x the performance depending on the machine.` or is it about decompression speed? it would be nice to have also a faster (rust?) decoder, though not sure how optimized the current one is

what data is that?

it's a bit corrupted becaue of JPEG artifacting

The original is on that website

i know

https://news.ycombinator.com/item?id=41475124

I almost want to try that out with jxl xD

in principle it should just do better

Direct link https://purplesyringa.moe/blog/webp-the-webpage-compression-format/

> Umm, apparently WebP only supports pictures up to 16383x16383. We can do that. <:JXL:805850130203934781>

also https://canary.discord.com/channels/794206087879852103/805176455658733570/1282123030113292311

depends, as it requires an encoder to be good at compressing an "image" with pathological dimensions (one-pixel high in this case)

Wasn't there an 'ultra data saving mode' or something for Opera mobile that pre-rendered websites and sent an image instead? Kinda just re-invented it thinking of how well patches would work for a webpage :P

I'm actually surprised to see a claim that webp lossless is good at brotli, as it wasn't never the case in my old testing

the likely cause should be the input size

1.2x worse from that post

ah indeed

I should have mentally swapped the header...?

anyway I expect jxl to be similar as brotli as its inherent similarity in the core lossless coding algorithm

Doesn't have to be, also on that site they change to a 16k width and height (separately)

in that case you lose a large portion of possible backreferences

that said, I never tried that with webp (I did try that back then with png)

JXL can only reference the same group anyway, so your limit is 1024 pixels

yeah that's another issue

Alternate idea, the 12 byte smallest JXL file, just with the website stored in a Brotli box

*Technically* it's JXL ;P

Is JXLC mandatory?

unless web browsers expose an API to read arbitrary boxes...

I mean it doesn't have to be 1px wide

This would be an ideal case for your LZ77 based patch finding idea, to cross group boundaries

Maybe limit the image to 1024xNN so it can reference up to 1048576 back?

Yeah, that's what I was saying

I can imagine a few places where MA trees could help

Sorry, don’t back read

Maybe JXL audio compression isn’t as bad of an idea as I think?

It'd be very rare for cjxl to choose only LZ77 too

audio compression needs subtle changes to what lossy jxl already does, though

they typically need lapped transforms

EPF/ Gaborish?

not sure if that's sufficient for audio signals?

It's not bad, especially if you keep the quality high. I'll try and find my old test files, or just searching for `FLAC from: jonnyawsom3` might come up with them

(actually I have no idea whether that is okay or not)

Oh yeah I tested this with you I think

I keep forgetting

what I'm aware of is that MDCT, the lapped transform of choice for audio compression, is easy to analyze and prove mathematically that it preserves some important audio features at edge (specifically, minimal phase distortion)

In jxl you could cheat by making a tiny jpeg and concatenating whatever you want to it, then do lossless jpeg recompression on it 🙂

that will effectively just do brotli compression on that jpeg tail data

<@532010383041363969> referring from X, here's the exiftool outputs for lossy bayer, lossy linear, and lossless bayer underneath https://discord.com/channels/794206087879852103/805176455658733570/1259094540082741338

Lossy tile JXL files are in the message above, and the jxlinfo output for one of the lossless tiles is at https://discord.com/channels/794206087879852103/822105409312653333/1252968284702380083

https://www.androidauthority.com/android-15-performance-class-ultra-hdr-3480620/

ugh, that's a rather heavyhanded way of promoting a rather questionable way of doing HDR.

Why are Android and Chrome being so paternalistic about what image formats should or should not be used. They don't have the expertise in that domain to actually make good choices, yet they seem to feel it's their job to force adoption of some formats and to block adoption of others. It is quite strange.

you can look through the document and find a lot of changes regarding HDR which is pretty much all pointing to one thing which is HDR by default.

it's not all the way there in the 15 design document, but I would say it looks like 90% of the groundwork is layed, the 16 design document is probably going to make android fully HDR by default

Pushing HDR support is fine. Pushing Ultra HDR as a capture format, not so much.

Ultra HDR is SDR + sdr->hdr gainmap?

Yes

🤦‍♂️this wouldn't be a problem if they adopted <:JXL:805850130203934781>

it would, the explicit point of this is that you have images that look right on both HDR and SDR formats which is necessary for a transitory period which android is evidently pushing into now

Can’t HLG tone map to SDR?

Isn’t that the whole point of it?

can it? yes. can it do it good? no.

PQ can also tonemap to SDR with one of many functions, but again, none of them are actually good, they are just "acceptable" at best

If a phone can produce a nice tone mapped image at capture time to produce SDR+gainmap, then a phone can also produce a nice tone mapped image when rendering an HDR image.

When capturing the phone is converting the HDR data from the camera into SDR+Gain map, can’t you just reuse that process but instead give it a HDR image buffer instead of the camera buffer?

HDR videos play fine on SDR displays without needing a gainmap

Inbuilt tone mapping does it for you

It may be possible if you save a bunch of metadata with the image that can be used in processing, but it still likely wouldn't be as good especially if you are targeting a fixed mapper

ofc this is assuming you actually have tonemapping, which in most cases you don't

keep in mind, you are doing SDR -> HDR tonemapping, not the other way around. SDR is the minimum bar, and tonemapping support is not given. so we need a base SDR image, and tonemapping that to HDR. In terms of potential, (whether or not camera apps actually do this is up to the vendor itself) When a camera is taking a picture in ultraHDR or whatever it's called, it's creating the SDR rendition, and then using the extra data the camera can take to generate the HDR data.

Even disregarding the tonemapping, the format alone is still an issue here. the SDR image, is still going to work on say an android 7 phone, windows 7 PC, or maybe even a windows XP pc. etc, let alone 10-11-12 etc. if they had swapped to JXL, they only get compatibility with devices still getting support, which at most is android 11 where they could update the system to add jxl images.

It feels like a doubled edged sword. like sure you get maximum compat with old software and such but at the same time this could be used as one of those things that cause companies to be like "see? we don't have to stop using JPEG **ever**!"

can also affect newer formats negatively as well which in an of themselves don't have compat with older software, like why are there SDR to HDR gainmapped AVIFs around the place now?

sure there is software that support modern formats yet can't handle HDR or high bit depth images properly at all but I think at that point it's kinda the fault of the software

I can see the usefulness of the gain maps approach from the interop / web delivery point of view: if you want to send a single image that will work in legacy software and looks OK in SDR, while also allowing an enhancement when viewed in updated software and on an HDR display, it's a reasonable thing to do. The main problem I see with these "graceful degradation" approaches though is that you'll end up wasting bytes on the enhancement while most end-users will just get the degraded experience and not even know their software needs updating — the image will load, it will look OK, just it will look like an SDR image that is not very well compressed. I don't really see the usefulness of the gain maps approach as a capture format though. To me it makes more sense to capture in full HDR, and then you can generate SDR versions, SDR+gainmap versions, or lower fidelity HDR versions from that master image, depending on what is needed.

As an analogy: imagine your camera would produce a huge "Ultra TrueColor" file: the main image has been reduced to 256 colors and is encoded as a GIF, but there's a blob at the end that's another GIF which can be used to magically restore some of the original colors (not perfectly but it looks OK most of the time). That way it is easy to display the image on an old VGA screen that can only do 256 colors, and GIF is universally supported so it is very interoperable. Do you think this is a good idea?

I don't think this is how it works. More likely, the camera will natively have HDR data (14-bit sensor data or whatever), which can be tone mapped to SDR or just preserved in HDR. For UltraHDR you'd store the SDR version as the main image and add a gain map that can be used to approximately reconstruct the HDR image (not perfectly, since for that you'd need a full-res 3-channel gain map and here they're using a subsampled 1-channel gain map to avoid file sizes blowing up too much).

this may be the case on flagship phones, but a lot of phones are still creating HDR images via capturing multiple images in close succsession then squashing them together

ultraHDR by design is oriented around being a transitory format. it could be expanded to other formats without issue

either way, whether created in one shot or using multi-exposure, what you get is an HDR image that is then used to derive a nice tone mapped SDR image.

in the former is this true, but when using multi exposure, you simply save the processing to the HDR gainmap. This would be higher quality then tonemapping to an SDR image down the line if it is even possible for the app to do so in the first place

Can you convert UltraHDR to true HDR (like JXL or whatever)?

you would need to "render" it but yes

Looks good?

as food as the ultraHDR image looks

Still trying to find a way to properly tonemap my iPhone HDR HEIC images to JPEG XL

arent they just HLG images?

No they’re SDR + gainmap

Video is Dolby Vision/HLG

ah, I don't know of any apps that can render them

iirc they use their own gainmap spec

~~ https://github.com/grapeot/AppleJPEGGainMap ~~

ah crap wrong one

https://github.com/m13253/heif-hdrgainmap-decode

not quite, the backwards compatibility aspect of HLG just means that it looks alright when interpreted as BT.2020 (wide gamut SDR) apart from that, there's not really a difference when actually converting HLG or PQ content for SDR output (though PQ can go brighter and more saturated)

bt2020 uses rec709 transfer right?

i thought bt.2020 was the colour space, and bt.2100 was the HLG specification

nvm just checked, it uses the same transfer function

i was confusing transfer function with colour primaries

both specify BT.1886 (which is just 2.4 gamma on a display with 0 black level) as the EOTF

ye thats what i thought

both are colorspaces

a color space is defined as gamut + transfer + whitepoint

i meant primaries *

bt.2020 is typically used to refer specifically to the gamut

but in reality, it does define all three

BT.2100 defines 2 color spaces, one with PQ and one with HLG

yeah I never liked that lmao

i thought bt.2100 *was* the HLG transfer function?

no thats arri something,

ARIB STD-B67 (2015)?

btw im getting my info of [the codec wiki from AV1 for dummies](<https://wiki.x266.mov/docs/colorimetry/transfer>)

`ARIB STD-B67 (2015)` `Rec. ITU-R BT.2100-2 HLG...`

It might eventually be possible to transcode them https://github.com/libjxl/libjxl/pull/3552

not losslessly im guessing?

or yes?

is the gainmap a JXL codestream?

keep in mind, that a gainmap may need to be converted into different formats depending on how it's handled

yeah thats right

video/color specifications are a fucking mess in case you havent figured it out [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

do both define it the same?

they should

or are they *very slightly* different

i could imagine them being different by like 0.01% just to be annoying

they might operate on different bitdepths, but the overall function should be the same

like how Bt.2020 has two transfer functions, 10 bit (exactly the same as BT.1886) and 12 bit (the same thing but with extra precision in the constants) ?

> different formats Different formats like codecs? or different interpretation of values? If the latter, shouldn't it all be standardised?

interpetation of values

> shouldn't it all be standardised HA

standardization in colour? heresy

oh yeah, forgot that we're talking about colour science

interesting, don't think i've heard of that before, but here's that standard: https://www.arib.or.jp/english/html/overview/doc/2-STD-B67v2_0.pdf seems like it just defines the HLG OETF and not the EOTF?

is EOTF from gamma to linear?

also wouldn't it just be the inverse function?

shouldn't be too hard to just derive it mathematically?

every (?) standard has a deliberate mismatch between the OETF and EOTF due to... some effect(s) that i forgot the name of, basically things look different in the lighting of your living room than if you actually are outside

yes, it's the "gamma" applied by the display when viewing content whereas the OETF is the "camera gamma"

e.g. 2.4 gamma is definitely not the inverse of the rec.709 OETF

i don't understand digital colour theory and don't think I ever will

<https://en.wikipedia.org/wiki/Rec._709> ctrl-f for "dim surround" here

if you only care about signal reproduction on a display, you can pretty much ignore OETFs

no!

EOTF defines how a **display** device should treat the image, NOT how to convert it to linear!

this is a *crucially* important distinction as to convert sRGB to linear you need to apply the inverse transform

so gamma to linear is OETF^-1 ?

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

I reccomend watching this video as a primer since it actually does a good job at not being too confusing

also just wondering what transfer does JXL's XYB use?

at least the Y channel, X/B are chroma

this is not true, and it depends on the format itself, some specs don't even specify an oetf/eotf

for instance rec 709 does not specify an eotf, and one was only specified latter in bt.1886

I think it's 709 im thinking of anyways

i can understand why people argue that sRGB should not be displayed with the inverse OETF based on what it says in the standard, but from an ICC color management point of view that makes no sense, so i disagree with that (i think it's easier to argue that some standard is "wrong", i.e. not what should actually be done in practice, rather than arguing that everyone using an ICC color managed workflow is doing it wrong)

oe maybe that the standards is not "wrong" but more just "outdated / obsolete"

with a "revision" or something

to convert to linear, means to undo the encoding function, if you apply the inverse eotf (which is a 2.2) this actually causes further degradation of the image, not undoing it. This is why tooling like OCIO "undoes" the sRGB encode

troy sobotka had a good write up somewhere if I can find it

are cameras linear?

no

then what do they use?

they use whatever the fuck they want to

typo, meant inverse OETF (the piecewise function)

unless i confused something again "those" people are arguing that sRGB content is encoded with the piecewise function but should be displayed with 2.2, right? my argument is that it's both encoded and decoded with the piecewise function, to clarify

this is such a mess :/

this is why DNG exists

but is OETF from linear to gamma?

camera's do one of two things A) save into raw, typically some kind of DNG now B) pre-process the image into a jpeg or png or something

more or less

so RAW then has the "linearisation table" that converts into true linear?

and then after you edit, then the output gets chucked through the OETF to get the data stored in the file?

then when viewing the EOTF converts that back into display pixels?

(after going through whatever transfer function / colour space the image format uses)

or is this still wrong?

for color management, you typically undo the encoding (OETF optical > electro transfer function) since the EOTF is typically designed around how a display handles output.

sRGB is the greatest example of this because if you use the EOTF to convert to linear, it fucks things up because of the intentional mismatch that was designed for the displays of the era

you get an HLG EOTF by applying the inverse OETF followed by the OOTF, which is a power function applied to the luminance, with the exponent γ equal to 1.2 if the target peak luminance is 1000 nits (with a formula to adjust it if it’s not 1000 nits)

(actually two possible formulae but one pretty much supersedes the other)

https://github.com/libjxl/libjxl/blob/a4f67292d1cd99f969ad86aa5ceb272a6bec737a/lib/extras/hlg.cc#L14-L51

right, i was just pointing out that that part is missing from the ARIB standard

ah, right

it is in BT.2100, though (at least the part that relates to the peak luminance)

also mentioned by one of the inventors of HLG here (excellent video, by the way) https://youtu.be/XmZMyLOXB28?t=6m45s

I really need to learn more about HLG, I keep putting it off because i'm in love with absolute nit values from pq lol

while I can’t guarantee that the video will make you a complete HLG convert, I think it might at least give you some appreciation for HLG’s philosophy

Are you team HLG or PQ?

is it a cop-out if I say that it depends on the use case?

I admit that I do have a bit of a soft spot for HLG

but it’s not clear to me that current implementations of it take advantage of its properties

it seems to be frequently misunderstood

maybe it’s too clever for its own good

(see for example: all the people who claim that it has a 1000-nit peak)

Can’t it go arbitrarily high?

how *does* one define the nit peak in hlg anyways? is it left to metadata?

there isn’t one

the peak is that of the target display

it’s relative like SDR TRCs, just with the gamma adjustment on top

very nice video indeed, haven't seen it before

that seems like it would be nice for lower end HDR systems, but a nightmare to edit for hmm, I guess context can make up for that though.

part of the 1000-nit confusion is that, as BT.2408 (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-7-2023-PDF-E.pdf#page=29) puts it, there is an industry consensus that when converting between HLG and PQ, the peak luminance at which the renditions should coincide is 1000 nits

that seems a bit generic, but I guess in the end, the person trying to mix them could easily decide otherwise

on the contrary, the idea is that you can grade it on whatever display you have, and it should automatically adapt to look good on displays with different capabilities

i respect what they're trying to do, but the EOTF seems needlessly weird in the sense that it's not just a per-channel function

(also reflected in the fact that “The reference level, HDR Reference White, is defined in this Report as the nominal signal level obtained from an HDR camera and a 100% reflectance white card resulting in a nominal luminance of 203 cd/m² on a PQ display or on an HLG display that has a nominal peak luminance capability of 1 000 cd/m².”)

(this could be seen as hardcoding the amount of highlight headroom that HLG allows for, except that the use of “HDR Reference White” as a reference is more of a guidance than anything mandatory)

> Creatives making programme content may choose to encode content at differing levels, i.e. a dark indoor drama may put a grey card (and thus skin tones) at a lower level than shown in Table 1. Also, some productions may employ higher/brighter levels for outdoor scenes or for dramatic effect. However, significant deviation from the Table 1 nominal levels, in particular HDR Reference White, may lead to difficulties such as loss of important detail with static HDR to SDR down-mappers, which are usually optimised around these reference levels. When a static HDR to SDR down-mapper is used for transmission, it is therefore advisable to check for any detail loss in the derived SDR (for example in skin tones and/or displayed text) to ensure that the SDR image meets requirements and expectations.

Also not perfectly since you're multiplying two low bit depth images together, there will be large quantization errors.

``` >>> import colour >>> colour.models.eotf_BT2100_HLG([1,1,1]) array([ 1000.00003232, 1000.00003232, 1000.00003232]) >>> colour.models.eotf_BT2100_HLG([1,0,0]) array([ 765.40629303, 0. , 0. ]) ``` in any "normal" color space, EOTF([1, 0, 0])[0] (peak red in linear light) would be the same as EOTF([1, 1, 1])[0], i.e. the red component of peak white in linear light. but in HLG it's less, which makes the gamut pretty strange

so I guess to convert HLG to linear, you need to apply the inverse oetf, then apply the ootf on top of it?

so in this case the eotf = linearization here

pretty much, though the spec also includes a "variable for user black level lift" in the EOTF

fuck I hate color

it helps to be explicit on what we call “linear”, since in the OOTF, both the source and the output are linear

but the first O is scene-referred whereas the second O is display-referred

or to be more accurate, the O in first position (as in OETF) vs the O in second position (as in EOTF)

understandable, the HLG spec is definitely hard to parse

hlg was the most confusing one while writing transfer curve stuff for jxl-oxide

speaking of scene-referred vs display-referred we finally have a good document talking about it courtesy of exr

https://openexr.com/en/latest/SceneLinear.html

it's not too indepth, but it gives enough context

nice page, shows the orthogonality between linear/nonlinear and scene/display

It certainly beats the snot out of their old documentation.

In theory, PQ represents absolute nits, but in practice, e.g. when viewing PQ images in Chrome or in Lightroom on macOS, they are always rendered relatively to the overall display brightness setting. When thinking about HDR in terms of "some number of stops of headroom above SDR white" (where on a macbook, you only get 1 stop when the brightness slider is at the maximum, but 4 stops if you make SDR white less bright), then that's basically the HLG philosophy, right? It seems like it gets applied in practice to both PQ and HLG — presumably because it's the only thing that makes sense if you want to have adjustable overall display brightness / variable ambient lighting conditions.

> you only get 1 stop when the brightness slider is at the maximum No wonder why HDR was clipping

in HLG, the headroom in scene light would be constant

in display light, increasing display brightness would _amplify_ the headroom, because reference white would be brightened comparatively less than the peak

You mean when e.g. replacing a 600 nits screen by a 1000 nits one?

But on a MacBook, the screen will always go up to 1600 nits regardless of what the brightness slider is set to...

thats messed up lmao

Well not really, the SDR brightness still moves with the brightness slider. You just get more HDR headroom available when lowering the SDR max brightness.

(when moving the brightness slider below some point, it also starts lowering how bright HDR can go. It never gives you more than 4 stops of headroom)

interestingly, dolby vision hlg video played back with the dolby vision plugin on windows is always output with the same luminance and not affected by the sdr brightness slider (which is the only option windows gives you for controlling brightness with hdr enabled) not sure about non-dolby-vision hlg video, haven't tested that

it’s always capable of it, but for HLG content, it arguably shouldn’t

since with HLG, the peak is what the setting is supposed to change

if you increase the brightness of a given signal level (e.g. SDR white), it should increase the brightness of _all_ signal levels (albeit not equally), including 100%

(in fact, the peak should increase more)

(e.g. 203 nits at a peak of 1000 should become 289 at a peak of 1600)

well, unless the increase in mid-tone level is because of an increase in surround luminance

right, that actually invalidates quite a lot of what I’ve just said

arguably, it's incorrect to always use the same HDR brightness because viewing conditions are important, and dimmer viewing conditions cause people to lower brightness. HDR content will be overbright.

Imo, HDR should have more dynamic range than SDR, it shouldn't be forcing specific absolute nit values.

Is there am open source Lossless JPEG encoder I can run on Linux? Google is being immensely unhelpful.

well it does actually lower the brightness of HDR too when lowering the display brightness, so that's not really a problem. It just has more range available, i.e. less soft-clamping is going on. E.g. if you have a foreground at 100 nits, a sky at 1000 nits and a sun at 10000 nits, then it would be something like this: at maximum brightness, the foreground is 500 nits, the sky is 1400 nits and the sun is 1600 nits. at just-below-mid-brightness brightness, the foreground is 100 nits, the sky is 900 nits, and the sun is 1600 nits. at very low brightness, the foreground is 10 nits, the sky is 100 nits, the sun is 500 nits.

(just making up the numbers here)

hm

https://github.com/thorfdbg/libjpeg implements the full jpeg spec

ah, thanks :)

https://github.com/thorfdbg/libjpeg/blob/master/README#L102

I guess what you're looking for is what you get with this command line: `jpeg -p -c infile.ppm out.jpg`

thanks

in terms of decoding, what implementations exist?

also pretty much only this?

I'm gonna do some quick and dirty tests on my own photos to see how it compares to cjxl -e 1 -d 0

libjpeg-turbo also does include a switch for lossless JPEG, at least on arch

ah, so it does!

Chrome can’t open the result; neither can Eye of GNOME

nor GIMP (same error, so presumably same decoder)

interoperability-wise, it seems that there is little point in using this

worse software support than jxl

I'm just interested in how it might compare in ProRaw

Though the comparison I'm running atm is completely invalid since ProRaw uses 12-bit images and I'm using 8-bit images in the form of "high quality" JPEGs from my DSLR

It is also larger than png

``` ExifTool Version Number : 12.96 File Name : losslesstest.jpg File Size : 4.1 MB File Permissions : -rw-r--r-- File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg DCT Encode Version : 100 APP14 Flags 0 : (none) APP14 Flags 1 : (none) Color Transform : Unknown (RGB or CMYK) Image Width : 2048 Image Height : 1152 Encoding Process : Lossless, Huffman coding Bits Per Sample : 8 Color Components : 3 Y Cb Cr Sub Sampling : YCbCr4:4:4 (1 1) Image Size : 2048x1152 Megapixels : 2.4 ```

``` % du -sh * 181M originals 1.1G uncompressed 672M jpegll 385M jxld0e1 333M jxld0e2 319M jxld0e3 314M jxld0e4 186M jxld0.1e1 186M jxld0.1e2 175M jxld0.1e3 178M jxld0.1e4 205M jxld0.1e5 205M jxld0.1e6 207M jxld0.1e7 139M jxld0.2e1 139M jxld0.2e2 131M jxld0.2e3 133M jxld0.2e4 149M jxld0.2e5 149M jxld0.2e6 151M jxld0.2e7 ``` 35 photographs in each folder, mostly birds in a zoo and nature images (forest, ponds, streams, sky), but there are a couple of pictures of signs and random rocks too.

I was able to open the resulting file in GIMP, may be due to OS differences though

so for my images, jxl d0 e1 gave a 43% reduction in file size over thorfdbg/libjpeg

yeah it is one of the worst lossless formats that exist — remember it was created end of the 1980s / early 1990s

I guess a fair comparison would be to LZW TIFF.

Or patent-free alternatives based on RLE (TGA, PCX etc.)

the later JPEG-LS might also be worth a try

Just did a short comparison for fun, lossless JPEG does indeed beat LZW compressed TIFF

``` 2,1M losslesstest_e10.jxl 2,5M losslesstest_z9.webp 2,6M losslesstest_s0.avif 3,4M original.png 3,7M losslesstest.jp2 4,0M losslesstest.jpg 4,2M losslesstest_LZW.tif 6,4M losslesstest_RLE.tga 6,8M losslesstest.bmp 6,8M losslesstest.pnm ```

when outputting from PTGui, I’ve always wondered whether to pick LZW or “PackBits” with TIFF

maybe I should test them

PackBits is just RLE, LZW should be a bit better. Both are only useful for nonphoto.

ah, good to know, thanks

might at least be fast, I guess

eh, not that much faster

and yeah, 561 MB instead of 456 MB

… it’s 418 MB as PPM

presumably because of this: ``` Alpha: min: 0 (0) max: 65535 (1) mean: 65533.9 (0.999983) median: 65535 (1) standard deviation: 272.945 (0.00416488) kurtosis: 57643.5 skewness: -240.095 entropy: 0.000299361 ```

TIFF can do planar so for that alpha channel it could be useful to do some RLE 🙂

``` -rw-r--r-- 1 Sami Aucun 362351930 11 sept. 20:42 Rechberggarten.png -rw-r--r-- 1 Sami Aucun 277367458 11 sept. 20:48 Rechberggarten-e1.jxl -rw-r--r-- 1 Sami Aucun 272951639 11 sept. 20:49 Rechberggarten-e2.jxl -rw-r--r-- 1 Sami Aucun 248467798 11 sept. 20:49 Rechberggarten-e3.jxl -rw-r--r-- 1 Sami Aucun 456215281 11 sept. 20:33 Rechberggarten-lzw.tif -rw-r--r-- 1 Sami Aucun 561300484 11 sept. 20:33 Rechberggarten-packbits.tif ```

those are all with that alpha

note: the png took over two minutes to create from the tiff

compressing the png to jxl e3 took 15 seconds

(the image is 12040×5784)

Reminds me of when I was compressing a gigapixel image. Was done in under 20 seconds but also used 12 GB of memory, so my computer was... *Unhappy*, for about an hour after while it slowly recovered the swapfile

JPEG at the time of its release was actually quite CPU heavy in comparison to other formats used back then.

this is fine I suppose, I don't care how HDR an image wants to be, if im in a dark room, I don't want an image getting anywhere near 1000 nits let alone 1600. however you really should ideally have an individual total brightness control and a SDR brightness control like KDE.

https://github.com/xiph/opus/releases/tag/v1.5.2

"Newly" released

Let's see if the website's downloads will be updated

so is it like this? red = sdr max blue = hdr max green = display max x = brightness setting y = output

Something like that, no idea what the actual curves are

nor do i, oversimplification

i personally wish there was a way to lower the HDR headroom so I still get some hdr benefits but don't blind myself at half brightness going up to 1600 nits

-c:v libvpx-vp9 -g 600 -crf 35 -deadline realtime -row-mt 1 -cpu-used 8 -aq-mode 3 best way to maximum fast reencode 4k videos. For work (or upload on youtube) x264 bad quality, same speed (need more bitrate) x265 ultrafast 0.5x speed of vp9

I don't like JPEG XT, I like Jpegli 🙂

Seeing the [question](https://discord.com/channels/794206087879852103/848189884614705192/1284152529747312661) in <#848189884614705192> after the massive discussion the other day makes me feel bad for him having to type it out again

Seeing that it has been asked multiple times, it should probably be added to <#822120855449894942> ?

I'm not sure how many actually read or see that, maybe on the new website

svt-av1 by default (and in all ffmpeg builds) compiles without AVX512, although many optimizations are written in the source code. When compiling, it is necessary to add -DENABLE_AVX512=ON otherwise the AVX2 will be compiled as maximum. Svt[info]: [asm level on system : up to avx512] Svt[info]: [asm level selected : up to avx512] 👍

Does the jpegli encoder allow some sort of lossless optimization of existing JPEG files?

there's not really much more to do than what the existing `jpegtran` tools can already do. Besides optimizing the huffman tables, the only thing you can do is try different progressive scan scripts.

Might be worth a look for more details https://github.com/google/jpegli/issues/10

Which JPEG optimization tool would you recommend?

I guess the jpegtran from mozjpeg should be good?

I use https://github.com/fhanau/Efficient-Compression-Tool

looks like Safari treats HDR PNG/AVIF images with CICP correctly (that is, it tone maps them to SDR), but not PNG/AVIF images without CICP but with an ICC profile that has a CICP tag , where it shows something near-black

I think I just found a something pretending to be a PNG file, which was actually a TIFF file, using JPEG encoding, either in a PNG container or with a PNG file extension (???)

Could have been a JNG

Imagine my confusion when I tried to convert a PNG file and it said `Must not set non-zero distance in combination with --lossless_jpeg=1, which is set by default.`

`IMG_2151.png: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=1, orientation=upper-left], baseline, precision 8, 3000x2000, components 3`

It’s just a JPEG renamed as PNG

The “TIFF” there is talking about the Exif metadata structure

Ohh

You can treat it the same as any other JPEG

It's digital art, I'm guessing it was direct output from some program

How are JPEGs lossless?

Oh, JXL lossless transcoding

Yeah

Lol I wonder if this is just a case of "pepsi tastes better if you tell people it's coca cola" but with jpeg and png instead. Better perceived quality if you trick people into thinking it's a png? <:galaxybrain:821831336372338729>

PNG and JPEG taste the same to me

<:JPEG_XL:805860709039865937> 😋

<:pancakexl:1283670260209156128>

Probably someone exporting it and calling it a png thinking that would change the encoding

paint.net has this weird thing where the export dialog does not care what extension you use, the codec dropdown dictates the file contents. the default is JPEG output iirc, so you'll instinctively name the output file with ".png", but oh well, you actually just put a jpeg in a png-themed giftwrap box

it used to get me 8 years ago, it got me when i started using it again a month ago, and it's probably gonna get me in the future

I’m thinking about trying to use ProRes as an image format, like as a competitor to AVIF but for higher quality targets, what’s the best way to test visual quality currently?

looking at the images

afaik ProRes works only for video/animation. Did you mean ProRaw ?

ProRes uses a number of codecs so you can directly compare the result they give. highest compatibility is oldschool JPEG, high efficiency HEIF (h265-based single frame) and now either lossy or lossless JPEGXL

ProRaw is consistently 10x bigger than jpeg/heif so if your workflow requires minimizing loss, perhaps EXR could suit you better (its basically PNG but better, well supported in the film industry)

ProRes is mezzanine so each frame is individually stored, like WebP lossy or AVIF

You can tell ffmpeg to save a single frame with no container

The format has a simple header in each frame

That sounds absolutely horrid. Try dnxhd and cineform too

xD

your reference for comparing would be the original image or a lossless export for your highest quality target (png or jxl if you exceed its limits)

i personally diff images and normalize versions at the same factor, massively amplifies differences that wouldve otherwise been almost imperceptible

>Basically PNG I could not imagine insulting EXR this hard. EXR is the furthest thing from PNG. It does lossless. It does loss. It has associated alpha. It does not truncate out of scope data. It's extremely fast to use. It has one single, well-documented library that nobody else cares to re-implement because it actually just fucking works. It does not require hacks to support proper colourimetry data.

It's basically TIFF, but good.

Also, EXR can store a more than just raster data.

yeah, it just sounds like TIFF if it was designed with interop in mind

Yep, EXR is literally what came of every single professional usecase that deals with picture or still imagery data, needed a high fidelity interchange format got together designed one format and said, hey, you're good for a long time.

https://github.com/MegaByte/jpegultrascan

for trying different progressive scan scripts

I wish libjxl had a "lossy jpeg" mode similar to the lossless mode, that never ever results in a larger file

So lossy jpeg transcoding

does it sometimes make it bigger?

pick a very small distance (ie 0.1 or even lower, or q99 since people mistakenly assume things work like with jpeg) and it *can* make lossy output even several times larger than lossless. just tried with a spritesheet (transparency, lots of repeat patterns)

i thought we were talking jpeg to jxl transcoding

issue is nonsense selection of parameters by user. only way to guarantee a jxl is smaller than a jpg is reconstructible transcoding

so convert from PNG -> JPG -> JXL?

same situation. only lossless transcode guarantees smaller size without degradation, full lossless reencode can multiply filesize (same for jxl as avif and webp, thats how it works unless you sacrifice even more quality lossily until it fits target filesize)

I think you're just confusing them. Right now the transcode is lossless, so you get 20% smaller. I assume Pashi means a lossy transcode option, that uses the same techniques but does extra quantization, ect so that filesize doesn't bloat

with 20% lower, why would it bloat?

that's lossless transcode, which takes the same DCT coefficients and simply does better entropy coding with them. if you decode to pixels and recompress, you get further loss, but you don't necessarily get a smaller file. the distortions from the original jpeg would be compounded by new distortions. what pashifox is asking for is a mode where libjxl would take the DCT coefficients and do additional quantization to them to reduce the file size. the file would be smaller and the quality reduction highly controllable.

an interesting observation is that the difference in the real encoding speed is SVT-AV1 (av1) on my ryzen 5 7600, with multithreading enabled, with frequency "acceleration" to the limit of the board, and a temperature limit of 85 degrees, as well as overclocked memory up to (in my case) EXPO 5200. Gives an encoding speed of x0.181 While acceleration is completely disabled, completely, multithreading disabled, and CPU without frequency boost at all, and memory with just JEDEC 4800. The processor temperature is 41 degrees and its fan completely silent, gives a speed of x0.142

what res/bitrate/preset?

regardless, you've just made an observation most programmers have already thought over

the software speed problem is just that, a problem with *software*. computers today are plenty fast, software is just not built in a way to maximize speed

It still boggles my mind that any modern software is *still* single threaded

Good thing SVT means Scalable Video Technology, and that it has very fast (but blocky) presets

some things have to be single threeaded

but most things can easily be multi threaded, programmers are just lazy

adding naive but relatively correct multithreading to a program that can benefit from it is a cheap speed boost

doesn't have to be amazing, but anything is usually better than nothign

Ah yes, another """performant""" algorithm using only 1/12th of my computer's processing power

1/14th in my case

imagine the people with threadrippers

1/128th 😭

they open 15 programs at startup to justify their purchase 😆

most "common" software has multithreading today, but there's still a surprising amount that don't

electron programs get multithreaded rendering for free :^)

someone needs to make a CPU with like, 8 to 16 "big" cores, and like 64 small cores for background processes

And then the scheduler puts all of the intensive tasks on the little cores 😭

xD god

so like P and E cores?

but with a ton of E-cores

Yeah

sounds like something apple would do on ower core devices

Mobile phones have had a P & E core system for a while now