JPEG XL

Yeah thanks

and there are also limits for layer blending and animation fps

I recently have very interest JPEG format xl

There were 2 limits cut off the bottom, both referred to animated JXL's total pixel count and frame duration respectively

Who needs 1TPx image lol

How would you even Decode that

Cropped decode ;P

Or squeeze

a 1024x1024 image has 2^20 pixels. 15 bit color (5 per channel) fits in 1024x32.

**Qon** _“15 bit color”_ 2024 image/jxl 38 bytes https://jxl-art.lucaversari.it/?zcode=bYy9DkAwFIX3%2BxRnlyatshpMJpEY%2BgCUdhNphLd3o6IRpnv%2B7lf7MNolOJRk%2FMhXybygxvrZBeicyE8YUEERwHJnKVleplvtpjjQMQEEDLJrmlzsBHobWN80%2BUMzb1Lcf7mp4Z%2FjAQi0PxPgBA%3D%3D

Maybe you meant 48-bit color?

16 bit as in 16 bit per channel, just like when we say 8 bit, I guess.

https://en.wikipedia.org/wiki/High_color

yeah

Historically means 16 bits total

it's a bit annoying, that when we say 8 bit, or 10 bit, or 12 bit, it means per channel, but when you say 16, suddenly it means something else!

Does images with 16 bits per color channel exist? I'm not talking about jxl art with Bitdepth 16, I mean is there hardware for it?

My link links to https://en.wikipedia.org/wiki/Color_depth#Deep_color_(30-bit)

no, 16 bit is still very much associated with 16 bits per channel

what are you thinking of?

So sounds like 16 bit /channel cameras and displays don't exist, only used for storage during transformations to not lose precision in 12 bit/channel data

Qon already linked to it

Some decades ago, 16 bit color referred to 2 bytes per pixel color.

16 bit per channel is not common, it's more bits than needed

once i made a GIF image of the 2²⁴ 8-bit RGB colours for fun :p it takes a long time to show up because each frame adds 256 colours, and GIF viewers automatically add delay between frames :p

png supports 1, 2, 4, 8 and 16 bits per channel but not 10 or 12

It is very common for internal processing of all kinds, and also for intermediate images in production environments.

Like I said

I think cameras are creeping up to 14 bits. But in CGI, you can easily have 16 bits or more of dynamic range in a rendered image. At some point this would be tone mapped down, of course. Using 32-bit float as the intermediate format isn't uncommon.

I think modern CGI rendering is up to 30 stops, i.e. 30 doublings of brightness.

Probably because of technical reasons. 16 can store 12 and 12 wasn't common at time of making png format. My guess.

in the audio world, 14 bits was a long time the most you could get from an ADC

The CD standard was originally going to be 14 bit

interesting

I generally assume N-bit images are images with N bits per component, so typically 3N bits per pixel.

But it's confusing indeed. Sometimes 8-bit means like in png8 (so 8-bit palette indexed color), sometimes it means 8-bit RGB(A) like in png24 or png32.

Using the total is very confusing, e.g. in PNG you can have Gray+Alpha which are both 8-bit so that could be called png16, but you can also have 16-bit Gray which would also be png16.

High Color I would never describe as 16-bit, but as rgb555 (or rgb565)

oh hey I don't see you around here very often

indeed, but i looked in this channel on this particular day

😄

PNG is based on general-purpose compression (deflate), so keeping things byte aligned is kind of needed...

Yeah that was my thinking 👍

Yes, originally I was playing with this image in JXL https://commons.m.wikimedia.org/wiki/File:16777216colors.png A shame I doubt it could fit in JXL art due to needing 4 1024 groups

Multiple groups is not a problem.

For jxl art?

if you want different trees for different groups, you can do `if g > n` to have subtrees for each group. though I have no idea how groups are numbered.

The numbering is a bit weird, it starts at 21 iirc

There are group numbers reserved for things like DC, AC metadata, custom Quant tables, etc. These are all empty and skipped in case of modular-only encoding.

Here are some examples of multi-group images: https://discord.com/channels/794206087879852103/824000991891554375/833299488520011796

Good to know

**Tirr** _“Found an interesting case fuzzing jxl-oxide”_ 2024 image/jxl 33 bytes https://jxl-art.lucaversari.it/?zcode=PY5BC4JAFITv%2ByvmmKK5roZeLKhLJw8VeAsMV3chVHQpA398L1s8vYE3M99cTjdwdtSmkr1RSFmhK7qhSNlZ6kaZRTJd44M9OYHARaFKA1X2vWxH0CtHBn8j7lHoHOAG1qSpJxL%2BQxuMumllBd0a2cjBI7O1O8jW6PYfpb45ny3Mx1UaiN1u1XwZMy1%2FHwVCnkRJHKYiXqjUxD2MHYjaveRQP7v3CJo70UbxI9iaLw%3D%3D

so here's the tree: ``` RCT 0 Bitdepth 8 Width 128 Height 128 if y > 0 /* What happens if N = -(2^31)? */ /* With 32-bit signed integer, -(-(2^31)) == -(2^31). */ if |N| > 0 - Set 255 - Set 0 if x > 0 - W 1073741824 /* 2^30, so it overflows at x = 2 */ - Set 0 ```

the tree is set up so that black line appears if sample at the first line is zero (`|N| > 0`)

the buffer is 32-bit signed, so it will overflow to `-(2^31)` at y = 0, x = 2

now we need to take an abs of this sample value. technically it would be `2^31`, because the spec is defined in integer with infinite precision

uh wait nvm, I was just confused I think

no I'm thinking it right

so... its true value is `2^31`, but with 32-bit integer abs also overflows and yield `-(2^31)`

so `|N| > 0` is false and black line appears at x = 2

but if we follow the spec, `|N| > 0` is true and white line should appear

**Tirr** _“...and weird things happen if W -(2^31) is used”_ 2024 image/jxl 33 bytes https://jxl-art.lucaversari.it/?zcode=C3IOUTDgcsosSUktKMlQsOAKz0wB0oZGFlweqZnpGSVgJldmmkKlgh1QpYICkFnjVwPl6CoEp5YoGJmawtkGYMUVYHldhXAFXSNDE3MTC2MzEwsuqAoA

For this reason the spec somewhere says that basically if int32 is not good enough to store modular values, the bitstream is not conformant 🙂

So anything that overflows is technically not a valid jxl, and decoder behavior is undefined

doesn't abs count as an "intermediate arithmetic"? I wonder if 64-bit property vector is needed

`-(2^31)` totally fits in 32-bit but `abs(-(2^31))` is not

