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

[clytras]

• [✔] 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>
    );
  }
}
...

[clytras]

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.

[mnlbox]

@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

[clytras]

@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.

[tomershohet]

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

[plimerence]

same issue

[jjhampton]

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.

[callcter]

same issue with RN 0.57.1 on Android

[mnlbox]

Any plan to fix this? It's really annoying 😞

[clytras]

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

[callcter]

also in 0.59.1

[clytras]

@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.

[callcter]

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

[hrachqyutukyan]

also in 0.59.3

[mnlbox]

@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? 😥
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: 😥

[gevgasparyan]

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

[glacjay]

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

[glacjay]

react-native-fast-image v5.3.0 works for me 😂

[clytras]

react-native-fast-image v5.3.0 works for me 😂

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

[glacjay]

@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 😂

[lambdapioneer]

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:

react-native/ReactAndroid/src/main/java/com/facebook/react/modules/fresco/FrescoModule.java

Lines 96 to 114 in 8d5ac8d

	@Override
	public void initialize() {
	super.initialize();
	getReactApplicationContext().addLifecycleEventListener(this);
	if (!hasBeenInitialized()) {
	if (mConfig == null) {
	mConfig = getDefaultConfig(getReactApplicationContext());
	}
	Context context = getReactApplicationContext().getApplicationContext();
	Fresco.initialize(context, mConfig);
	sHasBeenInitialized = true;
	} else if (mConfig != null) {
	FLog.w(
	ReactConstants.TAG,
	"Fresco has already been initialized with a different config. "
	+ "The new Fresco configuration will be ignored!");
	}
	mConfig = null;
	}

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.

[tarcisioandrade]

@valery-lavrik Hello, did you manage to find a solution to your problem? I'm having the same problem as you, trying to render an image with a large height, but it doesn't get the right size.

[valery-lavrik]

@tarcisioandrade
The only way I've found is this. Not very nice, but it works
https://gist.github.com/valery-lavrik/11c2c1c3cb03918e1fb14fbb156945eb

[tarcisioandrade]

@tarcisioandrade The only way I've found is this. Not very nice, but it works https://gist.github.com/valery-lavrik/11c2c1c3cb03918e1fb14fbb156945eb

@valery-lavrik Does this code cut the large image into pieces?

That's the kind of image I'm trying to render.

[valery-lavrik]

@tarcisioandrade
Yes, that's exactly what this code does.
And it is these images that I also show in my application. You can see an example of this implementation - https://lavrik.site/

There are a lot of very large images in this comic book reader. I often have to cut them into pieces

[tarcisioandrade]

