JPEG XL

<:ReeCat:806087208678588437> 👉 xhe-aac

I guess HE AAC is not that desirable, because it's optimized for very low bitrates below 64kbps, so the support is lacking. AFAIK it's used only in digital radio broadcast for radio stations streaming in 32-48 kbps.

it does but you have to name it `.ogg`

for some reason

but then it works

https://en.m.wikipedia.org/wiki/Image_file_format#BAT

Does anyone know what this "BAT" thing is? Is it the same as JFIF?

I think that whole section is just garbage

I never heard about JPEG/BAT or JPEG 2000/DIG, cannot find any sources on it either, and those are definitely not "major graphic file formats" if they even exist at all

SPIFF and JFIF are real things (though SPIFF never became a thing because everyone settled on JFIF and then later Exif)

I think it would make sense to remove that section and add one on jxl instead.

There is JPEG XL

https://en.wikipedia.org/w/index.php?title=Image_file_format&diff=728946436&oldid=727383478 is the offending edit FYI

Yes, but it's in the "other" section atm. I think it might deserve a section of its own now, like heif and avif.

https://en.wikipedia.org/wiki/JPEG#JPEG_XL

Is foematted bad

I translated from Italian

And didnt bothered opening jpeg English page and go to the JPEG XL part/section

To me that's low priority

I value conpleteness of information

And I expanded the article

I tried to explain modular

<@794205442175402004>

Anyway do you seen any misconceptions error in the formattaton or in the explanation

If this was corrected by a person who has read the standard

Yurume,jon etc

I didnt read the standard so i don't know of what i'm talking

just use OPUS

HE AAC - is relic of legacy

HE AAC is really not very useful, considering there's no HE AAC encoder included in FFmpeg. It's not worth the effort implementing it.

Big lol. Got an image that kinda breaks lossless webp XD

-z (fast to slow): 0: 6,970,550 bytes 1: 7,017,512 bytes 2: 7,858,964 bytes 3: 7,861,684 bytes 4: 8,044,364 bytes 5: 10,612,614 bytes 6: 12,227,278 bytes 7: 12,228,010 bytes 8: 16,127,918 bytes 9: 10,909,992 bytes

(PNG is a few KB too big to send sadly)

Wonder why lossless webp is often very inconsistent speed/size wise...

Seems like it also performs extremely poorly with jxl

<@794205442175402004>is there a way for lossless JXL to find patterns in order to compress more efficiently? Seems like PNG and webp do that, but JXL doesn't (or at least not in the case of duplicate images in a single image)

Like, it's 16 times the same image

JXL fast to slow ``-e X -q 100 -I 10 -E 3 -g 3 `` 1: 26,373,455 bytes 2: 25,115,608 bytes 3: 23,510,930 bytes 4: 22,944,745 bytes 5: 22,887,137 bytes 6: 22,830,045 bytes 7: 22,401,728 bytes 8: 22,380,778 bytes 9: 23,223,119 bytes

Encoding that once with patches would help a lot

I wonder if there's a cheap enough way to detect this kind of thing.

<@179701849576833024> any idea for an algorithm that can detect such tiled patterns? It's not that uncommon to use seamlessly tiling patterns repeating, e.g. in 2D games.

Could Autocorrelation work? it's more 1D than 2D but should at least give something to start with

If the size of the patterns is a power of two (which may or may not be an assumption we can make), it might be easier, right?

LZ77 style patch hashing 🙂

Say hash all 16x16 blocks to uint32 values, find duplicate hashes, verify they're actually identical?

Or even 4*4 blocks, and then if they match greedily extend the match, say, one row or one column alternatively

I assume such repeating patterns are usually at least 64x64, if not larger, so to keep it cheap you could do a 1:16 hash map where only the first 4 rows are put in the hash, leaving the rest for the checking step. That would work for tiles of size 16x16, 32x32, etc.

maybe, who knows 😛

if you want to try this out, this image, FemaleStripedHorseFly and any terminal screenshot should make for good testcases

HEIC does support it, but Apple doesn't. So de facto HEIC doesn't support it imo.

Yeah that was an imagemagick bug I think

When using libjpeg or mozjpeg directly, the generation loss is fine

There's no point adding HEIC support to Safari as no other browser is going to support it anyway.

Yep. Also I am not sure if Safari on non-Apple devices would even be able to ship HEIC support, patent license wise

HEIC was a simple solution to save space for smartphones which don't offer storage expansion. It was free as HEVC encoder was already present. Only users were angry as they were unable to use their photos.

https://jpegclub.org/reference/jpeg-faq/ these guys are crazy

> Why isn’t Libjpeg available on Github or another code repository like SVN or CVS? > Libjpeg is not the usual patchwork project, it is a place where substantial development takes place. > A code repository is not helpful for such kind of development. > Program code plays in a limited formal domain of reality. JPEG substance plays in an informal domain of reality beyond that limited formal domain (in that sense can also be called transcendental domain). > All other image formats in use or on trial today (still images as well as moving pictures) have no such substance and will therefore disappear over time, replaced by the next unsubstantial format, and so on. > IJG JPEG is the only image format with a timeless substance and therefore requires an appropriate development approach.

Substantial Development (tm)

They need a weapon to surpass Metal Gear Solid 2: Substance before they're able to transcend Metal Gear Solid 3: Subsistence

Safari hasn't been on a non-Apple OS since ~2012 (Safari 5), so that won't be an issue <:kekw:808717074305122316>

Interestingly enough, we have started to see HEIC gain some presence in dedicated cameras for in-camera HDR imagery.

But I feel like most people would rather shoot in some raw format...

Oh they discontinued all non-Apple Safari versions? Lol I missed that

