JPEG XL

Sounds like something I should try aom-av1-lavish in Oh shit no Builds

👉 <:AV1:805851461774475316>

It ready-made builds, they are certainly not the newest. but they are just like yours - only AVX

weird, i don't know why AVX still keeps getting built even when specifically disabling it

`-march=x86-64` ?

I doubt it.

The blur and edge masking is quite demanding.

damm this server 8 mb

<@557099078337560596> i do it

Regular ssim also requires a blur operation... The main difference is ssimulacra2 aggregates using different norms and keeps track of 6 subscores per component (and scale) instead of 1, but computationally that doesn't really make much of a difference.

Jxl jpeg transcode be like https://github.com/OptiVorbis/OptiVorbis

more like mozjpeg, jpegxl redefine the bitstream entirely... but perhaps in the future there will be an optijpegxl 😄 given the expressiveness of the format

using the depth map in photoshop is pretty fun

https://imgur.com/bPhSfcC

<@456226577798135808> I came across your thread asking for depth buffer to be saved along with the color screenshot, which apparently wasn't possible back then but you might wanna check these out: <https://framedsc.com/ReshadeGuides/depthguide.htm> <https://github.com/murchalloo/reshade-addons>

Oh, that's really interesting, thank you very much!

👍

I use Ogg Vorbis since 2004, still didn't switch to Opus.

Quite surprised that this project wasn't announced on hydrogenaud.io where all the audio compression geeks are discussing this stuff

i wonder how this combines with aotuv libvorbis patchset

https://github.com/AO-Yumi/vorbis_aotuv this

reading what it does, should combine well

interesting. well, I switched to OPUS in 2017 and transferred my entire music collection to 128 and 141 kbps

this is the first time I've heard about this site. well. therefore, is extremely unpopular.

A. It can't be. I don't have to compile anything!

Well, it's the website where you can find developers of Opus, FLAC, and Ogg Vorbis, and many other popular audio codecs.

I always thought that it is quite popular place to discuss audio codecs 🙂

foobar2000 is also quite popular audio player that is supported on that forum, its author and authors of many great plugins are there also

These days audio codecs are not as exciting as they were 10-20 years ago, people just use Spotify and don't care about audio coding, so this forum is not as active as it was back in the day, but I doubt if there is any better alternative.

I don't think it would combine at all.. aotuv is a set of patches that changes how vorbis files are created at encoding time to try to improve quality by changing how and what bits are discarded while optivorbis takes already existing vorbis files and tries what it can against them to reduce file size while changing non of the audio data in a lossy way.

also i'm pretty sure atleast one of the optivorbis devs is already aware of aotuv

speaking of aotuv here is a useful repo https://github.com/enzo1982/vorbis-aotuv-lancer

Also, important bit: almost all aotuv patches have been merged into Vorbis.

in the past it seems so

however the newer ones aren't since I don't think the people behind vorbis trust them as much anymore

since in the past there where issues caused from aotuv

https://cdn.discordapp.com/attachments/677266163994198020/1075905185420939374/DZgas_music_tracklist_he_aac.mp4

I don't think we need forums like this, download flac, compress it into opus and drop it wherever you want. Although I don't use anything except discord and telegram

The sad thing is that there will be nothing after opus (maybe sad, opus the best)

I would like to have a codec that has vorbis on the lower frequencies, opus on the middle frequencies, and the tops are created through a mixture of opus and he-aac v2 sbr technology, as well as stereo via ps👨‍🔬 🤤

it was, some time ago, as was doom9 for video processing/encoding but, now, average people are much less interested in that stuff and most enthusiasts have splitted into different smaller or even private communities

that's... pretty weak logic

i'd rather you not criticize a website when you haven't (as you said) even heard of them before, without knowing anything about it

calling a website unpopular with reasoning that he haven't known of it before is such a weak logic that it's more of a comedy than criticism

i can't see why it would conflict. as you've said, optivorbis changes non-audio parts. while aotuv changes how audio parts are compressed

aotuv can't re-encode existing files to be more efficient, so optivorbis devs being aware of aotuv patchset don't really tell anything

for fresh encodes from flac, libvorbis-aotuv and optivorbis should be okay combo, provided one trusts current aotuv over official libvorbis. sorry if previous wording was confusing

