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

Reply via email to