Really guys, Im not angry and I do grasp it.
I don’t think my description of the problem was misleading .
All the Xojo documentation I could find on saving a picture to disc is ‘all or nothing’.
e.g. If you can’t create it in memory , you can’t save it to disc.
But if the consensus is that even should I succeed, nothing/very few apps could use the result anyway, then I’ll simply not do it.
Not a problem.
[quote=167847:@Jeff Tullin]Really guys, Im not angry and I do grasp it.
I don’t think my description of the problem was misleading .
All the Xojo documentation I could find on saving a picture to disc is ‘all or nothing’.
e.g. If you can’t create it in memory , you can’t save it to disc.
But if the consensus is that even should I succeed, nothing/very few apps could use the result anyway, then I’ll simply not do it.
Not a problem.[/quote]
AFAIK Xojo is indeed all or nothing. But although I am not a specialist of picture formats, I suspect most of the common compressed formats are not “windowable”. All or nothing. In other words not meant to load only a portion of the picture, since their compressed content cannot be accessed in relative terms. Uncompressed bitmap such as BMP could probably be accessed by coordinates, but then they are notorious for their memory voracity.
I see how a picture could be encoded/decoded to a disk buffer instead of memory, or even accessed by portions, which would satisfy your desire, but then performances would probably become unacceptable. Not to mention there is probably no way to use native Xojo picture methods, so it would have to be entirely coded.
Paging seems to be the best option. Just stitch pictures together as needed. After all, this is exactly what geographers have been doing with paper for centuries…
Internally Core Image on iOS processes images as separate tiles and then stitches the files back together when saving.
If you’re generating the image from scratch, you should be able to use ‘tiles’ and then if you create you own bitmap writing code, you should be able to write these tiles out in segments into a single file.
Just bear in mind that most bitmap formats read left to right, top down, so you’d have to use some math and jump around inside the binary stream.
Could you use a vector format? What is the end purpose of these images? With such a large image, I’m guessing high resolution printing? If you’re uploading to Facebook, they have a limit of 2048 on the longest side 
Ah, theres the rub…
I’ve been creating the paged images for years.
In the last few months I’ve had more calls (there are always some) for ‘can I have these all as one page but with the same level of detail’?
Basically customers who know what they want, but don’t know or care that things like memory limits exist.
I’ll point them to the stitch-pictures-together sites mentioned above.
Probably no.
Best I’ve achieved so far is to use PDF.
DynaPDF recognises where you re-use an inserted image somehow, so it only seems to store a duplicated image once, along with the display coordinates.
This makes the PDF a vastly reduced size, it streams to disc, and for display purposes, most PDF readers don’t allocate more than the screen’s worth of memory to do the displaying.
If you create the bitmap file yourself you can stitch them together within your application. it just means you’ll have to write out the bytes yourself. The TIFF file format is pretty straight forward, and if I remember correctly, you can actually chunk the data into sections…