Accessing pixel values of Texture2D

I was wondering if there is a way to read/write pixel values on a UTexture2D object (e.g. read values from a heightmap or draw something on a texture).

I’ve seen that there are FTexture2DMipMaps stored on the Texture that contain BulkData, which might be the pixel data of the texture. My idea was to get the first mip map and access its data somehow.

Is this even possible? Maybe somebody could give me some pointers in which direction to go.

Thanks!

First you need to understand that a texture is normally, a sum of multiple images called MipMaps. MipMaps are down-scaled versions of your images, always in steps of power of 2, so the original image, is, say, 512x512 - this would be the MipMap “0”, then the engine generates the MipMap “1” which is 256x256 and then MipMap “2” which is 128x128, this continues on down to 16x16 I think. The farther away the texture is rendered, the smaller version of the image is used. This means that you need to access the mipmap 0 of your texture.


First we need to access the mipmap 0 of the texture, it is important to only access the data we need through refrences or, like I did here, pointers, either will do. We do this to directly access the original data in the memory instead of copying that data into a local variable. This saves memory and speed:

FTexture2DMipMap* MyMipMap = &MyTexture2D->PlatformData->Mips[0];

With this, we can access the BulkData which contains the raw image data:

FByteBulkData* RawImageData = &MyMipMap->BulkData;

Considering this texture data is used in the rendering thread, we need to lock it to make sure nothing else can access it while we are using it, if we didn’t, we could cause memory corruptions or crashes. So now we lock the image data which will also return a pointer to it - which we can then go ahead and cast the unformated data into an array of FColor’s:

FColor* FormatedImageData = static_cast<FColor*>( RawImageData->Lock( LOCK_READ_ONLY ) );

The FColor array is ofc 1 dimensional. So to access certain parts of the image, we need to use the width and height of the texture to calculate the position of the pixel we are wanting to lookup. Here’s a small statement that does just that:

uint8 PixelX = 5, PixelY = 10;
uint32 TextureWidth = MyMipMap->SizeX, TextureHeight = MyMipMap->SizeY;
FColor PixelColor;

if( PixelX >= 0 && PixelX < TextureWidth && PixelY >= 0 && PixelY < TextureHeight )
{
	PixelColor = FormatedImageData[ PixelY * TextureWidth + PixelX ];
}

Now, for demonstration purposes, I broke down each step. We could easily access and cast this in one line:

FColor* FormatedImageData = static_cast<FColor*>( MyTexture2D->PlatformData->Mips[0].BulkData.Lock( LOCK_READ_ONLY ) );

And now that we are done with everything, we need to unlock the memory again:

RawImageData->Unlock();

or

MyTexture2D->PlatformData->Mips[0].BulkData.Unlock();

Hope this helps.

I’ve tried this without success. A completely black image (32x32 DXT1) is returning values like:

(R=0,G=0,B=0,A=0)
(R=170,G=170,B=170,A=170)
(R=0,G=0,B=0,A=0)
(R=170,G=170,B=170,A=170)
etc...

Does the mip map raw data already account for texture pitch?

Edit: I just realized this post was old, hopefully you (or anyone) is still around to answer the question though.

The given solution seems to work fine if the following settings are used for the texture;

  • Mip Gen Settings: NoMipmaps
  • sRGB: false
  • Compression Settings: TC Vector Displacementmap

This article might also be of use.

It works for me. Is it possible to sample the texture with bilinear filter? I don’t want the exact pixel value, I need the interpolated value.

Does locking/unlocking frequently affects performance?

Thanks!

Can you answer this question in bluepprints, Thanks!

Hey guys! I’ve done the exact same thing and my editor keeps crashing when I hit play. What I did was make a public Texture2D reference variable in my blueprint class created from my c++ class, asigned a image with NoMipmaps, sRGB: false and VectorDisplacementmap (RGBA8). I’ve then called this code via ReadPixel function I’ve exposed to ue4, but it crashes. What I’ve managed to do is locate that PlatformData->Mips[0] crashes the editor for some reason. Any ideas?

Hi. I used this code to read layer-info from landscape weight map textures.

But what if I want to modify the texture? I changed the lock mode to read/write and wrote colors to the pixel-array, but I didn’t see any effect afterwards :frowning:

Help please!!

I was able to dynamically change textures by procedurally editing their bulk-data, but the next time I restart my project/editor all the changes are reverted.

So how do I save the modified bulkdata to disk? I saved the texture asset after modifying it, but that’s not enough.

edit: actually, nevermind. I found the “persistent” data under UTexture2D::Source.

Hi, any idea about how to do this using blueprints ?

What about on Android? I set texture settings to VectorDisplacementmap (RGBA8) and it works on WIndows desktop. However, it doesn’t work on Android. I think maybe that’s because UE4 on Android uses a different texture format maybe?

On the off chance anybody reads this: TC Vector won’t appear in your editor if you set the texture group to UI. Instead do-

Compression Settings: UserInterface2D (RGBA)

Thank you so much, the answer I needed in the smallest of corners.

I’ve tried your method but my result is always the same color (205, 205, 205) for each pixel, that doesn’t match the visual content of the same texture applied to some mesh in game, have you any ideas?

Thanks.

I’ve got the same issue as invrsion. Does anybody know how to fix this? Or did you fix it invrsion?

Such a hot topic!

I’m trying to find a BP solution too, so there is a Image (Texture2D) to Bytes (PNG) node from Low Entry Extended Standart Library.

And here is the answer: Victory Plugin.

How would you go about getting the center of those pixels?

Same issue here, I can’t UpdateTextureRegions also :frowning:

If it’s crashing for you, try changing ‘FByteBulkData’ to ‘FUntypedBulkData’. It worked for me!

Hope this helped someone!