I was going to explain once and for all why this is such a tricky thing to do (with really nice diagrams of memory usage and so on), but I figured it would probably take less time to just write a small console app that gets triggered after all the image tiles are exported and which will stitch them all together.
It runs outside the Rhino+Grasshopper process so it has at least 2GB of clean memory to operate in. If you're running on a 32-bit OS and the uncompressed image is larger than 2GB, this will still fail and you'll have to patch them by hand.
The intermediate images get written to the Temp directory, so they'll stick around until Windows deems them stale.
I also adjusted the bit-depth, if the output format is jpg or bmp then I use a 24 bits-per-pixel, png still uses 32 bits-per-pixel. Maybe this will solve the Photoshop loading problems. I cannot test this as my install of Photoshop consistently crashes on startup.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Permalink Reply by taz on April 24, 2010 at 12:07pm
Cool!
Are you going to push that out with 7 or can you distribute it sooner?
I think for all the Adobe Suites you can download a 30 day free trial if you need to.
No, it needs to be controlled from within Grasshopper. It won't work unless the tiles have specific names (different from now) and unless you can supply a plethora of command line arguments.
Dear David Rutten and Dany Boys, I appreciate your explain and clue to the answer. Now I solved the problem with PS script and understand the reason of picture fraction. Thank you .