JPEG XL

Doubts? The license_agreement.pdf speaks pretty clearly…

JPEG wants to avoid random people on the internet appearing to be JPEG

or JPEG-endorsed, or whatever

The logo isn't necessary there. But it would be good to have it there if it was possible in terms of licensing.

ISO BMFF is not at all controversial: it was used in the 1990s so it is certainly royalty-free. The validity of the HEIF patents is another issue, and doesn't affect jxl.

I will ask around in JPEG what the intention is with those logos

We were also discussing if we could add the unofficial / comunity logo (the ambigram). But it faded somehow…

It's the logo of libjxl

I would say it's widely used. I *guess* the community website is more popular than the official jxl page.

https://it.wikipedia.org/wiki/File:Struttura_Codec_JPEG_XL.png

there isn't a file with this name

but you can see a link

Where did you find the link, <@!416586441058025472>? If it shouldn't be there, you can remove it.

this contained the jpeg xl architecture

basically the table of the structure of jpeg xl codec

made by jon sneyers

i removed cause of duplicate

jon removed it

Vulphere (https://commons.wikimedia.org/wiki/User:Vulphere), are you on this server by any chance? 🙂

Of course. But people can have different nicknames on different sites. I also do that.

that's the original

I'm confused - what's the problem with “Creative Commons Attribution-NoDerivatives 4.0 International License”?

That's a new piece of information. (In March, we were talking about it as "JPEG XL unofficial logo".) Would you find it a good idea to clarify it somehow in the repo, on the community website, inside the SVG itself and in the SVG filename? I'm asking this because even I'm quite confused about the logo (although I've been following jxl for months). So I guess that newcomers will be confused even more.

well I don't know if it's the "official" logo of libjxl, but it has been in the libjxl repo for a while and shown on the front page of the gitlab/github repo for a while now

See here: https://commons.wikimedia.org/wiki/Commons:Licensing#Well-known_licenses

I assume that by being in the repo, it is also covered by the repo license, which is BSD

the logo itself was declared to be CC0 by its author

NoDerivatives is not free, but I think that's exactly what JPEG wants for their logos

yeah, doubt they're going to change it

... I didn't like that logo anyway

those logos are basically stamps that say "approved by ISO/IEC JTC 1 SC 29 WG 1"

you don't want anyone on the internet to make derived ones and make it look like they are actual JPEG projects

in other news - why is my (and Jon's, and Jyrki's) name a broken link on wiki? 🤣

right, I understand about the article not existing, I'm more doubtful about the second part... xD

Kakadu uses the j2k logo in that way: https://kakadusoftware.com/

Intopix uses the JPEG XS logo: https://www.intopix.com/jpeg-xs

but I guess those are not derivatives...

nope

they're just using the logo to identify that the product supports that particular jpeg standard

I don't quite get why Wikipedia doesn't allow BY-ND (or BY-NC for that matter), isn't that a bit unnecessary?

I mean it's a bit weird that they would allow totally proprietary copyrighted logos to be put on pages because of "fair use", but they wouldn't allow a BY-ND logo because random people on the internet cannot do whatever they want with those

I think there's probably some confusion on what "derivative" means. Using those logos just to refer to those JPEG standards is fine. Changing those logos to pretend to be a JPEG standard (say by making such a logo that says "JPEG AVIF") is not fine.

at least that is what I think is the intention here

well that actually happened in the past

like these guys: https://jpegclub.org/

who are claiming to be the "only true reference JPEG"

which is not true

they started diverging with their "JPEG SmartScale extension"

so anyway, yes it is a bit of a problem when people are making their own changes/extensions to a spec and then claim to be the "true" standard

jon has said the jpeg logo can be used only by jpeg

I don't know to what extent steps have, can or should be taken to take that down

the name "JPEG" is legally afaik just an informal name for the committee and for the standard, so I don't think much can be done

The thing with enwiki and Wikimedia Commons is that there are some different rules for allowed content. I've seen many images on enwiki that can't be on Commons (and thus on other Wikipedias) because of that.

Nevertheless it still seems to me that the official logos can't be even on enwiki due to the licensing stated on jpeg.org.

if this is possible: https://commons.wikimedia.org/wiki/File:Microsoft_logo_(2012).svg

then I don't see why JPEG logos wouldn't be possible

https://commons.wikimedia.org/wiki/File:Apple_logo_black.svg

if that is considered "simple geometric shapes", then surely the JPEG logo is also "simple geometric shapes"

https://commons.wikimedia.org/wiki/File:IBM_logo.svg

Hmm, this completely changes the situation… 😉 But seriously, if nobody objects it, the logo will probably be able to stay there.

Yes. But if bigger technology businesses don't do that with their logos, why would JPEG? It's a nice advertising, isn't it?

So, the presence of JPEG official logos on Commons could encourage us to upload the ambigram logo as well, right? 🙂

<@!792428046497611796> <https://github.com/libjxl/libjxl/pull/7> Also https://discord.com/channels/794206087879852103/804324493420920833/847176447897370624

Sorry, I don't get the point here…

