search

mrousavy / react-native-blurhash

🖼️ A library to show colorful blurry placeholders while your content loads.
https://blurha.sh
MIT License
1.98k stars 70 forks source link

[BUG]encoding performance #127

Closed zhigang1992 closed 3 years ago

zhigang1992 commented 3 years ago

Bug

Describe the bug Encode image hangs forever. (more than 10 minutes) 65002079883__EF07E735-C2CD-4F2D-AAE6-039A86ED0917.HEIC.zip

To Reproduce Try to encode a image taken by camera

Expected behavior It should return within reasonable amount of time

Screenshots image

Environment

Additional context iOS Xcode 12 iPhone XS Max

info Fetching system and libraries information...
System:
    OS: macOS 12.0
    CPU: (20) x64 Intel(R) Core(TM) i9-10900K CPU @ 3.70GHz
    Memory: 23.71 GB / 64.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.5.0 - /var/folders/v4/8jyh3pp92x58b6gkspmqv7z00000gn/T/yarn--1628488191469-0.9396605774893039/node
    Yarn: 1.22.10 - /var/folders/v4/8jyh3pp92x58b6gkspmqv7z00000gn/T/yarn--1628488191469-0.9396605774893039/yarn
    npm: 7.19.1 - /usr/local/bin/npm
    Watchman: 2021.06.07.00 - /usr/local/bin/watchman
  Managers:
    CocoaPods: 1.10.2 - /usr/local/lib/ruby/gems/3.0.0/bin/pod
  SDKs:
    iOS SDK:
      Platforms: iOS 14.5, DriverKit 20.4, macOS 11.3, tvOS 14.5, watchOS 7.4
    Android SDK: Not Found
  IDEs:
    Android Studio: 2020.3 AI-203.7717.56.2031.7583922
    Xcode: 12.5.1/12E507 - /usr/bin/xcodebuild
  Languages:
    Java: 15.0.2 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.2 => 17.0.2
    react-native: 0.64.1 => 0.64.1
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found
✨  Done in 2.83s.
"react": 17,
"react-native": 0.64,
"react-native-blurhash": ^1.1.4
mrousavy commented 3 years ago

Hi! Thanks for the bug report! It hits the encodeBlurhash line, right? So it's not failing in loadImage?

zhigang1992 commented 3 years ago

Yeah, it stuck at encodeBlurhash line, loadImage has no issue.

I've also tried using the latest Swift implementation from blurha.sh and it's the same.

Maybe I should open an issue over there instead

zhigang1992 commented 3 years ago

I think it's related to this

https://github.com/woltapp/blurhash/issues/19

Will try to resize the image first

zhigang1992 commented 3 years ago

It reduced to 4 seconds now when resized to 32x32 and then encode

It encodes super fast now when resized to 32x32 first

mrousavy commented 3 years ago

What pixel format does your UIImage have? I assume it's not RGBA8888, right?

zhigang1992 commented 3 years ago

What pixel format does your UIImage have? I assume it's not RGBA8888, right?

I actually have no clue. 😄

It's a image returned from https://docs.expo.dev/versions/latest/sdk/imagepicker/ that's taken by the iPhone's camera app.

mrousavy commented 3 years ago

Image is HEIF/HEIC Screenshot 2021-08-09 at 16 41 05 apparently colorspace is RGB, I really wonder why that's so slow. Maybe the stride implementation would solve this, or as he mentioned in the issue, moving the pixel conversion outside of the loop would work? You could experiment with that if you are a bit familiar with Swift.

Btw, why are you encoding the images on-device anyways? I always used a backend for this to run the C-implementation on this which was 100% reliable and fast and doesn't block the user

zhigang1992 commented 3 years ago

We are using firebase as our backend, upload file directly to firebase storage bucket and get the download URL.

We actually do have a backend cloud function that automatically encode any new upload photos, but it's a async process, which means that for a few seconds after the upload, the image hash will not be available.

Which is a bad user experience for a real time live streaming app.

And after resize to 32x32, the encoding is now <100ms. It's acceptable performance even if it's blocking the user a little bit more (Users are already blocked for the duration of uploads, a few more ms should not be that obvious)

I think the slowness is related to the efficiency of the swift implementation.

An image the size of 3024x4032 is pretty heavy to do a for loop on.

zhigang1992 commented 3 years ago

I don't think there are any actions to be taken from this repo, will close this issue now.

😄

mrousavy commented 3 years ago

I think the slowness is related to the efficiency of the swift implementation.

Yeah I think it is pretty fast but there are a few things that can still be improved. If you have time and want to investigate this, I'd happily give you pointers in the right direction :)