JPEG XL

I'm using this https://github.com/libjxl/libjxl/blob/main/doc/developing_in_windows_msys.md ```cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DBUILD_TESTING=OFF -DBUILD_SHARED_LIBS=OFF \ -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_ENABLE_PLUGINS=ON \ -DJPEGXL_ENABLE_MANPAGES=OFF -DJPEGXL_FORCE_SYSTEM_BROTLI=ON \ -DJPEGXL_FORCE_SYSTEM_GTEST=ON ..```

I don't think that's necessary. I will use my builds exclusively in order to get the latest version before my tests. for which neither productivity nor compactness is needed. And besides, there are daily builds here https://artifacts.lucaversari.it/libjxl/libjxl/

yes, it helped... now cjxl size only 5000 kb

But to run, still need the libraries in the folder

I think it's time to do a couple more comparative tests of jxl avif <:AV1:805851461774475316>

I've been doing one like once a day

looks ordinary

https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=78265&viewfull=1#post78265

> cjxl.exe -e 9 -d 1.25 > avifenc.exe -j 4 -d 10 -y 444 -s 5 --min 20 --max 30 I think the length of the team is very indicative. that jpeg xl is so simple.

likely cjxl -e 6 gives results that are pretty much just as good as -e 9

nightmare-funny meme

lol

Did you make that or does it come from somewhere?

what exactly?

the text I made and fun avif compress. I'm meme creator

in my bio there is a link to my telegram group with 1000 people where I make memes or just drop out another memes.

or anything

once again, ssimu2 vertically & bpp horizontally

What image is that? Kind of strange to see ssimu2 saturate already at 1bpp, must be a rather simple image I suppose?

Non-photographic, I would assume

kind of weird graphs, this is a photo with some detail in the front, but a good amount of background blur with simple almost one-color surfaces

Is there a good image dataset for compression tests? Like, a large dataset where we could possibly compare jxl, avif, jpegli, libjpeg, mozjpeg, etc.

It was photographic. A headshot of Rey from the Force Awakens at 1080x800

how do people generate those graphs?

very carefully

do you mean the data behind the graphs, or the graphs from the data?

both

the graphs look similar enough that I'm guessing there's some common tool doing the graphing

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

the last graph looks as though it’s from some spreadsheet software, maybe Excel

(the fonts and icons are a bit Microsoft-like + it doesn’t look like Google Sheets)

I would tend to use either something like that or gnuplot, but there are plenty of other options (e.g. matplotlib, plotly)

Plotly is nice to make interactive html plots

not sure about the others, but i generated my data using a script from one of the people at the AV1 Discord, i sent it here (https://discord.com/channels/794206087879852103/794206170445119489/1077113705050947635) i just used excel to graph it

cav1ar from the AV1 discord wrote me the script

Is there any Firefox fork for Android with jxl and Firefox accounts sync support?

firefox nightly

go to `about:config` & enable the JXL flag

Hmm. I don't want nightlies.

If I wanted to test the compression on a gif, what would be the easiest way to do that? When I try use https://squoosh.app/ I just get still images.

`cjxl input.gif output.jxl` ?

Thanks for your help I'm running on arm Mac can I run any of these? https://github.com/libjxl/libjxl/releases/

well that was simple enough thank you very much.

<:Kaiju_GoodJob:945878924913684490> <:Praykaiju:916507434795815002>

sadly the gif became larger, time play around with the options I guess

well-optimized gifs can be tricky to make smaller in jxl. You can try `-e 9 -g 3` and possibly add `-I 0 -P 0` to see if that helps...

Nice, using both ```-e 9 -g 3 -I 0 -P 0``` the file size was reduced by 22% from the original size. Using those options is the compression still lossless?

Also are these options documented somewhere, this file appears to not have them documented. https://github.com/libjxl/libjxl/blob/44778c6902084bd239c5fb8eaa53bfd90dd9face/doc/man/cjxl.txt

Just noticed the animation isn't working for them either, could be the viewer I am using tho

yes, cjxl should be lossless by default when starting from gif. You can add `-d 0` to be sure.

best to report the bug to the viewer you are using... I know some viewers don't do animation, but if it shows gifs with animation then it should also show jxl (and apng, and webp) with animation, imo.

I'm using xnview, do you have an example animated .jxl that is known to work I can test the software with. I looked in the server and couldn't find an example. https://www.xnview.com/en/xnviewmp/

when using the -d 0 option the size increases, seems like the smaller file size might have been caused by compression then.

Animated JXL http://188.121.162.14/jxl/animation.jxl https://github.com/libjxl/conformance/tree/master/testcases/animation_icos4d https://github.com/libjxl/conformance/tree/master/testcases/animation_newtons_cradle

Thanks for those resources, it allowed me to test the app and it's broken and does not play animation.jxl. I'll have to email the app dev and let them know.

PhotoQt on Windows plays animations.

fwiw I loaded the .jxl files as images into a local html page then viewed them in Firefox Nightly and they were static. So the reference animation.jxl and the others I made

firefox nightly's support for jpeg-xl is very limited it's missing support for transparency, animation, progressive decoding and color profiles. a list of browsers that currently support jpeg-xl is in this tweet https://twitter.com/jonsneyers/status/1626878007091527680

Thanks for that clarification, my mistake

Just tried Thorium I've experienced the future in animation form

<:4pepeWickedCool:900275195728760863>

https://github.com/eclipseo/eclipseo.github.io/tree/2f93d184577d273cac729e778d73fdcc8a93d0a8/image-comparison-web/comparisonfiles/subset1/Original

https://twitter.com/lxer_feed/status/1630854786835701764?t=XkmBD-983IEb79abTy68Hw&s=19

Radiance image format? What is that

OpenEXR?

looks like this : http://paulbourke.net/dataformats/pic/ 1 byte of mantissa for R,G and B and a 4th bit of exponent shared by all

by the way <@794205442175402004> 🙂 I sent a pull request for the community website of jxl few days ago, I don't even know if I did it properly (I'm not familiar with pull request but it seems still open) are you the reviewer/merger ?