Currently in README.md <https://github.com/libjxl/libjxl/blob/main/README.md#checking-out-the-code> `git clone https://gitlab.com/wg1/jpeg-xl.git --recursive` But the main repository now is on Github, so `git clone https://github.com/libjxl/libjxl.git --recursive`

OK, I made another PR.

It's nice to update those links, but it's not _incorrect_ to point to the gitlab one, it will keep being a mirror

i hope in july we would have next release of jpeg xl

with improved lossless compression and

with no significant regression and blurring at mid bitrates

i hope they fix up patches heuristics for modular

I also hope that 😛

pre-release of what?

the 0.4.x branch is pretty much that

frozen

ah, a lot of things changed, but I am not sure there was anything that would actually affect lossless encoding performance

or lossy for that matter

the main thing that happened is that there was some speedups, some memory optimizations, and implementing all the format features in the decoder

no, it's not

I hope vardct can get integral transform selection improve, 🙂 This improve probably can improve high contrast sharp edges and smooth have gradient area quality for non-photographic image. > like this https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=66545&viewfull=1#post66545

to me jpeg xl isn't at same level of webp

see what you can have with webp at 21,7 kb

21 kb

pretty bad, both of them 😛

I compile cjxl (8304ea44) for windows (non avx2) yesterday commit (deleted)

The git webpage is not clear for windows, it's impossible to compile with clang easily, i use msvc, and i need to undestand how to compile the avx2 version. (it's not clear why we need 2 differents binary for that :/)

With msys2/clang it's pretty easy. Can't tell about avx2, I only have avx-cpu.

where you found original png

<@!424295816929345538> when you found original png?

https://news.lockheedmartin.com/2021-05-26-Lockheed-Martin,-General-Motors-Team-up-to-Develop-Next-Generation-Lunar-Rover-for-NASA-Artemis-Astronauts-to-Explore-the-Moon

google

do you have the file

i did my effort

-q 36.844 -s 2 --use_new_heuristics --dots=0

with this

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

19,8 KB (20.367 byte)

crixis one 21,4 KB (21.917 byte)

i think he used less distance

what settings did you used do you remember all

and the build number

my image is 0.363 bpp

0.320 bpp

15 Kb

i do not know what i'm doing

which settings you used

same build and settings as me

-d 6

speed?

and build?

7

build?

the 4dddce or the before

8304ea44)

did you used new heuristics or the normal one

normal one

and the build?

can you send the cropped png?

so i make a file

let's get to a good size

ah i used d 5.784

is that d = -q 36.844

i used used the size of the website

https://www.punto-informatico.it/artemis-gm-lockheed-martin-progettano-ltv/

Is it possible to losslessly drop chroma information (i.e. just keep luma) when recompressing from jpeg to jxl? Or some way to do that even within jpeg?

I think it should be possible within JPEG

Alright, I'm going to see if I can't find something that will do it <:FeelsReadingMan:808827102278451241>

it's probably not too hard to write something that modifies the JPEGData struct from JPEG XL to that effect

but also likely nontrivial

when next commit squashed?

when is ready?

jon said once a week

now we do development in the public github repo, so things happen in real time, no more waiting for sync

`jpegtran -grayscale color.jpg > grayscale.jpg` should do the trick

sorry i created fork of libjxl

what means veluca 23 commits behind

hasn't he made anything

not any heuristics

why jyrki isn't in there?

no github fork from him

where he does his development

why nobody has the latest commit

i think they do in private repos, whatever repos they want

then they add when they want deymo or something to review

Yes, that is how github works.

For current version libjxl, -d 1.0 -s 7 and -s 8 will use which p-norm?

it doesn't quite work like that. AFAIU, they both aim to get BA-maxnorm 1.0, but in -s 7 it is more likely it will occasionally get a worse BA score though the p-norm should still be <= 1.0, while in -s 8 it actually does BA-iterations so it should get a BA-maxnorm that is more consistently around 1.0.

But on large target distance(-d 2.5~4+), maxButteraugli can't get good performance on this distance?

I think probably like this(not sure)? -d 0.5~1.9 maxButteraugli -d 1.9~2.5 6-norm? -d 2.5+ 3-norm?

has new modes also more decoding speed for modular?

IIRC no

do you have the original?

this is the best source i found

<https://mma.prnewswire.com/media/1519216/Lockheed_GM_Defense_LunarVehicles.jpg?p=publish>

much higher res

anyway

my JPEG attempt

~20kb

i try this

19 kb AVIF

def looks better than webp

avif is better in crazy small images

i did a jpeg xl one

better

thanks to you

-d 5.5711 -s 7 --use_new_heuristics

is this also jpeg xl

because it looks very the same about what i posted now

This is not bad! avif-like

use resize before encode save a lot off quality

if is bigger why it looks better

did you use speed 9

wrong size

what you did this look absolutely great

i guess is new heuristics because i see blurriness

ok latest try

resized image

what size?

-d 4.6388 -s 9 --use_new_heuristics

that was 480p instead of 832x468

should probably stick to one res if you wanna compare

the avif don't look that much better