@valery-lavrik
I saw it, but I noticed that in large images the scroll doesn't look very good with the slide, I think I'll render with webviews anyway :(

[valery-lavrik]

@tarcisioandrade
I don't have any problems with scrolling... Externally, a sliced image is no different from a simple one.

The option with rendering in webview does not suit me because I need to specify headers to upload images.

[GNUGradyn]

How is this STILL a problem???? I can't convert to jpg because I need the alpha channel

[Abbondanzo]

This is a result of using the Fresco image library under the hood, and I tried to provide some customization for this in #44803. Lemmie try to dive in and provide some context.

Some background

There are two problems afoot that have been smashed into one here: one is the result of aliasing issues (as is the case in the example provided here) and the other is the general blurriness that people see when using a particular prop resizeMethod (as is the case from the example provided here).

React Native has a prop on Android, resizeMethod, which lets you control how Fresco determines its own resizing mechanism. In Fresco's documentation, there's a few paragraphs that cover the differences between the mechanisms and which you should be reaching for:

If the image is not much bigger than the view, then only scaling should be done. It’s faster, easier to code, and results in a higher quality output. Of course, images smaller than the view are subset of those not much bigger than the view. Therefore, if you need to upscale the image, this should too be done by scaling, and not by resizing. That way memory won’t be wasted on a larger bitmap that does not provide any better quality. However, for images much bigger than the view, such as local camera images, resizing in addition to scaling is highly recommended.

As for what exactly “much bigger” means, as a rule of thumb if the image is more than 2 times bigger than the view (in total number of pixels, i.e. width*height), you should resize it. This almost always applies for local images taken by camera. For example, a device with the screen size of 1080 x 1920 pixels (roughly 2MP) and a camera of 16MP produces images 8 times bigger than the display. Without any doubt resizing in such cases is always best to be done.

Let me place emphasis on this part: if the image is more than 2 times bigger than the view (in total number of pixels, i.e. width*height), you should resize it

There are three resizeMethod options: scale, resize, and auto. When you don't set resizeMethod, React Native will
default to auto make the choice for you based on the image type: local images get set to resize and network images get set to scale. Scaling can result in antialiasing issues such as this one (notice that the image is pulled from network).

When you apply the resizeMethod of resize to an image, Fresco will take your source image, take the dimensions you wish to scale it to, and find a power of 2 closest to those dimensions. In memory, Fresco converts the source image to the resultant bitmap and renders it. So, if your source image is 1000x1000 but you want to render that image in a 150x150 box, Fresco scales the image down to 250x250 and passes it off to Android to take care of the rest. This is a bit more computationally expensive, but the resultant images are generally better looking.

There's a technique of resizing that Fresco can apply called downsampling. Rather than taking a power of 2, it can take a multiple of 2. This technique is only applied to JPG images, hence you see slightly better results from JPG in examples like this. Calling back to our previous example, our source dimensions of 1000x1000 can be scaled down 6x to 167x167 (Fresco rounds up). Rather than using 250x250, the resultant dimensions of 167x167 are much closer to the desired 150x150.

Finding a(n imperfect) solution

I've tried to remain concise on what React Native is doing, but you're probably more interested in how to fix this. Fresco isn't a perfect solution here. It applies really basic mechanisms for resizing and scaling images on the client that aren't perfect for every use case. First and foremost, I highly recommend producing images as close as possible to the destination sizing. If you can convert your 1000x1000 image to 150x150 ahead of time, this is less work for every client. It's important to recognize that different devices have different pixel densities, so on higher-end devices that 150x150 is actually 300x300 or 450x450. This is why React Native supports the @2x and @3x suffixes as outlined in documentation here. As long as the file names are consistent, React Native will always pick the best image for the pixel density of the device for you.

If you're going to render images served from the network, try fetching them in your desired destination resolution too. You can determine the "true" resolution of an image using React Native's PixelRatio.getPixelSizeForLayoutSize. It's a common, recommended practice to let your server apply resizing and you can reduce the computational overhead of manipulating bitmaps on the client.

If you still want the device to do resizing for you, but your resultant images are blurry, you can tweak the quality of the image with a bit more Fresco customization. Apply a combination of resizeMethod="resize" and resizeMultiplier as outlined in #44803 and the source image you're trying to change the size of will not downsample all the way but will let Android scale the image from a larger dimension. So, back to our 1000x1000 image as a PNG. Let's say you want to scale down to 30x30. If you use resize on its own, the image gets downsampled down to 32x32 (31.25 rounded up). This can result in extreme quality loss. However, if you set your resizeMultiplier to 2.0, then the image is only downsampled to 63x63 (62.5 rounded up). The hardware layer, with a bit of aliasing, will take care of the rest.

Every use-case is different, every solution is different. It's important to find the best solution for your needs. Resizing on the client every time is computationally expensive, but resizing once ahead of build-time is quick. Hope this helps a bit!

[clytras]

@Abbondanzo there are so many use cases that people want to use the original and actual size of the image, like when creating an interactive map (without messing with tiles hell etc.), zooming images without loosing quality, game and parallax backgrounds and the list can get bigger. IMO it's not a good thing for a library or a framework to enforece such optimizations without giving the option to the devs to eliminate such configurations and behaviours.

resizeMethod never worked for this issue, it was completely ignored regarding image downsampling. The only solution was to link Fresco from source, fix the issue by disabling downsample inside Fresco downsampling code and then complile Fresco to use with the app like mentioned here facebook/fresco#2397 (comment), facebook/fresco#2397 (comment), facebook/fresco#2397 (comment).

Fresco isn't a perfect solution here.

I'd argue that, I believe Fresco is a very good image processing library for Android and it does a good job, IMO it's that it should allow people to customize using options when using optimizations and opinionated techniques.

[Abbondanzo]

resizeMethod never worked for this issue, it was completely ignored regarding image downsampling.

Downsampling should have been a new resizeMethod altogether. Unfortunately, the downsample mode (currently) can't easily be configured on a per-image basis.

I'd argue that, I believe Fresco is a very good image processing library for Android and it does a good job, IMO it's that it should allow people to customize using options when using optimizations and opinionated techniques.

Fresco is a great image processing library but not one-size-fits-all in every case. It does a decent job at rendering images provided a dimension but isn't designed to service some of the use cases you've provided, particularly in conjunction with the limitations set by ReactImageView. There's a higher incentive to craft assets fitted to exact uses, across multiple dimensions (and part of the reason why the Image component supports source sets). Forwarding that work to the client, whether it comes in the form of downloading a larger image over network or the processing time it takes to perform a resize, should be avoided if possible.

I'd love to open it up for further customization, and I'm all ears for ideas. The FrescoModule that React Native publicly exports lets you set your own ImagePipeline or ImagePipelineConfig and, one step further, the MainReactPackage takes an ImagePipelineConfig if you want to customize it even further. Since these settings are entirely Android-specific and set at the beginning of the application lifecycle, they don't make much sense as Image component props. Most of the defaults are sane (with the exception of the downsampling mode, that's being fixed) but if there are other optimizations or techniques that Fresco does haphazardly, we should fix 'em!