ah I assumed that by combined you meant aotuv being used on already existing vorbis files not in the sense of optivorbis and aotuv being used together at encoding time to have the better quality of aotuv with the lossless file size savings of optivorbis being applied after

I didn't know that you where simply asking how well optivorbis does on aotuv encoded vorbis files

yeah i was kinda wondering but after reading details of how they do it i figured it should be fine

quite a normal logic. I've been studying compression for more than 7 years and I don't know about this site, never bumping into it in my life. It would be logical to say that this is an unpopular site. for a very small number of people.

*I can make a guess*. that the original official LIBvorbis wants to save the maximum legacy. And that is why they will not combine the current LIB with developments from optivorbis. Since the internal structure of the files is being compressed, I can assume that these files may have a problem when playing any non-official or just old Vorbis decoders.

I feel like you can conclude that it’s possible for it to be an unpopular site, or maybe even that it’s likely so, but not *definitely*. Maybe you just so happen to not have run into it.

It's a very popular site for codec fans. Heck even I know about it. LoL.

well. I took the new opus and flac builds on it. it seems to be literally everything that is useful on it. I don't think I'll ever remember again.

Oh. well great

any good upscalers you guys recommend? I'm trying to upscale .bik (Bink) video files to replace in some old games. I haven't figured out the .bik encoding part yet, so if anyone knows a better way to do it, lemme know preferably, one that's reasonably fast (probably AI/CUDA/RTX/hardware-accelerated) upscaler+motion interpolator to target 1080p60

<:uhoh:650565843851280384>

lmfao I cooked my GPU for this <https://imgsli.com/MTU3NjAy/0/3> upscaler my ass. it just looks like a denoiser at best, so either I'm doing something wrong, or the upscaler just sucks either way, I give up

what about ewa_lanczos?

``` ffmpeg -i input.bik -init_hw_device vulkan -vf 'hwupload,libplacebo=w=1920:h=1080:upscaler=ewa_lanczos:format=yuv420p,hwdownload,format=yuv420p' <output_options> ```

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

I was doing some tests with AV1 and I find that svt-av1 gives the best saturation of the CPU and the best speed but looks fugly at high speeds. aom looks much much better than svt, at the same encode speed and bitrate. rav1e probably would look better but I couldn't wait 1200 years to finish the encode.

really I don't understand how rav1e can be so unuseably, brokenly slow

So those are my conclusions. Hope ya enjoyed, leave a like and a comment and don't forget to ring that bell, it really helps me out okay thanks guys

this is quite obvious to anyone - AOM is better than SVT-AV1. this is written on the AV1 discord server. I saw literally the same thing in the developers' comments on the new features for SVT-AV1. SVT-AV1 is ideal for streaming, it use a lot of thread. and that's it. excellent.

SVT-AV1 is also a good solution if the task is to switch from AVC to AV1 while maintaining encoding speeds <:AV1:805851461774475316>

the main thing is to disable CDEF

what's cdef? also aom simply will NOT use all of my available CPU no matter how many tiles and row-mt I use

aom just refuses to scale across multiple cores.

SVT does but the quality is so bad.

SVT is not even worth using.

You would be better off using a different codec entirely because it defeats the purpose of AV1

the bitrate/quality/time tradeoff is just bad, for acceptable quality you will end up with a HUGE file that is larger than older codecs

You would be better off using x264

that's how bad it is

aom can produce a much better file at the same speeds as SVT-AV1, despite being crippled and using less CPU

So I consider SVT a total failure

On top of that, SVT does not even work unless you get the resolution exactly right

Looks like Signal is open to AVIF support potentially. They shut down JXL pretty quick though, citing Chromium

Try av1an

wow

since at this point most browsers support AVIF, what would you consider to be "sane default" settings for avif encoding?

e.g. for jxl `-d 1` is a sane default

anywhere from `-e 4` to `-e 7` being good options

(lossy, that is)

and is it really worth it when jpegli exists and I can just serve JPEGs?

Activate FP MT for video.

Do I have to use `-aom-params fp-mt=1` or something? aom has zero documentation of what switches it has or what settings are recommended.

