Please post this "Split it!"- answer, as it is, in LC's blog. This is good even for real beginners.
Large files or large data shouldn't be a reason for _incomplete_ 64Bit implementations that would make once again LC Script slower. > Mark Waddingham wrote: > > > > Tom Glod wrote: > > I will... if u wanna replicate...put an image on a stack..make it > > 32k x 32k > > ..... and try and do a export snapshot of the image, LC goes POOF... > > Trevor > > said tha last version of 8 (8.13) had some memory issues solves, so i > > will try to test is there too. > > Currently, the engine implements 'export snapshot' by allocating a > raster (32-bits per pixel) of the size of the snapshot you are making, > rendering into it and then compressing it. > > So really the maximum size you could hope to snapshot is 16k x* 16k > pixels as that requires 2Gb - the engine in general uses signed integer > indicies, so the maximum memory buffer it can manipulate is 2Gb bytes. A > 32-bit process would probably struggle to do that (due to only having > around 2-3Gb of user address space to use) - as there is overhead in > rasterization and then compression; but a 64-bit process should be fine. > > There is a bug here as (at least in this specific case) the engine > should fail gracefully (as we know there is a hard limit in the size of > an image the engine can process). > > As you correctly point out 32k x 32k comes in at 1Gb pixels - which at > 24-bit RGB comes out at 4Gb of data. No 'normal' 32-bit application > which isn't explicitly designed for manipulating huge images will be > able to deal with something that size. I would expect applications such > as Photoshop to be able to deal with them though since I believe their > native raw storage format for images pages from disk as required (so you > never have the 'whole thing' in memory at once - just the bit you are > looking at / editing). > > One important thing to remember is that the amount of memory required to > take a snapshot is (SOMECONSTANT * 4 * the number of pixels) in the rect > of the snapshot (I've not checked but I would estimate 0 < SOMECONSTANT > < 2) which means that you can get LiveCode to generate very large > images, but you have to break the problem down by splitting up the > snapshot into bands and probably use an external (command-line) tool to > compress the image into your format of choice (how big an image such a > tool can process, again, will be dependent on whether it needs to load > the entire image into memory to compress it or not). > > Rough idea: > > repeat with i = 0 to pHeight / kBandSize > import snapshot from rect (0, pWidth, i * kBandSize, kBandSize) > write the imageData of the last image to file tOutputFile > delete the last image > end repeat > > After this you will have a very large file with the raw xRGB data in it, > so you need to find a tool which can take raw 32-bit xRGB data (with > specified order of the RGB), the width and height and process it into > jpg or png or whatever format you require (I'm hoping others who know > more about such things might be able to chime in here - ImageMagick has > an arsenal of command-line tools, for example). > > Warmest Regards, > > Mark. > > P.S. There is a hard limit of co-ordinate magnitude in LC and thus the > size of any object - 32767 pixels on any side of anything. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