Edge which is cross-platform only has HEVC support on windows with the mediafoundation decoder installed iirc Although it might work on mac assuming it takes use of the videotoolbox decoder.

Animated PNG can make much smaller file than equivalent GIF if used right, although opotimizing APNG is kinda tricky.

apngopt is the only program I found to be able to optimize APNG files, but it's not that great. My hand-crafted APNGs are smaller.

It's in any case intra-only besides being able to have cropped frames (which gif, webp and jxl can also do)

Real video codecs will beat it for anything that benefits from motion vectors

In this case, it's simple 16 color graphics. I did some simple interframe using cropping and transparency, the same way GIF optimization works.

We should add something like that as an option to the libjxl encoder

Currently it just encodes frames exactly as how they're given, but having an option to auto crop etc could be good

Can even do some motion with patches

Indeed, automated process would be great. Creating interframes manually during creation of the animation is possible, but it's kinda technical. One have to understand the principe.

It's easy enough to autodetect bounding boxes of the changed pixels.

APNG has one design flaw. All frames must use the same pixel format. If the PNG has palette, all frames also must use the same palette. I guess APNG was designed mainly with RGBA in mind, but it's quite limiting.

In jxl frames are independent, they can't share a palette.

That's good. In JXL, one frame could use thousands of colors and other frame could use just a few colors. For example, a banner where text is displayed over a background. I guess, in JXL, lossy and lossless frames could be mixed as well. I was playing with that in webp.

Something like text scrolling over a background could be done extremely efficiently in jxl because the text can be done with patches that get alpha-blended at different offsets in each frame.

Very tricky to make an encoder that extracts that kind of stuff from already blended frames, but if integrated in authoring tools it could be done - we just need to expose some way to manually specify patches then

It could be really useful for small UI animations.

And for the bouncing logos on DVD players, lol.

That makes sense. The most effective way to take advantage of those features would be export to JXL directly from layers in the graphic software.

Bettet yet, I have a cursed idea. Create patches from ME.

I mean, a JPEG-XL encoder is allowed to do ME if it doesn't implement in the final bitstream, right?

Patches have offsets, not at subpixel resolution but still, you could do a poor man's ME by find rects with the same vector and doing one patch for each such rect

Opus 160 kbps vs AAC 128 kbps who wins?

Depends on AAC encoder

not sure, whatever youtube* uses

my guess is that opus is higher quality, especially since it's the default. but I wanna be sure cuz I'm tryna [redacted] some videos from youtube and wanna know which tracks/codecs have the best quality

251 will generally sound the best

which is 128k vbr opus

yt-dlp incorrectly reports 251 as 160k on older versions iirc

keep in mind since it's vbr it tends to overshoot

🅱️opus wins.

Ahh that explains it then

I have a vague suspicion that it might depend on the codec in which the video was originally uploaded but I have done exactly zero empirical testing of that hypothesis

the opus is much better on youtube, with the exception of the 258k aac used for youtube music premium

At 256 kbps, any decent audio codec should be indistinguishable from CD audio.

does mp3 count? 👀

If lame is used, I'd say yes.

But I'd still use flac for preservation.

phew, then the free MP3s I get from my local library should be good ```Audio Format : MPEG Audio Format version : Version 1 Format profile : Layer 3 Duration : 4 min 52 s Bit rate mode : Constant Bit rate : 256 kb/s Channel(s) : 2 channels Sampling rate : 44.1 kHz Frame rate : 38.281 FPS (1152 SPF) Compression mode : Lossy Stream size : 8.94 MiB (99%) Writing library : LAME3.98b Encoding settings : -m s -V 4 -q 2 -lowpass 19.7```

FPS kinda low tho, guess I gotta upgrade to an RTX 3080 Ti, unless the human eye can't see more than 24FPS <:HaDog:805390049033191445>

You're not supposed to hear audio frames. 🙂

not unless you get one of my 24 carat gold-shungite alloy cable to make the audio truly lossless <:galaxybrain:821831336372338729>

I hope you have a hard drive with gold plated platters.

https://www.tomshardware.com/news/nvme-ssd-for-audiophiles

*you don't?*

anyway fr tho, does AAC split the bitrate evenly for each channel or does it dynamically allocates it depending on which channel is active? cuz youtube allows higher bitrate than usual for surround sound tracks so I wonder if uploading a stereo track with 4 silent channels would improve quality because of the higher bitrate <:Thonk:805904896879493180>

youtube's bitrate is high enough that it shouldn't matter

depends on the encoder

I don't know what youtube's encoder does, but since it's targeted at streaming, presumably it's very close to CBR

so it wouldn't do that

here's the mediainfo of that AAC 6Ch 384 kbit/s ```Format : ADTS Format/Info : Audio Data Transport Stream File size : 3.55 MiB Audio Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Format version : Version 4 Codec ID : 2 Channel(s) : 6 channels Channel layout : C L R Ls Rs LFE Sampling rate : 48.0 kHz Frame rate : 46.875 FPS (1024 SPF) Compression mode : Lossy Stream size : 3.55 MiB (100%) ```

~~getting more FPS now so it should sound better, right?~~

<@794205442175402004> It seems like Google has unveiled some new ML codec research stuff: https://www.google.com/url?sa=t&source=web&rct=j&url=https://storage.googleapis.com/clic2022_public/slides/Challenges%2520in%2520incorporating%2520ML%2520in%2520a%2520practical%2520Nextgen%2520Video%2520Codec.pdf&ved=2ahUKEwi-yLSot8T6AhUo7rsIHbEBCrE4ChAWegQIHRAB&usg=AOvVaw0r92R4YvlLuYyncOd1I8HQ There is one little problem however.

Sigh

Why do people keep treating images as a 1D list of pixels and human perception as computing the mean squared error between two such lists?

