XSF Discussion - 2019-10-27

MattJ, blurhash calculated server-side or blurhash expected to be sent from the client?

I'd say it should be part of the SIMS

jonas’: I think either works - there are some advantages to client-side (sender)

MattJ: what's the benefit of blurhash over a small BoB preview?

Sender controlled preview doesn't necessarily cover the NSFW case without extra work

the only difference between blurhash and preview is the resolution, right?

Kinda, kinda not

You can get away with lower resolution blurhash because of the blurring

Preview at the same resolution would be blocky

Very

MattJ: most modern rendering algorithms will blur instead of blocking

All blurhash algorithms blur, regardless of image type/etc.

All? There's more than one?

Implementations

Sorry, I have a baby in one hand and the other is multitasking between making lunch and typing

MattJ: if we add a BoB into SIMS, we surely can demand it to be blurred up to the original image resolution ;)

And like a tiny very compressed jpeg image there

8x8 or smaller

I really don't care if you want to spec the same effect a different way that works

I am just trying to do stuff

Currently that means I am not going to get everyone in a channel to upgrade their clients to one that sends a hash, but I have a bit of influence on the server side ✏

Blurhash is well defined with multiple libraries available

JPEG is well defined with multiple libraries available ;)

If you can do better, I beg you to

Reviwe progessive JPEG! :)

12:29:19 Ge0rG> MattJ: most modern rendering algorithms will blur instead of blocking Quality of blurhash isn’t comparable to linearly interpolated pixels of a low-res previow

Zash: awesome idea! make the preview image the first layer of the progressive jpeg, that way we can skip some bits on the actual transmission!

jonas’: this is exactly what I want to learn - what's the difference?

https://blurha.sh/

look at it

technically, I think they use spherical functions or something like that and save the coefficients for those

but I haven’t gotten around to look into it in more detail yet

From when I read the spec it sounded like one block of JPEG

converting an image into an 8x8 px JPEG is a standard feature of any platform that supports JPEG images. Converting into blurha.sh... not so much

The 4x3 JPEG file I made is 667 bytes compared to 28 bytes for the same image's blurhash

and some things display it blocky, some do blur (but so far I haven't managed to find an image viewer that does blur and also allows unlimited zoom)

That's one of these moments where actually studying that stuff at university would have been helpful. Because I don't really understand what blurhash is doing

Need to ask my university buddies at some point

I really like the idea behind blurhash, would be pleased to use it in Movim :)

again, what's the actual benefit over a significantly downscaled picture?

Presumably that the "hash" is smaller.

No jpeg overhead?

The decoding / upscalling is specified?

the jpeg overhead needs to be offset by the additional library overhead, though ;)

okay, https://github.com/woltapp/blurhash/blob/master/Kotlin/lib/src/main/java/com/wolt/blurhashkt/BlurHashDecoder.kt doesn't look like a huge overhead ;)

> We usually decode placeholders that are 32 or even 20 pixels wide, and then let the UI layer scale them up, which is indistinguishable from decoding them at full size.

Heh.

Huh

could be really nice to also use it for the avatars :)

I’d question the "shell-safe" base83 encoding though. the character set contains $ and * and # and { and } and [ and ]

not that it matters much

Daniel, they essentially do what jpeg does

I’m not quite sure why the rendering is that much better though

maybe because they have more bits for the few pixels

Because it's done in JavaScript of course

ah, probably because what jpeg would normally expand to just 8x8 pixels, they expand to more pixels, and they don’t do that linearly, but they evaluate the cosine functions the DCT gave

that’s why it’s smoother than upscaling a 8x8 jpeg

what i dont get

ok there are librarys who let me get the hash from a picture

but i dont see one that let me get a picture from the hash

note, blurhash is a misnomer

it’s not a cryptographic one-way hash function

lovetox, https://github.com/halcy/blurhash-python here is an encoder and decoder thing

where do you see the decode?

https://github.com/halcy/blurhash-python/blob/master/blurhash/blurhash.py#L77

hm yeah but this is some fork

not the original project

but good :)

it’s linked in their readme

I guess their decoders are all JS because web

yeah hm the original project has it in c and only wraps in python

also it lets me just pass a filename

with this fork, i have to install PIL and numpy to even pass something to the lib

which makes sense

(the original C thing also is only an encoder)

why does it make sense, i will never install numpy and PIL only to get a blurhash

insane to me :)

you need PIL to load image data

you need numpy to efficiently calculate the DCT and do the inverse

i dont think so, the c implementation doesnt need numpy so why should the python one

you can do it in pure python, but it’ll be slow

they should just add a decode method to the c version

and nobody needs the pure python one

I bet "PRs welcome"

except that the C version has restrictions on the input file formats. e.g. they don’t support all JPEG and PNG variants

or i save me the whole trouble with 3 thirdparty librarys

and just show the same blurred out placeholder for all pictures

this seems like a gimmick, i get that its nice for webpages with many pictures

but for a messaging client where most of the time only one picture is on the screen

i would not add all that stuff