[clytras]

Downsampling should have been a new resizeMethod altogether. Unfortunately, the downsample mode (currently) can't easily be configured on a per-image basis.

Exactly, and that's why it can't work using resizeMethod per component as you suggested above.

Fresco is a great image processing library but not one-size-fits-all in every case. It does a decent job at rendering images provided a dimension but isn't designed to service some of the use cases you've provided, particularly in conjunction with the limitations set by ReactImageView. There's a higher incentive to craft assets fitted to exact uses, across multiple dimensions (and part of the reason why the Image component supports source sets). Forwarding that work to the client, whether it comes in the form of downloading a larger image over network or the processing time it takes to perform a resize, should be avoided if possible.

You are missing the point of consistency. The behaviour on iOS is different. This issue does not happen on iOS when using the RN stock <Image/> component. If we have a platform to support multiple devices using the same code/components/libraries, then that platform must ensure the consistent behaviour accross devices when using stock and built-in components. Fresco is a Meta project, that even though it's not bound to RN directly, it was originally made to feed the RN needs. Somewhere near 2018 (RN 0.56), they made image downsampling the default behaviour and they break that cross platform consistency.

The assets and images may be bundled inside the app, and I agree with you that large image sizes should be avoided, but if the use cases need such assets, then the platform must easily allow the developers to use such big assets, which wasn't the case here.

I'd love to open it up for further customization, and I'm all ears for ideas. The FrescoModule that React Native publicly exports lets you set your own ImagePipeline or ImagePipelineConfig and, one step further, the MainReactPackage takes an ImagePipelineConfig if you want to customize it even further.

Unfortunately that is not the case for image downsabling. We cannot alter that configuration using ImagePipelineConfig. We tried that in the past and it never worked because the downsabling flag was not connected within Fresco.