thanks for pinging me, I don't check my github notifications frequently so I tend to miss stuff

no problem, if I can help

how beautiful look it would be if there were line-by-line block decoding... <:banding:804346788982030337>

libxl dll . 🤔. 😆

https://mortenhannemose.github.io/lena/

Haha and it's actually quite good as a test image too, nice mix of very easy blurry stuff, fine details, high-contrast textures, low-contrast textures, etc

optipng -- 286 bytes jxl -e 10 -- 206 bytes 1 bit bmp paq8px -- 158 bytes

nice, it performs better than a tightly optimized png !

Isn't optipng kinda meh though?

I got 208 bytes with ect

webp -- 434 bytes

For compressing 1-bit monochrome bitmaps, you should try JBIG2 and TIFF with G4 fax.

Of course, these 2 codecs are literally the only 2 things that are written on any site about binary image compression. But apparently the jbig2 ready build for Windows simply does not exist on the Internet. I couldn't find it anywhere at all. at the same time, I can't build it, because? because. Why don't the creators publish ready-made binaries on github? because it's a fucking open source. so i just can't say anything about this algorithm. There are binaries for **webp**, there are binaries for **optipng**, there are binaries for **cjxl**, and there are also binaries on **paq8px**. But JBIG2 decided that no one should use it.

Many, many times I find a great looking project on github, only to find they didn't bother to upload a 1MB exe precompiled

JBIG2 can be used in pdf iirc. Also I think imagemagick can do it, not sure though.

https://github.com/anotatta/jbig2enc/releases

JBIG2 is a very specific codec though, doing only 1-bit black and white and nothing else.

It's quite good at it, but it's a rather niche thing to be good at. Even if you are interested in grayscale, you generally want to have shades of gray, not just binary color.

person forked and build it, BUT IT's WITHOUT LIBRARIES, I've been piecing together each library for half an hour. as it turned out, the best place is fedora pkgs

