can't thank you enough for all the extra info mark....I'm going to read it over a few times to make sure I got everything I could out of it. will re-engage this idea as I go forward ... I still need to lock down my maximum presets, so I will still have to play with this in a week or so.
Thanks On Fri, Feb 10, 2017 at 5:29 PM, hh via use-livecode < use-livecode@lists.runrev.com> wrote: > 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 > -- *Tom Glod* CEO @ *MakeShyft R.D.A* - www.makeshyft.com Developer of *U.M.P* - www.IamUMP.com _______________________________________________ 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