-d 4.5

hmm, still beaten by AVIF i'd say

avif is better on stars and cars, jxl on earth, terrain and space suits

but is know that in low quality avif is very good

crixis one looksbanding

and chroma discolouration

mine a bit better but more blockiness

id say is definitely on par with avif

19,6 KB (20.098 byte)

for the jxl

19,0 KB (19.483 byte) for the AVIF

what are the avif settings

speed and quality if there is a min or max quantizer all the two

I used the paint.net plugin

speed "slow" (second slowest)

<https://github.com/0xC0000054/pdn-avif>

how many are the speed in AVIF PAINT.NET

someone has newer builds OF JPEG XL?

with also the improved s 1 s2

i think that needs to be still merged?

does someone has a newer build of JPEG XL?

for what, Windows?

idk, seems alright

yes, sse4 windows 7

Windows 7 is EOL so it will be hard to find anyone producing builds for that

*probably*, but without testing I couldn't say for sure

New windows binary with msvc compiler: e87b769f commit 97 (deleted)

it's not the 0.4 branch? They don't need to write 0.4 release candidate? 🙂

5184 warnings on visual studio 2019 😆

``` INPUT the input can be PNG, PPM, PFM, or PGX ```

Probably because of the 5184 warnings 😄

Built with msys2 ``` v0.3.7-51-gaf6ece2 sse4 - 2021.06.01 cjxl.exe D9DE989DF31B6F6B24B47493A78F9D374A44B94B 6.55 MiB djxl.exe 549DE234D6E266F44EE66595BD3E58641C51B2FB 4.92 MiB ``` https://github.com/eddiezato/eddiezato.github.io/releases/download/bin/jxl-win64.7z

can you link both commits please

i don't undertand, my cjxl.exe works with jpg and png

because maybe you built the one from jon

so the improved speed 2 lossless

Yeah, it works with jpg, but failed with gif 😕

so where a need to modify config file in project?

so i tested this

at q 67.8 s 9 the quality is as good as

for %i in (C:\Users\User\Documents\bn2*.jpg) do cjxl -j -s 6 -q 63.52 --epf=2 -p --gaborish=1 --patches=0 --dots=1 --use_new_heuristics %i %i.jxl

for that particular type of image

i'll make a more comparison

I build with msys2/mingw64. The commands are: ```bash cmake -B build -G Ninja -S ./ -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_DEVTOOLS=ON -DJPEGXL_ENABLE_OPENEXR=OFF -DJPEGXL_ENABLE_SKCMS=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_STATIC=ON -DJPEGXL_WARNINGS_AS_ERRORS=OFF -DCMAKE_CXX_FLAGS='-ffunction-sections -fdata-sections' -DCMAKE_EXE_LINKER_FLAGS='-Wl,--gc-sections -Wl,--no-export-dynamic' .. ninja -C build strip -s build/tools/{cjxl.exe,djxl.exe} ``` I'm not much of an expert on this. I figured out which cmake flags to use by reading `ci.sh` 😄

I just build main branch from github repo with the last commit at the time

i only edit the CMakeSettings.json and look at the cmakelists.txt but i don't see what is wrong. You wright jpeg encoding don't works ^^

See the improvements in medium quality

there are virtually no regressions to new heuristics 12052021

who fixed this?

jon or jyrki?

i tried also

for %i in (C:\Users\User\Documents\gww\*.png) do cjxl -q 98.23493 -s 8 --epf=1 --faster_decoding=5 %i %i.jxl

with 24052021

an older build raysar sent in this server

i do not have the build commit

FOR NEW COMMIT I USED

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

so the eddie zato commit

Ok i need to undestand how to fix that ^^, i hate compile projets 😄 `1> [CMake] -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11") 1> [CMake] -- Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR) 1> [CMake] -- Could NOT find JPEG (missing: JPEG_LIBRARY) (found version "62") 1> [CMake] -- Could NOT find GLUT (missing: GLUT_glut_LIBRARY GLUT_INCLUDE_DIR) 1> [CMake] -- Could NOT find GIF (missing: GIF_LIBRARY) (found suitable version "5.1.4", minimum required is "5") 1> [CMake] -- Could NOT find JPEG (missing: JPEG_LIBRARY) (found version "62") 1> [CMake] -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11") 1> [CMake] -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11") 1> [CMake] -- Could NOT find PNG (missing: PNG_LIBRARY PNG_PNG_INCLUDE_DIR) 1> [CMake] -- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE) 1> [CMake] -- Could NOT find JPEG (missing: JPEG_LIBRARY) (found version "62") 1> [CMake] -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)`

issue closed

<@231086792315633664> I think you need something like jpeg(libjpeg-turbo), zlib (zlib, libzlib), and png(libpng)

And glut/libglut

Just look up each dep online + your distro

it's not with the git --recursive? i'm on windows with visual studio

So zlib ubuntu

If you used ubuntu

Well git recursive is important

But it looks like you're missing libs to me

Compiling full windows. So you know where a need to put all theses libraries?

If you're using windows make sure you're using msys2

I think you can install everything from msys2 with pacman

