JPEG XL

https://artifacts.lucaversari.it/libjxl/libjxl/2022-11-08T12%3A51%3A53Z_0d5f6450f6be84cf550f0a6ede8a297447a0565a/

i copied 21 files

all the executable as someone said

in pictures/q

show output File

I can't open the computer, at the moment

then can you describe what was art there?

Screenshot of a video

YouTube

Neomelodico

Size 3,5mb

Original jpg 6,2mb

It saturated my RAM

And was slow to encode

Like One minute and ten

First time at 99%

<@416586441058025472> what it has to do with the fact that I need to look at the boundaries of the VarDCT Blocks

I don't know how to use benchmark XL

Tool

Of the images i used it didn't changed colours

But i didn't used backgrounds

You can report to jon on GitHub

<:SadCheems:890866831047417898>

And you say you used benchmark xl

It works

I get an identical image but with a broken color profile

I didn't open on xnviewmp but on Windows photo viewer on Windows 7

No problem

Only a background in the black borders

With pinky tones

But image display good

I don't understand at all How this can allow me to see the VarDCT

It uses iccv4

Color profile

<@416586441058025472>I don't understand How this can allow me to see the VarDCT

I encoded a normal image

And posted the screenshot of powershell

Go in <#794206170445119489>

Hello <@226977230121598977> Sorry to bother you, This nonphoto content sample(white blank) is very interesting, I test this sample on libjxl v0.6.0 229f574(nonphoto_separation branch) and libavif aom [enc/dec]:3.2.0-143-gf20d487e3, Look like libjxl nonphoto_separation experiment feature is very useful on this case. > base png 202 > jxl > d 0.1 e 9 211(separate=1) > d 0.1 e 3 200(separate=1) > d 0.5 e 9 211(separate=1) > d 0.5 e 7 388(separate=1) > d 1.0 e 9 207(separate=1) > d 1.0 e 7 374(separate=1) > d 12 e 7 379(separate=1) > > avif > cq-level 7 317 > cq-level 15 321 > avifenc --min 0 --max 63 -s 4 -j 12 -d 10 -a end-usage=q -a cq-level=7 I still look forward libjxl lossy can implement more improvement and feature for nonphoto content 🙂

ehh

<@461421345302118401> https://discord.com/channels/794206087879852103/794206087879852106/1038861311964098641 It's the second day I've been trying to figure out how to do this. can you help?

I haven't use benchmark_xl before, look like I get same error on my windows 10 system. > speed_stats.GetSummary

I have exactly the same error

<@532010383041363969>

<@853026420792360980>

benchmark_xl on Windows not work command --debug_image_dir and --save_decompressed

it's a known but that I already reported

You on linux?

I am, but the bug is cross-platform

`--save_decompressed` doesn't work

oh no

https://github.com/libjxl/libjxl/issues/1872

oohhh I absolutely can't get a grid of VarDCT blocks at the moment

well so and so

You do not need `--save_decompressed` for `benchmark_xl` to generate the `ac_strategy.png` files. It will work with just `--input` and `--debug_image_dir` (and in your case `--codec`, because you want to change the encoder speed preset). So, assuming you have a debug build of `benchmark_xl` and Graphviz tools in your PATH (`benchmark_xl` depends on Graphviz), you can try something like this: ``` $ ./benchmark_xl --input=/tmp/jxl/orig/white.png --codec=jxl:lighting,jxl:thunder:jxl:falcon,jxl:cheetach,jxl:hare,jxl:wombat,jxl:squirrel,jxl:kitten,jxl:tortoise --debug_image_dir=/tmp/jxl/debug ```

This is what I get after running this command:

After `benchmark_xl` finishes, the `ac_strategy.png` files should be in sub-folders of the `--debug_image_dir` you specified.

The `convert` tool mentioned earlier is part of ImageMagick and would be needed for overlaying the original image with `ac_strategy.png`, which in case of your pure-white image is definitely not needed.

the latest head improved jpeg1 coding further by 2 %

```C:\Users\a\Desktop\jxl-x64-windows-static-1>benchmark_xl --input=13.png --codec=jxl:lighting,jxl:thunder:jxl:falcon,jxl:cheetach,jxl:hare,jxl:wombat,jxl:squirrel,jxl:kitten,jxl:tortoise --debug_image_dir=. benchmark_xl v0.8.0 6f8cd1b [Unknown] D:\a\libjxl\libjxl\tools\benchmark\benchmark_codec.cc:52: JXL_ABORT: Invalid parameter lighting```

I'm already tired, you all write me something and Nothing works for me

<@865952699433484298> you can *just do it* for these 3 image and send the results here. https://discord.com/channels/794206087879852103/794206087879852106/1038860533325103165

maybe make a separate encoder for xyb, because I noticed that there is a cjpeg_hdr or combine hdr and xyb jpeg into one encoder?

i also worry that chrome might find reasons not to accept the improved jpeg decoder as well, because it will be slower than libjpeg-turbo (and quality improvement is not a priority over speed) and because its newer and this lib has not been in production as long as libjpeg-turbo, so there are higher vulnerability risks