I've always found lame to be worse than the Fraunhofer encoder tbh

lame might be better for VBR though?

tbh I find it hard to recommend mp3 at this point

AAC, Vorbis, OPUS, ~~& USAC~~ are much better options

Unfortunately there's not really a good foss AAC encoder for VBR

FDK is a great CBR encoder, but it's VBR mode leaves a lot to be desired compared to something like CoreAudio Toolbox

and FFaac is... FFaac

Although it's rc isn't bad tbh

I really wish nero would open source their AAC encoder at this point It holds up well when compared to FFaac's twoloop, and also offers PS & SBR coding.

also twopass audio encoding <:FeelsAmazingMan:808826295768449054>

Vorbis is used in many games. I haven't seen that much usage of opus.

Because unity only natively supports PCM, ADPCM, Vorbis, and MP3

That's not only unity but other engines as well.

Yeah definitely, I've just only worked with unity + that's really widely used

As far as I can see Unreal only supports raw formats natively? That can't be true right? There's gotta be some common library people use then for audio

bink? 💀

Many games use libraries like OpenAL or FMOD.

oh, I hadn’t realised that about fdk’s vbr

it’s what I have been using

it's actually pretty solid now

If you're used to LAME it's fine, but only having 5 VBR is kinda limiting in most cases

Twoloop is okay, (I'd consider it my baseline for an audio encoder), but imo it still has a long way to go, as nero digital & mediafoundation both tend preform better. I assume we also won't get SBR & PS for another few years, since they're still under patents.

Ideally even just adding in fdk-free (AAC-LC only FDK) would be a good solution for ffmpeg users who don't want to compile themselves. https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=fedora

is that the main limitation? I was concerned that it might be about quality vs. bitrate

FDK has a fairly aggressive lowpass on everything that's not vbr5 I know you can disable it in `fdkaac`, but I'm not sure about `aac-enc` or ffmpeg

FDK tends to be more optimised for CBR anyways though Haven't bothered to test how vbr compares yet

oh, yeah, I think VBR 4 cuts at 16kHz and VBR 3 at 12 kHz

or something like that

I think it's 16KHz at 96kbps+

which is pretty silly imo

even forcing 529.2k (max allowed for 44.1k aac) still does the lowpass <:kekw:808717074305122316>

SBR and PS don't really matter since that's in the domain of "lol use opus"

I wouldn't exactly say that In my testing I've found FDK HE-AAC to be preferable to libopus sub ~48kbps

Generally I like using PS in place of mono as well

Although PS sucks as a stereo replacement

USAC at 12k using the Fraunhofer CDK encoder is actually really good

BTW, guess who found this? It wasn't me. It was <@416586441058025472> <:kekw:808717074305122316>

I searched av2 codec last 24 hours

Yes, and the fact that you found this on your own is honestly admirable.

And it was 24 hours bef

Is described as confidential and proprietary

So this i won't talk on Wikipedia

Even in less than 1 week you can round the document

When I get "used" to a lossy codec, the artifacts get MORE annoying, not less

Like the distinctive awful scratchiness Opus adds to my favorite instrument, the harpsichord.

That actually sounds like a great idea for a gif2jxl transcoder

Someone should make a djvu-to-jxl transcoder...

Do you hear artifacts at higher bitrates too?

Pngout has an interesting quirk that the compression is influenced by the original encoder.

Encoding the exact same picture using different PNG encoders may cause different "/n" value (number of block splits) in Pngout. Higher "/n" value results in slower encoding and usually increases the file size.

block splits are done after zlib and for the most part can be safely concatenated, up to crc

so it should have minimal effect

I'm not sure what does this mean in Pngout particularly, the documentation is kinda vague.

basically in the context of the PNG format itself, it breaks the image data into one or more consecutive IDAT chunks

this is after zlib

each IDAT chunk has a crc32 of that chunk, but once you strip that CRC32 off the chunk you can just concatenate the payloads of the consecutive IDAT chunks

it's pretty common to write 4k-sized chunks

but the limit I think is 4G

or something slightly under

since the chunk size is a 32-bit integer

This is not the case, there's only one IDAT chunk.

oh, then I'm not sure what block size means in that context

unless it's the blocksize of the DEFLATE used

I have this hideous shell script that recompresses a PNG by concatenating the IDAT chunks and then uses parallel zopfli to recompress the zlib layer without changing anything else https://0x0.st/oaS7.sh

I never understood what the purpose is of all the crc32 in png. For checking that the data is not corrupt, you can also just check for malformed deflate stream and mismatching sizes (more or less bytes than what the pixel buffer should be).

It's not enough for error correction, but in terms of error detection it doesn't really help either imo

In my experience, it's worth trying different filter methods as well. Optipng does that automatically. Pngout doesn't do that but yields better results if I do all filter methods manually. Pngout is very slow in that case but that's not a big deal. It runs on a single core, so I can use my computer normally during the process.

There's also oxipng which is based on optipng. Oxipng uses zopfli and the compressions seems to be comparable to Pngout. I haven't tested oxipng too much yet.

personally I use optipng and then take its output and recompress it with zopfli

using the script above

Then oxipng should yield similar results as optipng combined with zopfli.

https://github.com/libjxl/libjxl/issues/1828 <@604964375924834314> this sort of stuff drives me crazy

This is the closest to a test suite for this I know of: https://kornel.ski/en/color

Professional photo editing software doesn't correctly encode grayscale jpegs. It will happily create jpeg with blank color channels.

that's OK, when Cb and Cr are all zeroes they should compress quite well anyway

It made about 100kB per photo.

That's more than what I would expect.

I'm wondering if bKGD chunk in PNG has any practical use. It seems to be just a suggestion which is ignored by viewers.

I think the only time it's ever used is if the viewer wants RGB only, and the only app I know of that wanted that was IE6

I see some people discuss audio codecs... anybody interested in old-school audio compression (ADPCM, CVSD and similar)?

also other time-domain/low-complexity audio codecs in general like FLAC, MP2, SBC, Apt-X...

Microsoft had their own implementation of ADPCM but they never used it.

I didn't know they never used MS-ADPCM, but other multimedia content and games for sure have used it

fun fact: MS-ADPCM is not strictly ADPCM, it can also do 2nd-order linear prediction as well as zero-order coding (adaptive 4-bit PCM)

I don't know what's the difference berween different flavors of ADPCM. Windows is shipped with MS ADPCM and IMA ADPCM codecs, both are 4 bit. All WAV files included in Windows are uncompressed PCM.

Musepack? 😁

I've been interested in AC-3 as well lately Quite impressive to see how well it holds up, even today!

i hate ac3

it doesnt work in browsers

What kinda of justification is that? <:kekw:808717074305122316>

By that logic you also must hate pretty much every codec then

afaik chromium has E-AC-3 decoding now, which must include an AC-3 decoder as part of the spec

sometimes a release has ac3 and it wastes a lot of time because there's no sound and it's annoying

mostly just different prediction/adaptation tables, some also had different output sample formats (some were built for 8-bit PCM, some 12-bit PCM, some 16-bit, I swear I've even heard of ones for 24-bit PCM)

some had leaky output integrators too (to allow the decoder to recover from bitstream errors), while others didn't

never actually studied musepack

use a desktop player then?

Just use MPV™️

not a solution for multiple people with the ease of just going to a website

I don't really see much use for AC3 as it's pretty old and inefficient and most people don't have 5.1 setup anyway.

Stereo audio in decent quality is sufficient for most cases. If high quality audio is needed, lossless is the way to go.

<@826537092669767691> cavif speed 7 and 8 seem to be doing exactly the same thing, is that expected behavior?

Perhaps not intended, but I'm also not surprised.

Native spdif support <:YEP:808828808127971399>

For multichannel it's basically the only codec you can use that'll ensure everyone can decode it

Doesn't spdif support multichannel PCM as well? Bluray also uses more advanced audio codecs than plain AC3.

The Wikipedia page about spdif is kinda brief like spdif was not popular at all.

SPDIF was stereo PCM only While BD does support better multichannel formats, it's also required to include a fallback track, with most common one being AC-3

I wouldn't exactly trust the wikipedia page on a product to see if it's popular or not <:kekw:808717074305122316>

Considering how long is spdif supposedly in use, I'd expect there would be more details.

What else is there to cover? Not every wikipedia page needs to include *every* single detail about the technology

If I wanted to learn about S/PDIF, I'd say this would be a fairly good starting point

from a brief look over I guess it could include possible support for mpeg multichannel/mp2 and possibly AAC?

For example, I'm missing information about data transfer rate options. That's the basic information about any data transfer interface.

Anyway, people are switching to HDMI aduio which provides more bandwidth so it doesn't need to rely on a limited set of codecs. Also audio can be always transcoded by the player.

Btw I was wrong. MS actually used adpcm. I found a few adpcm wave files in the clipart library in MS Office.

While people are switching over to HDMI audio transmission, standards still need to support legacy hw, and I know a ton of people that are rocking mid-2000s HTiB setups, even if they're connected to newer BD players or streaming boxes.

While I don't think AC-3 should be used for new stuff/standards, imo it still has a place today, as a legacy codec

Too bad ATSC never adopted AAC...

Video interfaces don's use video codecs, only audio does that for some reason. Video interfaces send uncompressed video. It would make more sense to transfer uncompressed audio as well.

Audio processing generally

also stuff like Atmos/DTS:X Can't be transmitted over LPCM

In theory also more options?

Generall you might want only one video stream but multiple audio for different languages, channel counts, descriptive, etc

I was speaking to someone recently about Dolby E, and that's why it's normally used Since you can interpolate and transmit multichannel Dolby E as stereo LPCM, allowing yout to fit three different streams in the space of one multichannel LPCM stream

which is useful in SDI and stuff

iirc

Multiple audio tracks are common but only one is played at the time.

yeah and you need to transmit every audio track at once

multiple AC-3 interpolated to LPCM vs single LPCM multichannel

Why would you transmit all audio tracks? Only one need to be read from the disk.

Everything can be converted to PCM. For a legacy device, lossy conversion is acceptable.

I'm talking about transmitting codecs in a broadcast environment

But broadcast is a different thing. Broadcast uses compressed audio and video. The receiver decodes the video and sends uncompressed video over the cable. So it could do the same thing with audio.

no it doesn't, it's terrible

except Opus has OS-level support in every operating system today

if you're talking about Broadcast, I believe it still uses MPEG-2 in some situations. Broadcast using something is not a metric for being a good tool.

"People own old hardware" does not mean AC-3 is impressive, it means that people own old hardware.

https://youtu.be/9kaIXkImCAM

ICO file format is weird. Most of Microsoft file structures are aligned to 2 of 4 bytes. ICO is not. I guess the requirement for alignment was not put in the spec because the size of Windows bitmaps is always multiple of 4. This changed after PNG was allowed in ICO because PNG can be any size. However PNGs can start at any byte offset in ICO file and Windows will load them just fine.

https://www.headlesscreator.com/an-introduction-to-image-formats

did anyone follow it live?

here are my slides: https://docs.google.com/presentation/d/1ZEXaI7Hy6jRn94VMdxAOS1sKSWfC5qHr-6ihHc9N_mY/edit?usp=sharing

except DisplayPort has a lossy compression codec now (DSC)

out of curiosity, does anyone know how to build okular plugins on windows? i'm trying to do the following: https://discord.com/channels/794206087879852103/794206170445119489/1033176071643861022 but <@456226577798135808> says it requires a plugin called "kimageformats", https://discord.com/channels/794206087879852103/794206087879852106/986420514757181590 which i don't really know how to build on windows

Good to know. Another thing to be aware of.

kimageformats is available on Windows via MSYS2 platform.

good to know!

yeah, problem is i'm trying to move *away* from linux due to workflow issues, but honestly i could probably just dual boot w/ arch and be fine

i'm trying to learn how to optimize most of my media without quality loss

<@886264098298413078> how do you suggest i go about this? should i download okular through msys2 as well?

since this exists: https://packages.msys2.org/package/mingw-w64-x86_64-okular?repo=mingw64

Yes, install everything via MSYS2. Maybe also some optional dependencies.

thank you!

(I believe brooke goes by she)

but thanks

nbd

also i was just coming back to say

i've got kimageformats, libjxl, and okular, and i'm still getting errors after trying to open .jxl files

okular's being launched from a mingw64 instance

<@886264098298413078> any idea where to go from here?

i would've assumed downloading `mingw-w64-x86_64-kimageformats-qt5` would work since it has `mingw-w64-x86_64-libjxl` as a dependency but it didn't make a difference

how compiled is okular you're trying to launch

because if it's not actually from mingw it won't be using kimageformats libs

i just did `pacman -S mingw-w64-x86_64-okular`

https://packages.msys2.org/package/mingw-w64-x86_64-okular?repo=mingw64

i figured it'd just be like arch where once you have the package it just works

i got this output from launching a window using the `okular` command

i don't currently have the windows binary installed

.cbz files under .jpg images work, neither standalone .jxl or .cbz under .jxl work

I can try it myself on Monday. I never tried okular from MSYS2. I would try to check if shared-mime-info is installed and then if JXL works in other Qt or KDE application.

just installed `mingw-w64-x86_64-shared-mime-info` now

can you give an example of a program to try it with?

I would build qimgv or qview from source to test it.

i'll give it a try, but doesn't qimgv already natively work with .jxl files?

it does on windows

oh wait no it probably doesn't on linux right

i'll build it then

They load JXL via plugin.

waiting for standard gcc to install right now then i'll get to compiling

never mind, needed make, now i've got a separate error

if i don't end up getting this working i might just dual boot with arch to prevent further issues

so just hoping for the best at this point 🤞

<@886264098298413078> yeah, compiling qimgv doesn't seem to work, getting stuck on this: ```CMake Error at qimgv/CMakeLists.txt:123 (message): You are on an unsupported platform! (Not Win32, Mac OS X or Unix)```

also: ```System is unknown to cmake, create: Platform/MINGW64_NT-10.0-19042 to use this system, please post your config file on discourse.cmake.org so it can be added to cmake```

wait lemme try something real quick

qimgv built Windows version on MSYS2. Wait till Monday till I try okular myself.

alright

oh there we go i managed to build it

<@886264098298413078> ```-- Configuring done -- Generating done -- Build files have been written to: C:/msys64/home/r/qimgv/build```what do i do now? the next step is `sudo make install`, which i'm assuming would just be `make install` here but that just outputs `make: *** No rule to make target 'install'. Stop.`

god linux stuff is so hard on windows lmao

Just make or ninja Then just run ./qimgv.exe in the folder where it was built.

ohhh right it was building for ninja so i should have run ninja

thank you i forgot to include that

building now

Don't install, who knows where the files will be copied.

.jxl files still do not work

just a blank screen

libjxl is installed?

`mingw-w64-x86_64-libjxl`, right?

Yes

yeah, that's installed

do i have to manually build it like this? https://github.com/libjxl/libjxl/blob/main/doc/developing_in_windows_msys.md#build-libjxl

OK, I'll look on Monday why it is not working.

alright, i'll try this as a last resort

i appreciate the help

nahhh i'll give up i'll just wait

this is racking my brain lmao

Interesting, Windows icons in PNG format are required to be RGBA 32bpp format. I've tried the weirdest format I could come with - grayscale 2bpp with tRNS transparency. It works just fine.

Microsoft is still using bitmap format for small icons. As all relevant versions of Windows support PNG, I would just ditch bitmap icons completely.

The one trick I know about PNG icons, is that if the size in the ICO header is 0x0 then Windows takes the icon size from the PNG data instead

They started using it with 10, providing 768x768 icons

Size 0x0 is indicated in the header for 256x256 and bigger icons because only 1 byte is reserved for the value.

The size may be still indicated for smaller PNG icons, Windows may use it to quickly choose the best fitting icon size.

The reason why okular from MSYS2 (but also some other applications) have troubles to open JXL, is related to mime-type identification. JPEG XL files should be identified as image/jxl, but these applications receive application/octet-stream instead (and refuse to attempt opening because they think it is unsupported file).

where do they get the media type from?

I'd like to know the answer too.

i getcha but i'm probably not even gonna ask how to fix it

Create C:\msys64\mingw64\bin\data\mime\packages\ folder and copy/link freedesktop.org.xml file there (it is usually in C:\msys64\mingw64\share\mime\packages\ )

oh, okay! did this work for you?

Yes, it works for me.

awesome, thanks! 👍 will try out shortly

<@886264098298413078> works perfectly!

<@886264098298413078> one more question - for .jxl files in particular, do i need `kimageformats` or will `libjxl` by itself do?

If it is a Qt or KDE-based application, then you need kimageformats

alright

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

<:AV1:805851461774475316>

FaceBock's EnCodec is shit. But: I tried to use it hybrid with the vorbis codec for the bottom (the best codec for this), and the neural network for The upper frequencies of sound, it came out 10+6 kbit, and you know, it turned out better than aac HE 16 kbit

10 kbps Vorbis 4000hz + 6 kbps FaceBook EnCodec 24000hz

=<:PepeGlasses:878298516965982308>

for comparison

I hear a bit of autotuning

🤔

Unfortunately, the neural network encodes and decodes sound for so long that it doesn't even make sense to develop such hybrid codec assemblies, because vorbis is encoded for 1 second and the neural network for 10 minutes

12 kbps 48 kHz STEREO ONLY

How do you play ecdc file? I guess there's no plugin for fb2k

https://github.com/facebookresearch/encodec

Today I did the checks, these are really real

The cloudinary webpage image analyser should really compare compressed SVG against raster formats. Currently it compares the uncompressed even when it is served with a transport compression.

Is this correct? Not sure if I am missing something - they appear to be describing AVIF as supporting progressive rendering similar to interlaced JPEG yet I don't think it does. I found discussions of adding this - or something similar, but they seem to have ceased over a year ago with no progress. https://web.dev/compress-images-avif/

As far as I understand, they added a 'progressive' mechanism which basically consists of a redundantly encoded preview frame. I don't think it is something you'd want to use in practice, since it sacrifices some compression and you only get a 2-step progression in return.

Good point, I will pass the message

I just updated to the latest AVIF and generated a large image. It did not progressively render at all. I don't see any settings in the help to enable any sort of progressive feature and I can't find any documentation for such a thing. All the articles about it online state that AVIF does not support progressive rendering. Only thing I have been able to find was an issue opened quite a while back discussing how they would like it to work more like JPEG's progressive decoding (some claim it wouldn't be possible without a lot of complex re-tooling while others claim it's already possible to do in the existing spec which is confusing - which is it?): https://github.com/AOMediaCodec/av1-avif/issues/102 Eventually they decide it would be easier to just add a smaller preview image and close the issue in favor of: https://github.com/AOMediaCodec/libavif/issues/605 This issue is still open and ceased discussions over a year ago. It really seams like it doesn't support any form of progressive loading. If anyone knows how to do this, let me know. As of right now, the statement made on web.dev seems to be false or possibly misleading?

Progressively decodable AVIF means there are multiple pictures inside one AVIF file. For example one small (low-res or very low quality) image first and final-large image at the end. Some examples here: https://github.com/AOMediaCodec/av1-avif/tree/master/testFiles/Xiph I think libavif can read those multiplayer/progressively_decodable AVIF images but libavif does not encode such files yet (it might change in the near future)

yeah it's a bit like JPEG XL's preview frame — we don't use that at all at the moment but it's also a way to add a smaller preview that is completely separate from the image itself

it's a bit misleading to call this "progressive" though

it's the same thing as having an embedded preview/thumbnail in Exif

is there any purpose of embedding a preview/thumbnail in exif for progressive JPEG though?

it's completely redundantly encoded as a separate image, so it only adds bytes, and there is no guarantee that it actually represents the main image — it could be a completely different image, as sometimes happens when people crop an image but the preview that is in the Exif does not get updated

no, it is typically done in camera-produced JPEGs which are sequential, and the thumbnail is just a small preview so the camera can show something without processing the whole file

ah, that makes sense

Thanks. Still seems misleading to advertise a feature that nobody can use yet. But also as <@794205442175402004> pointed out - its not truely progressive. That block should probably be altered or removed. There is a way to do it now using 2 images with a `<picture>`: https://www.techie-jim.net/blog/AVIF-preview-image-example/

Ah JPEG thumbnails, I've just got rid of those because they compress poorly in jbrd. Anyway, I will probably generate thumbnails in the native JXL format when the feature is available.

Doom's FIREBLU texture is the bane of video codecs. It destroys any video compression.

Pretty sure that happens with any sharply defined pattern with high contrast.

It is an ugly pattern though.

this one is probably extra bad because it's high contrast in all three Y,Cb,Cr channels

oh god I can especially see the Cr channel causing problems

Oh

https://jpegxl.io/articles/rans/

That page says av1 uses ans, which is not correct

<@439539398657441832> are you the one who maintains that website?

will correct, thanks!

The fact that animated PNG doesn't support local palettes is really a missed opportunity. PNG can do much better than GIF as long as the entire animation fits in 256 colors. Converting GIF which is using local palettes to truecolor PNG is not worth it, the file size will grow significantly.

I'm actually considering cartoon style animation where this would make sense.

<:Thonk:805904896879493180> <:Thonk:805904896879493180> <:Thonk:805904896879493180> <:Thonk:805904896879493180>

<@226977230121598977> just curious, how did you get .ecdc playback working? i kept trying different stuff but got awful results

like i tried a 24kbps run and it added this weird polyphony

and as much as i kind of like it i don't think that's normal

No need to use 24, it doesn't make the quality better

Is this the original or the output? I don't hear any problems

https://encode.su/threads/3966-EnCodec-High-Fidelity-Neural-Audio-Compression

Sounds like some kind of aliasing. It's pretty noticeable.

Just for curiosity, I tested favicon.ico in PNG ICO format and it works. I kinda expected that.

Format support for favicons is better than it was years ago, but still has a tangled web of support: https://dev.to/masakudamatsu/favicon-nightmare-how-to-maintain-sanity-3al7

Huh, I just put the file in the root directory and it worked.

output

for some reason, yuv444 in AVIF getting worse quality of smoothing dark gradients in low quality, unlike yuv420

that looks like a poor upsampling algorithm

how are the chroma planes upsampled?

I have no idea. I use standard AVIFENC (use AOM) and also 10 bit

out image open in PaintDotNet

opening in firefox 108 I observe the same

firefox uses libaom iirc as well

so it wouldn't be any different

problems smoothing the guards

perhaps there are some structural differences that allow yuv420 to make some kind of shift and smooth out the guards, while yuv444 encodes an identical line inside the block, and such a noticeable problem appears

I like to respond with https://www.sisvel.com/licensing-programs/audio-and-video-coding-decoding/video-coding-platform/license-terms/av1-license-terms

Sisvel is actually asking for royalties for av1 (no idea if they are actually collecting any, but still).

Microsoft has never made any claim that their patent would be relevant for jxl, let alone asking for royalties.

Also Microsoft has made a statement that they will not ask for royalties if their patent is used in royalty-free codecs: > Microsoft Patent No. US11234023B describes a proprietary, independent refinement of the work of Dr. Jarosław Duda. Microsoft supports open source, royalty-free codecs such as AOM. *Anyone who uses this patent in an open source codec that does not charge a license fee has our permission to do so.*

(source: https://wiadomosci-wp-pl.translate.goog/kod-geniusza-jak-jaroslaw-duda-zmienil-swiat-i-nic-na-tym-nie-zarobil-6824682458536864a?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp)

The patent is too recent to apply to libjxl, but even if it would, Microsoft has explicitly made a statement that they will not seek royalties for uses of the patent in an "open source codec" which should cover libjxl and all other open source implementations of JPEG XL.

So I really don't think Microsoft's patent is the reason for Chrome's decision. That patent poses no issue for jxl. It is still a stupid patent of course, and Duda is right to fight it.

<:monkaMega:809252622900789269> <https://forum.doom9.org/showthread.php?t=179122&page=6> ```I recently could talk with some profesionnals, notably to know why I have lost contact with AOM for example, and they told me that I don't realize that machine/deep learning image/video codecs are knocking very hard at AOM's door and they are announcing next-generation results, outperforming AV1 and VVC, and even outperforming AV2 and ECM...``` So maybe this is the reason to reject Jpeg XL, because soon there will be a new next-next gen superb AI codec that will outperform all existing and future formats by a huge margin, although it is hard to believe that this is true <:galaxybrain:821831336372338729>

JPEG is working on JPEG AI, mostly driven by Huawei and Bytedance. But I doubt this kind of thing will be ready for practical deployment anytime soon.

They can show nice compression results at the very low bitrates, but fidelity at the higher end is an issue, and the size of a decoder would be pretty huge (likely hundreds of megabytes)...

More importantly, question is if people will be prepared to trust this technology to preserve the fidelity of their images? It's basically a black box where you don't really know what kind of deep fake manipulation it is really doing on your images.

yeah, an unbounded failure mode is what I'm most concerned of those kind of AI-based compression methods

in traditional (non-AI) lossy compression, you get either good results or mangled results that you can generally recognize that fact

in AI-based lossy compression, you may end up with mangled but equally believable results

in fact it is kinda inevitable when they are targetting very low bpp, where any unbelievable (say) representation is another bit wasted

I think there might be applications in areas where appeal is the only thing that matters and fidelity is irrelevant - e.g. games and entertainment

But I think there will always remain a need for classic compression with some fidelity guarantees.

alternatively classic compression can be superpowered by ML models 😉

you still have compression primitives with bounded failure modes, but ML models may be efficiently search through exponential combinations

AI-based block type and adaptive quantization weight selection is certainly something that can lead to encoder improvements while working within classic bitstreams.

And filter strength selection, etc.

MA tree learning maybe too

Some codecs were trying to alter the reality, that's why JBIG2 is banned in some countries.

I believe JBIG2 primitives themselves are not problematic

it was an overly aggressive encoder to disregard failure modes

The implementation was poor, so straight ban was the easiest solution.

ah, yeah, that's understandable

yeah, I had the same thought also found an interesting paper about metrics for AI codecs http://ds.jpeg.org/documents/wg1n85013-Performance_evaluation_learning_based_image_coding.pdf

```From the results over all the images, the metrics that correlates better (according to Pearson) with the MOS follow this order: MS-SSIM, VIF(P) and NLDP. If only classical classical compression metrics are considered, the scores with the highest correlation, in order, are: Butteraugli, MS-SSIM and VDP2. On the contrary, for AI compressed images the best performing metrics are: MS-SSIM, VMAP and VIF(P); however, for this last case, VMAF underperforms for the Spearman correlation. In general, the MS-SSIM is clearly the winner since it predicts well the image quality for the different compression artefacts``` MS-SSIM is surprisingly not bad for AI codecs <:PepeGlasses:878298516965982308>

wow!

I mean, there is always a possibility that some metrics are tuned to catch failure modes in classical codecs better, but what a striking difference

~0.9 to ~0.1?

one can argue that a failure mode of those ML codecs is better suited to generate a believable (but substantially different, so unacceptable for classical codecs) image in any case

I think the only use case where I would trust AI is tuning settings for the best possible lossless compression.

otherwise it's hard to explain this situation

Butteraugli is meant to measure pixel-level fidelity of classical compression. AI codecs tend to have geometric distortions (shifting edges by a few pixels, etc) and replace textures by completely different textures (at the pixel level) that semantically look similar (e.g. replacing the input grass and trees by different but similar-enough grass and trees from its training set).

So it will give AI codecs much lower scores than what humans would give

Also note that the subjective experiment methodology they used (and are still using) in JPEG AI is not really looking at fidelity at all, but rather at appeal. They don't show the test subjects the original, they just ask which image looks best.

(with this methodology, it can easily happen that compressed images get a higher score than the original, for example)

so, then, that explains something

Yoah, so such formats will turn everything into stock photos.

<:galaxybrain:821831336372338729> Practical Learned Lossless JPEG Recompression with Multi-Level Cross-Channel Entropy Model in the DCT Domain https://arxiv.org/pdf/2203.16357.pdf https://i.imgur.com/nzM5vAY.png

I want to keep my honest DCT coefficients. They may be ugly but they're real.

at least it's lossless

yes

Due to limited unicode support in Windows command prompt, I have to sometimes pass the 8+3 version of the filename to programs. As long as the file format uses three letter extension, everything is fine. However if the file extension is longer, it's simply truncated to three letters. Some particular formats using four letter extension don't provide any three letter alternative and in some cases, truncating the extension may completely change its meaning.

If you switch Windows to use UTF-8 as the legacy codepage for all apps it should work fine, I've done that and I've had no issues passing unicode filenames to cjxl

I know about this possibility but I'm worried that may break something else.

Yeah, I've only ever seen one app that went a bit funny (The installer for WinDirStat), using an english language locale shields me from a lot of potential issues

Worst thing I have to deal with is stuff using US date formatting instead of the correct method

> Also, it is important to underline that only 8 images were selected > for subjective assessment and thus, to confirm the results it is necessary to repeat the experiment with a larger dataset, > including a larger variety of image types and distortions

Would be a good idea to boycott AVIF?

No, just use it for what it was made for - low bpp situations. Personally, I rarely have a need for this, but could be fine for thumbnails as a lower quality fallback. Wish it could only be loaded on slow internet connections but not really possible on the web. There were various solutions proposed for this but most would allow some form of fingerprinting and were rejected.

I wonder why we need separate image formats from video instead of just for example using an IMG tag for a single frame or animation, because judging by how many people ignore the features of Jpeg XL, anything more than just showing a picture is not needed anyway

You mean video-based format? Or using an image instead of video?

yeah, I mean image formats that are based on video formats

WebP and AVIF are. JPG, GIF, PNG, JXL, and others are not.

In low bpp, like thumbnails, I would just stick to webp to simplify the system and no need to serve multiple different file formats.

Oh you mean why do they exist? Not sure the exact reason - I suppose video format creators felt having 1 single format that could do all media would work. So far they've had limited, varying success. WebP was kind of a "meh" to me as it didn't really get enough compression over JPG to justify it. It does decently as a PNG replacement though. AVIF really was meant for situations that most are not yet targeting: developing nations where internet is slow and spotty. Also as a replacement for video thumbnails - it would be easier to just use the same keyframe format rather than use another image format. The problem is, they lack som web features that people have used for decades and sometimes are more restrictive in supporting higher quality representation if the video format doesn't need it.

How well does WebP do in that case? I've not really tested it at low bit

yes, also WebP has a separate lossless mode (but it was added later and therefore just got additional disadvantages like limited resolution and only 8-bit), but I mean lossy WebP, AVIF, HEIC and maybe some future ones, then why add complexity instead of allowing a single frame or animation in IMG or something like that hmm, however, except when alpha is required, but this usually has a very messy implementation

I think they do. If you put an AV1 in an img tag I believe it acts as a gif, looping continuously, no audio (I think Firefox still has a bug out on that). Not sure what you mean by having an image over video.

I mean inventing a new image format from the video format with new containers, headers and stuff, instead of just using the video format as a single frame (and just tell the browser how to handle it)

I believe they both use HEIF containers - pretty sure it's the same, just includes some more image-specific data for AVIF. As far as using a video, it's MUCH bigger than an image. Using it for a single frame is fine if you just read the first keyframe and stop, but many videos start with a black or white screen, so it's not always useful to use the first frame. You might want something that's 500 or more frames in. Might not even be a keyframe at that position. It would be a lot of downloading (not all servers support http ranges, most do now, but it was hardly supported when videos first arrived). So it's better to have a way to just use your own image as a placeholder.

to talk about AV2 when in 2022 there is no power to encode even AV1

by this time, there is only the power to encode HEVC slow, which was released ten years ago, and only now the technology has reached the point where it can be compressed. all other real people continue to use AVC

u can encode 1080p video using AOMENC speed 0 - how long will it take? a week?

the recently released EnCoded neural network is size 80 megabytes and takes a miraculously gigantic time for encoding and decoding, hundreds and thousands of times longer than classical algorithms

it's not a problem if the browser knows what it is and shows it as a picture or animation as a GIF, that's why the IMG tag should be used, otherwise the only difference would be in the container, which doesn't give much in the way of real usable features that are not present in these video formats originally

and this is a good argument, which is observed both when using Stable Diffusion to restore an image and when using EnCodec for sound - only at extremely low bitrates they have the advantage

all companies always show test results for the sake of profit, REGARDLESS of how much real time was spent on compression

I can say that paq8pxd is better than all the archivers that you use every day, let's use it, why not? Oh, yeah. there is not enough u life for compression

As I said, I think it is supported in browsers other than Firefox. I know a number of people that share this viewpoint. Not sure what the argument is...

large neural networks work well, they win, but they cannot be used on a daily basis. small neural networks do not work well enough to change ecosystems for them

Lossless JPEG lol

and where are PNG and WEBP?

this work is not worthy to be read

I mean, why not standardize using video in the IMG tag, maybe even in raw bitstream or with a minimal header, instead of inventing a separate image format

This is about lossless Jpeg recompression, not just about lossless formats in general

to talk about lossless compression and not to mention the most powerful and currently available codec WEBP

WebP can't transcode Jpegs, it will be regular lossless compression from pixels

That's not what the img tag was meant for. It doesn't show video controls or any way to use your own. It will play video, like a gif. But a full video with audio should use a video tag.

did you even know how crookedly lossless mode is implemented in AVIF, in principle, just like in JPEG, the whole picture is filled with data at 100% compliance and then internal compression algorithms are simply applied, but because of this approach there are a lot of options when AVIF is ten times worse than lossless WEBP

why is this a problem?