In msys2 you just need to install all the mingw-versions of these dependencies with pacman

i don't want to use msys2, it could works on visual studio: https://gitlab.com/wg1/jpeg-xl/-/blob/main/doc/developing_in_windows.md

`pacman -Syu && pacman -S mingw-w64-zlib mingw-w64-libpng mingw-w64-libjpeg-turbo`

I think that'll do it

<@231086792315633664> it says what to do right here

Do you think they'd be default in msys2?

Yes i do that. Everything is installed ^^

🤔

Weird

i need to find how to say to cmake where are the lib missing ^^

Maybe adding lines int the cmakesettings.json

Yes i will use docker or msys2 if i don't understand 🙂

At least it forces me to understand how it works.

for what it’s worth, I use msys2 myself

it works very well

Is there a way to write the version number with the commit to the exe when building? e.g., replace `v0.3.7` with `v0.3.7-54-g8ec268b`

Hey I had a question I think I have the answer to but I wanted to make sure. Because vardct uses variable block size that makes lossless cropping like jpegtran-style no longer feasible right?

You can still do it, but it would be at a 256-aligned offset instead of an 8-aligned offset, so not so useful

You can also do reversible cropping though: keep the whole image but change the image dimensions and the frame position to put things outside the canvas.

How to control -m --lossy-palette --palette=x quality? If I set a number on --palette=50000, encoding time will very slow... and if set --palette=0, lossy-palette will only use 1024 colors? > -m -s 9 --lossy-palette --palette=50000 -g 2 -E 3 -I 1 --num_threads=12

At the moment, there is no way to control quality with lossy palette, and it has only been tried with the default palette (which is no signalled palette, only using implicit colors and deltas)

I understand, thank you 🙂

Hello <@!794205442175402004> --lossy-palette --palette=x, x available values is 0 and 1024? I try --palette=20000 and --palette=40000, encoding time will very slow... > -m -s 7 --lossy-palette --palette=20000 --num_threads=12 > -m -s 7 --lossy-palette --palette=40000 --num_threads=12

How can you show the colors of default implicit palette? Is it possible with `jxl_from_tree`?

> --lossy-palette > [modular encoding] quantize to a palette that has fewer entries than would be necessary for perfect preservation; for the time being, it is recommended to set **--palette=0** with this option to use the default palette only I don't think it works correctly with other values than 0, also it is still an experimental option which does not work together with lossy mode and other options

> use a palette if image has at most K colors (default: 1024), so --palette=0 == --palette=1024?

Perhaps (at least it does not make sense to try other values)

But I get different file size on 0 and 1024, > -m -s 7 --lossy-palette --palette=0 --num_threads=12 > -m -s 7 --lossy-palette --palette=1024 --num_threads=12

Maybe it will work in some way, but it is not designed and tuned for that yet, I remember Jyrki once said that there are many ideas for different palette options, but at the moment there is no time for these experiments https://mobile.twitter.com/jyzg/status/1329067794995011585

Not yet, I should add an option for that

No, palette 0 means "have at most 0 colors in the palette"

Lossy palette can still do stuff with a 0-color palette because every palette has implicit colors when you have an out-of-bounds index

Lossy palette would very likely get better results if it were to actually create a custom palette for the image

But for now we only have an encoder for lossless palette, and one for 0-color lossy palette

ok, I understand, thank you <@!794205442175402004> <@!111445179587624960> 🙂 so lossy palette(p0) still a experimental option? can't use on real environment?

Yes, but for some images it can already give quite good results