Scanners and fax machines used to do 1-bit quite often but that was mostly to save memory and because they assumed the data to be mostly black text anyway (and they didn't really care about antialiasing, as long as the text remained legible). Or that's what I assume happened.

for some reason on PKGS.org a website for downloading has been written download - download-ib01.fedoraproject.org - this should be replaced with archives.fedoraproject.org to make everything work

Bilevel images as they are called (hence JBIG: it's the JPEG BI-level Graphics format, or at least I think that's what it means)

given that it was built using msys2, perhaps the easiest solution would be to install msys2 as well

it’s generally quite useful anyway

I find fish a much more comfortable shell than cmd.exe or PowerShell

it doesn't work, you know what kind of library liblept-5.dll ? it was very difficult to find her

my guess would be leptonica

“An open source C library for efficient image processing and image analysis operations”

I think the concept of bilevel images is kind of obsolete. Sure there are still images like that and occasionally it's exactly what you want, but to dedicate a special-purpose codec to it or even to spend much effort specifically optimizing for it, I think that's kind of pointless in 2023. We don't really have any capturing devices nor display devices anymore that do 1-bit only, afaik. Or it has to be something quite niche or quite retro.

libwebp-7.dll 👏

https://www.google.com/search?q=jbig2+xerox

hey, why doesn't CJXL support webm on input m? here in an unknown low-codec JBIG for which there are not even binaries. libwebp is required to run

cjxl is not meant to be imagemagick, taking any input format. It is a reference encoder, it should take some very widely used formats as input (pnm and png, and jpg for jpeg recompression) but other than that I think it should only support other formats if that's needed for specific format features that are missing in the other input formats.

WebP can do nothing that APNG cannot do, and we already support APNG.

yep its jbig2 build is dead 0xc000007b

I'm just laughing at the fact that the forgotten JBIG2, which has not been updated globally for a dozen years, suddenly supports WEBP

https://en.wikipedia.org/wiki/JBIG2 Disadvantages When used in lossy mode, JBIG2 compression can potentially alter text in a way that's not discernible as corruption. This is in contrast to some other algorithms, which simply degrade into a blur, making the compression artifacts obvious.[15] Since JBIG2 tries to match up similar-looking symbols, the numbers "6" and "8" may get replaced, for example. In 2013, various substitutions (including replacing "6" with "8") were reported to happen on many Xerox Workcentre photocopier and printer machines. Numbers printed on scanned (but not OCR-ed) documents had potentially been altered. This has been demonstrated on construction blueprints and some tables of numbers; the potential impact of such substitution errors in documents such as medical prescriptions was briefly mentioned. German computer scientist David Kriesel and Xerox were investigating this. Xerox subsequently acknowledged that this was a long-standing software defect, and their initial statements in suggesting that only non-factory settings could introduce the substitution were incorrect. Patches that comprehensively address the problem were published later in August, but no attempt has been made to recall or mandate updates to the affected devices – which was acknowledged to affect more than a dozen product families. Documents previously scanned continue to potentially contain errors making their veracity difficult to substantiate. Following publicity about the potential for errors authorities in some countries made statements to prevent the use of JBIG2. In Germany the Federal Office for Information Security has issued a technical guideline that says the JBIG2 encoding "MUST NOT be used" for "replacement scanning".[22] In Switzerland the Coordination Office for the Permanent Archiving of Electronic Documents (Koordinationsstelle für die dauerhafte Archivierung elektronischer Unterlagen) has recommended against the use of JBIG2 when creating PDF documents.

we need to send fuck such developers. I don't waste a second on this. let your "creativity" remain forgotten with 0 stars in github

Well, or more competently -- *You made a website but didn't make a binary* well good luck with the promotion

AVIF, HEIC and JXL could also be used to do bad lossy compression by using intra block copy and patches in a too aggressive way and replacing an 8 by a 6. It is a property of a bad encoder, not a bad codec.

jbig2enc builds fine on msys2+mingw with this patch applied: https://github.com/agl/jbig2enc/issues/64#issuecomment-468192089 and the proper libraries installed

though it probably spent way more time in autotools than in g++

why are autotools so slow

> bad encoder Given my *deep *knowledge of JPEG XL, I would say that LIBJXL has not implemented half of the format's capabilities in 5 years of development, But your assessment may be lower

That's why I always say lossless has to be the new lossy.

People rely on an encoder too carelessly. They archived entire files which were subsequently destroyed. the dilema was then big because of jbig2 with the unfortunate pattern matching.

You know, I downloaded MSYS, I downloaded the project, the project says, "If you're running msys" just run: ./autogen.sh

there is a slight complication with msys2 vs. linux which is the msys vs. toolchains split

you generally want to do package management in an “msys2” shell and build stuff in e.g. a “mingw64” shell

you would use the msys2 shell to install, say, `mingw-w64-x86_64-autotools` to do that

and `mingw-w64-x86_64-libwebp`, and so on

ah, `pacman -S mingw-w64-x86_64-toolchain` (in the msys2 shell) is probably a good place to start

how good that we live in a world where for build needs the consultation of a Jpeg XL core developer

maybe I can do without an extra gigabyte of libraries

OK, build it. however, I do not know how to create a program with libraries inside. and also I don't know what libraries are needed at all, so I moved all 70 library files to a folder and it worked

jbig2 -- 279 bytes

IS THAT ALL? oh come on!

You're being quite demanding on people who are probably doing things out of their own creativity, putting in their own time and effort to create a project. Yes, it would be very nice if they provided compiled binaries and it would definitely help regular users use their project more widely. If that's their goal, then that's a good thing. But some people just don't have the time to compile binaries for each major operating system, or even for Windows, because it's painful, takes up time and electricity, and needs a lot of work to assure static libs, no compilation errors, etc. Again, open source comes without any guarantees, so I believe that frustration is best directed at contributing to the project and helpfully suggesting, rather than rant as if you have a right to force other people to work for you on a passion project.

For larger projects, yes, binaries are almost necessary, but for smaller things, sometimes, they're just not worth the hassle.

i mean it's still at least as much work to set that up lol

In this particular case (plain black and white palette) i was able to squeeze out a few more bytes out of jxl: minus 6 bytes - to 200 bytes with "--override_bitdepth 1" and minus 3 more bytes - down to 197 bytes by changing "#000000" color component to "#7f7f7f" (with "--override_bitdepth 1")

oh, it's even 196 bytes with -e 10, I was going with -e 5 before

Definitely. MSYS2 environments make it easier, but it's still pretty annoying.

I actually dislike msys2 lol, I've always had issues with it

people don't need sources at all, nobody needs them. only the program and its functions are needed

but the trend is this. that no one is doing this. just look at this https://github.com/drowe67/codec2 there's nothing build here? who is to blame for this?

and now look at the releases here https://github.com/PurpleI2P/i2pd/releases/tag/2.46.1

and I am sure that this should be in absolutely every project if its authors want it to be used 👆

Packaging is the task of distros. Maintaining software is already enough of a task, no need to demand that every project author also maintains up to date binaries for your favorite platform.

I do need the sources, nobody less one... 😄 windows having no "distros" do we have an official packager for c/djxl ?

Does it look like an unknown project? no, if your project has support and popularity, be kind enough to make binaries for all platforms that you can.

would you mind to contribute yourself to this ?

most often this happens at a time when people are creating hundreds of builds for themselves. but the author still does not post a single ready-made solution

Windows is just a bad distro, I don't understand why you would pay for it. There are many free distros doing a much better job at packaging software.

I agree 😄 last time I booted under windows was... last year, yet some windows users exists, perhaps DZgas could be our packager 🙂

Do you think that **I** should make ready-made binary for the author of project? doesn't that sound funny?

well, somebody has to do it

if you don't, we'll have to find someone else

Don't worry. paid windows is really the worst distribution ||🌚||

author

authors

maybe

as an open source project, there is only what people bring in

but I understand your frustration....

authors of Jpeg XL did this https://artifacts.lucaversari.it/libjxl/libjxl/

wonderful !

it's just hard for me to understand. why, in this case, do people post code on github, in general. They do not description and that's it. No builds. usually there are not even instructions. you just have to know everything and everything here (to know everything that the author of the code knows) in order to use it

is it really from jpexl authors ? what do you miss from this artifactory repo ?

yes it's repo of <@179701849576833024>

ah nice !

it's just a script that downloads the gh artefacts, nothing too fancy

personally I use github to sync work in progress 😄 I'm not alone, it explains the mess of some projects, even if public

so github produces artifacts ?

I'm lost, what are you missing DZgas ?

builds

like this ? https://github.com/libjxl/libjxl/releases

yes

but not exactly like this ? 😄

you need to set it up for your project

and it's usually a massive pain to do so

you want the last release ? how are these tagged binaries made veluca ? manually ?

although this... one of the biggest I've seen. I would even say that the packages were overdone for linux.

for 99% of projects on github, it can be said - AT LEAST SOMETHING

it starts like this :P ``` luca@zrh ~ $ cat /data/github-get-artifacts/get_artifacts.py #!/bin/python import requests import os import dateutil.parser import email.utils import subprocess from pprint import pprint ```

it just looks at all the pipeline runs and downloads the outputs

but are they cross compiled for windows ? or do you have a dedicated machine ?

github does it

nice !

doing mostly python I never dug this kind of feature of github 😄

it's open source, why dont YOU do it

also, the entire point of open source is that the *sources* are open and available...

as a devil's advocate, even if it's not my case, I can understand that a **user ** of a soft (especially on windows) expect binaries... hopefully, github provide them

I'd argue 99% of users couldn't care less about it being open source, too

except the ones on this discord I guess 😄

but also most of those people are people who don't like to pay for things

maybe it's the assumption of open source meaning free and open source

true, i do expect binaries too, i just also understand that i probably shouldn't be so antagonistic towards the developers...

yea, i'm not really an open source purist or anything, if proprietary software works better, then of course use that whatever is best for the use case

OPEN SOURCE now means no developer responsibility. you need to you do it

no. I will not waste time on this and will find another ready-made solution.

it always meant that

are you under 20 years old?

because why would anyone do anything for free

I don't agree with your This vision of the world

software isn't charity

What does this mean?

why does github exist?

to increase productivity

productivity of anything for free?

productivity of entities

to make more money

any

Well, that's it. and what does open source have to do with it?

nothing. open source means nothing for users

ok

why do open source at all?

✍️

to get other people to do the work

no even wrong 😄

the more politically correct version of this is : so that every one can contribute

> nothing for users > do the work

regular users, other developers

in this case, you can use statistics on the number of people you are talking about

1%

0.01% ?

it's for creators. same can be said for other art stuff

like what is a normal user gonna do with stock footage

> stock footage nothing. they no longer exist. use neural networks

🤷‍♂️

for the users, there is the releases : https://github.com/libjxl/libjxl/releases

you should be grateful there are releases

*free releases

If there were no ready-made releases here, I would have sent this format to fuck -- 2 years ago

it's not like this format is not financially motivated

Oh, come on. It was only necessary to create the most powerful codec in the world

WSL2 conflicts with VirtualBox

I’m having to stick with WSL1 because of that

I’m not sure whether it is even possible to set up on new installs

No

Is image magick's -quality 90 equal to -d 1.0?

cjxl (libjxl) - yes

Looks like WIC is broken.

in windows photo viewer with the jxl wic codec dark areas get messed up

although this seems like more the fault of windows photo viewer then the wic codec

since I tried the wic codec in other programs and it worked fine

Likely a colorspace issue of some kind

I have noticed that windows photo viewer has issues with third party codecs

for example if you use the webp codec then every webp you open will become very dark

oddly enough, in windows vista it works just fine lol

Probably it depends on the source image and the way it is encoded. The source is a jpeg from fujifilm 24mp camera and I used imagemagick to downscale it to 50% and converted it to jxl using imagemagick.

I think it's just any jxl or webp

yeah theres just something wrong with how windows photo viewer handles things

Now I have used ` -set colorspace RGB -colorspace sRGB -strip` to magick conversion.

oh no. it looks bright now.

imagemagick has a bug where it writes sRGB png files incorrectly using only the gAMA chunk and not the sRGB chunk

and it very confusingly lies about it too when you do `identify`

colorspace RGB in imagemagick is a linear colorspace

and then you ask imagemagick to convert it to sRGB which applies a power function

you can use TweakPNG (windows only, but works in wine) to manually add an sRGB chunk

TweakPNG is nice, I’ve used it quite a few times

I am encoding a screenshot to jxl. vardct e9 produces bigger file than e7.

`❯ du -la 32K ./e9.jxl 24K ./e7.jxl 128K ./2fa backup codes.png 184K . `

With VarDCT e3 or e4 will currently sometimes give smaller sizes than anything else

e3 and e4 is bigger than e7

As I said, sometimes

hmm right

haha classic. Give the screenshot img

These backup codes are not in use. I have regenerated new ones.

aww

literally "artificial image"

14-byte Exif ✍️

~/Music/tmp ❯ ./cjxl ssss.png s.jxl JPEG XL encoder v0.9.0 c4927fbf [AVX2,SSE4,SSSE3,SSE2] Read 850x650 image, 127609 bytes, 126.6 MP/s Encoding [VarDCT, d1.000, effort: 7], Compressed to 24475 bytes (0.354 bpp). 850 x 650, 1.10 MP/s [1.10, 1.10], 1 reps, 4 threads. ~/Music/tmp ❯ ./cjxl ssss.png e9.jxl -e 9 JPEG XL encoder v0.9.0 c4927fbf [AVX2,SSE4,SSSE3,SSE2] Read 850x650 image, 127609 bytes, 144.3 MP/s Encoding [VarDCT, d1.000, effort: 9], Compressed to 28726 bytes (0.416 bpp). 850 x 650, 0.20 MP/s [0.20, 0.20], 1 reps, 4 threads.

and use --gaborish=0 for best

and --epf=0 for best bytes

hmm. still slightly larger than e7.

still slightly bigger than e7

i say for e7

oh ok ok

yeah nice compression

for some reason e9 has made more unnecessary and inefficient blocks

This is not really an image where dct is useful at all. Avif will likely use palette blocks all over the place here. We should make jxl use modular on an image like this, or at least in the region with the white background.

Only Modular gives more file size than would like. about 3 times more than necessary. e7 works well. it's not that important. it is important to know why the stronger e9 algorithm gives a worse quality than e7 here.

Modular gives 40kb size.

2 times more <:PepeOK:805388754545934396>

53kb at e7. 46kb at e9.

Modular always e9 is too powerful, it will be better than any

although there may be times between e2-e5 when a more powerful function compresses worse on Modular

butteraugli thinks the e9 encode has lower max norm and is closer to the target distance than the e7 encode. The cost is more bits. This is an expected result.

oh no, DPReview is closing

<@794205442175402004> I remember you saying that you don't check github notifications that much so I am here to tell you that currently there is a pull request that someone has made for the jxl community site https://github.com/jxl-community/jxl-community.github.io/pull/10

one of the reasons I bring this to your attention is because I plan to do a pull request of my own once this one is reviewed

Thanks!

Merged it

I will continue on the pull request I was working on, no ETA for when I will be done but I will ping you once I am

<@794205442175402004> my pull request is finished! feel free to review it whenever https://github.com/jxl-community/jxl-community.github.io/pull/11

(I waited until the other pull request was merged since mine might have conflicted)

I should probably mention that I did not touch the images on the test page

Yes, there is user of highway other than libjxl in Chrome

https://twitter.com/hikari_no_yume/status/1633014129806942208

https://www.rollingstone.com/music/music-news/riaa-vinyl-units-surpass-cds-1234693223/

vinyls are just much more interesting as a medium. CDs are p much always either same or worse than lossless internet downloads, what's value in that in current year

with vinyl you get different sound at least, which often has worse signal to noise ratio but that's something that human brain can filter out easily & that may actually add up to effect of having "warmer" sound

You could add some noise/warmness/whatever and burn it to a cd

The only real selling point of vinyl is the quality of the jacket

I guess it might also be a more 'fun' physical object to own / show to people, and I suppose in some genres like hiphop there is value in being able to do scratching and other turntable effects.

in terms of fidelity, there's no value though — just like film photography has no better fidelity than digital photography.

Some people like to hold what they own

mmmmmmmm holding physical harddrive zraid array with over 1TB of flacs :>

Holding my active and writing hard drive dock full of all the family photos

i messed up more drives than i'd like to admit by touching them while they're spinning :<

the value of vinyl exists but again it's stuff like album art, or physical object value

not in fidelity

you get people who disbelieve the sampling theorem but that's essentially a rejection of digital audio as a whole

not of CDs

it's usually just a (imo warranted) resistance to people who smugily proclaim that digital is all everyone should use because quality

when in fact quality provided by vinyl is fully sufficient except when records get old ofc

like u know that rebellious urge to confuse & discard knowledge of people who evidently don't care about values you care about

though i don't even see much of that nowadays its like you gotta go out of your way to find groups who do that

one could legit argue that cheap DACs could sound worse than proper turntable but thats like idk if anyone do argue that either

and good ears

there are audio systems that are very good on all agreed metrics but sound wrong

the audio signal (the number values in a .wav file or on cd) is the 2nd derivative of the loudspeaker displacement, and the loudspeaker itself a harmonic oscillator (i.e., 2nd order), but eq-corrections are done with 1st order systems -- the power spectrum is ok, but the bass is shifted in time and around the oscillation it has truly weird time behaviour

once JPEG XL is completely deployed we will fix audio? 😄 yes or no?! 😄

I'm an old fashioned digital person. I bought about 100 audio cds per year during last 4 years (I bought 'collections' off from people giving up their physical media).

someone could make a jpeg xl vinyl -project for 2023-04-01 fools', a project that would put a 'label in the center of the virtual disc' and then put a wav-file audio circling it -- with tools to convert to and from wav

jpeg xl audio compression

Jpeg audio... It just sounds wrong xD

good audio gear/musical instruments is like good food, easy to get used to -- but something that you will miss once you experienced it long enough

Ohh, right. You mean turn the audio into image data surrounding the label. I thought you meant on physical vinyl again

jpeg audio sounds like it would be worse than mp3 lol

I cant help but think of this https://youtu.be/jmaUIyvy8E8

Not only when the record get old, but scritches, wows and flutter (due to fluctuations in the speed of rotation) are a pain, solved only by the most expensive turntables

CD is high quality music for the proletarians 😅 the only paradox is mixing. CDs have a much wider dynamic range but are often mixed far too loud (cf loudness war) whereas vinyls, targeting audiophiles are perfectly mixed... The problem lies in the studio, not the support

scratches which shall be considered physical damage can happen on CDs too. physical damage is its own thing. and audio CD players can have their own issues too. fair point that bad things can happen on vinyl more likely but that wasn't the point i was making

the point was that personal experiences wise vinyl can end up being better for arguably statistically wrong reasons due to handling & equipment selection biases of buyer, which may end up adding to audiophilic collective experiences of it

minor scratches on CDs do not affect the sound at all

whereas scratches that affect the sound of vinyl are pretty much unavoidable

(or dust, or…)

And the irony is strong here, if present day audiophiles don't choose the audio quality above everything else 😁 but I understand your point

on that note, I need to rip the best CD set ever

Make an online conversion tool and it could actually get used, if it works well enough. There are plenty of platforms (forums etc) that allow you to share images easily but not sound. This could be a way to circumvent such limitations...

masterpiece

Bonus points if it is somewhat robust to recompression, or maybe if it can even survive being printed to physical paper and photographed with a phone.

Uncompressed audio is about 10 megabytes per minute, right? For stereo 16-bit 44.1 kHz. So an uncompressed song is about the same as an uncompressed 10 megapixel photo...

If you pick the image width so the tempo of the song fits well (assuming constant tempo), there might be some spatial correlation in the image already if you just treat the uncompressed audio as an uncompressed image

I suppose frequency transforms can help too to turn the 1D sound into something more 2D-ish

Like a jpegxl wav giant qr code?

Yeah, something like that. But less redundant and error-correcting. I want it to be convertible even if you do lossy transcoding on the image, so you can hear the compression artifacts

Btw my April's fool tweet from two years ago: https://twitter.com/jonsneyers/status/1377508854024523778?t=s22-fr81KOUSIahAhsZXiw&s=19

If my jokes become reality, maybe I should tweet the opposite thing this time around 🙂

The bombzen isn't in the av1 server

I already encoded hydrium 0.2.0 audio

Now I will do libjxl

https://raphlinus.github.io/color/2021/01/18/oklab-critique.html

<@794205442175402004> I have made a new pull request for the jpegxl.info site feel free to request any changes I make to it before you merge it

such as if I should change the wording for the new description I wrote for the site's metadata embed thing (I don't remember what the standard is called)

