Blurhash.encode very slow

[abdullahIsa]

Hello, thanks for this but somehow Blurhash.encode() seems to be very slow, anyhow to make faster?

[mrousavy]

Hey! This is using the algorithm from the official woltapp/blurhash library with some minor modifications to make it run in parallel.
Keep in mind that this is quite an expensive operation (and isn't fully optimized for speed) which is running on a mobile device (small CPU).

Unless you're seeing minutes of execution time, I'm guessing that this is expected - could you share some numbers?

[abdullahIsa]

Hey! This is using the algorithm from the official woltapp/blurhash library with some minor modifications to make it run in parallel. Keep in mind that this is quite an expensive operation (and isn't fully optimized for speed) which is running on a mobile device (small CPU).

Unless you're seeing minutes of execution time, I'm guessing that this is expected - could you share some numbers?

Hello i see but ya its taking almost a minute or more but while it's running it does not cause any sort of UI/JS blocking. The long time wait makes it feel very slow to users. Thanks.

[rhett-moonward]

Hello, thanks for this but somehow Blurhash.encode() seems to be very slow, anyhow to make faster?

I think this may be a recent bug. I'm having a similar issue but it is only while encoding pictures that are immediately taken and uploaded from react-native-image-picker. Uploading and encoding an image from photo gallery is fine but it gets stuck when encoding an image that is taken from the app.

[terrysahaidak]

Today I had this same bug when I was using blurhash with crop-picker. It turns out that when you give blurhash 2.3mb image to encode it takes some time. So in order to fix this, you need to compress your image to a smaller size. I was using 1000x400px image, and it took only a few seconds on iPhone 11. Using an even smaller image gives pretty much the same result but makes it even faster.

[MortalKastor]

I feel that it's not a bug, but the expected behavior according to the official blurhash Readme:

These implementations are not very optimised. Running them on very large images can be a bit slow.
[...]
The trick to using the algorithm efficiently is to not run it on full-sized data. The fine detail of an image is all thrown away, so you should scale your images down before running BlurHash on them. If you are creating thumbnails, run BlurHash on those instead of the full images.

A trick that can work with react-native-image-crop-picker, but on iOS only*, is to pass something like below as options

{
    compressImageMaxHeight: 32,
    compressImageMaxWidth: 32,
}

so that you get a tiny picture as path to pass to Blurhash.encode, and rely on sourceURL for the uncompressed image.
By doing so, the calculation should only take a few tens of ms.

*on Android, sourceURL is undefined and you can't get the path to the uncompressed image.

[ChristopherGabba]

+1 on this issue. I let the encode run for 2 minutes before I terminated the instance and it would not compute the blurhash. I used the react-native-compressor package to shrink the file to a low quality and max dimensions of 32 x 32 and it ran instantly.

It's definitely related to the image picker's output file size I believe.

[terrysahaidak]

For anyone experiencing slow blurhash encoding make sure you run additional compression on the file before passing it to the blurhash.

Compression of the image is super fast on iOS so it should be magnitude faster than using big images directly.

[ChristopherGabba]

@terrysahaidak Agreed. Would be nice if this was directly part of the encoding function to be honest, at least for iOS. Would make the package more functional on it's own.

[sabeerbikba]

In my understanding, Blurhash applies a filter on top of the image and then generates a hash from that image. During the decoding process, this hash is used to create a base64 image string. This approach works well for the last 3-4 images when the base64 string is added directly to the HTML page, rather than using separate image files. However, this behavior can sometimes cause the page to crash if it contains too many images, making it less suitable for pages with a large number of images.