JPEG XL

But the encoder will see that there are only 32 shades of R,G, and B, and it will make a channel palette

I suppose you could also use `--override_bitdepth 5`, so it will store it as an actual 5-bit image and it only has to do channel palette on alpha then

(in principle you can also do 5-bit rgb and 1-bit alpha but there is no cjxl option for that)

https://bartwronski.com/2021/02/15/bilinear-down-upsampling-pixel-grids-and-that-half-pixel-offset/

Hmm, maybe it is worth making a request to add this magic core to popular image manipulation utilities (although I don't know how good it is in practice) http://www.johncostella.com/magic/

it's just an approximation of Gaussian I think

Bart's blog post was actually a motivational factor to invest a bit more in downsampling right now

Even though I used a similar system in my Ph.D. thesis in 2001 exactly for bilinear filtering and had been thinking about this for a long time, and my implementation in pik included an iterative refinement approach

Bart is a great colleague -- he publishes a lot of creative and expressive stuff and is pleasant to work with

Also an interesting upscaler based on RAISR (but only for GPU) > RAVU (Rapid and Accurate Video Upscaling) is a set of prescalers inspired by RAISR (Rapid and Accurate Image Super Resolution). <https://github.com/bjin/mpv-prescalers>

https://artoriuz.github.io/blog/mpv_upscaling.html

https://artoriuz.github.io/blog/images/mpv_upscaling/tables/fps.png

https://artoriuz.github.io/blog/images/mpv_upscaling/fractional/tables/violet_frac_vif.png

I'm using this for image upscaling too for a while. They are good

Fsrcnxx shaders look good for movies

And https://github.com/JWSoh/NatSR

Have you tried it yet?

No, just reading the paper And it's probably not for use right now, but in the future I think something like this will be used more often, and neural upscalers will be more "natural"

I see models and code on readme

They don't work?

I see download links too

It works, I mean, right now it's still not suitable to replace common upscalers (or rather not everywhere)

Ah. Okay.

we played with neural image scalers in an 11x11 neighborhood (during pik development)

in pik's requirements space it didn't work very well

particularly we noticed that without side channel information a neural interpolator would occasionally create non-faithful weirdness

when we finished that effort we thought that for fine quality target interpolation we would need to augment the neural stuff with side channel info and it wasn't feasible to improve the resolution without it in d1 category

Some of them include. XYB can be converted to linear light spectrum without complex stuff.

https://youtu.be/aVwxzDHniEw

from https://link.springer.com/article/10.1007/s42979-021-00770-x

We should really make a spline drawing tool that can eventually be integrated in authoring tools like photoshop and gimp

Or rather inkscape and the like

I think for line drawing, jxl splines (centripetal Catmull-Rom with varying sigma and color) are more powerful than what svg has to offer

For filled shapes with gradients and stuff like that, of course we don't have that and svg does

But a lot of vector art is mostly about the lines

One thing I regret is that we don't have blend modes for splines

It's always kAdd

It would be useful to have kBlend (where alpha is given by the sigma thing)

For self-intersecting curves, or just overlapping multiple curves, that could have been useful

Also filled shapes could maybe have been painted with that (filling it with fat lines)

Another thing is that splines only paint on the color image, not on extra channels

For spot colors and alpha channels, splines could possibly have been useful too

I guess I should have played with splines _before_ the bitstream was finalized 😅

no idea - the encoder doesn't use splines at all atm

but for authoring tools I imagine you'll often want curves to be drawn on top of the image in an opaque way, not arithmetically added to the image

JPEG X2L when?

jpeg xxl

I don't really believe in "v2" versions of formats

So jpeg-xxl then.

😛

I considered it carefully and decided against it

That is something I don't remember thinking about -- consider it an oversight or at least not getting a lot of attention

I wanted to have the possibility to render text with web fonts on JPEG XL (to be able to cut-and-paste from images) -- I wasn't able to convince anyone else that that is a good idea so I dropped that fantasy

I fell in love with Catmull-Rom splines in my second job where I built tools for radiation therapy, including the volume modeling and contouring tools

Usually people use B-splines

Yes, centripetal Catmull-Rom is nicer

We didn't measure but I intuitively thought that catmull-rom splines can be controlled with less entropy and with more prediction

Text rendering would be cool but it's a big can of worms and a big decoder/spec complication

I think we made a mistake in not allowing for that

it is weird for users that some text they can cut-and-paste and other text not

and being able to cut-and-paste phone numbers, addresses etc is just nice

also great for indexing and search

Cut and paste and rendering are two different things though

of course machine learning will fix it eventually

Rendering is complicated, but just storing utf-8 strings is not

depends on what is asked from rendering

We can have rasterized text layers where the layer name is the utf-8 string you can copy/paste

or what is guaranteed

Layer names we have, the api even already exposes them

and most computers showing images already know how to deal with text -- in a well-designed system it would not be additional complexity

It's only a matter of the UI inverting their alpha channel to simulate "you selected it" and you can do copy paste. Whole strings only though

that would already be great

of course homogenous UI experience is better than cut-and-pasting text from images working differently from cut-and-pasting from a text field -- user doesn't necessarily see a difference

Other option would be some syntax convention to put some html+css in a layer name, which is supposed to look identical to the raster pixel data of that layer. Then viewers can just show the pixels, but browsers and smart viewers can act as if the html is there

yeah, svg, html, or even just 'start a line of text from (x,y) with size 17 pts' without proper layout

We could also define a file format level box for such info, and use the brob mechanism to brotli it

if the main use case would be to copy the address for navigation, phone number for calling, email address for contacting, then relatively simple things could have worked

If we define it as a jumbf box, we can also make it work for other formats like jpeg

DjVu with OCR layer 😄

(-:

Images and video with hyperlinks on them are quite desired, "shoppable media" is how we call it

Things are possible with js or other trickery, but having a native and standardized way of doing it would be neat

E-commerce sites want to have images (or video) of a model wearing shoes, clothes, accessories, and you can click on those to get to their product page

(that's why we call it "shoppable media")

Of course the concept itself is more generic

There are some security considerations (malicious links could be added to make literally viral images)

Probably there are already existing approaches, I dunno if there's anything good

But adding text and links to images and have it as embedded metadata as opposed to external side info, that's certainly cool and useful

question is how expressive to make it - at some point it might be better to just use packaged html, or svg or pdf, with an embedded jxl, rather than jxl with embedded hypertext

it would be nice if one could cut and paste text and click on urls from images and videos (including streaming, screensharing and presentations)

mini-enigma: how easy is it to guess what this was an attempt at?

I mean, the enigma is to guess it, not to estimate how easy is it to guess it

Iso paywalls grouped by price?

not quite, but nice attempt 😄 let’s say it’s a bit more directly jxl-related

I probably know the answer 😛

a version of some plot drawing tool that produces a jxl with splines?

uh, that would be an interesting project

I hadn’t thought of this game as a potential idea generator

what it was was an attempt at ||estimating the noise level in an image for use with `--photon_noise`||

the graph is ||the computed probability density function for the parameter||

Embedding an SVG (subset of spec for text) within JXL might have been pretty cool. Any other live text would seem to me a slippery slope, though (so much added complexity with fonts, shaping, rendering etc). I bet SVG part of JXL would be implemented by browsers in 2077 😜 .

SVG is basically html+css+javascript + some vector graphics

(((if I had not known the answer I would have guessed 'visualizing the normal')))

Within a web context, that has been possible with the <map> element since HTML 3.2. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/map

IMO this is out of scope for JXL. It would be better to do it the other way round and put a JXL inside of an SVG for this behaviour. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/image

Sure, but that requires markup that is authored and maintained separately from the image resource. Doing this with just an img tag makes things more self-contained and easier to work with.

jxl in svg sounds good to me, but then the svg spec needs to be updated to allow jxl (it currently only allows jpg, png and svg)

Also https://svgwg.org/svg2-draft/

https://twitter.com/zachleat/status/1430944481965182976

I wonder to what extent authoring tools could export such images to vardct+splines (+modular for non-spliny nonphotographic stuff)

i think it's really really old thing

wait did i actually mess up that gdk pixbuf patch

oh. empty pattern. because "\x00\x00\x00\x0CJXL \x0D\x0A\x87\x0A" starts with null character..

now i see why they have designated flags for zero in their mask

https://github.com/libjxl/libjxl/pull/507 sorry lol

https://github.com/GNOME/gimp/commit/2599d79292d04665569f958e4f46c288ff3f985b uhh wait what why

nvm that's only for gimplegacy i think

ok so anyway yeah gimp's loader stuff was also affected by the same thing..

but gimp stuff is like undocumented as hell so i had to dig deep into source to figure out that they do their own escaping pass against pattern so that they can specify zeros (only octal though)

why can't they just document this stuff properly :<

but yeah should be fixed for real this time

also yeah they will be changing API for gimp3 but i don't think it's worth caring about it now as whatever they have in git is subject to change still

for some reason gimp still can't load jxl when they're not named .jxl. i wonder if patterns are not working right, or they are only invoked when file is input what ends with .jxl

i think specifying extensions does that, yeah

well, not really. but eh it works with extension so fine whatever

ok i was trying to sleep (it's morning here already) and then i realized why it wasn't working

gj brain basically it interpreted space same way as `,` (it's also separator) and ended up probably ignoring whole signature

yep. now it works with whatever extension

so okay that PR now really totally fixes things and i goto sleep peacefuly

someone should maybe merge this or something.

I approved it, I think you can merge it yourself now 😛

if you can't... I'll do it

> Only those with write access to this repository can merge pull requests.

so yeah

ah, I thought you could once it was approved

done

(I generally don't blanket-merge before the author tells me it's ok :P)

Link not found

https://github.com/danielgtaylor/jpeg-archive

no, no need to refresh the package database so soon

`-Syu` is just short for `-Sy` (refresh the database of the packages that are available in the repositories) + `-Su` (upgrade local packages to versions available in the repositories)

ooh 😁 my bad

then most likely yes, thanks for spotting

Yes. "packman" is a typo. I'm not a native Arch user. I'll fix it soon...

using the "native X user" expression in the same way you'd use "native X speaker" is a bit amusing 😄

`-Syu` is a combination of `-Sy` followed by `-Su`

`pacman -Sy` downloads the package list itself from the repos. `pacman -Su` run a system upgrade based on the currently downloaded package list

it's the equivalent of `apt-get update` and `apt-get upgrade` respectively, if you're familiar with APT.

As for when to use them? that part is easy

Never use `pacman -Sy` unless you're planning on immediately running `pacman -Su`

`pacman -Syu` is usually what you want

`pacman -Su` skips the `pacman -Sy` step which can be handy if you say, ran `pacman -Syu` and then Ctrl+C cause you forgot something mid-package-download, then you can just run `pacman -Su` and skip that part since you did it already

`pacman -Su` is almost entirely useful simply cause you already did the `-Sy` part

https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported

if you want to see if updates are available without downloading them then yes you cannot use any form of `-Sy`, correct

indeed

but it appears you know the solution

~~either that or you clicked the wiki link~~

personally I do not ever do any package install stuff without calling `pacman -Syu` successfully first

🤔 https://www.dpreview.com/news/0501469519/google-researchers-detail-new-method-upscaling-low-resolution-images-with-impressive-results

<https://iterative-refinement.github.io/> <https://cascaded-diffusion.github.io/>

Is it useful to build cjxl djxl with pgo?

It is still laughable to use AI's plausible hallucinations for crime scene investigation. People who happened to be in the training set of that AI will be significantly more likely to have done the crime...

Especially if this will be added to every smartphone and the resulting photos will be considered unprocessed

It feels so wrong that we've had 2-3 decades of megapixel races in digital cameras and display devices, and just now that we can achieve great fidelity, we also have appeal-prioritizing codecs and AI processing that can completely kill fidelity.

Information that isn't there, isn't there. No amount of AI can magically create information out of thin air. It's only plausible interpolation.

Suppose you could get convicted because an AI wrote incriminating text messages based on a log of your past texts.

(btw that already kind of happens: people get kicked out of facebook and twitter all the time because AI translations of their non-English words violate the terms and conditions)

Yes, also for smartphones these days the competition for photo quality is mostly between AI enhancements than improvements in actual hardware specs For example, my friend's vacation photo with digital zoom made on the new iPhone (and with each new generation the digital zoom is getting bigger and I think there is a strong urge by companies to make it more visually pleasing)

Now it's like oil painting (but if there are chances to add details and make it look like a real resolution, I don't think any company will refuse it)

there was this gem in the comments: > Why would a network trained to be the most accurate at detail reconstruction need to be diverse?

I think "detail reconstruction" is misleading wording to begin with. It's not reconstructing anything, it's inventing pixels in a way that is plausible w.r.t. the training set it saw.

I think some things can be reconstructed plausibly

for example one property of the world is that electromagnetic forces are required to keep atoms close to each other as objects

objects have some homogeneity and occlusion properties

if you can choose between a continuous line and a stream of pearls, perhaps the continuous line is a more feasible construct

when the interpolate knows about average teeth structure of the airspeed of an unladen African swallow, then it is too much for me

Sure. But making a face out of 5x5 pixels is never going to be "detail reconstruction", it will always be plausible invention, no matter how fancy the AI model is

https://github.com/c2pa-org/public-draft

Content Authenticity Initiative has a draft spec out

It's a new metadata spec

it's basically an attempt to counter fake media by making it possible to have cryptographically authenticated media, so e.g. websites can publish pictures where end-users can confirm the authenticity (i.e. linking them cryptographically to trusted sources)

so e.g. if you see a picture of Trump doing something silly, you could check whether the source is some reputable press photographer, or someone/something less reputable (or more likely, the authenticity metadata is just missing)

End users will be able to verify

I think the idea is that it could become something like the lock icon on https pages

You could check the certificate chain to see what the source of an image is

It's then still up to you what you consider legitimate sources, that's of course a very interesting political question

I hope the technology will not lead to more censorship. Like always, technology can both be used for good and for bad.

https://twitter.com/h_okumura/status/1434008113594585092

What is the issue Fabian 🤔

the face depixelizer is great

Barack Obama -> Dan Smith

I think there may have been some whitening in there as well. 😱

It's probably just a colorspace thing and compression artifacts

Like interpreting a P3 image in sRGB and then passing it through some generations of lossy compression

People like to put a meaning and intent to artefacts of incompetence or random things. "Media wants X." where the only somewhat universal thing that journalists want is to drink coffee.

Except for those that want to drink tea.

Lmao I just joined and the first thing I read is about this AI tool... and my name is Dan Smith + I look like the output photo. Touche stranger.

looks to me like a full -> partial range issue

lmao. I got the name from a key and peele sketch

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

LMAO I can't believe I've never seen that

Hello, I get a special case for manga(comic) content, could anyone can teach me how to lossy compress this image? This grayscale case can't compress very well on vardct mode and other dct encoder, look like webp lossless can get smaller file, if I want do some lossy compress on libjxl, how optimize parameter for this case? > original jpg grayscale 8 bit-depth q90-444 4441x6213 7,449,514 > jpg to png grayscale 8 bit-depth color-256 4,553,432 > jpg to jxl j-d1-e7 6,247,960 > jpg to jxl j-d1-e8 5,984,783 > jpg to jxl j-d2-e7 4,456,084 > jpg to jxl j-d2-e8 4,159,367 > png to jxl d1-e7 6,247,963 > png to jxl d1-e8 5,984,786 > png to jxl -m-q100-e7 5,921,998 > png to webp lossless 3,831,452 > png to webp near-lossless-40 3,914,916 > jpg to mozjpeg q90-444 7,294,452 > JPEG XL encoder v0.6.0 11e431d [AVX2,SSE4,Scalar] github build

grayscale-png

grayscale-jpg

I don't think lossy will be better for this kind of content and if blind encoding with best mode selection is required, a good solution would be to wait for the improved `separate` option in JXL

That make sense, I agree separate option very useful, but I worry separate option don't have high priority, probably have to wait 2022...😢

are there python wrappers available fro jpeg-xl?

For now I still recommend use cjxl. > https://github.com/olokelo/jxlpy

Thanks!

That PR is unfortunately closed because apparently it needs to be reworked 🙁 https://github.com/libjxl/libjxl/pull/466

Yep, but this experiment showed that it can work

Also

i think with next build it will get good at

but do not know when next build will be out

anyway it won't be release

before 16092021 is unlikely a release

and viewing the changelog i think we won't have release in this 2 weeks

libwebp2 got an important commit

Cool, but e9 is too slow for big image for now, maybe we can convince dev increase separate option priority?

that improved psnr

i can try when jamaika make a build

Yes, it's just the most effective compression for most black and white images (in my tests), something like `-s 9 -E 3 -I 1 -g 3` and maybe `--patches=0` (since they are not always effective on text, dots and stuff like that in manga/comics), also I noticed that `-g 3` is usually very often better on this content, unlike other image types And, yes, a working separate option would be very useful

i care about compression

not quality

or compression for quality

because i tend to improve images sometimes not upscale or change resolution but doing photon noise, sharpening

so i want to be sure i don't inflate a lot of space

while images don't look too much different

like this type of image i re encode and don't look worse

i care about this

not at pure absolute difference

At compression

for manga is different

i have a lot of images i can notice the artifacts especially with 10 bit xiaomi (SAMSUNG) display

maybe they are not that revealing

i do not use high brightness, they are not suited for HDR and even if i set the color to fidelity

but at least i don't notice loss of quality going from 8 to 10 bit

i do not care about all colors in the world

I haven't try --patches=0 on pixel art compress, maybe disable patche can compress better, for now I using pingo-pngcolor-100 + cjxl-lossless-e9-g3-E3-I1-C1.

because i can't distinguish and the size obviously will be higher

or you use lossless or you use adequate settings

there's no reason to create big files even from raw i usually prefer an encoder that is smart

so new heuristics are no adequate for that

For images with a lot of very small similar elements on black and white images, it may be better to disable it, but for text it might be useful (there will be noticeably less artifacts around the letters)

patches also work on chinese text or japanese text? maybe cjxl separate option can handle better other language.

Language is not important, what matters is the repeatability of the same elements However, it does not always find them very accurately

oh, I got it 🙂

download this

do not use those settings

use only default

photon noise can avoid repeatable elements or patch could work less

or in a way that is overstimulated

and with current state of jxl don't work

from freedng cam i use

there is no improvement of quality since that date

but anyway i have newest cjxl, but there's no improvement in quality

normal heuristics is always better

but jxl has a lot to do

For pixel art content patches=0 not help too much, I guess manga(comic) content probably have more variable. > 9,131,641 > -s9-g3-E3-I1-C1 6,150,164 > -s9-g3-E3-I1-C1-patches=0 6,149,090

<@!461421345302118401> You can apply a bit of bilateral smoothing for noise/jpg artifacts removal and then reduce the palette to 16/8 colors using pngquant ```bash gmic '{}' to_gray repeat 2 bilateral 2,5 'done' o ./out/'{.}'.png pngquant -o ./out/'{}' -f --nofs --strip 16 -- '{}' cjxl '{}' -j -m -s 8 -g 3 --patches=0 ./out/'{.}'.jxl ``` > ./08colors-jms8g3.jxl 606,623 > ./16colors-jms8g3.jxl 1,096,422

Your best bet currently is using lossy modular.

I got a 2MB something file with `-m Q 50`

Anyway, I'm surprised `--palette=0` doesn't actually increase compression efficiency at all in BW images. Last time I tried it, it helped nicely.

I'll work more on it later, it was mostly a POC to show that it can make sense, but it'll take time to find a good approach where decode speed doesn't suffer too much, the quality/density gains are reliable, and there are no potential additional artifacts or other 'surprises'

Try --palette 0 -X 0 -Y 0

For grayscale, channel palette might also be doing silly things

The heuristics that decide whether or not to do global or local channel palettes are very simplistic: it's just done whenever the actually used values are less than N percent of the range between min and max

-X and -Y let you set that percentage for global and local channel palette

Not all grayscale manga have this issue, but probably no dct method is better? I think I need check bilateral smoothing + pngquant quality and lossy modular Q50 quality Thank you for very much 🙂

<@!736666062879195236> I haven't try bilateral smoothing before, bilateral smoothing is best filter for manga(comic) or anime? I worry filter will similar avif encoder, filter too much detail.

From the ones I've been able to try, it retains details on anime content quite well. I usually experiment with the values for it in gmic-qt for gimp/krita

I try to keep 'Spatial Variance' low (2-5) and adjust the 'Value Variance' to the noise level (5-20)

How to judge image need denoise? I don't have too much experience, like this case how to choose denoise level?

I just zoomed in (without scaling filter in image viewer) and saw the artefacts)

I can see some tiny gray noise on zoom in image, for this case choose low denoise level is better?

Yes, select minimum values at which it disappears

bilateral filter repeat 2 bilateral 2,5 is great, those tiny noise is gone. If I want recompress some jpg or some already dct content to jxl, do some slight denoise filter to remove tiny noise is better?

I prefer keep it as it is if not doing any heavy-filtering afterwards (like reducing number of colors)

Oh, for recompression

It _may_ help, but there is avif for such things)

avif denoise filtering is too strong, I guess slight denoise filter might be help recompress quality?

<@!179701849576833024> & <@!604964375924834314> : Apple Preview on MacOS does something funny to allow you to display HDR images even on SDR monitors: if you turn down the brightness of the monitor, and then look at HDR images in Preview, it shows the bright parts brighter than the (255,255,255) white. So if you set brightness to 100%, HDR and SDR is the same, but if you set brightness to 50%, then if effectively only reduces display brightness when there's only SDR content on the screen, and if there is HDR content, it keeps the display at 100% to show the HDR parts while dialing down the max brightness of SDR parts.

I wonder if Chrome on MacOS can be made to do that too

oh, interesting

would you happen to know if it also does that for HLG content? in my understanding, HLG should take into account the user’s preference on peak display luminance

I can try, do you have an example file? It has to be in a format that Preview supports though

(the OOTF given in BT.2100 explicitly refers to α, “the variable for user gain in cd/m²”)

I have a PNG but not sure Preview would interpret it as being HLG

otherwise I can make an AVIF file, or I can look into making a HEIC file

HEIC and EXR work I think, I dunno about png and avif

in png it doesn't seem to work, and Preview does not support avif

thanks, then HEIC is probably our best bet

HLG has been on my mind recently because so far we have mostly focused on PQ, with good success, but perhaps at the expense of good ol’ HLG

I think it only supports 10-bit 420 HEIC

so I have written a small tool to convert PQ to HLG, and one to render HLG for a given display peak luminance (optionally writing the result back as PQ)

but if you can produce 12-bit and 444 files too (so all 4 variants) then I can see if the situation changed

if I polish those tools a little (better command-line parsing and so on), maybe we can publish them as a sort of little “HDR toolkit”

at some point even 16-bit HEIC worked iirc, but then it stopped working, I assume because they switched to hw decode

hopefully, this works

and takes into account the colorspace information

(which hopefully `heif-enc` wrote properly to begin with)

the command was: ```bash heif-enc -q 95 -p chroma=420 -b 10 --matrix_coefficients=9 --colour_primaries=9 --transfer_characteristic 18 507-hlg.png -o 507-hlg.heic ```

it shows the image, but not with the funky HDR thing

and with this one? (just to make sure the problem is not with the method of producing the file)

Here's a photo of how I see things when I dim my screen to about halfway the brightness slider

the bottom right is a PDF of the jxl spec which has an SDR white background

the bright rings EXR file clearly has brighter whites

the HEIC files look different but neither of them go as bright as the EXR

it could be that they only do that HDR thing when showing EXR images

That's what I see when I set display brightness to max

in the PQ one, the car is a dull red and the sky is blue, while in the HLG one, the car is a saturated red and the sky is white

I assume that white square in the EXR test image is SDR white, so as you can see with display brightness to max, that's the brightest it gets

but with display brightness set to halfway, it becomes gray and you can see the brighter-than-SDR-white rings

it's funny that I have to make literal photos of my screen to show this, screenshots don't work

if I make a screenshot, it looks like in the second picture on that screenshot

(things get clamped to SDR P3)

https://www.w3.org/Graphics/Color/Workshop/talks.html

<@!111445179587624960> <@!736666062879195236> sorry for ping, I still feel confused to this manga case, Could you teach me why this case so difficult to lossy compression? I already try pngquant and jxl lossy modular Q50 method, both lossy method is good, but I still want keep quality, so I using denoise png to higher quality quantization. but I don't really understand why avif is better in this case? > original png to bilateral filter denoise + pingo-s9 4,050,574 > jxl Q80-e9 2,715,771 > (-m -Q 80 -e 9 -g 3 -E 3 -I 1 --palette=0 -X 0 -Y 0) > jxl d1.0-e7 5,955,167 > jxl d1.0-e8 5,615,851 > avif q15-s4 1,021,725 > (--min 0 --max 45 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=15 > -a color:enable-chroma-deltaq=1 -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5)

denoise-png

should we have a separate channel for manga problems?

I'd like us to be able to fix them and having more focus on it might be justified

I acknowledge it may seem a bit funny, but if it is effective -- why not?

This issue happen for specific manga case, other grayscale manga didn't happen this issue, I guess maybe cjxl separate option can handle those issue?

> avif q10-s4 1,372,891 > --min 10 --max 10 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=10 > -a color:enable-chroma-deltaq=1 -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5

BTW, remove `--max 10 --min 10` from avifenc and replace it with `--min 0 --max 63` Doing that makes it using a static Q for all blocks, and is therefore, less efficient 🙂

But last time when I used max 63 on avifenc I got more noise than source picture 🥲.

That should not happen <:Thonk:805904896879493180>

In fact, I've never had it happen to me <:Thonk:805904896879493180>

Anyway, the Gimp plugin is now really good.

--min 10 --max 10 made noise closer to the original

I'm not a big fan of using filtering before encoding, including denoise, because even in black and white images there are backgrounds and other artistic things with noise and small dots Also as far as I've noticed, black and white images and manga, if they're relatively high quality, are mostly in lossless formats (but color pages or covers can be in lossy) So it would be very nice to find some options or maybe even optimize the encoder that would give good results with decent speed on such black and white images, as there are so many such images and it would be quite demanded, also maybe have a special mode like lossy palette, but more suitable for this

For good quality I would prefer improved lossless compression for B&W images because it would guarantee absence of artifacts and losses that are not always noticeable, and maybe something like near-lossless mode, when also these losses were more predictable and free of artifacts But for medium and low quality, yes, it's better to use lossy and for JXL it still needs more tweaks to reduce ringing and mosquito artifacts

And also a working `separate` mode would also be useful, especially when there is no way to identify the type of image or the image itself is mixed

when next improvement of image quality?

I was finally able to get consistently smaller lossless BW images with this vs WebP: `cjxl input.png output.jxl -s 9 -I 1.0 -d 0.0 --palette=0 -X 0 -Y 0` 3,821,020

Of course, it is quite slow...

I have tested these settings on a lot of different B&W images and manga and these settings give a fairly stable close to maximum results in general, but it is also slow and maybe it is possible to speed up the encoding with fixed predictors and some other settings for B&W https://discord.com/channels/794206087879852103/794206087879852106/884825075461787699

And also comics or manga may not necessarily be black and white, but instead of black there may be some other color (like blue and white)

In lossless compression I'm having cases where jpeg -> jpeg-xl is bigger than jpeg -> png And even where jpeg -> png -> jpeg-xl is smaller than jpeg -> png or even smaller than jpeg -> jpeg-xl

Thank you for your reply 🙂 I understand lossless is great, but it is really difficult keep all image keep lossless for me, for now I want find a method to keep quality and reduce file size, like near-lossless or visually lossless(but get some generation loss). av1 option is really hard to optimize, thank you for your teach 🙂 For now I look forward jxl separate mode can reach true visually lossless in d0.5 e8 for mange content.

Here is what I was able to do with the Scope options: `-s 9 -I 1.0 -d 0.0 --patches=0 --palette=0 -g 3 -X 0 -Y 0` 3,369,369 It seems to work very well for monochrome manga.

Yes, but on some images `--palette=0 -X 0 -Y` may give worse results

If it is grayscale, why would it hurt?

🤔

Idk, but I've compared these settings as well

channel palette can be useful, especially if you have a grayscale image that only uses a small amount of shades of gray

when next improvement in image quality

or for advancements in ISO

For manga or drawing, for now I notice some online shop using jpeg q99 444 or q94 444, (they also provide lossless png file), I think high quality lossy is a acceptable option. And look like some online shop start using avif, I guess if jxl can get better lossy quality and encoding time for those content, probably those online shop will choose jxl to deliver product.

Are you using jpeg recompression mode or modular lossless on jpg source?

<:monkaS:847592665293389835>

```#!/bin/bash for file in *.jpg do cjxl "$file" ouput-path/${file%.*}.jxl -q 100 -e 8 --strip -I 1.0 -E 3 --num_threads=12 done```

> cjxl -j -m -q 100 -e 9 // modular lossless > cjxl -e 9 // jpeg recompression mode

I did this, but I also did one test without --strip and the size difference was only in KB

No. You are using it wrong

I see, I do be dumb

cjxl produces lossless jpg -> jxl by default.

You should not use -q on jpg source for lossless compression

I see, so what is the right way to reencode jpg losslessly?

cjxl in.jpg out.jxl

so I just don't add the -q param?

I think it doesn't make a difference if you add -q 100, but it's not needed, on "lossy formats" the default is to do lossless recompression

(where "lossy formats" are JPEG and GIF)

I see, so can I do `cjxl img1.jpeg img2.jxl -e 8 --strip` ?

if you do --strip, then you cannot get the exact same jpeg file back again, and you lose any exif/xmp

but the image data is there

-e 8 likely is not worth the slowdown, I'd just do default

but yes, you can do that

actually, -e 8 isn't bothering me, I just am not using -e 9 because I really didn't notice a significant difference in file size that would justify the time spent

Yep, -e 8 is slightly better, with not much increase in encoding time

do you still get bigger jxl than png?

yeah, still bigger with this

jpeg is 3,6MB jxl is 3.3MB and png is 1.8MB

Weird

I'm using pingo -s9 to optimize the pngs btw

Depends on the content, if it's repetitive, png can help a lot

yeah, it's a grayscale image

Try using -m with that image

on the png?

On jpg

-j -m

was missing the -j lol

1.5MB

now it's working

oh yeah, these jpegs are bloated, I saved like 60% just from jpeg to png

Also try using -m with the optimized png.

1,5MB

yeah, it's working

thank you for the help

For lossless pixels (as opposed to lossless jpg), -e 9 might be worthwhile

Look like Indexed grayscale image not suitable lossy compress. > Input file: 003.png | 441695 bytes > Image: 1114x1600 pixels | 8 bits/sample | Indexed grayscale | 64 color(s)

But for png grayscale image, near-lossless compress still a worth option. > png - 4,050,574 > avif q7 2,462,806 > --min 0 --max 63 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=7 > -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5 -a color:sharpness=2 -a color:qm-min=0

Also some unexpected result

If don't use lossless compress, use -d 0.1 -e 8 --separate will very near lossless? (like webp near-lossless 80).

d1

d1 separate

Demonstration of how `separate` works, the blurred area is VarDCT, the rest is modular

Btw, I don't quite understand why exactly this area

No idea, the heuristic is a bit fragile I guess

cool, d1 separate version still look very good.

So when image quality improvements commits

I demand answers /s

Research doesn't work like that

I can't plan when exactly I will have the next good idea

They will come soon™️

The question is not if, just when 🤣

I'm trying something like this. But it doesn't work. `wget 'http://res.cloudinary.com/dofnr4zc9/image/fetch/w_1920,f_jxl,d_1/https://w.wallhaven.cc/full/y8/wallhaven-y8gp9d.jpg'`

Ah lol yes we don't have distance in Cloudinary

Try q_90

Or q_auto:best

Which are atm the same thing for jxl

The problem is in wallpaper link. If I use someother link, it works fine. But it does not work with wallhaven link.

I can download it using `wget 'https://w.wallhaven.cc/full/y8/wallhaven-y8gp9d.jpg'` but idk why it doesn't work with cloudinary.

It could be that it has policies against us fetching it

I see. Thanks for the info

I'm not sure if we respect robots.txt, but we might

Also they could just blacklist an ip range that includes us

cjxl separate option use which modular method compress non-photographic frame? look like there didn't use haar-like transform?

No, just color quantization

Maybe Jyrki Alakuijala have some color quantization idea? > https://encode.su/threads/3108-Google-s-compression-proje%D1%81ts?p=64872&viewfull=1#post64872 pingo encoder dev implement different lossy mode, predictors ,color transformation, palette(256c) for png lossy, color transformation is really powerful for drawing, but for noise and color gradient, predictors method is better.

yes, ideally we do something like delta-palette but in XYB instead of RGB

Also, does XYB have any advantages for lossy modular mode or is it redundant? Or maybe it allows to use more lossy tricks, including for delta-palette-like?

It does have advantages, being a more perceptual space

But it's also just that we need to use XYB for the modular patches if we use XYB for the lossy vardct parts

For now separate option use heuristic to segment the image, this heuristic use which method Identify content type? probably have a quick heuristic Identify this area is suitable for DCT or not suitable for DCT?

yes, main research question is how to properly combine different (DCT and no-DCT) coding methods without creating boundary artifacts, making decoding a lot slower, or being counterproductive in terms of density savings

I try to find a method Identify pixel art and non-pixel art, but for now I just put this work to TODO list.😛

Perhaps edge detection could be performed on thin long edges to then do edge masking telling the encoder to use lossless/lossy modular on these lines.

The only problem is that once noise is in play, that can cause some problems if additional steps are not taken.

the main problem is not so much detecting where to do what, but avoiding boundary artifacts on the edge between different techniques

in current patches that's not an issue since patches are only detected when there's a solid background color, so you can subtract the background from the patch and get residuals for VarDCT that are clean

Oh right, I completely forgot about that.

in what I want to do here, there is not necessarily a solid background on the "best to use non-DCT" parts, so that makes it a bit harder to find a way to avoid boundary artifacts (which could be bad for the final image but also for compression if they cause extra entropy)

I understand, avoid boundary artifacts is a difficult thing, I can see this issue in Scope test.

> 4,050,574 original png + denoise > 3,317,755 -d 1.0 -e 7 --gaborish=0 > 5,955,167 -d 1.0 -e 7 > 3,136,700 -d 1.0 -e 8 --gaborish=0 > 2,462,806 avif q7 > (--min 0 --max 63 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=7 > -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5 -a color:sharpness=2 -a color:qm-min=0)

I think gaborish have some issue...🤔

that smells like it's a quite non-photographic image where patches are useful

yes, that's a manga image, https://discord.com/channels/794206087879852103/794206087879852106/885516651657822219

right

interesting that gaborish makes such a big difference in size

must be that the sharpening it does at encode side is really messing up things

it's an image with a lot of very sharp black/white edges

for an image like this, I'd use something like `--override_bitdepth 3 -m -v --patches 0`

because it's basically a black and white image, you don't really need 8-bit grays here

by reducing the number of colors (maybe even all the way to 1-bit), compression gets a lot better

I wonder if it is possible to do something like lossy palette, but for grayscale and b/w images to make some similar changes for better compression and the colors will be decreased automatically until it will not be noticeable visually

`--override_bitdepth 2 -m --patches 0 -g 3 -e 9` looks quite OK to me

that's what you get with that setting

possible: sure - and likely it would also be useful to do such things on alpha channels, btw

Because the lossy palette does not work well on such images and can often be worse than normal lossless

oh, on override_bitdepth 2, background have a big error.

lossy palette is currently only implemented for RGB, I don't know what it does on grayscale

oops, right

didn't look at that part where it actually does use grayscale colors

yeah some kind of lossy preprocessing would be useful here that keeps gradients intact but changes basically-black-and-white parts into reduced colors

then in the groups where it's needed, we do real grayscale, but in the groups where we can, we use local channel palette in a lossy way to reduce it to fewer shades of gray

if the shades of gray are only anti-aliasing around sharp edges, there's no need to have 256 of them

Also, something like this can be changed on a per-block basis, like here, when it needs more colors for the background, but less for everything else? Or perhaps it would be better to improve the lossy palette mode 🤔

modular can do palette/channel palette globally for the whole frame, but also locally for the 256x256 group (or whatever the modular group size is)

<@!111445179587624960> sorry for ping For now I waiting Jyrki Alakuijala improve integral transform, I think this improve can increase drawing quality,and fix my drawing gradient area artefacts issue, I plan lossy convert some manga and drawing to cjxl d0.5~1.0 e8, I should keep waiting until separate option implement or just waiting this improve implement should be fine? what's your opinion about this? > they are relatively rare and I know how to fix them, but haven't got up to it yet -- still more focused on reducing ringing/worst case behaviour with graphics > ... also they are rare because I'm heavily penalising 8x8 dcts currently because of the 8x8 constant color blocking artefacts it brings to gradients (and artificially favoring 8x16 and 16x16) > once I'll have better degradation for 8x8 dcts, I can have a better balance of integral transforms, too

I think both will be needed, because even if separate is implemented and will work, there may be cases where it is inconvenient to use and it can be noticeably slower encoding/decoding speed and also even separate uses a combination with VarDCT

But separate is still closer to the visually lossless quality and avoiding artifacts on such content

This is old 4,months ago

Thank you for your reply 🙂 Actually I also plan spread jxl to chinese community, but I still can't get stable lossy quality for drawing and manga, so for now I waiting jxl dev improve quality... > Jyrki Alakuijala comment link https://discord.com/channels/794206087879852103/794206170445119489/882884730134093864

Why is this image smaller as webp than as jxl? Is there any way to make it smaller? Losslessly, of course.

oh, A Small Hike. it's a good game. </off-topic>

is that webp file losslessly compressed?

Yes

From a PNG from the game's press kit which I converted to webp

Also it's called A Short Hike lol

Is that the image, or is that a screenshot of the image?

So, group size can sometimes make a big difference and as I said before it is nice to have something like automatic selection it in the future

128x128 works best here?

Might be that tighter local palettes help on that image

```GiantMountainScreenshot.png.jxl_m_E3_I1_9 5,270,580 GiantMountainScreenshot.png.jxl_m_E3_I1_g0_9 4,649,223 GiantMountainScreenshot.png.jxl_m_E3_I1_g3_9 5,820,340 GiantMountainScreenshot.png.jxl_m_E3_I1_g3_patches0_9 5,817,299 GiantMountainScreenshot.png.jxl_m_E3_I1_p10000_g3_9 6,289,721```

But, yes, perhaps the choice of palette affects and this is something that needs to be improved primarily in lossless

<@111445179587624960> what does `_9` at the end mean? --effort?

Yep, these are options for benchmark_xl

so -g 0 works the best for all lossless?

No, just for this image

I'm doing a test on a 99MB image, but it's taking forever lol