or if the position of the bit depth info should be changed for example

Thanks! LGTM

<@794205442175402004> oh my I just noticed that the places for the webp and jpeg are swapped for the wide-gamut test..... i'm sorry for the mistake here is the fixed html file since it's such a small line change I don't think I should submit a full pull request for it.

apologies for the mistake. I didn't fully validate the line placements

I'm on holidays, only have phone, so please do make a PR, is easier for me

alright done!

as of today/yesterday discord now compresses images sent through it

this means recompressing JPEGs

and also recompressing PNGs

and it doesn't even make the new JPEGs progressive.... they are baseline

also when it takes in a PNG it doesn't spit out anything lower then 24-bit

which means if this image is sent in discord it becomes around **5 times** bigger in size now

waaa

due to discord's new system this image becomes around **5 times bigger** when sent in discord, compare it with the one in the rar file

wat

It was already weird having heavily degraded previews with larger file sizes than original (GIF).

those where just thumbnails now discord is messing with the actual full files

Thank you discord for doing unnecessary useless work and wasting your time even though no one asked you to 🤝

wasting our time? that's not a problem because noone asked, but witg the DISCORD NITRO we will ASK and allow you to share additional 257th channel of RGB

oh, rip

you'd think they'd at least keep OG if it's smaller

I'm going to have to do more testing but from first glance discord looks very dumb