and ffmpeg does not have an option like that so I assume I would have to use something like what I typed above?

That is correct.

Sorry for pinging you.

It's not enabled by default and not documented anywhere, the source tree has no instructions on the different options, who the heck is developing this?

What an annoying library

It is documented in cmd line flags of aomenc though.

so I would have to either run aomenc -h or something or look at the source code to know what options it has?

Ugh...

Well it's not here... https://aomedia.googlesource.com/aom/+/refs/tags/v3.6.0/apps/aomenc.c

It's not here either... https://aomedia.googlesource.com/aom/+/refs/tags/v3.6.0/aom/aom_encoder.h

There's no obvious place in the source tree where to find the list of options.

Am I just stupid or is libaom stupid?

nothing in the doc/ folder too

Either I'm really dumb, or this library is unuseable.

There's just zero information anywhere...

Thanks for the heads up anyways, next time I'll try that

4x4 tiles was not helping

https://streaminglearningcenter.com/articles/svt-av1-and-libaom-tune-for-psnr-by-default.html

Is AV1 some kind of joke?

libaom is not designed for humans?

Have you tried "enable-tf=0" with svt-av1? I always thought that it simply lacks consistency, but after turning tf off it's much better.

More details, less blocking with the price of only slightly higher filesize, around several %.

It's better to use it. Try cdef=0

In my case tf produces a solid amount of blocking like these https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/1810 . But tune doesn't fix it, only disabling tf does.

WAV original OPUS 256 VORBIS 320

> it has been shown before that Vorbis tends to outperform Opus at high bitrates

What about aac? Does it perform better than opus at higher bitrates?

With AAC it's simple, don't use it.

😄 and if you can't here the difference between two settings... why bother 🙂 personnally, I don't ear plotted spectrums

I use it for WhatsApp media

fdk-aac at vbr setting 4 or 5

oh, and Discord

or do they support newer codecs now?

ah, vorbis is ok

has always supported OPUS.

I just tried Opus and the web client didn’t show playback controls as it does here for Vorbis

or does it just need to be in the right container?

Oh, yeah. just (literally) rename the end of the file with .opus on .ogg

Yep, I also noticed there's a toggle for AV1 in the settings now, I assumed it would've just been automatic

That toggle if for AV1 streaming. I assume you'd turn it off if you have a buggy or non-existent hardware encoder.

I just discovered the BBC has a public R&D website, and apparently AV1 used to be pretty awful compared to what we already had https://www.bbc.co.uk/rd/blog/2019-05-av1-codec-streaming-processing-hevc-vvc

NOPE.

This was a completely dipshit study at the time.

We always complain about this study whenever someone mentions it.

`Disabling --lag-in-frames vs VVC, 8-bit AV1 vs 10-bit VVC, not disabling lookahead for the other encoders`

it is also psnr and 2019

It's nearing 4 years old now so I assumed it was wrong anyway, but strange they messed it up that badly

It was done on purpose 😄

and psnr is especially bad for av1 (even worse than any other codec) as a correlation with subjective results

optipng -o7 -zm1-9 | 30 931 bytes webp | 28 180 bytes cjxl -e 9 -q 100 | 13 589 bytes paq8px_v208 | 6 713 bytes (faster than jxl) JPEG XL -e10 gives a significant advantage, by about 5-10% for 1-bit images. but for an image of this size, it's deadly slow speed

https://github.com/hxim/paq8px/blob/master/model/Image1BitModel.cpp I couldn't find anything more powerful on the internet for compressing 1 bit images, at all. Even Jpeg XL is 2 times worse. Perhaps this is the most powerful of the existing functions. In addition, its code was updated just 8 months ago

I wonder what exact settings -e 10 comes up with, and if the're good for most 1bpp images like this

27 003

I am pretty sure that jxl _could_ compress that image much better using patches fully, but likely the current patch detection isn't exhaustive enough to find all the matches

Basically the top row could be encoded as a patch frame and then the actual image could be described just by copying rectangles from the patch frame.

That would be more effective than pixel-level lz77 matching

Could an option be available to provide patches from external sources? If they are explicitly known

Like a list of pictures provided to the command line

Or a list of coordinates...