yes, it is experimental, and it is mostly there for us to know that the implicit (delta)palette entries are actually useful (because that's something that goes in the decoder/spec)

Do you have newer builds

v0.3.7-51-gaf6ece2 sse4 - 2021.06.01

not this

but at least the 55

because i need to make this spidermario test

and he didn't say when it expires

so if you have builds and wb is ok with sharing

you can start now

Fabian, recommendation: install a dual-boot linux distro on your computer and compile it yourself 🙂

yes but with jpeg there wasn't such a need

you opened paint and clicked save

without compiling anything

Or perhaps (after these builds have been enabled) https://github.com/libjxl/libjxl/pull/12

I do not post new builds because there are no major changes, especially in the quality of VarDCT, it is a placebo effect and wrong comparisons when fixing some bugs or changes in Readme.md improve the encoding quality

no quality is better

i see discolouration

and luma noise

in some photos from older encoder

and blurring

still at q 48.6 they look the same

no improvements

with the dilvish build

i used also patch 1 (do not what is)

and the raysar commit (that is the build when petr submitted)

those are obviously not adviced to use

Pretty sure that if in 1991 you would want to experiment with the latest jpeg encoder, you wouldn't just "open paint and click save", but you'd try to find something on usenet or something and try to get it compiled. JPEG XL is currently where JPEG was in 1991: almost standardized, implementations still experimental, mainstream adoption still has to happen

but the better quality is not perceived

for example you take an image like this

and you re encode

it loses yellow saturation

what are you comparing to what?

no is good the dilvish build

i closed the issue

and i posted a zip file in jxl and libjxl

but anyway this is closed don't think anymore about it

right

q 48.6 i used for the nasa photo

the one from Lunar

lockheed martin

it was a jpg and i resized with paint and save as png

for this is improving already on the density compression

17,4 KB (17.843 byte)

no the quality looks pretty good

i'm seeing videos in youtube mp4

try encoding with

-q 69.7376 -s 7 --epf=2 --dots=1 --gaborish=1

shouldn't this go to <#803645746661425173> or <#840831132009365514> ?

so images can be posted in encode params

i didn't know

im not actually really sure how it's different from <#803645746661425173> in what it's supposed to have :P

this kinda seems closer to <#803645746661425173> though

firefox BUG

<#803645746661425173> is a comparison of different options or encoders under some conditions where they can be compared, but this is just encoding with some options

right

now there is the comparison

Hello <@!794205442175402004> I tested some other png lossy color palette implement + jxl lossless, result is very good, A little curious, jxl lossy palette will get some new features in next few month?

It's not a current priority but there is certainly a large potential for encoder improvements in that area, I think.

And other types of non-DCT near-lossless techniques

Modular is a very expressive sub-bitstream, lots of things could be done with it

It's mostly a matter of spending time on encoder improvements, which is currently not the biggest priority since there is still a bunch of other kinds of improvements that need to be done, especially robustness, memory reductions, library api, integrations, etc.

ok, I understand, thank you <@!794205442175402004> 🙂

Hello, i build cjxl with docker and cross compilation (dfc730a8), but it crash with an error missing libgif-7.dll libjpeg-62.dll libpng16.dll So it's not a static build, maybe we need to modify the docker documentation for noob like me. So i modify the CMakeLists.txt `set(JPEGXL_STATIC true CACHE BOOL` and then run `export BUILD_TARGET=x86_64-w64-mingw32 CC=clang-7 CXX=clang++-7` then `./ci.sh release` So there is the last binary working great from now for windows (dfc730a8)

10 747 970 bytes for cjxl.exe, it's big compare to other scope built ^^

I wrote to https://github.com/mozilla/standards-positions/issues/522#issuecomment-853919129

Very interesting read and I agree with all of it (as much as I can not having much hands-on experience). But this argument, which I have seen cited here, may be seen as an excuse for poorer performance of JXL vs. AVIF at low bpps, IMHO: > I observe JPEG XL to have some more tendency to become artefacty before it comes forgetful, and for AVIF to become forgetful first and artefacty later. This may lead into user confusion if cracks and bolts start disappearing rather than user being otherwise informed about bad quality of image transport. I, for one, would enthusiastically welcome JXL improvements in this area. I definitely get the point of the argument. I also tend to prefer **some** artifacts to a plasticky smudge (even aesthetically, never mind ethically!), but I would still choose this AVIF over this JXL without hesitation: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_03_16/index.html#89-vezelay-basilique-2&AVIF-AOM=t&JXL=t&subset1 (or this: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_03_16/index.html#clovisfest&AVIF-AOM=t&JXL=t&subset1) (is this comparator current? is there one that tracks the encoders improvements more closely?)

Also, JXL has improved on low bpp as well (though maybe not between these comparisons, but he had improvements) <https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_04_20/index.html#clovisfest&AVIF-AOM=s&JXL=s&subset1>

Thanks for the URL to newer comparison! (🤦). Strangely, I can see the same JXL (13469b) for Tiny balloons whether it’s 2021_03_16 or 2021_04_20…

Yes, the result was worse in even older comparisons

🤔 <https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_02_15/index.html#clovisfest&AVIF-AOM=s&JXL=t&subset1>

About the improvement on low bpp, it is needed and it is also a problem of better acceptance, a lot of comparisons are going on the lowest bpp (because it is more visual and many people think it is the best method). But about the problem of pleasant looking images at very high compression (when the bitrate is not enough to preserve the original well) I also talked a long time ago and have often encountered it. When there is no choice, yes it is better to have a nicer looking image (even if it is far from original and has lost many details), but often many people start compressing any image extremely strongly, even when it is not necessary and not everyone closely compares result with original, mostly if there are no noticeable artifacts, everything is ok. I know people who compressed their images and photos a lot and were happy about the huge space savings (like they took up 5-8 times less space), while the originals were also often deleted, but until I clearly showed how different they are. Not all people understand how to properly compare and how much they can compress images, and before the advent of video based image formats, Jpeg-like artifacts were a definite stopping factor for that (when they are visible, it means that the compression is too strong) And this is even more true for Web, since there is a huge demand to reduce traffic and with new formats I'm not very happy to get a Web-world with heavily compressed filtered images (not all of them are that necessary, but it's often the case that it's the compressed image that's the maximum quality it has left in history)

In short, let's say a new codec is 50% more efficient than the previous ones, so we can get better quality or even nearly lossless with, say, 20-30% less size? No, most likely we will get 70-80% smaller size with worse quality (but with better artifact hiding and filtering techniques)

