Processing extremely large images

[atudorica]

Hi,

   I couldn't find out if this question was answered on the forum, but how can one deal with super large images? I have 32 bit fits images of 300 000 X 300 000 pixels or more, which occupy a disk size of about 100 GB each. If I'm trying to load three of them into memory to use Channel Combine for example, I'll obviously be running out of memory, not even 128 Gb is not enough sometimes

    Should I downgrade them to 16 bit, although for some the problem might still remain?

   Are the images always loaded into memory? Any way to go around that? I was thinking to work on a small crop to create process icons, then applying all of them to the large, original image. But then, the background modelling might not be the best for example...

   Thanks a lot!

Alex

[Nocturnal]

Memory consumption for an image is determined by the size, number of channels and internal accuracy. I'm pretty confident that the default internal accuracy is 32b float with optional 64b float. So even if you reduce the depth to 16b before loading PI will still allocate a 32b float number for each pixel per channel.

In other words I think you may need a different solution, perhaps cutting the image into tiles.

[Carlos Milovic]

It depends on the process. Some of them require an internal copy (or several, as in TGVDenoise and almost all of multiscale processes) of the image, at 32bits. Others, just get double accuracy (64bits) in a pixel by pixel scheme.

[atudorica]

Thanks for the answers!

   First of all, I'd like to make color images out of them with Channel Combination. I don't need to remove any backgrounds or gradients in the images; do you think that splitting the images into smaller ones, combining them with Channel Combine and then applying the same stretching, unsharp mask, saturation processes would allow for a seamless transition between adjacent tiles?

   All the best,
Alex

[mschuster]

Alex, if seams turn out to be visible, you might try cutting your tiles with overlapping pixel borders (couple hundred pixels?). And then clip the results to reform the mosaic. This should help reduce seams on processes that rely on local neighborhood statistics (e.g. unsharp mask, adaptive histogram equalization).

Mike

[atudorica]

Thanks Mike, I'll cut them in more manageable sizes with some overlap. Do you have any suggestion as to how should I blend the edges of the smaller tiles together? Making a transparency gradient at the edges sounds good to me, but I don't know how to do that with PI, or if it is possible with it.

[mschuster]

Alex, if the overlaps are wider than process neighborhood sizes, then blending is not needed. Just cut away the overlapping border regions from each processed tile so that their remaining center portions abut exactly with no overlap and reform your mosaic. Try a test on just two adjacent tiles and double check that there is no seam. If you still see a seam then first try again with more overlap. If the seam does not go away with a reasonable sized overlap then blending is the next thing to try. Probably blending would require a software tool or scripting, as doing it manually in PixelMath would be very tedious.

Mike

[georg.viehoever]

The problem with the tiling procedure may be the re-mosaicking, which again requires the full amount of memory (at least for the final image, but most likely also for intermediate images). As long as you don't want to produce an image that can cover the wall of a football stadium (with no visible pixels when viewed from 45 cm distance), it is probably the best solution to downsample the images to something more manageable.