imo this one of the worst discord changes so far

So they made PNG non-lossless... Truly *an* update of all time

pixel wise they have the same values (unless there is a color profile because discord discards them now)

speaking of: https://cdn.discordapp.com/attachments/1075919445538652223/1094435516168032286/discord-before.webp https://cdn.discordapp.com/attachments/1075919445538652223/1094435517208199240/discord-after.webp

^ a little before and after

discord just ruins PNG and JPEG files

WebP and GIF are unaffected

is discord stripping ICC profiles now too?

Just `mv image.png image.bin` 😄

someone should make something like a userscript that uploads as .bin in addition to normal

haven't played w javascript things much myself tho

It could be neat to have a a bot that will show thumbnails for e.g. `.png.bin` and `.jpeg.bin` files.

that'd require you to upload stuff that way which either means userscript or actually renaming your files.. which would be unreasonable usability harm for yourself

& you can't use bot in every server, or private chats

That’s fair enough.

A potential solution is to just upload the image elsewhere and just post a link on Discord.

yeah that'd be nicer. userscript for that :^)

my prophoto green doesnt work in discord anymore...

I've noticed few days ago Discord already bloating my pngouted files.

Not sure if they changed it but you used to be able to edit the extension inside the upload dialogue without affecting the original file

Anyway. I discovered an interesting quirk in Gimp regarding color profiles. If the image is converted from a custom color profile to sRGB, there's a possibility for random by-one error. It occurs seemingly randomly with the same image and the same settings.