Yes i have yes I'm afraid that devs compress more than jpeg because they are blind and happy to reduce server space. I think we need to force people using jxl to read documentation how to smart compress and compare picture before using it.

I don't think a format is driven by an user base

Journalist have a big power to educate users. We need to not miss the moment where jxl become popular.

I think low bbp issue is depend on design intent, av1 encoder is video format, so they focus on how to use limited bitrate create good or okay quality, even lost some detail. jpeg xl encoder is still image format, so they focus on how to keep important detail and have good compression rate, vardct mode is base on butteraugli distance, butteraugli is design for high quality(guetzli and pik), so on low bbp or large butteraugli distance, vardct can't work very well on current version. For low bbp use case, I think can use jxl lossy-palette(without dct), or maybe jxl will implement some lossy filter mode.

Sometimes, let's say DivX/Xvid got acceptance and popularity at one time because of users (although mostly piracy) or FLAC, MKV etc. and only later they had to be supported by other manufacturers/companies And also a lot of formats promoted from above by large companies, but unpopular with users quickly disappeared

I think it's good if a codec allows you to do both of those things (better fidelity while still being smaller, or worse fidelity but same appeal and a lot smaller). I personally don't like using better codecs to reduce fidelity, I think that's a short-sighted approach that values the easy measurable (bytes) too much and the harder to measure (visual fidelity) too little.

Yes, however, I am not against improving visual perception at low bpp, if there is a use for any compression it is good, it would be better than if the encoder allowed to compress to very small sizes, but because of the very low quality it was nowhere to be applied in real use For example there are previews (when there is also a higher quality image) or thumbnails for videos and other things not very important for accurate image preservation I'm more about that people don't always use it correctly and it brings not just only benefits

Has the problem of a malicious JXL been discussed?

What if I made a 500 million pixel wide jxl using jxl from tree

Wouldn't that suck a lot of memory to the point of a crash

Can the decoder know when such an image is being decoded on a machine without enough resources and fail gracefully?

Well, not if you made the decoder so efficient that it barely consumed more RAM than the raw image size <:kekw:808717074305122316>

I can only hope

I mean, it has improved quite a bit.

There was a point where encoding a 200MP image took up 28GB of RAM I think?

Memory usage especially for lossless at max compression is up to 10x the original image size for me

We're now down to 14GB.

Maybe it's more like 5x now, I think I tested it on 0.3.5 or 0.3.6

As far as I know the profile for browsers is limited in resolution, also JXL uses groups/tiles also limited in resolution like 256x256 and up to 1024x1024 for lossless and theoretically if there is not enough memory the next tile just might not decode

That makes it a lot less dangerous

a browser will likely refuse to decode too big stuff

ideally, a 200MP image should just take 800 MB in chrome (one byte per channel)

I believe rn it takes a lot more (7.2gb with djxl I think, if it's more then I need to double check)

it shouldn't be needing to do more than one block at time.. no?

In my case, it takes 1,4GB of view the whole 8b 200MP image

you said 14 before 😛 which is it?

I meant encoding, not decoding.

Sorry.

14GB would be quite scary during decoding <:monkaMega:809252622900789269>

not in *all* cases (progressive images take more, and you still need the DC for VarDCT...) but you also need to store the image itself *somewhere* 😛

that's better xD

is it grayscale or color?

8bpc color.

8b doesn't actually change anything

well, yes, more but not really whole-image kind of more, just some DC and per-block stuff in addition to destination bitmap

I see. I thought native higher bit-depth source would take up more decoding time+memory vs the LBD source.

1.4gb seems a bit too low then - I suspect you get higher peaks during decoding, but not sure

keeping contexts for progressive may be tricky though

You are correct. Total peak seems to be 1,5GB. 1.4GB is the local maximum when the image is zoomed and fully decoded.

nope! we use 32-bit ints/floats everywhere at the moment, the plan is to keep only 32-bit floats/ints group buffers (so 256x256ish per thread per channel), and then a few borders (ideally O(width) or O(height)), and if and only if the image is progressive then 16-bits per channel unless you're doing some weird stuff with very very high bitdepth content

I'd have expected more something like 4.8gb tbh... oh well, better this way xD

I mean, the image itself is VARDCT encoded with speed 7, so it's not exactly the most demanding scenario, right?

On one of the old builds via WIC

ahhh I thought you did lossless

all vardct will, today, just do about 1-1.5 bytes/pixel + the output + some_constant * num_threads

(that first value can be taken down still)

Yeah, I doubt such a highly detailed image at 200MP would only be 6-7MB using modular 😆

I didn't actually look at it 😛

spoiler: I don't actually have a jxl viewer on my personal laptop... (well, there's chrome)

what distance value did you use?

I think I used a distance of 2 a while back to make it fit within Discord's 8MB limits.

Chrome doesn't like it very much xD

Yeah, lossless is kind of special.

Total peak? 4,9GB with that image with modular lossless. Local peak during normal viewing is about 1,5GB.

yup sounds about right

can be improved, but needs work (and I find myself having less and less time xD)

<@!111445179587624960> the windows built i create works on both avx2 and sse4 cpu, why your binary don't do the same? It's not at all practical to share 2 different binaries.