I'm not sure this tree encodes correctly with jxl_from_tree: ``` RCT 0 Bitdepth 8 Width 128 Height 128 if y > 0 if |N| > 0 - Set 255 - Set 0 - Set -2147483648 ```

jxl-oxide decoded the tree as below (note the constant). maybe this is a bug in jxl-oxide or jxl_from_tree. ``` Decision { property: 2, value: 0, left: Decision { property: 4, value: 0, left: Leaf( MaTreeLeafClustered { cluster: 0, predictor: Zero, offset: 255, multiplier: 1, }, ), right: Leaf( MaTreeLeafClustered { cluster: 0, predictor: Zero, offset: 0, multiplier: 1, }, ), }, right: Leaf( MaTreeLeafClustered { cluster: 0, predictor: Zero, offset: -1342177280, multiplier: 1, }, ), } ```

**Tirr** _“Why does this turn black?”_ 2024 image/jxl 30 bytes https://jxl-art.lucaversari.it/?zcode=C3IOUTDgcsosSUktKMlQMDTnCs9MATGMLLg8UjPTM0rATK7MNIVKBTugUgUFILPGrwbIMTIAAaCIrkJwKlCdsaGBuRGca8DFBWGAlRkCAA%3D%3D

``` RCT 0 Bitdepth 17 Width 128 Height 128 if y > 0 if |N| > 200000 - Set 131072 - Set 0 - Set 200001 ```

ah yeah that turns black

**Tirr** _“Hybrid integer configuration overflowing (I guess)”_ 2024 image/jxl 36 bytes https://jxl-art.lucaversari.it/?zcode=C3IOUTDgcsosSUktKMlQMDTjCs9MATGMLLg8UjPTM0rATK7MNIVKBTugUgUFINMPyDQ0M4ACoJiuQnBqCULIEC5kwMUFlTOHKQcA

`1_600_000_000` is ok, but `1_700_000_000` is not and goes somewhere like `1_163_129_088`

32-bit property vector is ok, iirc we recently clarified that in the spec because it wasn't obvious

Property vector is considered like sample values, not like intermediate arithmetic

that's nice, thanks for clarification

It's especially useful encoder-side, since there you might want to actually store significant amounts of property values

For lossless float32 this can actually matter. And for jxl art 🙂 For normal 8-16 bit images it doesn't make any difference of course.

I'm updating/rewriting the frontend of the jxl-art page! 🥳 <:JXL:805850130203934781> - Now it's a dark mode look that doesn't flashbang your eyes! - Much better space efficiency with side-by-side panes! Since code is mostly vertical you can have your image in almost full screen. - Ace editor with Sublime text keybinds! Multi-cursor editing, line manipulation keybinds (like duplicate line) etc... - Nice Monokai theme. Syntax highlighting mode `javascript` works great for both javascript and jxltrees! - EJS templating language preprocessing on your code! You can include simple calculations like `<%- 2**bitdepth - 1 %>` in your code instead of supplying a value or you can generate the whole jxltree code with JavaScript! **Bonus feature**: EJS support means you can add comments like `<% /* comment here */ %>` without fear of your code being corrupted by jxl_from_tree's buggy comment handling! <:KekDog:805390049033191445> <:Hypers:808826266060193874> - Tabbed layout: EJS preprocessing steps will be output as additional tabs (if you have EJS tags in your code) so that you can view the jxltree code. - Slightly better error output messages. Todo: I'm considering adding tabbed layout to right pane as well. The tabs would be for image viewer, error message and the wtf so you can read errors or wtf next to your code instead of showing the image. Also error handling needs more improvements.

very cool

have you tried my <https://embed.moe/jxl_from_tree>

First time hearing about it

very cool 😄 lmk if you'd like me to host the updated version

(of course you can also send a PR to surma)

I do, just need to figure out how to do a PR 🤪

I'll PR <@228116142185512960> as well if he wants it.

I accidentally started by cloning `main` branch, so you will have to merge in your veluca branch edits again.

that's fine

<@179701849576833024> ```### Before you contribute Before we can use your code, you must sign the [Google Individual Contributor License Agreement] (https://cla.developers.google.com/about/google-individual)``` Is this project actually a part of google or is this file `CONTRIBUTING` just a file that somehow accidentally joined the folder?

Uhm

Good question, I think Surma used to be at G at some point

<@228116142185512960> maybe you can clarify?

There's for sure no such checks on my fork though

I haven't figured out PR's yet, but you can see that it works (link was so long it became message.txt)

my fork has `main` and `gh-pages` forks. `gh-pages` is just a branch for github pages where build files are moved into root

nice nice

publish doesn't work when it's hosted on github of course since the secret ENV for the bot isn't there, but the page is working correctly otherwise with ejs processing and all. The link on my gh-pages is also incorrect, drops /jxl-art/ from the url. Modifying the url manually shows that it displays correctly.

But that should just work, with your usual build and publish steps when you host it on your site

I just realized recursive EJS fork bombs should probably be stopped after N steps instead of letting it go on forever. Eh, closing the tab gets rid of it... but a fix would have a simple counter in the loop...

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork tells me that I should select my fork from this list to create a PR. I'm not on the list though. <@179701849576833024>

link to your fork?

https://github.com/Qon/jxl-art

that doesn't seem to be a fork?

did you click the "fork" button on gh?

I probably accidentally cloned it instead...

yeah that probably explains why

I think you might need to delete and fork

oh ok

Finally it worked :D

Wait I just noticed: now I accidentally forked it from surma and PR'd him instead

😅

Not sure how that happened...

No, I did fork veluca. And I used the fork link, I was definitely on veluca/jxl-art gh page when I created the fork

But for some reason, when making a PR on veluca's page, forked from velucas repo, it defaulted to surma and sent the PR there instead.

And the GUI just collapses if I try to change target from surma to veluca, I have to change source first or it wont work

GitHub is just great like that

PR'd correct repo now

Though I was planning on PR'ing surma as well anyways, if he wants it. So no harm <:kekw:808717074305122316>

Hey at least I could just rename the first cloned repo, make the fork, `git push origin main` (and gh-pages) and then it was solved <:PepeOK:805388754545934396>

mhhh would you mind adding ace as a submodule instead?

doing `npm i ace-builds` instead?

Would make sense...

So I tried that, but I don't know how to import the theme and mode files. Do you know how the build system wants import paths? `import "ace-builds";` works to get the editor running. `import "ace-builds/src/theme-monokai.js";` doesn't work though. I've tried many variations

I have absolutely no idea

