Packer.GetTexturesForAtlas returned textures are not readable anymore (Unity 5.1.1p2)

In Unity 4.6, i was used to access sprites atlases by name to encode them in png and reuse with custom materials.
In Unity 5.1.1p2, the returned atlas are not read/write enabled and throw an exception, for example :

var tex : Texture2D[] = Sprites.Packer.GetTexturesForAtlas("ESS1Body");
tex[0].GetPixels();

UnityException: Texture ‘SpriteAtlasTexture-ESS1Body-64x64-fmt5’ is not readable, the texture memory can not be accessed from scripts. You can make the texture readable in the Texture Import Settings.
UnityEngine.Texture2D.GetPixels (Int32 miplevel) (at C:/buildslave/unity/build/artifacts/generated/common/runtime/TextureBindings.gen.cs:277)
UnityEngine.Texture2D.GetPixels () (at C:/buildslave/unity/build/artifacts/generated/common/runtime/TextureBindings.gen.cs:270)
SaveSpriteSheetScript.Start () (at Assets/_Epsilus/Scripts/Utilities/SaveSpriteSheetScript.js:25)

the returned texture can be seen in the script’s inspector but can’t be read or saved to disk, any help appreciated

Edit : Bug Report Case 708708

I’m still struggling with this. Sprite Packer Policy example in the documentation didn’t work until recently (see Sprite Packer Policy example doesn't work ? - Web Resources - Unity Discussions)
Now it just have an harmless error. Unity tells me that i have to create a custom sprite packer policy :

@ So how to modify the sprite packer policy example to save generated atlases to disk ? Should there not be something like ‘AtlasSettings.enableReadWrite’ ? I’m not familiar with this, ist it more complicated ? Once again, it was working without modifications until Unity 5.

Still no resolution on this?

1 Like

@mvargas please let me know if you find a workaround

We ended up with a solution in which we manually create a copy of the Texture2D, read the raw texture data into that new copy, apply, and copy pixels one by one. Ugly.

I considered importing all the textures with the isReadable flag set, but this prevents these textures from supporting sprite atlases, which is not what we want at all.