My non-AVX2 build is the same, AVX2 is just compiler optimizations and it runs faster on modern AVX2+ CPUs (but not works on non-AVX2)

jxl plugin doesn't appear on gimp < export

while using latest development version

should i change gimp with the version before

what is right version of gimp

i copied in appdata

now i will check

amazing

i have to install another 1 gb of program

because you didn't say what gimp version i needed

Hmm, I'd recommend to use the latest verstion always (unless you have specific reasons not to).

Can someone shed some more light on the XYB color space used by JPEG XL? how does its transform coding gain from RGB compare to, say, ICtCp? Is there perhaps a white paper explaining the rationale and data behind it? apologies for the random question - there doesn't seem to be much reading material on the topic from googling, apart from its introduction in pik EDIT: RGB to XYB is trivial, as seen in the `RgbToXyb` function over at https://github.com/google/butteraugli/blob/master/butteraugli/butteraugli.h ``` [X] [1 -1 0] [R] [Y] = [1 1 0] [G] [B] [0 0 1] [B] ``` 😑 pretty boring, lol

<@!532010383041363969> is the one who can explain that best

I _think_ it's not hugely different from ICtCp, except it has a different non-linearity that supposedly better models spontaneous cone activation (and the cube root variant which is used in jxl has the computational advantage of being just a cube at the decode side)

Both are based on LMS and aim to model the human visual system.

I'm not sure what the patent situation is on ICtCp, do you know?

I'm not sure if there's a patent situation on ICtCp itself but it's part of HEVC (and HEIC by extension). It's also extremely similar to XYB in that it models the luma and yellow-blue opponent process well, but I was curious to see exactly how the differences play out

ICtCp was made by Dolby and I assume they have patented it (haven't checked though). No idea what kind of licensing model they would have for it, could be royalty-free, royalties for hardware implementations only, I dunno.

Ok thank you. You can say me how to create this optimized binary? You do test to mesure the speed encoding improvement?

`-march=native` for Clang or GCC, for the CPU on which it is compiled, but for public AVX2 builds I use `-march=haswell`, these are relatively optimal optimizations for modern CPUs, both Intel and AMD starting with Ryzen These are old comparisons, but not much has changed since then: <https://www.phoronix.com/scan.php?page=news_item&px=Haswell-vs-Znver1-GCC-5>

JXL can be ~5-8% faster depending on encoding modes and options, not a huge increase, but my encoding can take weeks or months and it's a noticeable difference

`-O3`, `PGO LTO` options can also give a boost and -O3/LTO are CPU-independent (but for Windows I cannot compile with PGO and LTO for some reason)

Ok thank you 🙂, if i want to add this option in the ci.sh where i can put this? <:FeelsReadingMan:808827102278451241>

It is better not to change ci.sh, but do something like this: https://discord.com/channels/794206087879852103/803663417881395200/835686632946270229

Yep

That's why I compiled several binary builds, for AVX2+ CPUs with better optimization and for older ones without AVX2 support and that was initially an answer to why I do not make only one build https://discord.com/channels/794206087879852103/794206170445119489/850184330465640480

at least in theory, with dynamic dispatch, AVX2+ builds shouldn't be significantly faster than non-avx2 builds...

Yep, but in practice there is a difference, even x264 gets better results on some CPUs, given that it has a lot of hand-written optimized asm code

I mean, we compile the "hot" functions for no avx, avx2, avx512 too already

yup

Maybe the compilers do some other optimizations or does them more correctly when the old CPUs are "dropped"

with -march=haswell etc *everything* gets optimized using haswell instructions, not just the specific ones the code is designed to have dispatched versions of

yes, might make a small difference since the not-hot functions also contribute something

also for modular encoding, there's quite a bit of stuff that hasn't been parallelized or SIMD'ed at all yet, and maybe the compiler can do a bit of optimization there (well it's not going to parallelize it but it might SIMDify some things)

(with wider SIMD than with a generic cpu target, I mean)

yes, modular likely gets the most benefits

My jpeg xl art become viral

15449 views

15957

