JPEG XL

https://youtu.be/J_imFJ4Kljw?t=395

esp this classic moment

What if sRGB image interpreted as XYB?

What I sent from Windows and what I received on Android. Some heif-art

this was supposed to be gaussian noise

(I am doing some more explicit SIMD in -e 1)

also, has this not been tried yet? https://discord.com/channels/794206087879852103/794206170445119489/1052917315030745160

writing a fast ANS for JXL is Pain(tm)

I mean `doing Huffman codes per-channel`

ah, nope

my broken dithering code looks pretty cool imo

trying to do better AVX512 fast-lossless.. (source image was supposed to be gaussian noise xD)

one bug fixed, at least one remaining...

Beautiful how noise gets turned into a 🌈 rainbow 🌈 in just one group

More Rainbows

[Seizure Warning!] gifsicle errors are fashinating

(okay, after I cut it, it corrupted even more. In original corruption credits didn't flash)

Our guess was that gifsicle was trying to convert per-frame palette to global palette, but it failed halfway.

This us magic of S5 finale

the issue is discord iirc, open it in your browser

I've had an issue with gifsicle errors that don't happen in browser

but do happen in discord

ah, looks like this one also got corrupted in browser

interesting

Nah, the issue was that gallery website was "optimizing" GIFs with gifsicle on upload, but sometimes it went wrong. I have original uncorrupted one, this one I downloaded from site.

I just use gifsicle CLI

Is it bright enough ?

“oups” indeed

chessboard.png error is not quite flat despite my efforts to improve

that's a pretty heatmap

this is the butteraugli error image at d1, not exactly glitch image

it is still enjoyable and originates from errors 🙂

crosspost from jxl-oxide thread, broken progressive HF gave me these blocky artifacts

not bad, not bad

honestly very good looking by the standards of what happens when you get an image decoder wrong

Built in pixel-art generator :P

That could fit very nice on Minecraft screenshots 🤪

I know the idea of old DOOM demos or a minecraft mod that exists now where you just store game data rather than image or video fascinated me. Obviously it doesn't work every time, but something about storing 20 minutes of full quality gameplay in a few MB if not KB makes me smile

Is it from Sumeru area? Archon quest?

screenshot is taken at Sumeru bazaar. I'm not sure exactly what quest

I'm not sure XYB DCT coefficients are supposed to look like this

The coefficients themselves, not doing idct?

oh, I'm interpreting int16_t as uint16_t

yea, I wanted to check my forward DCT so I dumped the 16-bit coeffs

but then I rendered that image as though they were uint16_t without biasing them

I once accidentally configured madvr to use nearest neighbor chroma upscaling and it made videos look exactly like this cuz of chroma subsampling

something is wrong with handwritten SIMD

fixed single indexing mistake and now it's broken more nicely

oh that *never* happened to me 😛

now some varblocks are a little bit off

maybe dct4x8

is jxl oxide your implementation ?

yeah

there's a devblog thread <#1065165415598272582>

indeed ! but I just had a question 🙂 will it be compatible with the generation of a WASM ?

haven't tested, but it should be

nice !

uh, more like LF coeff problem

maybe LF coeffs are not transposed correctly

fixed, great

Huh, is discord rounding out that image preview for anyone else?

Hasn’t it always done that? Under some limited value of “always”.

For me it's completely circular though, almost like it's being rendered as a profile picture

oh yeah that's a thing discord does now

forgot when they started doing it

I didn't see it because I have discord setup for everything to be square on my end

I know they started rounding corners with the 'gallery view' update, but a literal circle seems a bit extreme

oops

what happened with this one?

don't know yet <:kek:857018203640561677>

ah, figured it out, it was an issue with CfL

first steps trying to read video frames using the FFmpeg API

<@853026420792360980> I’ve copied data out of an AVFrame into a `uint8_t` buffer using `av_image_copy_to_buffer` but it’s not clear to me how it is laid out in the resulting buffer (as is probably obvious from the above image), am I missing something obvious?

the format should be AV_PIX_FMT_RGB48

how'd you get this?

as far as I'm aware, av_image_copy_to_buffer always copies it as planar data

regardless of whether the original image was packed or planar

if you take that buffer and just dump it as a PNG you're going to be interpreting planar data as rgb48be, which is not what you want

also how did you obtain this PNG?

it’s my attempt at reading it in a planar way

the AVFrame is the result of converting another AVFrame from yuv to rgb48 using swscale

if the resulting avframe is AV_PIX_FMT_RGB48 then it's already in packed 16-bit little-endian r-g-b order

if you want planar pixel data then you should use AV_PIX_FMT_GBRP16LE

I'm assuming your native endian is little-endian

I see, thanks

(packed = interleaved, right?)

yes, packed is what PNG uses

and what libjxl takes/receives

do note that buf[0] is the green channel, buf[1] is blue, and buf[2] is red

i.e. GBRP is G-B-R-planar

it's in that order

but RGB48 isn't, is it?

rgb48 is R, G, B in that order

nice, thanks

RGB48 is either RGB48LE or RGB48BE depending on your system native endian

yeah, I found out and decided to set it to LE

thank you for your help

got another one, I guess it's from buggy CfL

ah no it's not CfL as it's chroma subsampled

this looks like HF coefficients are misplaced

or LF ones

one or the other is not in the right place (idk which one cause I dunno the original)

yep, that one is from misplaced LF/HF

both of them were incorrect 😛

at least I'm getting good at figuring these out <:kek:857018203640561677>

Kinda like the little color balls at the bottom (technically spot color I guess)

Those are from some kind of misplaced chroma coefficients

this is the error for the bike testcase

it's very small, which suggests to me something weird is going on

like a typo or something subtle

it's definitely varblock-dependent

can’t seem to get FFmpeg to convert a GBR Y4M to a YUV h.264 MKV

encoding as-is to GBR h.264 MKV works (but is not ideal)

oh no, the green martians from progressive jpegs are back...

JPEG WOKE the new format even more inclusive

This is Just a photo of JPEG XL developments a reeally old photo

6 months ago I saw it shared

that would be very surprising, because 6 months ago, the tool I am working on that produced this did not exist

<:kekw:808717074305122316> classic fab

Smh, imagine not knowing Fab is a time traveler

what did you try?

and does Y4M even support GBR?

what happens with: ``` ffmpeg -i input.y4m -vf libplacebo=colorspace=bt709:format=yuv420p -c:v libx264 output.mkv ```

Y4M has no way to signal the YCbCr matrix, whoever reads it needs to know what it is anyway

to that effect, this works (input is full-range GBR, Rec. 2020 primaries, sRGB TRC): ```bash ffmpeg -colorspace 0 -color_primaries bt2020 -color_trc 13 -color_range pc -i test.y4m -c:v libx264 -crf 14 -preset veryfast test.mkv ``` the output file has those same characteristics and reads properly in MPV

but inserting a `-vf colorspace=ispace=gbr:iprimaries=bt2020:itrc=13:irange=pc:space=bt2020nc:primaries=bt2020:trc=13:range=pc` doesn’t seem to work, it tags the output as YCbCr (Rec. 2020 matrix), but the conversion doesn’t seem to happen properly given how it looks

likewise when using `colormatrix`

`libplacebo` might work better, I’ll have to try that

you might need to reinterpret cast it by piping to rawvideo

oh

GBR (identity) matrix isn't really supposed to be used with yuv444p

ah.

better off with gbrp

I wonder what happens if you try to do `ffmpeg -c gbrp -i input.y4m`

``` Unknown decoder 'gbrp' ```

er wait

`ffmpeg -pixel_format gbrp -i input.y4m`

it seems codec y4m doesn’t have that option

``` Option pixel_format not found. ```

I wonder if you use `pix_fmt` instead

I tried that too, same result (even still mentions `pixel_format`)

ah they aliased it

probably gonna have to do `ffmpeg -i input.y4m -f rawvideo - | ffmpeg -f rawvideo -pixel_format gbrp -video_size 1920x1080 -framerate 30 -i -`

or maybe I should just modify my tool to output YCbCr in the Y4M

non-YUV inside y4m isn't really supposed to be supported

so is that why the `colorspace` and `colormatrix` filters seemingly won’t convert it?

I'm not entirely sure. they might have special code paths for RGB video

rather than multiplying by the identity

and thus could be getting confused somewhere

libautil/csp.c doesn't contain a matrix for GBR, for context <@604964375924834314>

```c static const struct AVLumaCoefficients luma_coefficients[AVCOL_SPC_NB] = { [AVCOL_SPC_FCC] = { AVR(0.30), AVR(0.59), AVR(0.11) }, [AVCOL_SPC_BT470BG] = { AVR(0.299), AVR(0.587), AVR(0.114) }, [AVCOL_SPC_SMPTE170M] = { AVR(0.299), AVR(0.587), AVR(0.114) }, [AVCOL_SPC_BT709] = { AVR(0.2126), AVR(0.7152), AVR(0.0722) }, [AVCOL_SPC_SMPTE240M] = { AVR(0.212), AVR(0.701), AVR(0.087) }, [AVCOL_SPC_YCOCG] = { AVR(0.25), AVR(0.5), AVR(0.25) }, [AVCOL_SPC_RGB] = { AVR(1), AVR(1), AVR(1) }, [AVCOL_SPC_BT2020_NCL] = { AVR(0.2627), AVR(0.6780), AVR(0.0593) }, [AVCOL_SPC_BT2020_CL] = { AVR(0.2627), AVR(0.6780), AVR(0.0593) }, }; ```

er, wait, it is

there's an RGB matrix there

but it probably has a separate code path for that

oh

I see, thanks

I see

I think the chroma matrix is the same for every luma coefficient

but I'm not entirely sure

I think youtube is having “gbr as yuv” issues as well – look at the preview when seeking on: https://youtu.be/mp7n8bX8d2g

I’m not completely sure but I might have uploaded this as RGB

Also their weird blur effect around the video is green.

oh, indeed it is (“Ambient mode”)

I have it disabled so I didn’t notice

tried optimizing entropy decoding and failed spectacularly

been there once or twice 😛

lol I wasn't the only one

a true work of art

entropy decided to take over instead of letting to be optimized

well at least I got the general outline correct

better

I didn't process that the first image was The Gecko until you posted the second

don't panic, your gpu is ok

Patches glitch?

About gpu, it remind me a question I wanted to ask : do they support HDR? Or are opengl, vulkan and the hardware pipelines only capable of 8 bits times four channels?

The programable piplines are HDR compatible AFAIK

well "HDR" is just a transfer function pretty much so anything that can signal either PQ or HLG would be considered lol

sure, but could it handle 10 or 12 bits per channel ?

tbf im not even sure what the original question is referencing.

I was wondering if graphics cards and fragment shaders could handle higher bit depth or higher gamut range as of today

yes, 10 bits is not an issue

(bottom right is full range vs. limited range; bottom left is RGB vs. YCbCr 4:2:2 vs. YCbCr 4:4:4)

graphics cards can render full float and even double float with, and most gpus support 10bpc and even 12bpc output

ok. Indeed I found some sources speaking of R10G10B10A2 or Rf16Gf16Bf16Af16 and even Rf32Gf32Bf32Af32 in opengl ES 2.x 😄

im not sure if gles supports it, but vulkan supports 64 too

it was inverse dct4x8 being done twice

Oh, lol

image from <https://github.com/tirr-c/jxl-oxide/issues/268>

Looks like one chunk got loaded wrong but everything else is correct

oh best bugs

seems unsqueezed very well

(this happened while porting unsqueeze to wasm simd128)

ehhh

on glitch-art should be also posted the image it should have been 😄

where's the fun otherwise? 😛

but assuming I got it right this time... 😛

because my brain spend much time trying to guess what it should have seen, it is a relief to see the answer 😄

oh it's one of the jellyfish.us samples

I think my LF coeffs are missing

or wrong CfL

... or maybe both

oh, this looks like an issue with LLF

if I had to guess

I had a similar thing happen, the problem was off-by-8

well off-by-factor-of-8 but yea

I can see a 32x32 block in the upper left corner of each Group

which is a red flag

it was HF CfL applied to wrong position, but yeah roughly that

makes sense

you can see yellowish chroma artifacts everywhere

Uploading of JXL photos to Facebook from iPhone results in unexpected artifacts.

Jxl encoding is slowing down Jon computer is struggling

The situation is Normal now

Now is superb e9 q18 ♥️♥️♥️♥️♥️

gradients going wild

looks likea CFL issue

those are exactly CFL-sized chroma screwy-bands on the lower left of the image

with a Group looking okay in the top left

CfL coeffs are Modular encoded so maybe that

was it a modular issue?

yes, buggy Gradient predictor

ah, but fixed

makes sense

(you know you've done too much JXL when you can look at an image and say exactly what part of the decoder screwed up)

bot

It looks unusual, do you still have JXL source?

yeah, but jxl image itself is perfectly fine, it was jxl-oxide in development that was buggy

Looks like it's using the LF Coefficients from whatever group is in the upper left corner

Looks a bit like a weird Kiwi

but then it seems to be able to load the data on macrogroup boundaries?

yea, it was an issue with positioning. did fix it

yea, basically each group was using the the LF coefficients from the upper left corner of the LFGroup

Makes sense

mixed up predictors 10 and 11 in WebP lossless

funny that we can still see some faces

these are really nice

we should also make a "glitch mode" in a jxl decoder where it mixes up some predictors 🙂

"cosmic ray mode"

I think a corrupter that shuffles patch indices would be interesting

It’s also fun to create earrape by screwing with predictors in FLAC

Force it to use the fixed predictors then screw with the weights of them

IrfanView likes to show webp with transparency in this way. Not sure why. In reality they are correct, not broken

Looks like it’s ignoring the alpha

And that glitchy looking stuff is what’s “behind” the alpha mask

I’m using these other formats as sort of “warm up” for writing a JXL decoder, I can imagine I’ll be posting a lot in this channel when I properly start

Just learned about canonical Huffman codes, very interesting ideas

Irfanview doesn't actually support Alpha, just replaces it with the background color. So when there's color under the alpha, it doesn't get replaced

It explains why this glitches change if picture was losslessly recompressed

It's why the image details says `Original 32bpp Current 24bpp`

what did you do

incorrectly read the lower coefficients

are you writing a video codec decoder?

what is the source footag?

not source but encoded properly and at a higher bitrate

yeah video codec

which one?

new codec i plan to release soon

oh, you're making one

yup

im probably going to make an image codec

based on the stuff ive read about jxl and webp

nice, it's a fun topic to dive into

what language are you using?

C

fair

is this foss or just personal project

once i release it, it will be essentially public domain

unlicence?

lol

i release under the WTFPL

do what the f*ck you want to public licence

haha niice

huh, I had some memories that WTFPL was considered problematic but apparently it is not or not anymore

it is for Google empolyees i think

but so is Unlicence

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

i added one extra to mine

i added "THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE." to the bottom of my README

apparently not anymore *shrug*

四:四:四

<:H264_AVC:805854162079842314>

There is a bug in the latest version of AVIDEMUX, if you play an AV1 mkv file that is in the encoding state and is not completely completed, and play it to the very end, then for some reason, when replaying, AV1 decoding will break, some data will be clogged with garbage. I have no idea why that is. But finally, for the first time, I was able to look at the true broken AV1

These are no longer primitive DCT AVC HEVC patterns. And something is... Yes, it seems the same thing

That first one actually looks really cool

Four four four

i usually use 四：二：二 or 四：二：零

Oh that's chroma subsampling

四：零：零 is quite uncolourful

yeah, this is what happens when you force SVT-AV1 to encode 444 content without supporting it

Same picture, different results.

Misinterpreting pixel arrays is always fun.

Could you share an example? Just curious

different decoders will show this image differently

Woah, definitely broken

1) Original image - EGA 320x200, 4 bit planes 2) Interpreted as EGA 640x200, 4 bit planes 3) Interpreted as CGA 320x200 2 bpp packed 4) Interpreted as VGA 320x200 8 bpp packed 5) RLE compressed image interpreted as uncompressed.