Even if I fear that font rasterisation (for manga or comics) will give slightly different results for each letter

Subpixel rendering is annoying, and patches will only work well for synthetic font renderings, not scanned ones.

Adding manual patches to jxl_from_tree could be interesting... Also to create funkier conformance bitstreams, since the current encoder only uses patches in limited ways (only kAdd blending, no overlapping patches, etc)

patch couldn't be moved by fraction of pixels ?

No, it's integer positions. But subpixel font rendering is becoming rare, it's too sensitive to the subpixel layout and now many screens can be oriented both ways (phones and tablets) and have high density anyway, I don't think it's still worth bothering with.

Yes, I was not thinking of subpixel rendering, but the fact rasterisation sometime fall on half pixels (with grey pixels)

font hinting could help thought

Ah yes subpixel positioning also happens. As long as it's only two variants per letter (half pixel horizontal offset or not), I guess it's still ok. Any idea what current font renderers are doing?

if I remember well (from the time I was interested in this) at the time were cleartype was published (the font engine of windows) subpixel was the way to go, but without a good hinting the readability was not improved so much, and it was indeed fragile to RGB configuration, so the hinting became the thing.

I'll try to find what libraries like pango does

and more importantly, what we have in existing mangas

So what's the deal with 4K Blu-rays on PC? I was planning to finally get a drive but apparently best case scenario, 4K playback requires to jump through several hoops, if I'm lucky or is straight up locked to certain hardware/software (I've even read it sometimes *requires* the integrated graphics to decode it which sounds preposterous when having an RTX)

I've been reading about recommended drives here tho tbh I'd prefer to play the video directly from the disc without having to dump it, let alone mess with flashing custom firmwares 😬 <https://forum.makemkv.com/forum/viewtopic.php?t=19634>

just flash it it's easy

get the lg

which model?

they're all the same so whichever your local store has

and I'm assuming you've done it. does flashing allow reading UHD from common players like MPC?

as long as you have makemkv installed

I see, so I take it makemkv has its own system-wide decrypter that's also used outside the app, right? 🤔 and does UHD require messing with fancy new codecs or something? or do you just pop in any BDXL disc and any player can load it?

you just pop it in

ooooh neat. I had never seen that dialog 👌

btw apparently flashing only works under certain specific conditions: > 1. Make sure your Drive was built after 2016 on label or late 2015 if you want to risk it. > 2. Drive Platform MT1959<Most important in makemkv > 3. SVC NS50+ LG only on label for NB drives NB50+ > 4. Just because your drive is the same model number does not mean it will work, if you are unsure ask me i offer remote flashing and check everything before i flash. > 5. Dont flash your dive if it does not meet these requirements if you do you will be unable to read all disks and unable to restore without dosflash that does not work on most modern computers > [...](so far, any firmware with date in 2020 is encrypted) > LG 1.04+ / BU40N 1.03 / Asus 3.10+ and similar > The newer OEM firmwares cannot be flashed easily due to the additional downgrade checks implemented by the drive/firmware manufacturer. If your drive has one of these firmwares, and there is no MK version of the same firmware/drive model or higher number, you will have to sidegrade to Asus 3.10MK (for compatible ASUS 5.25 drives ONLY) or (LG WH16NS60 1.02MK for compatible LG 5.25) or (BU40N 1.03MK LG Slim drives ONLY) respectively. (Note: MK firmware is available for firmware versions mentioned above.) Keeping the flashing of firmware in these scenarios within their respective family of drives/firmware (e.g ASUS firmware for ASUS drives and LG firmware for LG drives) at this stage of flashing. Then afterwards if that initial flash is successful you can move to different firmware respectively if you would like a different and compatible firmware version for the drive in question.

i personally have the lg ~~wh16ns60~~wh14ns40. i forgot it's flashed with the same firmware

my drive has manufactured october 2020

so it has an encrypted firmware? did it complicate flashing?

i just clicked the button on the flashing tool

if you can always return it, then you should just try it

i originally planned to flash, rip, then return, but got too lazy to go to the store and return it

hmm you wouldn't happen to have a picture of the label, would ya? something like this

let me take another

too much glare

dw that's good, just had to zoom in

so just so we're on the same page, you have managed to rip and play 4K UHD (4K/HDR) bluray XL discs after flashing, correct? just asking cuz I've read regular (non-4K) blu-rays are *way* less problematic

no, I haven't tried any 4k blu ray

but I have ripped one with aacs version 78

oh the wording is confusing on that page

encrypted just means that version can't be patched to support libredrive

but if you can flash another patched firmware, it's fine

<@288069412857315328> yup, I think libredrive is what I need. apparently it unlocks imposed read speed limits and encryption (apparently to intentionally discourage ripping), which is probably why compatible drives are so hard to come by 😔

it's mainly to be able to read the microcode so it can decrypt bluray

something like the inner track of the disc

Yeah, tho I think it doesn't actually decrypt/break encryption but rather bypasses it altogether, which apparently makes it more future-proof

you can bypass drm but encryption is encryption

wait, so those 2 are separate? I thought AACS was the DRM/encryption* libredrive bypassed, or is there another layer in the equation?

you can rip a blu ray without libredrive/anything

but the data is garbage

so libredrive just bypasses the encryption done by the drive/firmware, but it still needs keys/decryption of the actual raw data stored in the disc, right?

and if it's a common disc, you can decrypt the data separately if you have the keys

libredrive is to get the keys for decryption

which is stored on the inner part of the disc

is how I understand it

> The drive itself can easily read all the data technically. It is the drive embedded software (firmware) that “plays police” - decides what area of the disc can be accessed and on what conditions. > > So, how can one read the data from any area on the disc? The data on the optical disc is encoded as a series of small cavities called pits, that are organized in a spiral called a track. Had we had a sharp enough eye, we could've seen them directly. One way is to use a microscope - with a microscope one can clearly see the pits, apply standard (publicly defined) decoding algorithm and get the raw data from the disc. Obviously, this is a rather time consuming and expensive method. There is however a third way - take the drive back to the basic level. Change the optical drive embedded software in a way that the drive becomes a “primitive” device - one that just positions a laser, reads and decodes the data. Make a drive free from “policing” functionality, a drive that just passes all data from the disc to the user. We call this drive a LibreDrive.

<https://forum.makemkv.com/forum/viewtopic.php?t=18856>

so it doesn't really break in through the window, it just gets the key to the front door lol

> Please note that LibreDrive mode is not about hacking or meddling with AACS code. In LibreDrive mode the updated software communicates to the drive hardware directly, not touching or hacking AACS DRM code in any way at all. So your drive will continue to self-revoke on MKB updates and require authentication before releasing key material to the "authorized" software - it is just with LibreDrive mode all of it is no longer relevant.

does anyone here know anything about the removed experimental marked "delta palette" encoding feature of libwebp?

delta palette is a feature of JXL that never made it into webp

UHD Blurays are encoded in H.265.

and Rec. 2020 / PQ even when not particularly HDR, from what I recall

https://bugs.chromium.org/p/chromium/issues/detail?id=1424089 can anyone reproduce this issue on their phone?

(would be interesting to know on which devices the bug gets triggered and on which devices it doesn't)

Wait. If no app except for Chrome has an issue on Android, that means dav1d might be at fault since the system decode is libgav1.

I suspect the bug is in the integration code, not in dav1d itself. It looks to me like yuv2rgb being messed up at the edge when the image width doesn't match the neon vector width, which could explain differences between devices (depending on which arm code path they end up executing).

Could be a bug in dav1d too, but the pink smells like a yuv2rgb messup.

Green and pink are smelly colors in that respect

reproduced with Samsung Galaxy A51 5G

firefox for android does not have this issue

Both are using dav1d, right? Probably different versions though

I don't know

My guess is that it's a bug in the AVIF specific chrome code, not in the av1 decode itself. But I guess we will see. If my guess is right, then it's a nice example of how the "buy one get two, avif comes for free since we have av1 video anyway" argument is not entirely true...

Ah, so it could be a bug in libyuv instead, which would be an AVIF bug.

Happens on my Huawei Mate 10 Pro

Not sure if chrome uses libyuv or has their own code for that. Anyway, I hope they figure it out soon. This makes avif kind of undeployable right now...

And there's the difference between AOM and here, we still want them to succeed too :P

I like any royalty-free codec. And I also like progress. The main enemy is inertia, people who say that jpeg, png and gif are good enough and we don't need new stuff. I never saw webp or avif as an enemy, they do have nice things to offer, it's just there is more that can be done and jxl is getting much more things right than the "quick hacks" that (lossy) webp and avif ultimately are (not their payload video codecs, but the wrappers that turn it into an image format)

My phone has that problem. Pink line on the right edge

Chrome has it but thorium works fine

I still had Chrome 108 on my phone (stopped upgrading it), there it was ok. Now I upgraded to Chrome 111 and now I have the pink line.

Thorium 110 is fine

are there any downsides with progressive jpegs compared to baseline ones?

they are smaller and also have the benefit of being progressive and I can't think of anything that doesn't support them

so for example if I converted all my phone pictures from baseline to progressive in a lossless way would there be any downside what so ever?

Decode is slightly slower, but it's still very fast so I don't think it can really be considered a downside.

yeah decode speed is the only downside I could think of and it's very negligible

I assume one of the reasons why phones don't output progressive jpegs by default is for speed since users expect taking a photo to be a instant experience. it could also be due to the hardware encoders of phones most likely not having the ability to even output progressive although I don't know the process of how phones do hardware encoding (or even how common of a thing it is) so I could be wrong.

It would be nice if phones provided a "optimize" option to use in galleries to convert all baseline jpegs to progressive and reduce their size all in a lossless way

could also be used as a space saving method

Also how much memory you need to use. You can compress (and decompress) baseline JPEG without needing to store the full image, one row at a time.

Hardware jpeg encoding is always baseline, that saves a lot in sram

https://bugs.chromium.org/p/chromium/issues/detail?id=1424089

Still no solution...

Anyone deploying avif images with a width that is not an exact multiple of 8 is getting a pink line on Android Chrome. That's a pretty big bug. It's a bug of "rollback the avif rollout" magnitude...

that magnitude only applies when considering non-AOM formats :v)

dark humor aside this looks like just a decoder bug which will be fixed with time tbh

firefox' inability to display avif sequences is a lot more serious imo

Yes, I just wonder how it ever got into stable chrome...

Yes and no. Sure, it's a big bummer. But it just means you cannot use avif for animation yet, unless you only serve it to browsers that can actually play them. A regression like this is more serious, because it means we get customers who are now getting their website messed up.

it's complicated but that's probably right. i'm still salty about it though

I see also on xnview

And I'm using latest version of it

It's super stupid to have avif without animation, since animation is its killer feature. And imo they shouldn't send `Accept: image/avif` headers if they are still missing such a key functionality. They're again forcing people to use the user agent string to figure out the 'real' format support, which is not how things are supposed to be.

The pink lines? Really?

yeah that's exactly my issue with it

All the images pink

On Windows 10 also

But i'm using Firefox

I don't know if is a Firefox problem

I think yes

Because bluecord beta lags

But discord with a latest updated included

Don't

I don't know

I think there’s a Firefox flag in latest that allows animated AVIF

https://www.reddit.com/r/programming/comments/11zto8z/i_implemented_a_nasa_image_compression_algorithm/

😃

palemoon has JXL support but not AVIF support. this is due to JXL having better adoption than AVIF.

i dont know what reality Moonchild lives in but i want in

sadly Shopify websites only serve JXL images if the browser also supports AVIF

which means Pale Moon won't see or get JXL files on Shopify sites

I want to report this to Shopify but I really don't know how to

you could try in https://community.shopify.com/c/shopify-community/ct-p/en

dont know how much success you'd get though

Wait what?

That's really strange.

oh my god *please make it stop*

In the year of our lord 2023, Discord still lacks full support for webp.

piston moment

hopefully one day it will have full support 😔

https://twitter.com/nirbheek/status/1640311607535505411?t=SI0_Dk5Cy3ngOYafWCkz0A&s=19

This is a problem with hardware implementations: when you find fuzzerbugs, good luck mitigating them after deployment...

The pun in the abstract 👌"Modern video encoding standards such as H.264 are a marvel of hidden complexity. But with hidden complexity comes hidden security risk."

and frustration. hopefully ffmpeg is dope and does the job

A game develover is creating HLIF ("Halley Lossless Image Format") https://twitter.com/amzeratul/status/1640139569575198721

There will always be room for special-purpose formats, but I would recommend against it. One of the worst ways to lose assets is to have them in a format that nobody knows how to decode.

I would certainly prefer a very good codec with traction, support and an ISO norm, capable of supporting a wide range of applications, than a better codec (you'll always find a better codec)

He was told about FJXL which is already in libjxl ?

Judging by the fact that it's not in the tests, he doesn't know about it. maybe he's wasting his time

to be fair, I probably wouldn't use fjxl for pixel art 😉

I just now saw that it does not show the encoding time, which means that it is probably not fast. So need to tell him about -e 10 🙂

It's probably not horrible. It has palette and rle, so at least the basics are there. Probably if we add the Select predictor (which is probably better than Gradient for pixel art), it would be pretty decent...

It would be interesting to see a JPEG XL encoder optimized for pixel art! I’m currently using `cjxl -e 10` for a pixel art sequence I’m working on, and it was fine at first, but now that I have over ten pages, it takes a good several minutes to complete. (Though I shouldn’t be reencoding existing pages, it’s just that it was more convenient to regenerate the website altogether every time.)

Only -e 10? Because there are ways to have it run much faster and for better sizes if so

what do you suggest instead?

Generally for pixel art something like `cjxl -d 0 -g 3 - e 5` To start with, I can't remember the rest off the top of my head

and how is that better sizes than -e 10

Because lossy doesn't work well with pixel art, to the point you need to lower the quality by about 6x to compete, you can still do -e 9 with what I put above, but lossless is generally slower. Depends on the image sizes

tbf there was nothing about lossy/lossless i assumed it was already lossless

It defaults to *visually* lossless

i mean what zamfofex is doing

That's why I asked if they were only using -e 10 and nothing else

oh

I'm still on the e9 E3 I100

I've actually found I1 works better than 100 occasionally

Wish I made notes of all my testing now...

i cant even tell, these numbers keep changing all the time

used to be max 1

then 100

was it an addition? or was it a change in scale

no idea

Ah. Yeah, I do pass in `-d 0`. 🙂

Huh, I actually didn't think -e 10 worked with -d 0, it's only listed for lossy

e10 works only for lossless and yeah `I100` is not always better also instead of a full bruteforce `-e 10`, something like the best of `e9` `E3` `I1`/`I100` `g2`/`g3` can be faster and not much worse

need new e11 that does that

Anyone know the answer to my question here? (RE: JPEG non-XL, heh) https://twitter.com/David3141593/status/1641183616792248321

I'm guessing it's related to the "2:1 horizontal subsampling" they mention - but why did they do that?

here's what those values look like visualised, assuming I transcribed them from the PDF properly

Ah yeah, right, I got it reversed

Horizontal-only subsampling was common at some point, I assume because lots of things like TV broadcasting and CRTs were quite different horizontally than vertically...

Or maybe it's because horizontal subsampling is just easier to do when doing things row-by-row (or MCU row-by-row)

Regarding TV broadcasting - interlaced frame encode was common, and vertical subsampling would subsample from 2 different fields, which I guess would cause more artifacts?

thanks - so assuming your pixels are square and you're not doing horizontal subsampling, you'd probably want your quantisation table to be symmetrical along the diagonal, right?

I wonder how many people took that example from the spec and used it in scenarios it was never intended for lol

they still do that in video codecs

right, interlacing is basically temporal vertical subsampling

answer: "almost everyone"

gravity makes horizontal and vertical directions different

to have different frequency properties

also most cameras are hold with the right hand, and people don't know how to hold it straight, so usually horizon slopes down towards right in a picture

if you optimize a transform for a large image corpus, you will see these tendencies

are there any JPEG encoders that look at the actual content of an image, to derive the ideal quantisation table for that content?

(given some perceptual metric to optimise for)

hah interesting, I've recently started using a "real" digital camera and I noticed the same tendency in my own pics (since it's heavier than the phone-cameras I'm used to)

most cameras have a built-in level to prevent that, and some of them with stabilised sensors can even rotate the sensor to align it even if the camera itself is tilted

QOI support was added into GIMP 2.99.x https://gitlab.gnome.org/GNOME/gimp/-/commit/6892ab0530b759b63200696d9b5c9c1d6e12d22e

🤨 why

probably because it's quite ok

Because it seems easy...

Why not. I don't think anyone cares if the install size of Gimp becomes 0.01% larger.

There was user demand for QOI in GIMP, it was easy to implement and there was a willing developer to do the work.

But how do you pronounce it? Like french quoi?

Queue, oh, eye I'd guess. It is an acronym after all

Or ko-i like the Japanese fish

which one of these JPEGs has more generation loss?

I actually don't know

also I don't have the original image these are the highest quality ones I could find

I see the colors are different between them but I don't know which one is more indicative of generation loss for JPEG

I have no clue how many layers of generation loss these have but I know that they branched off at some point because some areas of the image have less or more artifacts then other areas

the main thing that I think matters in this case is the colors not the artifacts

2 is clearer and has very slightly more color to it, at least in my eyes

its like 2nd has less ringing artifacts

but wouldn't conclude that its got more color

in some areas 1st has more color variations

is this turbojpeg vs mozjpeg

also second one is probably better presentation

I have no clue as I can't find the original image and I don't know how many times these have been converted

but without knowing source its not known which one is more precise

probably still 2nd due to noticeably less ringing artifacts & less unnaturality of colors in some areas (back of this creature looks more colored in first but imo not exactly naturally so)

You can look at histograms of the quantized dct coefficients and see if there are suspicious patterns that hint at a previous encode with different quantization constants

I assume that both of these images have been re-encoded multiple times it's just that some of the later generations where done with different quality parameters between the two of them, so I don't know if looking at the histograms would be helpful since both of these have very likely been re-encoded multiple times over.

just take the mean and call it a day

I think i'm going to go with the first one because I think the extra colors in the second one is from color bleeding

"Get your own rat and make a new image"

Interesting, progressive jpegs tend to be smaller than baseline jpegs, even smaller than optimized Huffman. I didn't expect that. Is there some other optimization in place? Good thing baseline jpegs can be losslessly transcoded to progressive and vice versa.

yeah it's something i didn't expect either, so i have converted all my photos taken from my phone and camera to progressive jpeg's and tons of downloaded jpeg's to progressive

In progressive jpeg, similar frequencies are encoded together, so effectively it works like a fork of context modeling for the entropy coding.

Which tool could be used for converting jpg losslessly to progressive jpg

https://github.com/tjko/jpegoptim/

jpegtran can do that. IrfanView's losssless jpeg transformations can do that in batch as well.

Thanks

Optimized Huffman and progressive can be specified at the same time but it seems progressive overrides Huffman anyway.

Huffman makes no difference in progressive.

jpegtran produces slightly smaller progressive files than IrfanView. Supposedly they're using different libraries.

it does have this option that hints toward mozjpeg

I have a version of jpegtran from IJG. That doesn't have this option.

That's the version I could find precompiled for Windows.

i just got mine from mozjpeg, so that option kinda makes sense https://github.com/mozilla/mozjpeg/releases/tag/v4.0.3

that release is outdated the new one is here: https://github.com/mozilla/mozjpeg/issues/91#issuecomment-1218082085

Mozilla locked down permissions on github so no one is able to attach the files for the new release on github

Is it true that there is no codec that could be decoded faster than jpeg baseline? (with the best compression quality of course)

No. For one you could have uncompressed, then you can get into the ludicrously fast GPU texture type codecs.

http://www.radgametools.com/oodle.htm

It's a good idea

Casually studying mozjpeg in order to make a previews of my site (guetzli is too slow) I was surprised to find that "Enable trellis optimization of DC coefficients (default)" just kills pixels.

And that's with that - that the file size is identical. I don't understand at all how this is possible

at the same time, such death is most noticeable on ssim. then on hvs-psnr, but on psnr it is completely absent - last is the only one where everything works as it should

I also noticed that with -notrellis, the -tune-psnr and -tune-ssim parameters do the same job, and with -tune-hvs-psnr, they do a different one