Fresco: Image size can exceeds the limit after resize, causing 'Bitmap too large to be uploaded into a texture'

[kunny]

I'd like to display an image as large as possible within the limit, so I decided to write code as following:

ImageRequest req = ImageRequestBuilder.newBuilderWithSource(Uri.parse(NETWORK_IMAGE_URL))
        .setResizeOptions(new ResizeOptions(2048, 2048))
        .build();

SimpleDraweeView v = (SimpleDraweeView) holder.itemView;
v.setAspectRatio(IMAGE_ASPECT_RATIO);

DraweeController ctrl = Fresco.newDraweeControllerBuilder()
        .setOldController(v.getController())
        .setImageRequest(req)
        .setAutoPlayAnimations(true)
        .build();

v.setController(ctrl);

When I run above code with the image whose dimension is 720px*2478px, it is not displayed on the screen but getting following logcat message:

W/OpenGLRenderer: Bitmap too large to be uploaded into a texture (630x2169, max=2048x2048)

So I checked the imagepipeline to see what is happening in the resize procedure, found something weird in generating the numerator.

The numerator is generated In the method getScaleNumerator(ImageRequest, EncodedImage) from ResizeAndRotateProducer class, which calls roundNumerator(float) to get numerator from the ratio generated from `determineResizeRatio(ResizeOptions, int, int).

While getting a numerator value from roundNumerator(float) method, it adds extra ROUNDUP_FRACTION to maxRatio * JpegTranscoder.SCALE_DENOMINATOR, causing the numerator be more than the expected in some cases.

I tracked the value from each process, and the result is as follows:

In getScaleNumerator():

• determineResizeRatio() returned 0.82647294
• roundNumerator() returned 7

In doTransform()

• numerator is genrated from getScaleNumerator()
• With the numerator 7, JpegTranscoder resizes the image into 7/8 of its original size, results resized one has a size of 630px*2169px.

While the final image's height has larger than the limit (BitmapUtil.MAX_BITMAP_SIZE), it will not be shown on the screen.

When I remove adding the ROUNDUP_FRACTION in method roundNumerator(float), it generates a numerator of 6, which resizes the image smaller than the limit(2048px), results final image size of 540px * 1859px.

Here's a question:

• Why additional ROUNDUP_FRACTION is required in generating the numerator?
• If adding ROUNDUP_FRACTION is intended and cannot be modified, how can I avoid the above error?

[massimocarli]

Thanks @kunny for the detailed report of the bug. We're investigating on it.

[LiuDeng]

have this being solved?

[Francesco80]

01-14 04:08:59.726 6191-6223/com.example.android.justjava W/OpenGLRenderer: Bitmap too large to be uploaded into a texture (6432x4893, max=4096x4096)

How to resolve this ????

[michalgr]

This is not fixed yet. We can make ROUNDUP_FRACTION configurable (instead of using constant we can specify it in ResizeOptions with current value being the default one).

[michalgr]

Marking as a starter-task in case anyone wants to help to get this done sooner than later.

[Bots22]

Hey there , we've been asked to contribute on a github project as a semester task of our university (me and my teammate) and since we liked fresco a lot we decided to try to help out here!
We found this issue interesting and we tried to make a progress on kunny's work. I'm attaching our pull request that reffers on this issue! #1273