Since these settings are entirely Android-specific and set at the beginning of the application lifecycle, they don't make much sense as Image component props. Most of the defaults are sane (with the exception of the downsampling mode, that's being fixed) but if there are other optimizations or techniques that Fresco does haphazardly, we should fix 'em!

I think you are wrong here. RN does have dozens of platform specific component properties (to name some capInsets > iOS, fadeDuration > Android, onPartialLoad > iOS, progressiveRenderingEnabled > Android).

[Abbondanzo]

You are missing the point of consistency. The behaviour on iOS is different. This issue does not happen on iOS when using the RN stock <Image/> component. [...] Somewhere near 2018 (RN 0.56), they made image downsampling the default behaviour and they break that cross platform consistency.

iOS does its own downsampling too (source), so I believe that the intention was to bring Android's performance and approach to image rasterization inline with iOS here. It's just that downsampling isn't working as initially intended. Being prescriptive of optimizations or enhancements clearly didn't work in this case, so until that gap can be closed, it's best to disable the behavior and make it opt-in.

Unfortunately that is not the case for image downsabling. We cannot alter that configuration using ImagePipelineConfig. We tried that in the past and it never worked because the downsabling flag was not connected within Fresco.

The 3.2.0 version of Fresco has a new flag to disable downsampling outright, thanks to @sunnylqm's work. It can be manually configured if you wanted to set up your own pipeline config in the application, in the same spot you'd normally build the auto-generated PackageList. I've just spent a good while reading through all the comments in facebook/fresco#2397 so your code snippets are right on the money. And I'm going to try my best to get #45078 merged soon so this change is automatically made for everyone.

RN does have dozens of platform specific component properties

Yep, and those are all useful for their various purposes, but the pipeline config is created while the React Native Host is being spun up. It's not something that can be tweaked on a per-image basis, that's where the ImageRequest from Fresco comes in. My intent was to call out that any modifications to the image pipeline config should happen in native code and there's really no room to push them into component props.

[clytras]

iOS does its own downsampling too (source), so I believe that the intention was to bring Android's performance and approach to image rasterization inline with iOS here. It's just that downsampling isn't working as initially intended. Being prescriptive of optimizations or enhancements clearly didn't work in this case, so until that gap can be closed, it's best to disable the behavior and make it opt-in.

I don't doubt that it does, but the images don't get any visual transformation at all, so here relies the issue with Android and iOS inconsistency. What you see in my OP of this issue does not happen on iOS.

The 3.2.0 version of Fresco has a new flag to disable downsampling outright, thanks to @sunnylqm's work. It can be manually configured if you wanted to set up your own pipeline config in the application, in the same spot you'd normally build the auto-generated PackageList. I've just spent a good while reading through all the comments in facebook/fresco#2397 so your code snippets are right on the money. And I'm going to try my best to get #45078 merged soon so this change is automatically made for everyone.

Yes, after almost 6 years, in 3.2.0 after @sunnylqm fixed it; providing custom configuration for the ImagePipeline might work, but we didn't have had that back then when this issue appeared, we could not bypass this behavior easily just using configuration, that's my point.
This code that was there was preventing the downsampleEnabled flag to apply or not the downsampling algorithm.

