Large Sprites

Hello there :slight_smile: I’ve recently been loading photos into my drop box and exploring them in a project… how ever i have noticed something… anytime i try to load a large photo like codea crashes

I have not yet tried to copy this uri into a text file and attempt to “download” and display… but i would expect the same result… any ideas? or are files of this size just not supported?

I am calling the image like so sprite(img, Center.x, Center.y, w, h) “img” being the name “Dropbox:fileNameEtc”…

For the time being i will work around it but i am curious is there a max size to the photos codea will load…? or is it just the method in which the image is displayed?

Limit is 2048x2048

ok :confused: yeah the photo is 600?×?3125. I’ve commented out the sprite call… also it seems that it is also too large for spriteSize()
unfortunate :frowning: i was hoping to use it to generate large maps since it seems soo good at generating images

If you post more details of what you’re trying to do, someone may have a bright idea…

I would like to be able to load the image into memory and then be able to edit the extremely large photo (wallpaper for example) and (resize/crop) it to something more manageable… like take my desktop wallpaper, shrink it (within range) and apply a gaussian blur, then save it to be the wallpaper for my codea project. or at least be able to load images and detect if they are too big so it dosen’t crash my app… :frowning: just detecting if the file is too big would be a great start

Thanks for your time @Ignatz :slight_smile:

Codea doesn’t offer any way of examining images without loading them first, AFAIK.

You might try using file I/O to read an image into memory, but how you would determine the size from that, I’m not sure. Maybe someone else will think of something.

Image files usually have a header with the size and color depth information. You can look at the specs for the image format to see how many bytes to read in to get what you’re looking for. Then, if the files doable, you can open it normally.

@Ruttyj I am successfully loading map images for my game which are 9x the size of the iPad screen, e.g. 3096 x 2304 without any issues…

I do use img = readImage(…) then pass that object to sprite, you seem to imply that you are passing the image name as a string which may be less efficient…maybe create the image object first…


@brookesi: That’s very interesting…are you using an iPad > 2? If so, I suspect this works because the later iPads support max texture sizes of 4096x4096; it is Codea that will not let you load larger textures on those devices (it’s a bug). This is an interesting workaround.

Hi @toadkick, I am using an iPad 2 and it works without issue for me…


Ah! Apparently, iOS 5.1 bumped up the max texture size to 4096x4096 on iPad 2 :smiley: So, my theory still holds I think.

@toadkick Nailed!! :wink:

@brookesi Excited to hear there is some hope!!! I am using an ipad mini (original) with iOS 7.0.2 So i don’t believe it is linked with the OS version. It would appear the bottleneck is in the sprite() function itself… since you have proven that it will display these images but not load them… But you say 3096 x 2304 using readImage(…) !!! I expect one would pass the filepath as the argument? so for example if it was in dropbox it would be it would be os.getenv(“HOME”)…“/Documents/Dropbox.spritepack/largeImage.jpg”

Off note: and yes it would be much more efficent… I have read some experiments with sprites: where setContext was used to save sprite in memory to produce 10+ times faster performance… I would like to see how else we could tweek it :slight_smile:

I know using meshes would allow for the possibility of altering opacity while providing a speed boost in performance. now readImage(…) will allow us to load images of any size (larger at least)… mhmm looking promising :slight_smile:

Thanks @brookesi !!! :smiley:

@Ruttyj, I’m not sure about file paths and such, I just do:

-- init()
self.colourMap = image("Dropbox:Map1")

-- Draw
sprite(self.colourMap,x, y, ...)