unrelated, but that reminds me of kritas broken lossless webp export, in which it is always lossy or something

Color space conversion is not consistent among different programs, so slight rounding error is acceptable, but I'd expect consistency at least when using one program, following the same steps.

Not being able to export lossless webp is bad. That''s why I test the tools I use.

that's likely a bug more than anything else weird going on

if it's not doing the same thing on the same image it's probably reading from uninitialized memory that wasn't properly zeroed

I performed several attempts and Gimp produces exactly two different outputs for one input image.

Those outputs are alternating after a few attempts. It doesn't make difference if I do multiple conversions during single Gimp session or if I close and reopen Gimp after each conversion. It seems like it was influenced by system time or something.

It's likely influenced by whatever happened to be in RAM

As I said, there are exactly two possible results and they are alternating quite regularly.

I have some very very very bad news about discord's new image ruining system

hm?

it seems as though they have gone across all of their servers and replaced every single image uploaded to their platform with ruined versions

<:DunktsukiStare:759697530786938901>

larger PNGs and uglier JPEGs

also the JPEGs that are spit out are all baseline

...y?

are the xyb jpegs broken?

yes

are ICCs stripped?

yes

fuck

https://discord.com/channels/794206087879852103/1020724883241574472/1074995333916020777

there is an example

that image was uploaded months ago