Maybe something with rollup configuration. I don't know how though

I'll keep trying to figure out how make it work with ace in node_modules. But I'll be using https://qon.github.io/jxl-art/ for my jxl-art until then if you don't want my PR as it is now. Might take a lot more effort to get rollup/the build scripts to include the files I need when reading from node modules, for some reason... Lack of publish on my gh-page isn't really a huge problem, the share button works fine.

Doing image generation experiments: Works: https://qon.github.io/jxl-art/?zcode=jZDRCsIgFIbvfYrzAsFURl0FtZtdRgVdj7QUxhghUW-fW-6sOXXdHf_zfb_isThDRi5aGAWckVLquzLdtNdGyNamG7KrW1WRUgshm0JVTSNroIToG1xhC5wArOAkDbA8t7OLmR37w-Ehn9wGWR8M7PT0NdGlbuls9mP7vt-AHSPgWugknPfMm3r13b0nT3qWevlUiMO-9SQMo1jrwzEc2_lsEVfwlpCU0sa_CS7T6vhlkfWSjrfHgeUKfEUK-admYCj5AA Fails: https://qon.github.io/jxl-art/?zcode=jZHBCsIwDIbvfYq8gLB2TnYS1MuOooLnYastjDGkiL693ewy17XdbmnyfX8CPR0ukJCr4lpCmpJCqIfUbbVXmovGdHOyqxpZkkJxLuqDLOtaVEAJUXe4wRZSArCCs9DAsszUts1M2T2OT_FKTSPpGj07fv1MdKkdWpv92a7vJmDGANgUOmpOc6ZJnfpp79lEPUO9XcrHYV4-avpRjHXhEI7p68kgrOAWnxTTcBvzDuMqbg3Jc_rwM0FgPmL4uAiyJAaviUPLovCqOWxpXM9R8gU I'm not sure why though. The second tree is slightly deeper, but I've had like depth 100 in just pure x decision trees (after 1 or 2 y nodes) before without issue when I encoded a UTM starter pattern for the rule 110 CA.

Both should give 1 black pixel in top left corner, second link just gives an error when generating the image

Am I doing something wrong, or is jxl_from_tree doing something wrong?

running jxl_from_tree directly on that second example does produce a jxl file

so I dunno what's going on

Thanks for testing 👍

But now it's even more confusing <:SadOrange:806131742636507177>

it fails on surma & veluca pages as well so it's not my bug at least <:Hypers:808826266060193874>

I dunno if there are debuggers for wasm builds

Thought I might as well ask if anyone would like to try and turn this into JXL art. It should be *relatively* simple, but having one of the already established wizards try instead of me means it might be half an hour instead of half a month