If you want to create a huge panorama, it is probably the best idea to process manageable tiles first (I think Mike's suggestions are very good), and then combine them into a panorama using software particularly created for this purpose, such as Autopano http://www.kolor.com/image-stitching-software-autopano-giga.html.

Georg

[Nocturnal]

I have to admit I also doubted the utility of creating such a tremendous image 

[georg.viehoever]

300 000x300 000 is 83 GPixels. At 200 dpi (very good screen resolution), that's a side length of 38.4 meters. That's a fairly expensive monitor wall..., not suitable for my living room
Georg

[Nocturnal]

I thought perhaps the purpose was a zoomable/scrollable image on the web with tiling being done on the server. Still, I think someone who tackles a project like that already knows how to process images that big so I'm still baffled.

[atudorica]

Hi,

    Thanks for the answers. Mike, I'll try your approach during the next weekend and see what I get. As for the numbers, I got them a bit wrong, the largest image is not 300 000 by 300 000, it is only 180 000 x 200 000 or so, at least for the moment. The utility of such an image is of course disputable, but the least you should know is that they are not meant to be printed on some football field

    Another thing that must be said is that I'm just a PhD student not getting paid for doing this kind of stuff in his free time. The entire team behind such large datasets does not have the time to create nice color images from them, and STIFF (mainly used by the professional astronomers) does not do the greatest job, at least not when compared to PI. An example of STIFF at work (probably terribly unoptimized though): http://dls.physics.ucdavis.edu/Public/map.html and a PS badly processed image of the same kind of data by me: http://www.flickr.com/photos/27891676@N05/8676617436/ (try the largest version). So, the bottom point is that for the science we're doing here large mosaics are not necessary, but for pretty pictures yes, therefore we don't need to have the "expertise" to deal with supermosaics. These datasets are rather small (largest is 9x8 degree with a 0.187"/pixel scale), but there are some that will cover many hundreds of square degrees. What would be the approach to have a uniform, zoomable, nice image for these kind of data if I want to use PI for making the color image?

    An example of tiling at work would be this one, but please keep it low, it's not an official press release yet and must be modified before that happens: http://www.astro.uni-bonn.de/~marggraf/CFHTLenS/?frame=D1 Does that look to you like an unnecessarily big, useless image, which should be downsampled?

   Thanks a lot for the advice, it's really useful and I appreciate it, especially as I'm such a newbie with PI.

Alex



   

[georg.viehoever]

Impressive examples...

I guess the tiled approach is the best approach to PI use at this point. Once you have a good process for one tile, it can easily be applied to all tiles using the ImageContainer.

If you want to compile your tiles into a zoomable gigapixel panorama, I really recommend to use a software was developed for this purpose, such as Autopano Pro (100 EUR, so less than a student costs for one week), which will  also take care of making the remaining seams invisible. The key reason is that the software must know how to handle such huge images that dont fit into your workstations RAM. PI cannot do this at this time.

Georg

[atudorica]

Thanks Georg,

     Do you have any recommendations as to what format should I feed to Autopano Pro? Maximum quality JPEG would be fine? TIFF images cannot be larger than 4 Gb. 100 euro seems reasonable if it's doing a good job, but first I have to buy PI, I was working on a trial version until now. I'm convinced it's worth the money

     My plan is to cut 3x3 square degrees out of these large mosaics with quite some overlap between them (maybe 2-3000 pixels, just in case) and then process one field, saving all the process icons used for that particular field, then applying all of them to all of the other fields. Could I do that by merging all those process icons into one (with merge process icons) and then just applying it to images that I've loaded into the image container? Does it sound like a good idea to you, with a good degree of consistency between adjacent fields?

   Specifically, the processes I'd like to get the tiles through after combining the color channels are:

- Background neutralisation
- Color calibration
- ACDNR
 - Unsharp mask (quite soft)
 - maybe HDR multiscale transform (also quite soft)
 - Histogram stretch (applying the STF to it)
 - Curves transformation
 - Color saturation

   Is this order somewhat optimal, or should I change it?

  All the best,
Alex

[georg.viehoever]

Sounds like a good plan. The general process sequence is good for basic processing. You may want to have a look at the MultiscaleMedianTransform (instead of ACDNR and Unsharp Mask for sharpening and noise reduction). You have heavy blooming in the images - PI does not really have a debloomer due to the fact that this "invents" pixel values. Search the forum for hints on handling this.

Some recommendations:
- Some images need another image as a reference (for instance BackgroundNeutralization, ColorCalibration). You need to make sure that those references work with all your other tiles
- I recommend to make a few test runs first on a small set of images. Nothing is more disappointing than finding out that only a small portion of images looks good of the whole tile set after a weekend or so.
- You can get a ProcessContainer of all processes applied to one image by dragging the blue triangle from the HistoryView on your desktop. You can apply this to a set of images by dragging an ImageContainer on the process icon located on the desktop. No need to apply individual processes to individual images... Search the Forum for ImageContainer and ProcessContainer to find additional information.
Georg