UnityWebRequest for over 4K images

Unity Engine
1

I have been using UnityWebRequest for ages without any problems retrieving images. But when the images are over 4096 pixels wide the handler returns a purple image (but the request success without errors and the amount of data seems correct)

I really need to use UnityWebRequest because it does the texture decompression on the background and I am working in a VR project

Note: I have tried with Unity 2017.3 and 2018.1

2

If you use Texture2D to load that same image, does it result in correct texture?

3

Yes it does,
if I use something like

Texture2D rawTex = (request.downloadHandler as DownloadHandlerTexture).texture;
                Texture2D t = new Texture2D(rawTex.width, rawTex.height);
                t.LoadImage(request.downloadHandler.data);
                mat.SetTexture("_MainTex", t);

I get this

853×421 392 KB

but if I directly assign rawtex I get

877×421 158 KB

This happens as soon as the image goes over 4096 pixels wide (these are pano images so they are pretty wide)

4

Perhaps you are being hit by the limitation as documented here:

5

I don’t see how the format relates to the RGB format really. Something as simple as opening the app in paint, and saving a a 1k version loads, but transforming it to >4k doesn’t and that should be the same format? I suspect something related to the buffer size or something like that used internally to decompress the image?

6

Can you submit a bug for this?

7

Done 1067886_nrnnkkuhh735e8ci

8

Has this bug been fixed? I can’t find the bug report Mephesto_Khaan created.

It is still a problem in 2017.4.16f1.

9

The fix to this bug will only come in 2019.1, since it’s not a “fix”, but an introduction of new API allowing larger numbers.
On old releases you have to manually check the value of the Content-Length header.

10

Thanks for the reply.

What is the maximum Content-Length currently supported by UnityWebRequestTexture?

11

I believe internally it’s at least 64-bit variable on all platforms. The issue is only with DownloadHandlerScript, where it’s exposed as 32-bit variable.

12

Just ran into this. Thanks for loggin the bug and providing a workaround (performance hickup is acceptable for my usecase)