yes, xyb should be a flag in a jpeg1 encoder -- too many systems fail with ICCv4

I have some positive signals from them for JPEG1 improvements, so I am hopeful -- but yes, it needs to be technically and by user experience comparable In chrome they allow for experiments, so if there are subtle considerations, it can be first place behind a flag and the impact can be explored It will still be like 5x faster than AVIF and 2x faster than WebP, so it shouldn't be disruptive for user experience

can someone just DO IT, the unhappy 3 pictures

if all coefficients are zeros, they all pack very efficiently -- thus the ideal coding uses only 8x8 dct and all AC coeffs zeros a more advanced coding might use 32x32 or 64x64s and then at the border use smaller transforms, they might insert an image for filter control and adaptive quantization -- but then not use it for the image you use because it is just flat

it is I who want to look at the structure of the blocks!

print it out in enc_ac_strategy.cc ?

<@532010383041363969>

also true, I never used that, just statistics and debug prints of ac strategy 🙂

--more_columns might also help -- it can print statistics on dct use

<@532010383041363969>you suggest something but I don't even want to try it, nothing works

not work

It's lightNing

What???

```C:\Users\a\Desktop\jxl-x64-windows-static-1>benchmark_xl --input=13.png --codec=jxl:lightning,jxl:thunder:jxl:falcon,jxl:cheetach,jxl:hare,jxl:wombat,jxl:squirrel,jxl:kitten,jxl:tortoise --debug_image_dir=. benchmark_xl v0.8.0 6f8cd1b [Unknown] **D:\a\libjxl\libjxl\tools\benchmark\benchmark_codec.cc:52: JXL_ABORT: Invalid parameter jxl** ```

Maybe you can already tell me what to do, I haven't been able to achieve anything for the third day <@794205442175402004>

```speed_stats.GetSummary(&summary)``` Error on WIndows on builds over the past YEAR

i check benchmark_xl v0.7.0 09e08f8

same

benchmark_xl v0.7.0 3aaae25 same

```benchmark_xl --input=13.png --codec=jxl:lightning,jxl:thunder,jxl:falcon,jxl:cheetach,jxl:hare,jxl:wombat,jxl:squirrel,jxl:kitten,jxl:tortoise --debug_image_dir=. ```

You had a : instead of ,

```C:\Users\a\Desktop\jxl-x64-windows-static-1>benchmark_xl --input=13.png --codec=jxl:lightning,jxl:thunder,jxl:falcon,jxl:cheetach,jxl:hare,jxl:wombat,jxl:squirrel,jxl:kitten,jxl:tortoise --debug_image_dir=. benchmark_xl v0.8.0 6f8cd1b [Unknown] 4 total threads, 9 tasks, 4 threads, 0 inner threads Error in jxl:lightning codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:143: JXL_CHECK: speed_stats.GetSummary(&summary) Error in jxl:thunder codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:143: JXL_CHECK: speed_stats.GetSummary(&summary) Error in jxl:cheetach codec Error in jxl:falcon codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:143: JXL_CHECK: speed_stats.GetSummary(&summary) D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:143: JXL_CHECK: speed_stats.GetSummary(&summary)```

Build Two Year Ago ```C:\Users\a\Desktop\jxl-x64-windows-static-2>benchmark_xl --input=13.png --codec=jxl:lightning,jxl:thunder,jxl:falcon,jxl:cheetach,jxl:hare,jxl:wombat,jxl:squirrel,jxl:kitten,jxl:tortoise --debug_image_dir=. benchmark_xl v0.7.0 28a26e6 [Scalar] 4 cores, 9 tasks, 4 threads, 0 inner threads Error in jxl:cheetach codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:133: JXL_CHECK: speed_stats.GetSummary(&summary) Error in jxl:lightning codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:133: JXL_CHECK: speed_stats.GetSummary(&summary) Error in jxl:falcon codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:133: JXL_CHECK: speed_stats.GetSummary(&summary) Error in jxl:thunder codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:133: JXL_CHECK: speed_stats.GetSummary(&summary)```

my Linux freind

why did it work for you?

I use exactly the same thing, and I gave my friend on linux exactly the same thing, but nothing works for both of us

Thanks a lot, I've been waiting for this for a long time

zsh yes

I want to say that it ... shit

and no, bash doesn't work either

<@456226577798135808>he also tried to compile the build himself, and it doesn't work either

That's weird, that stuff should normally not be compiled in

It's a debug thing to make a visualization of the MA tree

Installing `dot` would help, but it shouldn't be trying to call it in the first place

__jxl executes the command via system for some reason__ sh: line 1, dot: command not found

ahhah really bruh

<@794205442175402004><@456226577798135808><@532010383041363969> <@268284145820631040> <@853026420792360980> *I just for fun placed the dot file near to the program Inside it is the sh command: echo HELLO GUYS As a result, it started and even did something I have questions for the developers* *1. Why jxl use external commands in it's code? 2. Why dependency is not linked as library? 3. Just why?*