ugh

what amateurs

all the apple users with P3 displays weren't a sizeable enough portion ofthe userbase, apparently

does it lossyify lossless webp now too?

wow. that is silly. very silly.

just stripping all icc profiles and recompressing even the _originals_, that is.... wow

WebP and GIF are safe for now but GIF is probably on the chopping block next while WebP might not be touched at all

years and years worth of images are now ruined...........

do they also do this for people who actually paid, what's it called, "nitro" to be able to upload bigger files?

this is all such a big shame

I presume so. I have nitro so I can check

nitro classic*

the cheap one

at cloudinary we have one holy rule: never touch the originals

but later. currently walking to store

if you mess something up in derived stuff like thumbnails, that's one thing

it used to just be thumbnails and that was fine

now it is everything on discord

I figure that's standard. changing og is unrecoverable

ruining _originals_, that's just so very, very bad

amateurs

maybe there is some hope they have the originals backed up internally just in case?

although I doubt it knowing discord

this remainds me of: http://ascii.textfiles.com/wp-content/uploads/2023/03/image-6.png

Oh boy. Imagine a discord server that is being used just to share digital art — they just lost their entire archive?!

oh people use discord for stuff like that all the time

some people even use discord to host images for other places

and some people upload professional work to discord even

Pixel art specifically is super silly: discord will require more storage for the lossy versions of such images than for the originals...