(Yes it's a crusty jpeg, thanks Telegram :P)

There's more compression artifacts than signal in that mess...

Maybe you want me to recreate the compression artifacts in jxl-art <:KekDog:805390049033191445> <:Thonk:805904896879493180>

ISO Noise 256000

Not any better, but at least not scaled up

It's not centered

I *think* that's on purpose, but doesn't matter much

Took like 30 min just to get the coords https://qon.github.io/jxl-art/?zcode=7ZfPa8IwFMfv-Styl0Ly8vKSXAabFw9DxjbYWWY3C-JkK0P_-6VObW0b1urEnwch_SYv36T55PX52H3mgr0kw3TECQXrxcn7KF0075J0GE-9btnteDoasF4yHMaT7mgwmcRjrlj_I70ffKWMJW_8ld9wzTiP-FOcctB5W9SO882Hz_ib_KPwj2tBr4W1hAVp06CorEYUn_L20hkLMiCtjLMutREvtcsXkXVDyU5CvoDlELkWFtIsmxRcQSwvdWOoFLAhLzrmmTNQqaN-nkKIqfbUvbi_5quqy51WNjCviFl0n3e8H1W3NasZngW8-B8YFdguAllo6hxlLxTbWHd8hIGAd6SM0eaCSdZ-9w1JVmDPj-SIawntSNaly58vRCkpEJpfopbWPkDLEMhgNLprTm6YkwMkK4NtSQbQR4Ny29SYRVAoLZN0DnVzmLfJy2RCOKNzyp_SBSdm3D0xnzTOna1wtiGcQbj8ZPZVZoTMIwsk1DU575ScNZi2NKuaEzmDijlSaC3tlWUpgheJwEi8ZuadMvNJs7xVoSFlqGp2TktJh6maUQny_14uE-YFiI6awPzLLLFm8B0GMSdF4JitcaJ0af-9lHXhb79E4cwVrSNBq8NtS65CB6u12m89SSFrACtQsB8

No gradient yet though

On https://qon.github.io/jxl-art/ you can run this code to generate the .jxl

756 Bytes if you download the .jxl from the jxl-art page

This file

Thanks for taking it on

Adding gradients shouldn't be hard though

https://qon.github.io/jxl-art/?zcode=7ZhLT-MwEIDv_hW-V5HG4xk_Lki7XDisEAIkztU2bCOhgiBawb_HgSZ1k1iblC1QyKGSPfHM-DGfx9Pz40sJ4qpYlEtpCMRJXvxZli_Nn0W5yO-CXKH4cXO3nIuTYrHIV8fL-WqV30gtTm_LX_OHUojiWv6WR5KFlJm8yEtJ4Dcd6B0Ymmf3-V8TuhC6jYAbQSOiSNTyEIvqIXFv0167ptrXU-hY1aicyllYUWxAe23qwZWm3kxqS7etXesjE21UKgvYjOja6Fpp7ABArFhZivWC6LGaHvpI2N6TraEKcEvczAfRtD7024mX0P3Se0T_MtiVrpfaWcFTR1jvHbLpruuxZ3ilcBV-aHVivYTG4VDPWbWjNMb1LGhYTPjOtLVsJ2jeARoO-zwQGo3uC0KTSVY4DhpuXTTR4WsFhMN5Hek6KLBKMYOWyU-Z5tNlmgQ02tJYaBD581Az9sKvNEwq2RjlPfFwbnbJNsamyCHvdTimiZx3SDf09nRz2OTMdiLHpchB8Ir9nt9pKeeZQwN6AudAUg6jHQuO7jn7r1DdZJqcM3vFRkGSWYNW0YTNgeSbw8Zmp5eaUqkKx3tWynxMhUMaTCg1J272y81LzHszhJtXPIwYGOcfE81eQSKinPXQuiD-e9nh048nFbZo-pfrO4fzTLqRsZwKJma93yLApFwjOiBoRW9cp63Zca2Yq1vP With gradients 914 Bytes

Perfect

It's 640x640, doing `.map(coord=>coord.map(axis=>Math.round(axis/2)))` on the `coords` array would make it 320x320 (you also would have to reduce fadeout_y by the same)

.jxl supports images done like this up to 1024x1024

Yeah, the size of 1 modular group

But I'm considering... "upgrading" it. Secret project *hush*

Huuh....

I'm not talking about changing the .jxl standard. And I might not bother with it

What is the image for?

<@98957339243073536>'s profile picture/'logo', just because he's one of the few people that tolerates me discussing JXL at length haha

> It should be relatively simple For me, yes :3 But before my `line()` function was written and we had the proper hidden layer support that was added recently, this would be seen as impossible. I'm exploring other techniques for doing complex shapes though. But bugs in the wasm of jxl_from_tree are stopping me atm <:SadOrange:806131742636507177>

The only reason I thought it should be possible is because the JXl 'logo' looked similar haha

https://jpegxl.info/old/fallbacklogo.jpg

45 degree angles have been possible for a long time, they are kind of part of the language. I wonder how the lower part is made though...

Is it (without text) completely made as jxl-art though?

yes

https://jpegxl.info/logo.jxl

Do you have the tree?

is "`logo.jxl`" not it?

I mean the jxl_from_tree text language

ohhh

I believe djxl can dump the tree if built with debug stuff enabled. Hang on and I'll try it.

there's an old version here: https://discord.com/channels/794206087879852103/824000991891554375/829640351320768522

don't know if the tree for the final version was ever posted

Ok so predictors `AvgW+N,AvgW+NW,AvgN+NW,AvgN+NE: average of two pixel values ` are used for blurry 22.5 degree angles, which are then also a "language supported" angle

The gradient predictor is pretty much what I do for lines, except it clamps values

I think

What build flag is that?

I think I was misremembering

https://discord.com/channels/794206087879852103/824000991891554375/829790023481163826 gives me *this* after I fix the RCT to new format (1 -> 6) https://qon.github.io/jxl-art/?zcode=hVLLDoIwELzzFXsnJLQ8hIuJGiInDmrSDwAUbh6I0b93KwVWulUSEmams9OdoPpm6ECEYeiVbX_rhvF73w9Ne0cl806HC6Se11_hBVuIUQRA8ESQfMAHqmOJxAgBAtg9bpVfKfBBWlxgOKetYGyFsaGpRouYJryIH2GFMBAToe0VvuIL-yTw3A4QLWvU39Po8MlLZ2l3kAinwxBSLtRcXpznhLQ6XR6MVeTO69nZWqA92NpcCS_pjZwDo9Btks4sf52FZLFayLE8c5LpQ_9H9rqGjayR3G1Nfp7a5St7gfl8xiytHWy9xpPKjC2KzSG-KObEH3nEKzYJK__MJX6X_Ced9J3QC0y_2Rs

ah, there it was

It was either a developer build or a small hack you had to do to the executable. I know there was the Google CTF which needed trees

Oh wow, that's impressive. I'm sold more and more every day on this format lmao, thank you

off-topic but I was wondering why your name and pfp looked familiar and of course the reason ended up being Source engine related lol

I found the [original JPEG](https://avatars.cloudflare.steamstatic.com/eb1116435009d4d28af1d07cf50ca2d3976b301f_full.jpg) and jpeg2png manages to clean it up pretty nicely

Glad you like it! Use it as you PFP and that's thanks enough :)

Yeah, no more jpeg artifacts ;P

about jpeg artifacts, I cloned and compiled https://github.com/victorvde/jpeg2png and it works quite well to clean up messy jpeg. But the last commit is 9yo. Do some other similar project exists ? with better results ?

there's [JPEG Quant Smooth](https://github.com/ilyakurdyukov/jpeg-quantsmooth) but I wouldn't necessarily call the results better just different

Indeed ! it seems a bit less smooth for very flat areas. Anything good exists ith IA ?

waifu2x has existed for years. it's a neural net based tool

waifu2x is not only an upscaler ?

I'll test it

dpir

perfect for text, line art and anything else with only high contrast content

probably optimized for PSNR...

Cloudinary's new AI-based cleanup thing might also be good: https://res.cloudinary.com/jon/image/upload/e_gen_restore/f_png,q_100/eb1116435009d4d28af1d07cf50ca2d3976b301f_full.jpg

<@98957339243073536> we have started something great

Good

The brightness is still a bit better on my Xiaomi mi 11 lite 5G than yt but it has to be tested in an accurate quality

On yt brightness how i see on my phone I strongly prefer auto cloudinary jpg

But on tv? On laptop?

I once again have no idea what you're talking about

https://youtu.be/YaPzeLMGHTQ?si=9hyPcpez7R_PKtwP

Ok test video let's cloudinary judge the quality

Only for This server

I'm sick of Discord honestly. UI too dark

Huh...

It's been recompressed over the years because I keep losing the file lmao. Finding the original PNG on an old hard drive would be nice but it's not complex enough to warrant the search

A shadow that will always follow me 😔

I use waifu2x caffe — cunet denoise 1 For photo. For art use cunet denoise 3

It will be necessary to do comparative tests.

amazing results ! I'll have a look

waifu2x-caffe cunet (noise3_model) + realcugan-ncnn-vulkan models-se (up2x-no-denoise) I've been using this for a long time to fix lousy compressed art. and if, instead of "cugan", neural networks may have appeared better... but I just don't know how to fix artifacts better than "cunet"... *I don't have any examples at hand other than this, so I'm sorry for the cringe.*

<@226977230121598977> do you sometime encounter raw material which is not compressed nor scanned? I mean, a manga which is directly produced on a computer, saved as png and distributed as this?

<@1051137277813870592> you could also try real esrgan. I don't remember if it can only denoise though

Yes, I oversaw a project to compress 18,000 units of translated manga hentai (porn) into JXL

and if you need manga like that, like I said before, there is e.g. witch hat Atelier or hunter X Hunter on nyaa

I tested a few images yesterday and lossless was 30% smaller than lossy vardct/modular on them

I find an algorithm, a mixture of blur, sharpness, medianblur, which destroys the dots. what would it be ok to compress

That was a year ago. right now, the best solution would be to blur everything to hell harder and then restore sharpness use CUGAN

now have tools for FFT for sound. but in the case of manga, it would be nice to have something of the same for the image to just destroy the dots as if it were part of the "image spectrum".

unfortunately, and I DON't understand why - We are still no neural networks for destroying dots in manga. The transfer of points to luma gradient was simply not created. all I advise my friends to do when scaling manga is to use B-Spline - so that when rescaling manga on a monitor or phone screen, interference is minimal

this is for scanned halftoned images that presumably are actually grayscale so the dots are not intentional but an artifact of the printing technology?

like this: https://legacy.imagemagick.org/Usage/fourier/ ?

because I assume in some cases the dots are actually part of the art

yeah these days it's style

There are no gray colors. Manga printing is a 1 bit color technology

and there is gray

well yes, but either the artist intends to have shades of gray (and the printing technology turns it into some halftone pattern because it can only do 1-bit), or the artist intends to have dots (maybe even larger ones than what the printer resolution would imply)

link with correct anchor: https://legacy.imagemagick.org/Usage/fourier/#noise_removal

Oh, no, of course not, art is originally drawn in a single-bit format, in manga drawing applications,

<:linusretire:707375442226708542>

if the art is 1-bit, why do you want to destroy dots and turn it into smooth gradients?

I guess one problem is moiré?

I tried to scale manga while changing the dots size one time, using fft, but did not get far lol.

gotta scale in linear

due to interference during scaling

nearest neighbour or integer?

the fact is that manga drawn on paper has a huge DPI in terms of quality display, the points in Source arts are exactly those that the printing equipment will print, they are not subject to Discrete conversion, they are actually vector on the final material (paper)

the problem

linear light, when not nearest neighbour scaling

the fact is nobody draws manga on paper in year of our lord 2024

I like dots in manga, but when scanned (and even worse compressed) they exibit moiré which is very very ugly

they look fine when scanned at high dpi

I have a 1200 DPI scanner - it's quite enough to detect every grain of every point..... but there is no hardware (display) to "properly" view the scanned manga.... except for Ebook Reader

🧐 It looks very smart. added to bookmarks

**\_wb\_** _“Manga dots”_ 2024 image/jxl 34 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMOEKz0wB0oYGBlweqZnpGSUKFgZcoQXFibkFOakKFlxBziEKBlxcmWkKlQp2QBaQ4QdmKCjoKvi5KugawlhGILlwoBxQSFchOLUEyDCAsowA

I guess the main problem you have is that no display has enough resolution to properly view it without downscaling, and for downscaling algorithms it is tricky to avoid moiré / aliasing artifacts

my friend with a 8k monitor did not understand why I was so bothering <:PepeOK:805388754545934396> the best solution is an Ebook Reader or, if you have a 1000+ ppi printer, just REprint the manga on paper

But 95% of people who don't have this read manga on their smartphones - that's where all the problems come from.

To do downscaling without Moiré, best in my experience is to first do a Gaussian blur with a radius of half a downscaled pixel (so if you go from 20000 pixels wide to 1000 pixels wide, 1 downscaled pixel corresponds to 20x20 original pixels and you'd do a Gaussian blur with a radius of 10 pixels), and then do a simple pixel area downscale (INTER_AREA in OpenCV terms).

So manga reader software should probably do that and not some default bicubic or lanczos or whatever

that gaussian blur is generally very effective at preventing all kinds of haloing

always beneficial really in my testing

<@794205442175402004>that i do

its just works

<@251147778313551872> the method is working. but it has so many artifacts that it cannot be used... In addition, it is completely manual, no automatic processing... It's a pity that it turned out to be just a funny thing.

fun blur

literally neural network generation

<#806898911091753051> https://openmodeldb.info/models/4x-DWTP-ds-esrgan-5

<:monkaMega:809252622900789269> no way

in what way is it possible to draw an image of 31x17 pixels using JXL under the condition that the image information is only the brightness of a specific line to visualize the mask of my image search algorithm. (exclusively for visualization) because I have to store it in JPEG or WEBP images of a large size. Although the actual amount of hash information is 48 bytes

I'm not asking to do this, I'm just wondering if it's possible to implement it, since 17x and 31x masks should be superimposed with subtraction (mask difference) on the image in 50/50 percentages

so you have a base image B and then a layer H consisting of 17 horizontal stripes and another layer V consisting of 31 vertical stripes?

there are only images of stripes. A combined image is made from their difference

ok

Since these are 2 prime numbers, the image size should be 527x527 pixels when multiplied.

wait I don't understand

🙂

overlap by difference

that's a 31x17 image though

how do you get a 527x527 image?

31x17=527

you cannot place a 31x image in a 17x field

overlap 50% x 50%

the number of lines in one image is 17 in the other 31. technically One-dimensional. but one is usr for the height and the other for the width

ah, you're using 527x527 just so you can have 17 macro-lines and 31 macro-columns, so to speak

so that perfectly precisely observed in all proportions

so these stripe layers are easy to do in jxl art, just a tree of the form `if x > 16 if x > 33 if x > 50 .... - Set [value of 3rd stripe] - Set [value of 2nd stripe] - Set [value of 1st stripe]`

(or using y and steps of 31 for the other one)

please don't write examples. I don't understand JXL art at all. 🥴 I'm just wondering if it's possible to draw or not 31. and then draw lines 17 on top of them so that there is a pixel difference in place of the drawn lines 31

blending them can be done using one of the blend modes jxl supports. It doesn't have difference, but I guess you can use kAdd and encode the layer with all values having a negative sign instead of a positive

what kind of "pixel difference" do you need?

is it just A-B or do you need abs(A-B)?

yep

abs(A-B)

that is maybe trickier

an easier and maybe more informative way to visualize this is to put the horizontal stripes in one channel (e.g. Red) and the vertical ones in another (e.g. Green)...

something like this

https://qon.github.io/jxl-art/?zcode=rZG9bsIwFIV3P8WdERXXdpyYhYEundtKnVFjiBeChJHK2-M_7CR2N7Z7zrFv4vP96N4MIFhHPpQ-DcaPe216dbG-JJ_v34CE6CP8ws5OAHa825G7OamWepX0lkWdHMp4srIpmomZbSlmdgoYbRdBjpquiHLYyUoIsFnB4dzDdYTxvIb7eIOTMmAGBbpXB1htqrfe4Muemj9omda-FxIWm6ts3C6T4M_d4DWMFItFbi3-xPNm3C-CjgojzT_XePuk6RTnmabTAqc0ndN2c5jOkwVLvxlpydIHVNZY-ogL8hpY4akC_43Kzuutp5KbGg0qscAxORiv4gIHTnEgeQA

(you can also try other RCTs to spice up the colors a bit)

I get the idea

All those branches... how does the encoder optimize this for parallel execution?

That's where things get tricky. We already do stuff to reduce branching in the decode paths, but there is room for some more.

Some can't displayed on Safari https://jpegxl.info/art/

If I recall there's a minimum filesize for images to display, and JXL is the only time it's managed to make images under that minimum

The 73B one is displayed but the 81B one isn't

Huh... Well that's new

maybe rejecting the spline

current libjxl even rejects some old arts.

this tells us something about which version of libjxl they're using, I guess 🙂

originally splines had no limits, and libjxl would just decode anything

well current libjxl decodes this one

then we added limits because fuzzers were finding examples where decode would take lots of time and resources — these limits were first added in a somewhat unprincipled way, just as a security mitigation

then we updated the spec to actually define rigorous and well-defined limits for splines (in both levels of the Main profile, at least), and made libjxl use those limits instead

'Rubin golden vase' originally decoded, then didn't decode anymore, then decodes again — it was one of the examples I wanted to remain within the spec limits 🙂

so likely in a future update of Safari/macOS/iOS the image will decode again

Interesting

encode_decode

Maybe to do with the RCT numbers being changed?

yes, as far as the color issue

but the shape changed too

Looks like some scaling factor changed in jxl_from_tree output. The important thing is that the same jxl file decodes to the same image. But probably useful to figure out what changed there and make jxl_from_tree consistent with older versions again.

he has a little fez now 😂

Sierpinski: https://discord.com/channels/794206087879852103/824000991891554375/844164924527476757 XOR: https://discord.com/channels/794206087879852103/824000991891554375/926163221776314380

<@1135670115808059512>

oooh, I love this, thanks

what about pinning them? so we can find them again easily

**NewFeverish** _“Sierpiński Gradient”_ 2024 image/jxl 25 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTg4spMUwjX9QtXsFMw4FJQAPL8gFwoT0FBVyFcwRDKcixLD9cGqgTJ6CoEp%2BakJpcAJQE%3D

It looks pretty cool using other RCT vals too

**NewFeverish** _“Frozen Sierpiński”_ 2024 image/jxl 27 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTgCnIOUTDl4spMUwjX9QtXsFMw4FJQAPL8gFwoT0FBVyFcwRDKcixLD9cGqgTJ6CoEp%2BakJpcAJQE%3D

Is there any way to get the jxl prediction tree to generate images bigger than 1024x1024?

would be sick to be able to make desktop backgrounds using prediction tree art

1024x1024 is the max size per tree, but you can tile the trees into 2048x2048, 4096x4096, 8192x8192, ect

Actually, I lied

Adding `Upsample #` as 2, 4 or 8 will do what I said above, but actually scaling the image instead of just tiling

thanks, I was running into tiling like you mentioned. Playing with the Upsample value seems to expand the image properly, though I noticed it starts to blend colors together

That'll be because of the upsampling mode, there's a flag in cjxl to use nearest neibhour but it's not in the art tools yet

fair enough, so I could theoretically break out the hex editor and add the flag into the image myself?

maybe that or start helping out with the art tools repo. I appreciate the help so far, kind of fun to abuse a feature of image compression to do things like this

you would have to embed your upsampling weights into the codestream, idk if editing an existing file is allowed. anyway, it takes a lot of bytes relative to the tiniest jxl art

dang, probably not viable then to do it via text editor. Thanks for the input and I can look at the art tools if I have time

One of these days I'm gonna make a visual JXL codestream editor

i'm trying to write a parser but i'm still not sure what spec I should go by as there seem to be multiple specs

the latest one

can u link?

https://discord.com/channels/794206087879852103/1021189485960114198/1169087534060556339

that's the official one?

It's the latest one Jon has posted. I don't think there have been any notable changes since then.

ok thanks

When it says ```A bitstream is a sequence of bytes. A codestream is a bitstream that represent compressed image data and metadata. N bytes can also be viewed as 8 × N bits. The first 8 bits are the bits constituting the first byte, in least to most significant order, the next eight bits (again in least to most significant order) constitute the second byte, and so on. Unless otherwise specified, bits are read from the codestream as specified in B.2.1.``` does this mean the bytes `00101111 01010101` would be read `1-1-1-1-0-1-0-0-1-0-1-0-1-0-1-0`? is this correct interpreted?

yep

so it allows reading e.g. 8 bytes at once and process from LSB in little endian system

that's clever, so i can just load a u64 and just do ```cpp uint64_t x = read_8_bytes_from_file(); for(int i = 0; i < 64; i++) { printf("%d\n",x&0x1); x >>= 1; } ```

yeah something like that

there are some tricks to read bits much faster (which libjxl uses)

are the bits in the code stream read in the other order again then?

so like if i needed to read 4 u1's and a u4 from `01110101` i would get `1 0 1 0 0111`?

like `x &= 0xf; x >>= 4;`?

yeah exactly

that's really clever

it's a bit confusing (at least for me), but very natural to computers

this is probably the wrong channel, lets go to my old thread

https://discord.com/channels/794206087879852103/1208362658705838090

Cool, someone other than me used my fork <:BlobYay:806132268186861619> thanks! :D

I haven't done jxl art for a while but when I do in the future I will definitely use your fork

Thanks! And maybe I'll get back to trying to clean up the way ace-editor was included (to the proper but currently non-working way) so that others will accept my PRs.

I like it on desktop. On my phone, not so much...

**\_wb\_** _“Painting with light”_ 2024 image/jxl 31 bytes https://jxl-art.lucaversari.it/?zcode=C3IOUTDgcsosSUktKMlQMDTg4spMU0hWsAOKKigAmQFFqWWuRUVQAQUFXQW%2FcAVdIyjbsSw9XNtPwRCiNlwXKGenoGsIlgUK%2BAFFEAIgDeEKCDbIIEOoQcGpOanJJUBJAA%3D%3D

ooo

I like how those green and blue diagonal strokes look kind of natural (like someone used a blurry brush in Gimp or something), which was something I was not expecting

(considering the simplicity of this tree)

**Jonnyawsom3** _“New Wallpaper”_ 2024 image/jxl 51 bytes https://jxl-art.lucaversari.it/?zcode=RYzLCsIwEEX38xV3L4GkqOimoEVwFcQHs5Z2bAMVQgz9fqca6O5wzsy9Nnfs6BhyJzEPcJY4dAr7raWzhH7I2KwtPeLn%2BY6joCIKL7SoYQlQvCSZTikVARh4hqkKH6aeVx7uf8tGWw3jflWFV7OI%2BYGx8DzkytBNRmmzxi8%3D

Always fun playing with the RCT

Readable

Because of vertical split? Making the layout adjust to screen aspect ratio seems sensible. I just would never actually edit any jxl-art on my phone, so I don't need space for a keyboard. And without the need to accommodate the screen space used for a touch keyboard the use case is just viewing. And if I wanted to view some jxl-art on my phone I would hold my phone in landscape mode for the vertical split anyways. And maybe even with a horizontal split since the code area is adjustable anyways.

Yes, it would be nice to change the split direction depending on screen orientation. I don't really like landscape mode on phone (in terms of ergonomics)

The ergonomics of holding the phone that way? Or having to change back and forth because of using portrait for discord and landscape when clicking a link to view jxl-art? Or the constant switching keyboard on/off to be able to see the screen when keyboard covers the webpage?

All of those, but mostly the first and last.

**NewFeverish** _“Fadeout Sierpiński”_ 2024 image/jxl 25 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTg4spMUwjX9QtXsFMw4FJQAPL8gFwgzxDIU1DQVQiHsxzL0sO1gSpB6nQVglNzUpNLgJIA

A little bit different than "Sierpiński Gradient", where this time the gradient is facing up and to the right

neat

we should add some syntax to jxl_from_tree to signal it's PQ instead of sRGB, so we can make some HDR jxl art

Wide gamut & HDR version of a sunset

only 121 bytes for this beautifful image ??? [⠀](https://cdn.discordapp.com/emojis/853492103145324554.webp?size=48&quality=lossless&name=woag)

Color management can certainly change the demeanour of an image, very nice shades of blue at the top (Waterfox)

best viewed in Thorium on a recent macbook (or anything else with a good HDR display) 🙂

I don't have amd setup right now and am on linux so I can't view T.T

My 8 year old phone is the only HDR device I own, and I don't think any of the gallery apps currently support HDR

tried tonemapping to sRGB with jxl-oxide and seems like it overflowed

it was totally ok when decoded to bt2100 pq

some weird glitchiness happening on thorium

I think it's fixed; artifacts seem to be from extremely out-of-gamut input

it should be allowed to clip input to [0, 1] because the input rendering intent is Relative, but not sure

macOS (left) and jxl-oxide (right) tonemap a bit differently

jxl-oxide looks better to me 😉

« L’application ne répond plus »

Loupe (not sure about the underlying implementation)

loupe uses JXL oxide iirc

maybe jxl-oxide with external cms

seems like they're using jpegxl-rs, which means libjxl

interesting, I think it used jxl-oxide at one point, or maybe im mistaken with another viewer, could be crossing wires with occulante

it did used jxl-oxide but switched to libjxl mainly because of performance and some remaining bugs

ahh I see

I like the way this looks in Thorium

The Adobe Lightroom rendering is different, still OK but I guess it behaves differently for out-of-range values

Almost looks like a signature in the bottom right

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

it's the short version of my signature, my initials JS

time to remake this

Ahh, on my display it blended into the background somewhat, I see it now

I could have made it some bright neon color for some extra HDR effect, but I didn't want it to distract from the actual 'painting' 🙂

"Unexpected node type: This\n"

Is there a corresponding `jxl_to_tree`?

i've been wanting something similar, apparently it existed in an old version of benchmark_xl?

There was some info here about reverse engineering JXL files https://github.com/google/google-ctf/tree/main/2023/quals/rev-jxl/solution

looks like coold advertising for the format

That's interesting. I'll have to read more into that.

Alternatively, since [AllRGB.com](https://AllRGB.com) has been mentioned before, has anyone looked into recreating any of the high-compressed images there using `tree_to_jxl`?

jxl-oxide fuzzer playing around with jxl art

(decoded by libjxl, jxl-oxide seems to have a bug with upsampling+spline)

thanks for helping me test jxlatte bugs

The webapp seems to max out at 2048x2048 resolution, does anyone know a workaround? I need 4 times as many pixels to make it to 16777216

Best to use jxl_from_tree locally for larger images. I dunno why the web version runs out of memory, might be you just cannot allocate very much from js

Where can I find documentation on jxl_from_tree?

The web app is based on it, so you just put your tree in a text file

macOS is still having issues rendering it

preview fails with it for me

same

**\_wb\_** _“Barfing Chips”_ 2024 image/jxl 45 bytes https://jxl-art.lucaversari.it/?zcode=C3IOUTBS4HLKLElJLSjJUDDmCi0oTswtyElVMOLiykxTCNf20%2FULV7BTMOBSUNBVcCxLB4oo6JqCee5FiSmZqXklCmZcAA%3D%3D

**CrushedAsian255** _“Stage Spotlight”_ 2024 image/jxl 38 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsODiykxTqFSwU7AwMOBSUIBzDIEcBQVdBT8FXSMwEyiTDJSBiINkglNLFIzAmhB8Q5ghfiClUEldhXAgNoUZ6KqgrWDEBQA%3D

first time really attempting JXL art

Expanded version of 🤮

Thanks, can't unsee that anymore now <:KekDog:884736660376535040>

If you zoom in you can see it's something like RAM chips etc that is being barfed

Techno-vomiting

**\_wb\_** _“Irregular diagonal lines”_ 2024 image/jxl 31 bytes https://jxl-art.lucaversari.it/?zcode=C3IOUTDgcsosSUktKMlQMOZyK0rMTQ3IL1YwUNA1NzDg4uLKTFMI1%2FbT9QtXsFMw51JQ0FXwc1XQNQaz3IsSUzJT80oUTLgA

Kinda looks like rain

Hair via a microscope

Vinyl record grooves?

How does the "Select" predictor work?

**Anonymous** _“Completely Bonkers”_ 2024 image/jxl 70 bytes https://jxl-art.surma.technology/?zcode=VY%2B9CgIxEIT7fYrpZSHZ835sLATRKggWeQCNeJ1IOPTtTXJZPbuZyXw7ZDfGa3jEOwai8YYXtrCEpPzhmPXGmI7AcOC%2FXBpb4j36El9SaAhZnp5hSk6yLQQ7X1%2BREA9uvlI7LgNWK%2Bkq950anyd%2B07KuTN1pF4cXWkjpPJfq7%2FlrumaNIcVkqGWs5phxDhHSth8%3D

It's defined like this: `abs(N − NW) < abs(W − NW) ? W : N`

It's from lossless webp

**\_wb\_** _“Yet another phone wallpaper”_ 2024 image/jxl 51 bytes https://jxl-art.lucaversari.it/?zcode=Lcq7CsJAEIXhfp7i9DKwq5GkEjSFVkG8sHVwx2QgyhKHPL8jWB2%2Bw39pb4h0UMtSbERNSbPvug50Eh1GQ9UEupdP%2FyqToCLSJ9Kq4y5hB24I8OM8y%2BIMLoCxXwZPwPHvq0zyMPCWfjrOfVZ5GzaRvg%3D%3D

Thank you!

**CrushedAsian255** _“RayBeams”_ 2024 image/jxl 43 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKz0wB0qaGRlweqZnpGSVgZpBzCFCKKzNNwU%2FBTsHQxIRLQUFXwc9VQdfQAMgEioeDxC2NgBwwN6AotQwkYmQBFgGpdixLd8zJgeqAKksGqoFxQWqCU3NSk0sUdE2RxMIVDLmwKNdVcC9KTMlMzQO6EGFgJZqBcDXIgn4K2oYA

**CrushedAsian255** _“RayBeams 2”_ 2024 image/jxl 42 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKz0wB0qaGRlweqZnpGSVgZpBziIKhGRdXZpqCn4KdgqGJCZeCgq6Cn6uCrjGQBRQOBwlbGgE5YG5AUWoZSMTIAiwCUuxYlu6Yk6Oga2gAFQIqSwaqgXFBasKB0ihcQy4sKnUV3IsSUzJT84COQ5hViWYWXA2yoJ%2BCtiEA

**dogelition** _“Flag of Austria”_ 2024 image/jxl 41 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKz0wB0pYGBlweqZnpGSUKZkAmV2aaQqWCnYKhpSWXggKUYwzmgLnJQK4BmAPnGkK5Cgq6CsGpJQomZmgChjABCNfIAGIAlGdqyoVmMpq5aKaimIkwEQA%3D

Nice

**\_wb\_** _“Approximate Flag of Austria”_ 2024 image/jxl 37 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgCs9MATIsLS25PFIz0zNKFMzMzLi4XFJzShIDEnNSS0pSubgy0xQqFOzAMroKwaklCrqGYMFKoKCRkSGXggKUY2JiDOQoKEBUmZkjcQwtLLiQJAA%3D

**spider-mario** _“Swiss Flag”_ 2024 image/jxl 102 bytes https://jxl-art.surma.technology/?zcode=zZIxEgIhDEV7TpELOBNUXLaxsLK38AAuunQWFHp7dxE0gWCpVvBD5v83CTsfBncNI1h19MN09htUe%2BcvY4hX5c9why1oiwogiS6KKE%2BTfIqX1EkCLODgAixtUVjnjvSubXabzU1H%2FG6sUCWKqWKykF4TkNBVj3WbMXUusggRpoEjAtVIaSwUKDHmNXyXhwBoi1IrG1MDrInWhGvgfdgh%2FTg%2FmQ%2F%2FRP8wH5ZVJBS%2BzO3t8QA%3D

oops, there is already a previous entry for that

smaller, too (but a different shade of red)

you can make a "savoie" flag instead

salut, savoie ?

(sorry)

**\_wb\_** _“My phone wallpaper”_ 2024 image/jxl 29 bytes https://jxl-art.lucaversari.it/?zcode=43JJzSlJDEjMSS0pSeUKz0wpyVAwMTDl8kjNTM8oUbA0MOAKLShOzC3ISVUw5OLKTFMI1%2FbT9QtXsFMw4FJQ0FVwLEsHiijoGpmDue5FiSmZqXklQMUA

as far as I understand, both shades of red are legal: https://www.fedlex.admin.ch/eli/cc/2015/613/en#annex_2/lvl_u1

<@794205442175402004>’s is “RGB 255 / 0 / 0” whereas I went for “Pantone 485 C”

(I googled the sRGB values for that)

playing around with the `Gradient` value (i just tried 1 - 10) produces some very interesting results

the country of the croziflette ! so you can recycle your swiss flag and make a new one nobody made yet 😄

**\_wb\_** _“Unpredictability”_ 2024 image/jxl 51 bytes https://jxl-art.lucaversari.it/?zcode=43JJzSlJDEjMSS0pSeUKz0wpyVAwMjCx4PJIzUzPKIGwuTLTFMK1%2FXT9whXsFAy4FBR0FRzL0oEiCrpGBmDZdKCEkSGcZQRnGYNVuxclpmSm5pUomKByzVC5RqhcCy4A

**dogelition** _“Chromatic Stripes”_ 2024 image/jxl 22 bytes https://jxl-art.lucaversari.it/?zcode=c0nNKUkMSMxJLSlJ5QrPTCnJUDA1NOLySM1MzygBM7l0FfwUdI2MuQA%3D

Reminds me of this

the publish button isn't working so I guess I have to do this manually

**Lonnie** "*Some fucked up shit idk*" 2024 image/jxl 29 bytes https://jxl-art.lucaversari.it/?zcode=c0nNKUkMSMxJLSlJ5QrPTCnJUDA1NOLySM1MzygBM7mcMktSUguAEoZcXJlpCuG6fuEKdgq6hlwKCkCuH5AP4yoo6CqEK8BYQGUGXCBGcGpOanIJUBwA

Alternatively, at a higher bit depth

without looking at the code, guess what I did

one small change and

one more small change and

it didn't work for me in firefox (maybe because of enhanced tracking protection? idk), but it worked in chrome

Made a very fast and rough 'HDR' version, but not owning a HDR screen I don't actually know if it worked xD

It's color managed at least, so something changed

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/1281822284318900266/HDR_Test.jxl?ex=66dd1d87&is=66dbcc07&hm=3f6819c7d99e3ce925fe3b8fb5d660ee7c31f5021b99ea8e1da22bfd48ed05b7&

works and looks nice

Could anybody point me to the correct direction of manual jxl creation? I just want to create flag, it is very simple, two horizontal color bars

Can you give us a rough design?

https://upload.wikimedia.org/wikipedia/commons/4/49/Flag_of_Ukraine.svg

This?

Exactly. Now I want to know how to do it 😅

The if commands are prediction branches

If the command is true, it takes the top branch

Otherwise it takes the bottom branch

No, I mean how to convert from code to jxl. And where this screenshot is from

I use this one

https://qon.github.io/jxl-art/?

Thank you!

There’s a different one (the original) that more people use but I prefer that one

Is this the smallest ever?

However I still did not get the idea of these if c > 0, if c > 1, but ok for now

C is the current channel

Although I can optimise that a bit

Am doing some redundant checks

yeah, so basically: ``` if c > 0 if c > 1 - Set (blue value) - Set (green value) - Set (red value) ```

(if using RGB)

More optimised