React-native: RN 0.57.x Bundled large images have low quality when viewing using <Image/> component with 1:1 AR on Android

Created on 24 Sep 2018  路  56Comments  路  Source: facebook/react-native

  • [鉁擼 Review the documentation: https://facebook.github.io/react-native
  • [鉁擼 Search for existing issues: https://github.com/facebook/react-native/issues
  • [鉁擼 Use the latest React Native release: https://github.com/facebook/react-native/releases

Environment

React Native Environment Info:
System:
OS: macOS High Sierra 10.13.6
CPU: x64 Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
Memory: 111.21 MB / 12.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 10.9.0 - /usr/local/bin/node
Yarn: 1.9.2 - /usr/local/bin/yarn
npm: 6.2.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3
IDEs:
Android Studio: 3.1 AI-173.4907809
Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild
npmPackages:
react: 16.5.0 => 16.5.0
react-native: 0.57.1 => 0.57.1

Description

There is really low quality when loading large bundled images even when using resizeMethod="resize". This happens only on Android, not on any iOS simulator/device. Have tested it on Android 8.1 emulator and LG G6 with Android 8.0. Please see the screenshots bellow.

At the left screenshot we see the exact same code running with RN 0.56.0 and at the right screenshot we see RN 0.57.1. The code is just a simple image <Image source={require('./assets/ELHall1.png')} resizeMethod="resize" /> and the image size is 2111 x 4645 pixels. Both projects are fresh installed using react-native init RN057ImageTest and react-native init --version="0.56.0" RN056ImageTest

Reproducible Demo

It's the initial App.js with the <Text/> components commented and an <Image/> component added.

...
type Props = {};
export default class App extends Component<Props> {
  render() {
    return (
      <View style={styles.container}>
        {/*<Text style={styles.welcome}>Welcome to React Native!</Text>
        <Text style={styles.instructions}>To get started, edit App.js</Text>
        <Text style={styles.instructions}>{instructions}</Text>*/}
        <Image source={require('./assets/ELHall1.png')} resizeMethod="resize" />
      </View>
    );
  }
}
...
Bug Android 馃摝Bundler

Most helpful comment

also in 0.59.3

All 56 comments

After converting the PNG image to JPG, it renders just fine in full quality. Digging a little bit further, and reading about resizing mode at http://frescolib.org/docs/resizing.html, I read that resizing method has a limitation:

Resizing has some limitations:

it only supports JPEG files

I don't know if this is related with PNG, but it works using PNG images in RN 0.56.0.

@clytras I have same issue with remote images.
I also try fast image package but it's also low quality.
I'm using JPEG images and it's not fixed.
My React-Native version is 0.57.1

/CC: @DylanVann

@mnlbox did you find any fix for this issue? I am still stuck with RN 0.56 for now just because of this issue. The sad thing is that noone replies which makes me think this might be a missconfiguration or something related. I also have opened a SO question about this issue with irrelevant answears unfortunately.

EDIT
Still there with RN 0.57.8.
I'm also surprised how a behavior change such as this one, isn't marked as a bug since there is no documentation of how this type of behaviour changed and how would it work from now on.

I can confirm this change happen on my app as well, when updated to 0.57.8 and that it happen on 3rd part library like react-native-photo-view

same issue

I'm also seeing this issue in an application I'm working on. Using the RN Image component, I'm displaying a large .png image has actual dimensions larger than the screen, with the Image component resized to display within the screen's boundaries. The .png image displays, but at incorrect, low-quality, visibly pixelated resolution, on Android.

This bug does not occur on iOS. On Android, when I downgrade the app to React Native v.0.56, this bug also does not occur.

same issue with RN 0.57.1 on Android

Any plan to fix this? It's really annoying :disappointed:

This bug still exists in RN 0.59.0 and of course in the previous versions RN 0.58.x.

also in 0.59.1

@callcter there are some workarounds to this one like using a WebView or FastImage component or to replace the PNG image with an other format like JPG. This is a bug/issue started with RN 0.57.0 when then added a new metro bundler version/features. Best guess is that the bundler fetches a smaller/compressed/resized version of the image which is related to Fesco lib, the library that RN uses to handle images for Android.

FastImage is related to Glide and with error:
"Canvas: trying to draw too large(111720960bytes) bitmap"
@clytras

also in 0.59.3

@cpojer Any plan to fix this?
This issue really decrease my app quality and anyone ask me why your image still buggy after 8 month and I haven't any answer for this? :disappointed_relieved:
Why RN team release a version without quality check and enough test?
With this release approach we need add something like bellow to my app description after each RN version upgrade: :disappointed_relieved:
bre4o3t89xrz

react-native-fast-image v4.0.14 works fine but since v5.x it is broken.

react-native 0.59.5 encounter the same issue with local and remote .jpg images too 馃槀

react-native-fast-image v5.3.0 works for me 馃槀

react-native-fast-image v5.3.0 works for me 馃槀

@glacjay FastImage does not support local bundled images: https://github.com/DylanVann/react-native-fast-image/issues/248

@glacjay FastImage does not support local bundled images: DylanVann/react-native-fast-image#248

@clytras fortunately (or unfortunately) our projects doesn't use local bundled images 馃槀 so react-native-fast-image should be enough for me ... except that I need to change A LOT OF Images by FastImages 馃槀

Hey, this is Daniel from the Fresco team.

From the initial issue description it seems that the behaviour changed between 0.56.0 (June 2018) and 0.57.1 (Sep 2018). During this time the dependency of Fresco wasn't upgraded in ReactAndroid/build.gradle or ReactAndroid/gradle.properties. Only the OkHttp3 dependency was updated which seems unrelated.

For debugging, it would suggest to enable logging to logcat here:

https://github.com/facebook/react-native/blob/8d5ac8de766b9e435cbfa9bfa6b8a2b75b0e2a19/ReactAndroid/src/main/java/com/facebook/react/modules/fresco/FrescoModule.java#L96-L114

You can follow https://frescolib.org/docs/listening-to-events.html under RequestListener on how to register the RequestLoggingListener which will dump all information to logcat. That would be helpful for deciding whether this is caused by Fresco or some other change.

How to reproduce this bug here as minimum example:

  • update create-react-native-app to the latest version:

    • node.js: 10.15.3

    • npm: 6.9.0

    • yarn: 1.16.0

    • create-react-native-app: 2.0.2

  • create-react-native-app TestImage

    • template: blank

  • App.js:
import React from "react";
import { Image, Dimensions, Text, View } from "react-native";

export default class App extends React.Component {
  render() {
    return (
      <View>
        <Text>Open up App.js to start working on your app!</Text>
        <Image
          source={{
            uri:
              "https://wagonsclub.oss-cn-beijing.aliyuncs.com/static/carousel/carousel1_bg.jpg"
          }}
          style={{ width: Dimensions.get("window").width, height: 1000 }}
        />
      </View>
    );
  }
}
  • yarn start
  • run on my android device (1+5):

鍥剧墖

is there a fix to this problem? i cant seem to find a workaround.
using rn 0.59.0

Edit:

Changing the format from png to jpeg did "kindish" of improved the image. Still waiting for a fix or a workaround.

This is .jpeg
image

This is .png
image

update:

it HAS to be something with sizes. Im no pro here, but incresing the size of my png (original 720x6412) to 1024x5000 (could not increse height more because i lack the tools to do so) seemed to improve a lot.

image

hope this helps someone!

issue not fix on rn 0.59.8

Until today do I notice that create-react-native-app is deprecated...

So, here is the new minimum example project to reproduce this issue, created by react-native-cli v2.0.1, with the latest version of react and react-native. I'll try to keep it up to date until it's been solved.

Come across a temporary fix for my online project (not the example project above) for some cases, by remove some blurred images' borderRadius style. Hope it's helpful for someone.

I came across this issue as well.
Was working in _v0.56_. I'm now on _v0.59_.
In particular I was trying to render my image inside a ScrollView.
However I dont think that makes a difference from what I am seeing from others here as well.

My work around was to simply cut up my large image into smaller sections and have them render underneath one another.

For reference, my image resolution was: _1154 x 3838_
Afterwords, I cut the image in PS into 3 even parts.
Then just render:

<Image source={ imgPart1 } />
<Image source={ imgPart2 } />
<Image source={ imgPart3 } />

As a bonus performance improvement, I then switched to using a FlatList which will only load the corresponding image portion as the user is scrolling.

I know this may not be a applicable solution for others but might be worth checking out.
Hope this helps.

update example project to react-native v0.60.3 and the problem remains

any plan to solve this proble?

Why is this not fixed. My images look like garbage

This problem still exist in 0.59.9

Has anyone found out what is the maximum dimensions that we can use before it begins to look blurry?

  • Edit: I've tested a few and believe that the maximum dimensions is 2000 x 2000 in pixel.

@OriginLive React and React Native are community driven and everybody can contribute. I've spent some time trying to debug and solve this problem, but with no results. There are some workarounds that you can do like using JPEG images, or using other components to display the images. Of course we all hope someone with the knowledge and time will pick this issue here and solve it for good.

This problem still exist in 0.60.4

React Native use Fresco to render images on Android, and every props passed to Image component will be passed to Fresco. So it's not really React Native issue. Anyone interested can work on Fresco to land the feature.

@dulmandakh I think where the issue belongs to still remains uncertain, see https://github.com/facebook/react-native/issues/21301#issuecomment-486620268
Better reopen this until there is a clear conclusion

I just tried to narrow the version range. Now I can confirm that the issue was introduced between 0.56.1 and 0.57.0-rc0

@dulmandakh you shouldn't have closed this. We have comments from @lambdapioneer from Fresco team here. You got this wrong, please read my initial post again, as this is not a FEATURE request, this is a BUG, a bug that didn't exists before 0.57 at least.

You just closed an existing RN bug, why? To reduce the issues number? Anyway, maybe you know better than all the people here.

@lambdapioneer Actually I found a fresco version bump (1.9.0 -> 1.10.0) between 0.56 and 0.57 https://github.com/facebook/react-native/commit/b6f2aad9c0119d11e52978ff3fa9c6f269f04a14

Update:
I just confirmed this issue was caused by fresco version >= 1.10
After change fresco version back to 1.9.0 and soloader version to 0.3.0 on top of 0.60 branch https://github.com/facebook/react-native/blob/0.60-stable/ReactAndroid/gradle.properties#L15 , this issue is gone.

We cannot downgrade fresco version, and it's not supported in Fresco. If
Fresco adds support for it, I would happy to review and help to land it in
RN.

>

react-native-fast-image v5.3.0 works for me 馃槀

@glacjay FastImage does not support local bundled images: DylanVann/react-native-fast-image#248

Now,react-native-fast-image support local bundled images
<FastImage style={{ width: MyTheme.width, height: MyTheme.width/1080*8100 }} source={{ uri: Image.resolveAssetSource(require('../images/user_guide.jpg')).uri, cache: 'web' }} resizeMode={FastImage.resizeMode.cover} />
react-native: 0.60
react-native-fast-image: 7.0.2

rant_begin

@dulmandakh if RN can't support things that where working and break them just like this and with no documentation and by end devs/users discovering them, then RN should get rid of these components from the core and transfer them to external repos like Geolocation and Async storage, because those components obviously can't be supported by RN itself. I believe you get the picture.... something now working like this and suddenly in the next version not working, and on top of that, contributors and collaborators tell end users that it's not RN fault, but other libraries that RN uses (from the same domain/org BTW, Fresco is Facebook OS). What do I suppose to do now? Go at Fresco repo and open an issue there? Really? You could do that yourself instead of just closing this.

rant_end

@sunnylqm thanks for tracking down this issue and confirming my initial culprit. It's a bit obvious that Fresco is the problem here and now we know it for sure.

@zhuweideng thanks for letting people here know that FastImage now supports bundled images. I'd prefer an OOB way to handle large images because Image component exists and things where working until some point.

@clytras (Unfortunately) that's how oss works. You get both benefits and risks. Ask and wait and provide whatever you can provide, or just do it yourself, or walk away. Please stop blaming anyone working for OSS project.

@sunnylqm I am working to OSS projects myself and I know exactly how things work, please check my previous comment here https://github.com/facebook/react-native/issues/21301#issuecomment-516320519:

React and React Native are community driven and everybody can contribute. I've spent some time trying to debug and solve this problem, but with no results.

My rant is not for the nature of the OOS and that no-one picked this up to fix, besides please look the date that I committed the issue... it's almost a year ago. Since then please find a single comment that I complaint that contributors and collaborators do not do anything here. I don't think you'll find any. I'm frustrated about the fact that people just close an issue that is still there, that still exists. We have a problem here gentlemen and what do we do? we go and close the issue with no further actions. Well yes, the least I can do is to blame someone for that.

@clytras
In Chinese we say "You are blessed if others help you, but they are not obliged to."
I also feel frustrated about how rn core team deal with issues (one-year-issue just can not get a name in the list), but I fully understand and I can see that they are improving. I can say that "contributors and collaborators do not do anything here" is NOT true because there was a member from fresco team commented here (though he missed the point), which is very rare in this repo believe me.
Everyone have their problems, and yes they can not blame anyone who does not owe them anything. You have the right to ask for help anytime anywhere in any mannerly way, and feel lucky if someone do.
P.S I am on holiday but still busy working. I got notification so I came here and spent some time to help debugging. I was planning to open an issue in fresco repo but I think I need a minimal example using different fresco version to demonstrate but I really have no time at present. And after all why should I do this?

@sunnylqm please, you got it wrong. I forgot to add a question-mark at the end of that:

Since then please find a single comment that I complaint that contributors and collaborators do not do anything here. (?)

What I mean there is that I DO NOT complaint about anyone here. I know that contributors and collaborators like you and @lambdapioneer @dulmandakh working to make React and React Native better and we are all thankful for that. But when I think something is wrong I will tell/write about it. You call it as you like, OOS nature, disrespect, but I'll do it. I'd do it even if Mark Zuckerberg himself came here and close this issue. I have nothing personal to anyone, not you not @lambdapioneer @dulmandakh . I explained what bothers me.

I never said that you are obligated or you have to go and report the issue at Fresco lib, I said that @lambdapioneer @dulmandakh should have done that himself before he closed this but that is my point of view and I don't think I insult anybody by making that statement. So please don't go and report this bug at Fresco repo, I'll do it myself when I'll come back from my vacations.

Sorry for my misunderstanding. But you also got the wrong person, it's not @lambdapioneer who close this issue. Although I agree this issue should remain open, I understand the point that this is not directly related to RN and hence closing it is reasonable. If you want to argue, you better make a revert pr to discuss there. Anyway, I think this thread is done and further discussion should go to fresco repo and I'll follow there.

Yes, my bad! I'm sorry @lambdapioneer my rant does not go to you, but to @dulmandakh that closed this issue.

@sunnylqm I'll create an issue at Fresco next week when I'll return to my office. We can all discuss there about that issue and maybe finally fix it. Again thanks for helping track this down.

I contribute to RN on my spare time, and I had a time that I was creating
issues and waiting to be fixed. Some were fixable in RN, some others don't.

I found that issues that are related to third-party modules makes issue
tracking harder because we cannot do anything about it in RN. There are too
many third-party modules and we cannot keep track of them all. This is
s the reason I closed the issue and suggested to file in Fresco. Thank you

No worries :) no offense taken. I understand that it can be very frustrating when infrastructure breaks and the issue appear to be ignored and/or falls between the cracks.

@sunnylqm thanks for finding that version bump and confirming that the breaking change is associated with a particular Fresco change. That should help pinning down the underlying issue. Not sure how I missed that commit.

I assume it's related to how Fresco scales downs (sub-sampling) large images (which is an important feature for memory and performance concerns). There has been some changes in these area during that time mainly for removing native code dependencies to help reducing the also pressing .so unsatisfied link errors. So to say: it might be a side-effect of another large improvement.

Disclaimer: I no longer work at Facebook. I'll quickly link @oprisnik here who should be able to assign this accordingly :)

I'm just wondering why we can't keep this issue open until it's been fixed. Does the count of open issues matter so much?

And there are so many issues had been closed not because it's been confirmed been fixed, but just because there is no one commented for a while. Can't understand quite well.

@glacjay The count of open issues matters simply because human can not read too much. If you cut them some slack, they will go out of control like this. Imagine how would you deal with 5k+ issues? Where to start? You just get drowned.
Of course I agree sometimes it's ironic if people response with +1 it'll be locked ("too heat"), or no response it'll be closed ("inactive").

So I think we need a better issue management tool instead of just closing unfixed issues :-)

I am new to React Native development and facing the same problem with the image quality. Have any of you solved it or is there any solution yet?

@thnayan69 What is your react native's version? What are the dimensions of the images that you are using?

The discussion/workarounds are moved to https://github.com/facebook/fresco/issues/2397

@gorvinsky here's the details

  • react-native-cli: 2.0.1
  • react-native: 0.61.4
  • image size: 960*960

_Just adding my 2 cents:_

React Native (and therefore Expo) handles images in Android using @2x / @3x.

So, just copying and renaming my image to [email protected] and [email protected], the rendered image quality was much better (not HD so, but, well, it wasn't blurry and it's readable).

Also, I used JPEG instead of PNG, as PNG looked really aliased for the same image quality with Android.

Was this page helpful?
4 / 5 - 1 ratings