they don't make PNG files lossy

they recompress them in a dumb way

that makes them larger if they where already optimized

They keep the pixel values? But still strip the icc?

they recompress lossless PNGs as a lossless PNG without considering anything else

so the icc is lost

E.g. all MacOS screenshots will be wrong if you just strip the DisplayP3 profile they have

they don't even do a size comparison to see if their "optimized" PNGs are smaller or not

which is why so many of them become larger when put in discord now

I'm less worried about size than about correctness. But it's of course extra stupid if they ruin the image _and_ they end up using more storage and bandwidth...

Ohh, *ohhhh*, I just realised. This'll be why my client has been locking up and freezing when pasting any image copied to the clipboard. It'd be re-compressing the file before it's uploaded, also explains why I've had multiple crashes as soon as I try to paste larger files

it's done server side

so this shouldn't cause more clie client crashes

So they're just passing all images through MS Paint?

in a way you could say they pretty much are but just in a slightly more advanced way

Anyway, there's no point reencoding PNGs if there's no optimizer program used. On the other hand, PNG optimizations are pretty CPU heavy.

Interesting timing, but it seems you're right judging by networks logs. On mobile it definitely compresses clientside, even has a progress bar for it, so I assumed on computers with more power they'd have done the same

Do they do lossy transcoding of jpegs or lossless?

they reencode jpegs into baseline ones with no color profiles

so all progressive jpegs are now baseline in discord

if you put a 5.6MB jpeg into discord it will become around 900KB

so it seems it's lossy?

very very lossy

5.14MB to 1.92MB Hopefully this shows the difference

here's another comparison (I thought I posted this here already but I guess not)

I managed to pick the worst possible example for mine, since most of the image was blurred anyway, thankfully found some rope that was in focus enough to show the artefacts :P

damn, i think they're also downsampling color to 4:2:0

or maybe not all the way down to 4:2:0... does someone have a good method to check that?

exiftool will say what amount of chroma subsampling a jpeg has https://exiftool.org/

but discord very likely only does 4:2:0

yep, 4:2:0

like very very likely

original 4:4:4 reference file

According to IrfanView, the compressed JPEGs are 4:2:0 @ q=75, welcome to 1995.

they are also all baseline

discord doesn't even output progressive ones

Bruh, incompetent bastards.

They must be using the default encoder included in Chromium.

whoever at discord set this up knows nothing about images

Worse: they're doing this on purpose. They're willing to sacrifice revenue on free users to increase revenue from paid users.

Agreed. Likely just someone who thinks "an image is an image" and aggressively wants to save storage/bandwidth

They don't even use optimized Huffman tables.

Default libjpeg-turbo encode behavior

Cheapest possible

I still can't believe that they don't even check if their "optimized" PNGs are smaller or not

In the case of PNGs, saving the disk space/bandwidth was not the goal apparently.

well it probably was

they just have no clue what they are doing

and only did the most basic of tests

they re-encode images in the most basic way

something akin to taking a image and putting it in a image editor then saving it as the same format but at default or worse then default settingsa

settings*