I'm playing with an ancient SCR image format which just dumps the raw pixel data from VGA video memory, with optional RLE compression. I'm using this work (there's also other interesting retro stuff): https://github.com/Panda381/DOS-Progs

Time to buy a new graphics card

Very intentional glitch art, and not my QOI encoder being borked or anything

I fixed the bugs but I made a note in the commit history so I can revert the library to that version if I want in the future. I bet it'd make for some interesting glitch art when encoding actual images

https://www.reddit.com/r/AskPhotography/comments/1igjl8h/does_anyone_have_a_clue_to_why_this_photograph/

(there are five images)

https://www.rxddit.com/r/AskPhotography/comments/1igjl8h/does_anyone_have_a_clue_to_why_this_photograph/

3 more here without needing to go to reddit <:KekDog:805390049033191445>

Interesting, mixed AC and DC components with random data on the tail

yeah looks like it's the DC of one image that gets truncated at some point (in the middle or towards the bottom of the image) and then goes into the AC of another image.

i was about to respond "i saw this!" but i just remembered that the only reason i saw this was because i clicked on your link yesterday <:galaxybrain:821831336372338729>

or the one above it rather

maybe this can happen if it produces progressive jpegs but the encode somehow sometimes gets interrupted/truncated for some reason, making it produce a bitstream that is just some partial DC scan and the rest is a leftover of whatever was in the buffer before

is there a way to get the actual jpeg files from that reddit post? I can only see transcoded webps

yes, copy the image link of the preview: hxxps://preview.redd.it/does-anyone-have-a-clue-to-why-this-photograph-looks-this-v0-**xr487fhgkvge1.jpg**?width=640&crop=smart&auto=webp&s=27db8a414b62192be05db8b608962412d9a49e3c and change the URL to this: hxxps://i.redd.it/**xr487fhgkvge1.jpg** edit: you can just replace `preview` with `i`, you don't have to remove the rest from the url

You sure that's the original file though?

i'm not sure if/how that gets modified, i assume they scrub sensitive metadata at least

that's a 1080x1350 image, I would expect something higher res if it's a photo taken on a Samsung Galaxy S9

given that the macroblocks are 8x8 pixels in this image it seems correct to me

it's not progressive either, but sequential, which makes it a bit weird that AC and DC are mixed — at least from the jpeg bitstream point of view. I guess it still would be plausible there's some kind of uninitialized buffer problem at the level of dct coeffs buffers (maybe it has dedicated/statically allocated memory for those that still contains data from a previously processed image).

Samsung S9 has an 8 MPx selfie camera and a 12 MPx rear camera, is there a setting that makes it produce jpegs that small?

[doesn't look like it](<https://gadgetguideonline.com/s9/understanding-and-use-galaxy-s9-camera-settings/#1-Picture-size-for-Galaxy-S9S9-rear-camera>)

Could it be a thumbnail instead?

I know my phone has a few corrupted ones that only have a partial scan before turning grey

didn't expected that output when encoding PNG with alpha into JPG using cjpegli:

nevermind, it just seems like it is correct, it's just the guy/tool who encoded that transparent PNG that did some weird things

PNG optimizers will let transparent areas use whatever color the predictors choose, jpegli simply removes the alpha instead of zeroing it

try something like `convert orig.png -background white -flatten input-for-cjpegli.png`

hmm, maybe this pic will do the trick?

if I throw it at the "compress and die" analyzing tool, it just bails lol

> Corrupt JPEG data: premature end of data segment

looks like a metal gear solid effect lol

Does jpeg order with dc then ac or is it interleaved

Not xl , just jpeg1

either

that’s the difference between sequential and progressive

is a scan in JPEG 1 either the DC coeffs or (potentially a subset of the) AC coeffs?

DC isn’t treated specially, it’s just the first DCT coefficient

<@386612331288723469> Jon wrote a nice article on progressive JPEG: https://cloudinary.com/blog/progressive_jpegs_and_green_martians

...you can do lossless pixel art with "free" 8x8 upsampling in JPEG 1 by just using the DC coefficient in macro blocks

i shouldn't be allowed to have ideas

nah, the rendering in Chrome is smoother nowadays

https://github.com/libjpeg-turbo/libjpeg-turbo/issues/459

(you can try it for yourself by opening a progressive jpeg in https://progressive-jpeg-scans.notuom.com/ )

The one thing I don't like about that demo is that it transitions between them, so you can't do flicker tests

Though probably if you add scans with all-zeroes for the AC, it will not cost much extra and that will render as a blocky image

presumably it only blurs them during progressive decoding anyway, no? if it blurred the DC coefficients of the final image after all the other coefficients (if any) have loaded, that'd break the way the image was 'supposed' to look since it wasn't encoded with the knowledge that those coefficients would be blurred at all

if it blurs DC-only macroblocks in the final render that seems like an issue

i made this quality 1 JPEG a few days ago, i don't know for sure but from the looks of it many of the blocks only have a DC component and they're not blurred in Chromium, so i'm guessing it indeed only does it for progressive ones

Looks nice

Oh to be clear I didn't make it, someone sent that image with clear macroblocking and i wanted to compress it more out of boredom

but yeah i also think it looks kinda neat

Lo-fi art

howd you overlay this image's edges on top of another?

I think it just gets aligned naturally if each image is the same width

could you elaborate

how did you make this overlay

It's the DC of one JPEG (Smooth colors) merged with the HF of another JPEG (Edges and fine details) by forcing a corruption

whats dc and hf

DC = the very first DCT coefficient (the rest are called AC); HF = high frequencies

funny artifacts of my own codec (nothing serious, just experimenting)

looks neat 👀

it looks like it's using quad trees in some way?

yes and no. it's a side effect

I mean, there is actually no algorithm that specifically separates blocks into subblocks, it's an artifact, glitch

ah I see

cool entropy encoder bug in my codec

Not JXL, maybe still glitch art tho. Trying to transform float images to be compressible with any 8-bit image codec. Seems to work now, this version didn't...

Anyone have any sharable repos or scripts used for jxl glitch art? Interested in messing around with it

Forgot to post this here, but this was a bug with the [leniency PR](<https://github.com/libjxl/libjxl/pull/4062#issuecomment-2589898362>) > The image you get is the result of accidentally zeroing modular LF groups (while global LF is still fine and so is the HF)

16:1:0 chroma subsampling <:KekDog:805390049033191445>

2022

What's the bug here? Wrongly decoded palettes?

delta palette running on groups independently (messes with the predictors)

(courtesy of Zoltan)

it's a nice effect 🙂

Reminds me of my progressive delta palette, watching the pixels change as more groups load https://discord.com/channels/794206087879852103/1065165415598272582/1365008457383809055

Interesting, looks like it was running on columns instead of rows

that image has LF frame so maybe something is wrong with indexing LF frame buffer?

the bug was in SIMDfying `Epf2Stage`, and in the case where `sigma < min_sigma`, forgetting to copy the whole lane of input to the output and not just the first value (and leaving whatever was in the output buffer from before)

here is how it looks if you at least zero the output

strange, the top looks almost normal

is it enabled on a per-block level?

https://ffglitch.org/gallery/

to which extent is this channel a log of bugs in libjxl? <:KekDog:805390049033191445>

that one was jxl-rs 😁

oh! even better

it's interesting that these blocks are a bit smaller than you'd expect

but yes

_almost_

groups look so small in an image that large

indeed

sigh

F

good enough, ship it

XD

Interlaced JXL

reminds me of that FUIF demo

Reminds me of this (source: <https://github.com/libvips/php-vips/issues/36>)

old Minecraft versions used to have an experimental feature that would let you take 645 megapixel screenshots. it worked by stitching together many smaller screenshots, and basically always produced a glitched result

eh

Something appears to have gone wrong

I bet it’s _fast_ though

no idea why 8x32s would have broken but nothing else

the humble barcode transform

answer is that everything else I changed broke too, I just didn't notice 😛

ope

<@274048677851430913> I tried using your old ReShade fork that added JXL screenshots... <https://saklistudio.com/miniblog/reshade-jpegxl-saga/> Safe to say I think something broke xD

The JXL is 30 bits per pixel, while setting it to PNG gives a normal looking 24 bit file, so I think it's just interpreting my SDR data as HDR data

Wait uhh I didn't remember whether I pushed the simple lossless one or not yet

At the bottom of your blog post, you put a link to a precompiled installer with it

ohh yeah that one already with simple lossless~

tbh I only tested it on pso2 since I didn't have another hdr titles to test xD

I don't even have a HDR monitor, I was hoping it would fall back to SDR since you showed it in your blog 😅

*oh silly me I thought it's an hdr screenshot*

something might be triggering that it got flagged as hdr ><

smh, I had wanted to post a DRG screenshot like this as well 😂

just for good measure

is that using my reshade fork as well?

just drg with gamescope

if hdr is enabled properly, then screenshots appear as expected, as HDR AVIFs

This one was a PNG

then it looks like the game didn't give correct texture format, since my reshade fork is using that for a relatively crude HDR detection

Eyyy, rock and stone!

<@&807636211489177661>

Rock and stone!

DM'd you~ since I don't have the game, are you willing to test the fix?

Ah, sure. Discord didn't give me a notification

new day, new DCT bug

very tricky to go fast

"tall" rectangular dct blocks are annoying

making progress?

I started to implement VarDCT in my decoder, you're scaring me lol

looks like messed up interleaving during dct process

most likely, yeah

it's not too hard if you don't try to squeeze every last bit of performance out of it 🙂

20% of the work is making a correct decoder, 30% of the work is making an efficient decoder, and the remaining 50% is making the efficient decoder correct too 🙂

Not exactly glitch art, but I think I may have weighted smaller blocks slightly too high 😅

Ah well, back to tuning

That's interesting, it looks like some of the chunks are shuffled around

When you compare the whole collage to the miniature screenshot in the first one you can see that whole column and row seem to be missing, as some kind of off-by-one error

It kinda takes skill to break something like that

Possibly multithreading is to blame for the shuffling

yeah it's interesting

I got the last one by intentionally changing the window size while it was taking the screenshot

for the the second one I moved the mouse around, though I'm not sure if that had any effect. the first and third ones were taken without touching the game during the process

uh oh

my AVX2 impl is even worse

oof

Matching Minecraft's missing texture I see

"internet address space map" looking ass

I guess hardware decode didn't like this one

the discord preview is a lot more saturated than the actual image

poor color management in firefox I wonder?

oh it's the zoom causing it, wack

this image is hdr, but somehow it has problems displaying properly i guess

mpv also shows it improperly

tev works though

some weird color blending when downscaling the image it seems

yeah, seems like when interpolated in Rec 2100 PQ (as in the color profile in the image) it ends up doing this, I guess that's the dangers of interpolating in a not perceptually uniform color space

Interpolation should always be done in linear RGB I think The important thing is that showing a color interpolated halfway between 2 stripes will look the same as the 2 stripes side by side when viewed at a distance

The actual number of red photons that the monitor is emitting is what's important

Etc

I think linear RGB is slightly better, but doesn't really solve the issue? Because perceptually, brightness isn't linear, which distorts the middle point. This blog post is about gradients but essentially when you're scaling you're just doing gradients, just on a different scale https://aras-p.info/blog/2021/11/29/Gradients-in-linear-space-arent-better/

Gradients should be filtered however looks the smoothest. It's completely arbitrary what you like. However, any actual lighting math should almost always be done in a physically accurate manner (at least before tonemapping) Here, linear filtering is the objectively correct option. If you show alternating rows of pixels and blend them in a linear space vs a perceptual space (or sRGB etc), the pixels will always look like the linear space on a properly calibrated monitor https://www.shadertoy.com/view/McSyWm Here's a demonstration, although depending on your setup it might not be displaying pixel perfectly which would make it look wrong as basically nobody actually interpolates in linear space when they should

https://www.shadertoy.com/view/lscSzl This has a more thorough description

If you rescale an image and sample it in a way that correctly averages all rescaled pixels in the screen pixel, overall colors from a distance should be completely unaffected Which you'll see if you import that image into blender and scale the camera around or something. Blender has decided that they don't want to interpolate textures in sRGB (in cycles, they do in Eevee), although it doesn't really matter in that case as the raytracing algorithm happening in linear space still means it will look the same at any scale.

oh, right, I get what you mean, my bad, was wrong

though, that only works if the primaries in the linear RGB match the display's primaries, no?

As long as the display emits the amount of red, green, and blue light that you tell it to

I think a properly calibrated display will always look the same given the same srgb signal

that's assuming that the primaries of the display can subsume the primaries of the linear RGB? In the above image, the colorspace is not sRGB, and if the colors or their mid-point is out of gamut for the display, then you would get different results

clip/map then interpolate != interpolate then clip/map

I suppose the "correct" behavior is subjective when the display can't even show the colors. I don't know how best to resolve it if the midpoint is out of gamut. If the endpoints are out of gamut, you could clip before interpolating linearly I don't really have any experience with wide color gamuts though.