https://github.com/libjxl/libjxl/blob/c391c17397d18845ea5e1b0e4b2ff997424514d4/lib/jxl/modular/encoding/enc_debug_tree.cc#L118

that system call is behind a `#if JXL_ENABLE_DOT`, how did that get defined?

oh it gets defined for everything except iOS, what

*benchmark_xl was compiled on my machine benchmark_xl2 was downloaded as static program*

oh but that function only gets called if kPrintTree is true, which is never the case

https://github.com/libjxl/libjxl/blob/5fef3ec57452f2865a62c0e01cdcf3635f09b920/lib/jxl/modular/encoding/enc_encoding.cc#L41

it's funny that it's Modular code even though I don't even use it

everything uses modular code, VarDCT uses it for the DC and control fields

anyway it looks like you somehow have a build where someone changed kPrintTree

this error has been in at least all builds for 2 years now

no libjxl does not use this at all, this is just some debug instrumentation that should not end up in libjxl nor in benchmark_xl

I'm not a libjxl dev, btw

you're dev of what?

I wrote the FFmpeg plugin for libjxl, and I'm working on my own standalone decoder.

I called you because you participated in the topic, maybe you are interested.

that's fair. but in this case I have no idea lol

oh wait what

https://github.com/libjxl/libjxl/blob/83944e4b8d389d27e3851a85403f4045ecd53015/lib/jxl/enc_modular.cc#L1093

that call is not guarded by a compile-time `false`, so in the benchmark_xl case it does actually get compiled in

good catch, <@226977230121598977> !

<:BlobYay:806132268186861619>

https://github.com/libjxl/libjxl/pull/1881

libjxl-tiny doesn't use modular -- so it is a possibility not to use it

So tiny has no lossless?

no lossless, it is a model implementation for HW that could be put into cameras

<:FeelsReadingMan:808827102278451241> wh

I thought tiny was supposed to be good for shipping as a wasm shim until browsers support jxl

Jpeg XL can lossless use VarDCT?

-d 0.0000000~

well, technically, my example with a white sheet proves that lossless is possible

well well

well.

I would guess it's similar to setting jpg to 100% quality. Not lossless, but as close as you're gonna get.

now everything is clear

the fact is that the codec creates functions. for transformations and subsequent compression. And as I understand it, the chances of using certain functions depend on the quality, for some reason

And now I finally understand what they are

whoooa

Quality or speed?

jxl:squirrel:d5.0

e7

no way! d0.1 and d5.0 functions is identifical

But then why does it weigh 25 bytes more

what? why is that? why is there a difference? what does it count that?

bt_diffmap

I don't know what it is

but that's, problem

<@794205442175402004> don't know what's the ? for some reason, there is a different method for different qualities, and the more quality is set, the better the compression comes out

dot in corner

Technically, it does, for encoding DC and dctselect and quantweights, it just does it in an fjxl-style way where it only uses a tiny subset of what modular can do, with fixed MA trees etc

What's your input image and encode settings?

my classic jxl:tortoise:d0.1 jxl:tortoise:d5.0

it also turns out that at squirrel speed formulas are built so inefficiently that the Size of the file turns out to be 3 times more than tortoise and 2 times more than lightning

tortoise (speed 9) doesn't have much testing

anything can happen

but now I want to understand why In all cases, if the same speed parameter is applied to this picture, but Different quality - the size is always different

I'd use speed 7 -- perhaps consider speed 8 (which is also mostly untested but less aggressive, so less things can go very silly)

let's look at the speed 1

very simple

Identical blocks, identical formulas - size difference of 6 bytes

identical

jxl:lightning:d0.1 183 byte jxl:lightning:d5.0 177 byte

because what?

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