thank you 🙂 `export BUILD_TARGET=x86_64-w64-mingw32 CC=clang-7 CXX=clang++-7 cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-O3 -march=haswell" -DCMAKE_C_FLAGS="-O3 -march=haswell" -DJPEGXL_ENABLE_SJPEG=ON -DJPEGXL_STATIC=1 cmake --build . -- -j 16` On the docker linux i have many segmentation fault ^^ ||`third_party/highway/CMakeFiles/targets_test.dir/build.make:98: recipe for target 'third_party/highway/tests/targets_test' failed make[2]: *** [third_party/highway/tests/targets_test] Error 1 make[2]: *** Deleting file 'third_party/highway/tests/targets_test' CMakeFiles/Makefile2:1484: recipe for target 'third_party/highway/CMakeFiles/targets_test.dir/all' failed make[1]: *** [third_party/highway/CMakeFiles/targets_test.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... [ 37%] Building CXX object lib/CMakeFiles/jxl_dec-obj.dir/jxl/epf.cc.o [ 38%] Building CXX object lib/CMakeFiles/jxl_enc-obj.dir/jxl/jpeg/enc_jpeg_data.cc.o [ 38%] Building CXX object lib/CMakeFiles/jxl_enc-obj.dir/jxl/jpeg/enc_jpeg_data_reader.cc.o [ 38%] Building CXX object lib/CMakeFiles/jxl_dec-obj.dir/jxl/fields.cc.o [ 39%] Building CXX object lib/CMakeFiles/jxl_dec-obj.dir/jxl/filters.cc.o [ 39%] Linking CXX executable tests/aligned_allocator_test ../../lib/libgtest.a(gtest-all.cc.o): In function `testing::internal::StreamingListener::SocketWriter::MakeConnection()': gtest-all.cc:(.text+0x1edda): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking [ 39%] Building CXX object lib/CMakeFiles/jxl_enc-obj.dir/jxl/jpeg/enc_jpeg_huffman_decode.cc.o CMake Error at /usr/share/cmake-3.10/Modules/GoogleTestAddTests.cmake:39 (message): Error running test executable. Path: '/jpeg-xl/libjxl/build/third_party/highway/tests/aligned_allocator_test' Result: Segmentation fault Output:`||

Maybe disabling tests will help, but I have not tried compiling in the docker, I use MSYS2 `-DBUILD_TESTING=OFF -DJPEGXL_WARNINGS_AS_ERRORS=OFF`

Also tested. I will do some other tests with a clean docker ^^ ||`/usr/bin/ld: cannot find -lpkgcfg_lib_OpenEXR_Imath-NOTFOUND /usr/bin/ld: cannot find -lpkgcfg_lib_OpenEXR_Half-NOTFOUND ... etc clang: error: linker command failed with exit code 1 (use -v to see invocation) /usr/bin/ld: cannot find -lpkgcfg_lib_OpenEXR_Imath-NOTFOUND tools/CMakeFiles/benchmark_xl.dir/build.make:454: recipe for target 'tools/benchmark_xl' failed make[2]: *** [tools/benchmark_xl] Error 1 /usr/bin/ld: cannot find -lpkgcfg_lib_OpenEXR_Half-NOTFOUND /usr/bin/ldCMakeFiles/Makefile2:1405: recipe for target 'tools/CMakeFiles/benchmark_xl.dir/all' failed : cannot find -lpkgcfg_lib_OpenEXR_Iex-NOTFOUNDmake[1]: *** [tools/CMakeFiles/benchmark_xl.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... /usr/bin/ld: cannot find -lpkgcfg_lib_OpenEXR_IexMath-NOTFOUND /usr/bin/ld: cannot find -lpkgcfg_lib_OpenEXR_IlmThread-NOTFOUND clang: error: linker command failed with exit code 1 (use -v to see invocation) tools/CMakeFiles/djxl.dir/build.make:141: recipe for target 'tools/djxl' failed make[2]: *** [tools/djxl] Error 1 CMakeFiles/Makefile2:1357: recipe for target 'tools/CMakeFiles/djxl.dir/all' failed make[1]: *** [tools/CMakeFiles/djxl.dir/all] Error 2 clang: error: linker command failed with exit code 1 (use -v to see invocation) tools/CMakeFiles/cjxl.dir/build.make:115: recipe for target 'tools/cjxl' failed make[2]: *** [tools/cjxl] Error 1 CMakeFiles/Makefile2:1261: recipe for target 'tools/CMakeFiles/cjxl.dir/all' failed make[1]: *** [tools/CMakeFiles/cjxl.dir/all] Error 2 Makefile:140: recipe for target 'all' failed make: *** [all] Error 2`||

This type of projet is a litle bit complex for me 😄

🤔 `-DJPEGXL_ENABLE_OPENEXR=OFF`

Hello <@!111445179587624960>, I add -O3 -march=haswell to my cmake command, > -DCMAKE_CXX_FLAGS="-O3 -march=haswell" -DCMAKE_C_FLAGS="-O3 -march=haswell" \ But look like I lost some SSE4 optimize? > JPEG XL encoder v0.3.7 [AVX2] > cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF \ > -DJPEGXL_ENABLE_DEVTOOLS=ON \ > -DCMAKE_CXX_FLAGS="-O3 -march=haswell" -DCMAKE_C_FLAGS="-O3 -march=haswell" \ > -DCMAKE_C_COMPILER=clang.exe -DCMAKE_CXX_COMPILER=clang++.exe -G Ninja .. > cmake --build . -- -j$(nproc) > ryzen 1600, windows-10-x64-msys2-mingw64

You don't need sse4 if you have avx2

That is, avx2 is a superset of sse4

without Scalar optimize still fine?

my old build will display like this > SIMD supported: AVX2,SSE4,Scalar

I get only avx2 when march=native

with theeses optimisation it's impossible to execute this binary on non avx2 cpu.

So if cpu support avx2, JPEG XL encoder v0.3.7 [AVX2] is grest, if cpu unsupport avx2, will need SSE4 and Scalar optimize?