-    if (downsampleEnabled || !statusHasFlag(status, IS_RESIZING_DONE)) {

Yep, and those are all useful for their various purposes, but the pipeline config is created while the React Native Host is being spun up. It's not something that can be tweaked on a per-image basis, that's where the ImageRequest from Fresco comes in. My intent was to call out that any modifications to the image pipeline config should happen in native code and there's really no room to push them into component props.

I know that and I already have agreed with you but still you seem to ignore this:

Downsampling should have been a new resizeMethod altogether. Unfortunately, the downsample mode (currently) can't easily be configured on a per-image basis.

Exactly, and that's why it can't work using resizeMethod per component as you suggested above.

Look @Abbondanzo, you discovered this issue recently and I appreciate the fact that you are eager to help as we all want that issue to be resolved, but keep in mind that we were here "fighting" for this 6 years ago and along those years passed we've done some progress.

This was an issue. Meta closed this issue back in 2019 because they said it was Fresco's issue regarding not handling the props #21301 (comment). Fresco team kept the issue opened until @sunnylqm commited some fixes that are based on some proposals like this facebook/fresco#2500 (comment). This means that they recognize this was indeed an issue and we now have better and easier ways to overcome this behavior.

[tiliarou]

Unbelievable to see multi billion sh** company unable to handle a 6 years old bug affecting millions of users. So easy to transfer respo to third party as usual...

[Abbondanzo]

x-posting my update from #45078

• Add resizeMethod type 'none' to disable downsampling on Android #46866 was merged and adds a new resizeMethod called none. This maps to the NEVER downsample mode in Fresco on a per-image basis.
• I've added documentation regarding this new resize method to https://reactnative.dev/docs/next/image#resizemethod-android with a brief disclaimer about what I've shared here: it can be a footgun that causes runtime exceptions
• Add example of different resize methods #46873 adds a showcase of each of the four resizeMethod to the RNTester app. I'm setting up tests to run against these images to ensure that downsampling is always correctly turned off when this prop is supplied

You can follow along with the release status of this change by checking out the tags associated with 6202319 (right now there are none). When you pick up the change in a new release, it should be as simple as using it like this:

<Image 
  source={require('./assets/my-large-image.png')} 
  resizeMethod="none" 
/>

[clytras]

Thank you @Abbondanzo for diving into this issue and providing such a nice solution 🔥
After 6 years we'll have this resolved for good. Better late than never!

[valery-lavrik]

x-posting my update from #45078

• Add resizeMethod type 'none' to disable downsampling on Android #46866 was merged and adds a new resizeMethod called none. This maps to the NEVER downsample mode in Fresco on a per-image basis.
• I've added documentation regarding this new resize method to https://reactnative.dev/docs/next/image#resizemethod-android with a brief disclaimer about what I've shared here: it can be a footgun that causes runtime exceptions
• Add example of different resize methods #46873 adds a showcase of each of the four resizeMethod to the RNTester app. I'm setting up tests to run against these images to ensure that downsampling is always correctly turned off when this prop is supplied

You can follow along with the release status of this change by checking out the tags associated with 6202319 (right now there are none). When you pick up the change in a new release, it should be as simple as using it like this:

<Image 
  source={require('./assets/my-large-image.png')} 
  resizeMethod="none" 
/>

You can't imagine how long I've been waiting for this! how much shit code did I have to write because of this))))

[tarcisioandrade]

x-posting my update from #45078

• Add resizeMethod type 'none' to disable downsampling on Android #46866 was merged and adds a new resizeMethod called none. This maps to the NEVER downsample mode in Fresco on a per-image basis.
• I've added documentation regarding this new resize method to https://reactnative.dev/docs/next/image#resizemethod-android with a brief disclaimer about what I've shared here: it can be a footgun that causes runtime exceptions
• Add example of different resize methods #46873 adds a showcase of each of the four resizeMethod to the RNTester app. I'm setting up tests to run against these images to ensure that downsampling is always correctly turned off when this prop is supplied

You can follow along with the release status of this change by checking out the tags associated with 6202319 (right now there are none). When you pick up the change in a new release, it should be as simple as using it like this:

<Image 
  source={require('./assets/my-large-image.png')} 
  resizeMethod="none" 
/>

You can't imagine how long I've been waiting for this! how much shit code did I have to write because of this))))

WOOW, Now I don't have to cut my images to pieces anymore 😂

[sunnylqm]

Thank you @Abbondanzo for diving into this issue and providing such a nice solution 🔥 After 6 years we'll have this resolved for good. Better late than never!

Just found that the day @clytras raised the issue was exactly the day my second girl was born. no kidding she is in primary 1 now 🤣