jxl:squirrel:d0.1 2**8**5 byte jxl:squirrel:d5.0 2**6**5 byte difference of 20 bytes all debug output is identical (I'm hash of the all output)

<:JXL:805850130203934781> <:Thonk:805904896879493180>

quantization factors will be different, they're not in the debug output

but why are they different with exactly the identical output

it's like an 8-bit png being smaller than a 16-bit png even if the pixel values are identical

I wanted to say that this is a bug of rounding coefficients... but there is nothing... only White in the image

in general, this is not a tangible problem, but it is there.

it's too much of a special case to be worth detecting and optimizing it — it only applies to cases where doing more aggressive quantization happens to produce the exact same image, which can happen for single-color images but in general it will nearly never happen

and yet this is a very strange instability

Jon, perhaps we can learn something from it

I am sure that this can be done with much more colored if you draw on the borders of the blocks. Well, because of this, it can be noticeable on enlarged pixel-arts

I am just afraid that right now we don't have capacity to look into this -- Wasm implementation and faster 16-bit lossless encoding are our top-most priorities now

I think there is a good chance that every weirdness has a possibility to reveal an optimization possibility

we should carefully record this into our bugs and come back to this in about 12 months

I haven't said the funniest thing yet

compression of this image by the VarDCT method is **20 **bytes less than Modular

Encoding [Modular, lossless, effort: 9], Compressed to 130 bytes (0.002 bpp). Encoding [VarDCT, d25.000, effort: 9], Compressed to 110 bytes (0.002 bpp).

$ cjxl 13.png 13.png.jxl -d 0 -g 3 JPEG XL encoder v0.8.0 [SSE4,SSSE3,Emu128] Read 800x600 image, 202 bytes, 340.3 MP/s Encoding [Modular, lossless, effort: 7], Compressed to 53 bytes (0.001 bpp). 800 x 600, 1.63 MP/s [1.63, 1.63], 1 reps, 4 threads.

default group size makes it 12 groups, -g 3 makes it a single group

-g -1 == default --- default is how much

default is -g 1, which is 256x256 groups

12 ok

-g 0 is 128x128 groups, -g 2 is 512x512 groups, -g 3 is 1024x1024 groups

54 bytes if e 9

yeah, that kind of thing can happen

heuristics are just heuristics, not everything can be estimated perfectly especially not to the byte

eh, and how to get this in libjxl ...

I found new bug, with the parameters --modular_palette_colors=0 -P 15, a giant file is created, if you manually write -P 0, then everything is fine

Strange...

Last Build on Windows ```benchmark_xl --input=13.png --codec=jxl:lightning --debug_image_dir=. benchmark_xl v0.8.0 cdf0332 [Unknown] 4 total threads, 1 tasks, 0 threads, 4 inner threads Error in jxl:lightning codec D:\a\libjxl\libjxl\tools\benchmark\benchmark_xl.cc:143: JXL_CHECK: speed_stats.GetSummary(&summary)```

the same error as it was

<@794205442175402004> is there any comparison for this new jpeg encoder and decoder for these metrics? <https://jon-cld.s3.amazonaws.com/test/index.html> or could it indirectly interfere with the jxl adoption, since the difference between the old jpeg may become less noticeable?

Look like something happened on e5~e7? or separate feature affect heuristic? > d0.5-e3 199 > d0.5-e4 235 > d0.5-e5 308 > d0.5-e6 308 > d0.5-e7 388 > d0.5-e8 212 > d0.5-e9 211 > > -d 0.5 -e 3~9 --separate=1 --num_threads=12 > JPEG XL encoder v0.6.0 229f574 (nonphoto_separation branch) > input white blank, nonphoto content Probably can do some simple palette sort and fast DCT(use target distance) to help heuristic decide apply which lossy algorithm is suitable input pixel? > fast DCT:true, palette sort:true > fast DCT:true, palette sort:False > apply varDCT > > fast DCT:False, palette sort:true > apply lossy palette > > fast DCT:False, palette sort:False > apply lossless > > fast DCT:False, palette sort:False and input format is jpeg > apply jpeg lossless

I don't understand too

<@461421345302118401>there is a small answer here, and it also says below that this is not a particularly important bug right now https://discord.com/channels/794206087879852103/794206087879852106/1039936369436393613

perhaps it will be necessary to create a more complex and color picture so that it would be much more revealing to demonstrate this bug, but so far I'm already tired

> 12 months oh no... I thought current encoder is really great for photo content, I just hope encoder can get more quality improve and feature for nonphoto content. Better encoder heuristic can handle different type content, and increase encoder robustness for random input image.

unfortunately, we are not high-class programmers.... I mean, the source code is open. And you can do code improvements whenever you want.

interesting between q4 and q5

on 1 bit image

Is there recommendations for public reading material on jpeg XL beside the reference implementation?

distances >=20 (less than around q 4.68) have --resampling=2 by default

You mean technical details or high-level?

Probably middle level. Mostly so I know what I am looking at when going into the code. This is only for hobby stuff so I don't want to spend to mutch time figuring out what's going on

Or I wait until there are more writeups or the ISO/ DIN is available in my local catalog

Tricky

You can find spec drafts in this discord

a new day -- new problems of encoder characteristic

look at my new test picture

I'll start with the strongest

Oh ya thank you

fact that e1 size 7 times less, it is an actual LossLess. while the e7 at its size is Lossy

in XOR it's noticeable

I also want to say that the last build did not fix the errors on windows that were with the benchmark

and e9 made it even worse

resample=8 shows a completely different result than I expected

and here is the difference in quality between e1 and e9 at the same size. e9 is blur, and I don't understand why he and e7 do it the same way. It's a disaster for pixel art. Okay, this is just a criticism of VarDCT. Modular still works great

We need some heuristics to avoid doing vardct by default on images like pixel art where dct is a bad idea and modular will work better. Challenge is to do this in a way that doesn't cause surprises, because it introduces a big discontinuity in encoder behavior depending on image content (changing one pixel could lead to a completely different encode mode getting used).

there could at least be a heuristic for single color images

Yes, I guess. Feels a bit niche, but considering e.g. layered images, it might be relatively common...

you really need the mode of determining which image is in the frame... perhaps to do this, you just need to do 2 compressions VarDCT (on q100) and Modular at e1 speed and then select the mode that size less

https://twitter.com/sketchplanator/status/1590344714360082432?t=xxYdvCo5cnVJJAI0owQCmQ&s=19

Applies to image quality assessment too

Remember when a common criticism of open codecs was "since they don't have money, they rely on objective metrics, which results in worse quality than our proprietary and well funded stuff which relies on mass subjective testing"?

somewhat relevant

also https://www.discovermagazine.com/the-sciences/why-scientific-studies-are-so-often-wrong-the-streetlight-effect but I think I have already linked it in the past

(“Understanding Psychology as a Science”, 2008, Zoltan Dienes)

(another writing I have greatly enjoyed from that author is https://www.researchgate.net/publication/228711807_Bayesian_Versus_Orthodox_Statistics_Which_Side_Are_You_On )

psychology and politics start dominating all entities composed of humans if these entities get large enough. true objectiveness and intellectual motivation are already pretty scarce in general population, and they get easily lost / filtered out in bureaucratic megastructures

<:KekDog:805390049033191445> <:KekDog:805390049033191445> <:KekDog:805390049033191445>

Bro, when introducing a new standard from the likes of MPEG, they always use objective metrics like PSNR and SSIM <:KekDog:805390049033191445>

Yeah. I just remember seeing an mpeg person like, 7 years ago on HN explaining why Google's VPx codecs will always be worse than their codecs 😂

might have been an x264 author

I think I remember that post

it made some good points

Oh, shikari was mainly complaining about poor encoder design philosophies.

I specifically remember someone singling out open source projects

Thank you for your reply, It is really sad, I think I don't have enough encoder development skill to improvement nonphoto content quality and feature. Current libjxl is really great, but I guess I need find another way to process my nonphoto content.

and what kind of content do you have?

2d Art(pixiv), manga, comic, For some source, I want use slight filter and use lossy encoder save result.

avif speed 1-3 for all. webp q80-q90 for manga (if there is a lot of it, but if there is not lot then also AVIF)

I understand mathematically lossless is best for non photo content, but I prefer lossy but visual lossless or near lossless plan. (tiny error is acceptable)

I test libavif before, av1 CDEF have some benefit for non photo content, libjxl butteraugli is great for some type 2d art(non photo content).

if we talk about lossless mode only, then there is nothing better than jpeg xl

Agree

I like webp near lossless(60 or 40) lossy mode, so I still want to find a newer lossy encoder, quality near webp near lossless and higher density.

webp is not so good anymore... if anything, the new terminal versions have an **experimental **automatic filter adjustment function, it also makes the quality a little better

I tried it, it really smooths artifacts better, and removes unnecessary smoothing more cleverly, but coding takes about 2 times longer

There's a few near-lossless approaches that could be tried in modular

the difference between e6 and e7 looks funny

artsy

I've passed 1000 lines of code in my jxl decoder

how many structures can it parse yet

I'm almost done with the frame header

pro tip: how to pad your loc metrics to avoid elon firing u ```rust set!( r, self.encoding == FrameEncoding::Modular, Un(2), self.group_size_shift, u8 ); ```

Alright, FreamHeader finished, time for sleep

jpeg xl "E 6" turned out to be the best of the fastest compression methods, I'm happy to compress 700 thousand images

q 70 i use

https://crowd-jpeg.vercel.app/ "each visit to the page deteriorates the main image"

which made into the HN front page just right now and the visit counter is skyrocketing

is the video of this comparison on YouTube

someone has windows build of libjxl-tiny ?

is a virus on windows 7

if you want to download the only site is doom9 alternative jpg codecs

in new and alternative codecs section

but link is too old 2 months ago and in sendspace

it's amazing that he was there, thank you. but still there are problems with his Linux, he doesn't understand PNG or BMP. just like that on windows it will be possible to use it not without problems

cjxl_tiny.exe

AH! my friend outrun me by 5 minutes, and compiled it too (last build)

for some reason, the executable file turned out to be 3 times smaller (MSVC vs MinGW)

yes, I don't understand why it was impossible to put some kind of TINY PNG decoder

ppm not work

pfm only...well

I have a lot of software... but none can create a pfm file

Imagemagick can

`convert image.png -colorspace RGB input-for-libjxl-tiny.pfm`

I don't like Imagemagick

anyone more?

Gimp?

You can also use cjxl/djxl to produce a pfm

<:SadCheems:890866831047417898>

Yes

I did this

It would be very nice if in libjxl-tiny... and in standart libjxl was introduced the microscopic QOI

Gimp cannot handle pfm produced by djxl, the levels are all wrong like if they were shifted/truncated. Gimp also refuses to read pam files at all.

<:PepeSadCatGun:973222795150508082>

I get photoshop 2007. converted it to 32 bits, then saved it to .PFM. then compressed it. In Photoshop, the PFM file is displayed well, but cjxl-tiny has lost colors, brightness, And in addition mirrored the image

mirroring is photoshop problem, but the problem with colors is completely identical

Pfm has no colorspace info, libjxl-tiny expects linear, others will interpret it as sRGB

you gave me a command for Imagemagick, and it turns out it doesn't work, and photoshop too. In this case, I don't understand how I can get the PFM file Correctly to compress it via libjxl-tiny

Do you have a tagged png as input? If it is untagged, then you need to do something like `convert image.png -colorspace sRGB -colorspace RGB input.pfm` iirc

Also, to decode the jxl you need something like this: `djxl compressed.jxl decompressed.png --bits_per_sample 16 --color_space RGB_D65_SRG_Per_SRG`

not work too

How do you view the jxl file you get?

firefox and PaintDotNet is same

This gives the correct result. But now I have a question - why should I do this?

the decoder cannot decode correctly by default, it's the problem

returning to the topic of libjxl-tiny, there are artifacts like libjxl e5+ so some function also deteriorate images.. I wanted to do testing to find out how TINY would be worse than libjxl e 3. But now I won't do this because I'm not comparing photos, but this pictures, and at the very beginning already lost... I do not know which specific function is responsible for such artifacts... I just seemed to me that libjxl-tiny technology would be somewhere between libjxl e1-e3. in the beginning, I was wary when I saw 8x16 variable blocks in the description. But now it's clear to me that libjxl-tiny is all technology but little bit.

It would be better if djxl would do that by default, I agree. The issue is not in the decode, it is in the png writing...

Lol what

ol good velocidensity meme

I can't imagine it's anything but a troll

Everyone on 4chan is a troll

it kinda works though because encoders used to be worse back then and people were younger & less picky

it's like you'd often remember stuff sounding better than it actually will nowadays

it's a common meme yea

this image gains 0.05 butteraugli every time it's reposted

but what about my convergent jxl generation loss

what is mm?

I believe "mm" is for "minus-minus", for `--`

^ it's this, yes

once it finds `--` it stops parsing arguments and treats everything after that as a filename

now, `-` is officially a "hyphen-minus" (the official Unicode name), and also colloquially called a dash 😉

nah, a hyphen and a dash are different

there are many dash-like things: en-dash –, em-dash —, minus sign −, figure dash ‒, and the hyphen-minus from ASCII/Unicode -, to name a few

but I always pronounce `--help` and the like as "minus minus help"

when reading it out loud

and that's why I called it `foundMM`

I'd say dash dash help 🙂

...---... call for help.

._.

What the actual fuck? <:KekDog:805390049033191445> Bro, I got native AVIF support out of the box with KDE <:kekw:808717074305122316>

sounds like a classic consumer of proprietary software

"It doesn't work. Fix it."

These 3 plugins does not have enough information or guide to install them on mac/windows. proper documentation of installation or an installer is needed. it should be easier for an average computer user to install these plugins. they don't know about compiling software from GitHub.

for average user, github is not a familiar website. mostly they don;t need source code. it would be better if there is page for installing these plugins.

Would it be easier if there is an installer.exe and uninstaller for this purpose? many people don't touch windows terminal.

Does it cost some money for signing?

still it is better to have some installer even if it is unsigned and it triggers the antivirus.

https://wixtoolset.org/ may be this will work.

this is probably one of the funnier twitter interactions i have seen in the mess it's in right now

*sneaking jxl into a tweet quote for more visibility by also mentioning avif*

Not able to find anything like that, just Intel vs AMD... and all those statistics are from either self-done benchmarks or Steam -- so those stats are likely focused on the high-end & gamer markets. Typical Joe isn't going to be running benchmarks and may not be using Steam.

Granted, AVX2 goes back to 2013 processors. I would say stick with that. Usage of processors with just AVX are likely a fairly small %.

I think it'd make sense to follow the x86 microarchitecture levels, https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level

That groups AVX/AVX2 together into the same tier

i have a laptop which can do AVX but not AVX2

avx2 is haswell and later, sandy bridge and ivy bridge were very popular

Except they haven't actually built it yet. Looks like they are putting everything on v2 which doesn't appear to even have AVX support yet.

That was just a page I found talking about them, GCC/Clang have supported them for a couple of years

jxl larger than png and webp

What about -e 9?

31.4k. still I think it should compress it better than webp by default settings.

it's mostly that we need to improve lossless encoder heuristics for such cases

on compiling fjxl, I get the error during building. what is this? `❯ ./build.sh /usr/bin/ld: cannot find -lomp: No such file or directory clang-15.0: error: linker command failed with exit code 1 (use -v to see invocation) `

perhaps openmp is missing

`sudo apt install libomp-dev` or something like that should do the trick

do you know which package provides it? I'm using opensuse. https://pastebin.pl/view/raw/37bfa6ad

on my debian, I see these: ``` libomp-dev - LLVM OpenMP runtime - dev package libomp5 - LLVM OpenMP runtime libomp-13-dev - LLVM OpenMP runtime - dev package libomp-13-doc - LLVM OpenMP runtime - Documentation libomp5-13 - LLVM OpenMP runtime libomp-14-dev - LLVM OpenMP runtime - dev package libomp-14-doc - LLVM OpenMP runtime - Documentation libomp5-14 - LLVM OpenMP runtime libomp-15-dev - LLVM OpenMP runtime - dev package libomp-15-doc - LLVM OpenMP runtime - Documentation libomp5-15 - LLVM OpenMP runtime ```

I see these packages. not sure which one to install.

`S | Name | Summary | Type --+----------------+---------------------+-------- | libomp11-devel | MPI plugin for LLVM | package | libomp12-devel | MPI plugin for LLVM | package | libomp13-devel | MPI plugin for LLVM | package | libomp14-devel | MPI plugin for LLVM | package | libomp15-devel | MPI plugin for LLVM | package`

probably the same one as the clang/llvm version you're using?

It compiled successfully!!

>`WebP is a relatively new image format` <:KekDog:805390049033191445>

webp lossless is good, too 🙂

webp lossless iirc is something you et al invented from scratch, right?

like it's basically an unrelated codec to webp lossy

Yeah, it's completely unrelated

It has some nice ideas, some of which were brought to jxl, some we couldn't really bring to jxl...

Lossless webp is by design a bit closer to png than jxl: it also does things interleaved, sample values are bytes, and entropy coding is lz77-style. By contrast, jxl does things planar, sample values have arbitrary range (doesn't need to be mapped to bytes), and entropy coding is more statistical/ctx modeling (though there's also an lz77 option)

Interleaved and hardcoded for 8-bit rgba is good for speed and allows some interesting coding tools like the color cache, which is harder to do if you don't hardcode for a specific bitdepth and channel count

hello, I'm a game developer and want to add JXL support to my game since I saw the insane amounts of compression capable

the game is a 3d platformer made in C++

the problem is including the entire libjxl seems very bloated, are there "miniature" decoder implementations like `stb_image`, `dr_wav`, etc.?

or is including the library not too expensive size-wise?

as a past gamedev, I would suggest not to do that 😉

as a game developer you have *way* more freedom than jxl, and you can always use that as an advantage

for example it is very likely that you can use texture compression algorithms like PVRTC which can be decompressed directly from GPU

there *exists* a smaller implementation, I have written one (https://github.com/lifthrasiir/j40) but that sounds like a solution seeking matching problems

I want the formats used to be cross platform though

libjxl_dec is also a lot smaller than the full libjxl

I can try using that, I have tried j40 but even though I define the needed macros I get linker errors <@268284145820631040>

Let me send a pic

I can try `libjxl_dec` when I get a chance

huh that's strange. do you have multiple `#include <j40.h>` lines across your code?

I have one in a header

but without `J40_IMPLEMENTATION`, right?

Yep

can you try `::j40_from_file` etc?

didn't work unfortunately, still linker errors

I'm using DEVKITARM for the 3ds

(by the way you can get `CHAR_BIT` from `#include <limits.h>`)

Ohhh ok

thinking about that, I realized I never actually have built J40 in C++ (though it does have `extern "C" { ... }`), let me check that first

I have *other* issues to sort out (recent enough compilers will require `-fpermissive`, due to the differences between C and C++), but J40 seems to compile fine with g++

I have fpermissive enabled by chance

Extern c think makes sense though

I worried about the possibility that function declarations in `extern "C"` might be interpreted as something else in C++, but that's not the case

so your error indicates that, for some reason, compiler thought that: ```cpp extern "C" { j40_err j40_output_format(j40_image *image, int32_t channel, int32_t format); j40_err j40_output_format(j40_image *image, int32_t channel, int32_t format) { ... } } ```doesn't mean what I wanted to mean

I can't try anything now, but I will experiment later

I will try to actually install devkitPro

I've replicated every environment and still can't get the exactly same error as you've seen...

Ah dang

Appreciate your help though

so I narrowed it down to the macro not seeming to be defined, despite me doing so

as this still compiles, even though it shouldn't

ah wait

so it turns out I was dumb

now it dawned to me that I think you've found a very important caveat in J40

I needed to define the header with implementation before including the header that included the header

yes, exactly

so... if there are two `#include <j40.h>` lines and `J40_IMPLEMENTATION` was in between the second include will be ignored and you won't get any implementation

it seems it's very easy to overlook, neither I nor you were able to figure that at the first glance, J40 ideally should guard against such errors

yeah, I haven't encountered it with the stb or dr libs, so looking how they do it would be helpful

though are there more compilation flags other than `-fpermissive` needed as I did have some build errors

probably because J40 relies a lot on self-inclusion (sth like `#include __FILE__`)?

yeah, that's what I've seen

there are several main issues: implicit pointer casting (C++ doesn't like it; `-fpermissive` should downgrade errors to warnings), `[[nodiscard]]` incorrectly applied (you can `#define J40_NODISCARD` to disable J40's default behavior), `j40__floor_lg64` missing (huh, so there is no `__builtin_clzll` in this platform?), `posix_memalign` missing (oops), and finally enums declared in structs have independent scopes in C++

I mean this is probably the biggest edge case of using the header

idk who else would have the idea of using this library for the 3ds of all things

is it even barely practical? 🤔

J40 (and more generally JPEG XL) requires quite a lot of dynamic allocations and I'm very sure that you will have that problem even after you manage to compile J40 or libjxl-tiny

idk how well the 3ds performs in that, but I do know stb_image and audio streaming through those single headers work well :p

but besides from that practical concern, I designed J40 as a portable library and it's a shame that there are still lots of compat issues 🤣

(though you legit have to add multi-threading just to handle audio *and* gameplay)

I mean you don't know until you test

I still have a ton of errors with my game's cross compilation system that I have yet to fix

designing single header portable libs sounds really hard though with how dense they are, they are super useful though

<@794205442175402004> where is this libjxl_dec, I see the full version here: https://github.com/libjxl/libjxl

ye

BitDefender thinks that cjxl.exe is Gen:Variant.Tedy.210850

Tedy :--DDD

But there is not enough interest from the rest of the security ecosystem to declare it malicious.

signed by ev code signing certificate - https://antiscan.me/images/result/0cslKrLokF2w.png original unsigned - https://antiscan.me/images/result/htjyIY0KyB57.png

just give microsoft 300 bucks a year and found a company to whitelist your software from several AVs <:lul:946531054485930015>

10/10 works

lmao imagine using antivirus software /hj

sucks for corporate workstations where antivirus software is mandated by company policy... and it's usually crap such as McAfee or TrendMicro

at work we're forced to use McAfee even on GNU/Linux... and because of this we're forced to use Ubuntu because the policies are only set up to work correctly on Ubuntu and putting it in any other distro makes it wreak havoc

What kind of policies

Wow telegram desktop from flathub supports JXL view and upload

would be nice to add this for all platforms, then basically more than 700 million users would get jxl support https://github.com/telegramdesktop/tdesktop/issues/5522#issuecomment-1295915969

It will get JXL support on Windows too but people are demanding HEIC. Unfortunately HEIF implementation has vulnerabilities. It is not such big problem for an image viewer where you open only your images. But it is a risk to receive unknown files from other sources.

Why?

Because tdesktop app would crash upon receiving specific files.

Oh, that's not good. Why does it crash? Is the decoder just buggy?

Those are issues in libde265 (used via libheif). Time to time they get fixed, author has lot of work on other projects. Meanwhile new incidents are being discovered.

I see. I didn't know that libde265 had some security issues. I guess x265 could be used too, is that in a better shape security-wise?

doesn’t that do encoding only?

at least that’s what we wrote in https://research.google/pubs/pub50095/

> Note that x265 is only an encoder. We used the decoder in FFmpeg at revision 2d58fa (February 5th, 2020), which is not parallelized, even when the input would allow it.

Ah, no idea

What decoder does ffmpeg use then?

its own, from what I recall

https://github.com/FFmpeg/FFmpeg/blob/2324b917fce0eb0175ed3c135a51213e1bf7bc18/libavcodec/hevcdec.c

https://embed.moe/auto.gif?q=https%3A%2F%2Fcdn.discordapp.com%2Fattachments%2F794206087879852106%2F1046546161173008486%2Ftest.jxl

https://embed.moe/auto.gif?q=https%3A%2F%2Fcdn.discordapp.com%2Fattachments%2F794206087879852106%2F1046546161173008486%2Ftest.jxl

hm, why is the embed bot failing on this?

that's what I get when doing cjxl -d 11 on a random grayscale 160x120 face

with color, it's a bit larger

obviously this is very low quality. Probably still good enough to recognize a face though.

What exactly is the use case you have, <@1046483207568228383> ? Where does the size limit come from?

Yes.

ffhevc.

Hi! let's carry on the discussion in the forum 🙂

JXL supports colored splines. Does it mean JXL can losslessy encode amime-style pictures with lossy techniques for gradient and splines for outlines?

in theory, but no encoder does that atm

One complication is that jxl splines are added to the image, i.e. they don't paint over whatever is underneath...

So they can be used to draw lines on a smooth background, but not really to do outlines where the two sides of the line have a different color

Except if the color of the line is black or white, then you can cheat by using extreme values that can be added to anything and still result in black or white

(at least for black that works... For white maybe it doesn't really, and causes blindingly bright white instead)

You could always do a frame for splines with a kReplace blending mode

antivirus policies

corporate IT shit

Some AV vendors changed their opinion.

False positives happen all the time. If someone reported it I am sure they are correcting it.

<@853026420792360980> Does using jaotc improve jxlatte performance?

never heard of jaotc. what's that?

Precompiled machine code

just googled it. I'd have to investigate, tbh.

so cjpeg_hdr can encode jx-jpeg/jpeg_xyb? https://github.com/libjxl/libjxl/pull/1928

not xyb, as the ICC profile needs to signal either PQ or HLG to indicate that the JPEG is HDR

update: apparently jaotc is deprecated and only exists between JDK9 and JDK11

it's not worth it to try to encorporate it

Yeah I know. I used it on Java 11. it worked

jxlatte is built for Java 8 so it doesn't really seem worth it to me

to try to integrate it

Ok. But my Java 8 code worked on java11 too

ow, gcj looks even more dead