bbrks / go-blurhash

🖼#️⃣ A pure Go implementation of Blurhash

go-blurhash

A pure Go implementation of Blurhash. The API is stable, however the hashing function in either direction may not be.

Blurhash is an algorithm written by Dag Ågren for Wolt (woltapp/blurhash) that encodes an image into a short (~20-30 byte) ASCII string. When you decode the string back into an image, you get a gradient of colors that represent the original image. This can be useful for scenarios where you want an image placeholder before loading, or even to censor the contents of an image a la Mastodon.

Under the covers, this library is almost a straight port of the C version, which is known to encode images slightly differently than the TypeScript implementation.

Contributing

Issues, feature requests or improvements welcome!

Licence

This project is licensed under the MIT License.

go-blurhash's Issues

(MISSING)

After trying to generate a blurhash from this webp image

I get the following blurhash: LUC%!j(MISSING)g-=RixvyGo~nhS5jFj?kCWB

What does (MISSING) mean? I couldn't find any info about this.

Insanely slow

PNG image 1000x1000 pixels and 366 kB in size takes 2.7 seconds to generate 5,5 quality hash. That is insanely slow. How come?

Add DecodeDraw to allow custom image types

Originally, the library only has a Decode function that would always return an *image.NRGBA. This is a minor inconvenience, as some other functions (such as libjpeg's) can only do RGBA or other image types.

As a fix for the above inconvenience, a DecodeDraw function was added:

func DecodeDraw(dst draw.Image, hash string, punch float64) error

This function decodes the given hash and punch (which is now float64 for granularity) and draws the decoded image onto the given draw.Image.

The older Decode function now calls DecodeDraw internally on an *image.NRGBA. This ensures that the API isn't broken.

Benchmarks

After the changes, with Decode now calling DecodeDraw:

goos: linux
goarch: amd64
pkg: github.com/bbrks/go-blurhash
BenchmarkComponents/LFE.@D9F01_2%L%MIVD*9Goe-;WB-8         	62727241	        18.2 ns/op
BenchmarkComponents/LNAdApj[00aymkj[TKay9}ay-Sj[-8         	66509407	        17.9 ns/op
BenchmarkComponents/LNMF%n00%#MwS|WCWEM{R*bbWBbH-8         	56069827	        18.0 ns/op
BenchmarkComponents/KJG8_@Dgx]_4V?xuyE%NRj-8               	67373836	        17.9 ns/op
BenchmarkDecode/LFE.@D9F01_2%L%MIVD*9Goe-;WB-8             	    1254	    924818 ns/op
BenchmarkDecode/LNAdApj[00aymkj[TKay9}ay-Sj[-8             	    1296	    882316 ns/op
BenchmarkDecode/LNMF%n00%#MwS|WCWEM{R*bbWBbH-8             	    1214	    940441 ns/op
BenchmarkDecode/KJG8_@Dgx]_4V?xuyE%NRj-8                   	    1431	    805385 ns/op
BenchmarkEncode/LFE.@D9F01_2%L%MIVD*9Goe-;WB-8             	       6	 187144765 ns/op
BenchmarkEncode/LNAdApj[00aymkj[TKay9}ay-Sj[-8             	       9	 122129504 ns/op
PASS
ok  	github.com/bbrks/go-blurhash	16.277s

Before the changes:

goos: linux
goarch: amd64
pkg: github.com/bbrks/go-blurhash
BenchmarkComponents/LFE.@D9F01_2%L%MIVD*9Goe-;WB-8         	67750879	        18.4 ns/op
BenchmarkComponents/LNAdApj[00aymkj[TKay9}ay-Sj[-8         	56951818	        23.9 ns/op
BenchmarkComponents/LNMF%n00%#MwS|WCWEM{R*bbWBbH-8         	41726830	        26.1 ns/op
BenchmarkComponents/KJG8_@Dgx]_4V?xuyE%NRj-8               	50471245	        26.8 ns/op
BenchmarkDecode/LFE.@D9F01_2%L%MIVD*9Goe-;WB-8             	     962	   1295024 ns/op
BenchmarkDecode/LNAdApj[00aymkj[TKay9}ay-Sj[-8             	    1233	    976301 ns/op
BenchmarkDecode/LNMF%n00%#MwS|WCWEM{R*bbWBbH-8             	    1249	   1128537 ns/op
BenchmarkDecode/KJG8_@Dgx]_4V?xuyE%NRj-8                   	    1171	   1109666 ns/op
BenchmarkEncode/LFE.@D9F01_2%L%MIVD*9Goe-;WB-8             	       6	 190812766 ns/op
BenchmarkEncode/LNAdApj[00aymkj[TKay9}ay-Sj[-8             	       9	 120429582 ns/op
PASS
ok  	github.com/bbrks/go-blurhash	16.912s

Note: the performance is roughly the same, as the compiler is probably smart enough to know and inline the function call.

why is the component restriction from 1-9?

I get this error when trying to compute a 16x9 blurhash:

"blurhash: must have between 1 and 9 components"

But I can enter 16x9 here - https://blurha.sh/

So I'm curious why that limitation exists

Official BlurHash repo

The official implementation with documentation and explanations is now live at https://github.com/woltapp/blurhash, in case you want to link to it!