Orthorectification taking 10 hours; advice on optimisation?

development
#1

Hello,

I’m processing fine quad-pol RADARSAT-2 images through java with the following steps :

  • Subset
  • Radiometric Calibration
  • Convert to C3
  • Polarimetric Speckle Filter
  • Extract polarimetric parameters (17 of them, including 3 virtual bands)
  • Orthorectification

When I launch the Range-Doppler Terrain-Correction algorithm on the 17-band product, it takes 10 hours to write the resulting orthorectified product. This seems unreasonable. Do you have any advice on how to make this faster ?

SDB

Note : I’m using an external DEM, subset-ed to the scene I’m working with.

Here is my code :

package com.batchprocessing.java.snap;

import java.io.File;
import java.util.HashMap;
import org.esa.snap.core.datamodel.Product;
import org.esa.snap.core.gpf.GPF;

public class Orthorectify {

public static Product RDTC(Product product, File imageFile, String processingDone){
    File DEMFile = GetDEM(imageFile);

    GPF.getDefaultInstance().getOperatorSpiRegistry().loadOperatorSpis();
    
    /* Operator parameters*/
    HashMap parameters = new HashMap();
    parameters.put("demName","External DEM");
    parameters.put("externalDEMFile",DEMFile);
    parameters.put("nodataValueAtSea","false");
    parameters.put("outputComplex","false");
    parameters.put("pixelSpacingInMeter","8");
    parameters.put("saveLatLon","true");
    
    parameters.put("sourceBands","SigmaHH,SigmaHV,SigmaVH,SigmaVV,Span,PhiHHVV,PhiHHHV,HHVVcorrelation,Entropy,Anisotropy,Alpha,Alpha1,Alpha2,Alpha3,Lambda1,Lambda2,Lambda3");
   

    System.out.println("Orthorectifying product...");
    Product outProduct = GPF.createProduct("Terrain-Correction", parameters, product);        
    System.out.println("Done.");
    
    
    return outProduct;
}
#2

What is the size of the 17-band input-product (number of pixels, size in gigabytes)? Does orthorectifying a single band take a lot less than (10 hours)/17 ?

#3

What are your Java VM settings? How many heap space do you assign?
How big is the scene you are processing and finally to data format are you saving the data?

#4

Thank you both for your quick replies !

Each band is 6525x2933 pixels and weighs about 80 Mo. Orthorectifying a single band takes pretty much 10h/17. In the GUI, one band takes 4minutes.

VM settings are :
-Xmx10240m
-Xms10240m
-XX: +AggressiveOpts
-Dsnap.parallelism=8

Data is written to BEAM-DIMAP format.

#5

Try running the same product in the SNAP GUI with the SRTM dem and then with your external DEM.
Is there a difference in performance between the SNAP GUI and your program?

#6

Hello lveci,

Here are the results (the SRTM DEM doesn’t include my study area, I used the ASTER) for orthorectifying all 17 bands of the same product :

SNAP GUI + ASTER 1Sec GDEM : 5 minutes
My program + ASTER 1Sec GDEM : very long (I did not let it run to completion, but one band was already taking more than 20 minutes)

SNAP GUI + My DEM : 8 minutes
My program + My DEM : 10h

#7

Ok great. This means something is not initialized as expected in you program. I suspect the Config has not read the properties files and so the GPF cache size and tile size are small.

You may need to call:
SystemUtils.initGeoTools();
SystemUtils.initJAI(Lookup.getDefault().lookup(ClassLoader.class));

In the initJAI check what values are being set for the tile cache and tile size.

#8

I added the two SystemUtils call to my program; no change in performance.

I see the information about tile cache size and tile size is being recorded in the log. Could you tell me where I can access this log ?

#9

C:\Users\user\AppData\Roaming\SNAP\var\log on windows

#10

Thank you lveci,

So first of all, by looking at the log file I realized the VM parameters being used were not the ones set in the NetBeans project, but the ones set for NetBeans globally. They were way too low. So setting them to the values I gave earlier (Xms10G and Xmx10G) dramatically improved performance; writing one band takes 3 minutes instead of 45. I apologize for not seeing this earlier !

However, 3 minutes per band is still much longer than in the GUI.

Here is what I get in the initJAI :
parallelism : 8
tileCacheSize : 1024
tileSize : 512

#11

great! Now make sure the tileCacheSize is large enough. Try 2k or 4k depending on the memory available. It doesn’t matter much if you are running single operators but affects performance significantly with large graphs.

#12

Hi lveci,

Changing the tileCacheSize to 2048 or 4096 didn’t really change the performance.

I wasn’t certain where to set this parameter, so I tried the following configurations :

  • in .snap/etc/snap.properties while still calling initJAI in the code : the variable remained set at 1024
  • in .snap/etc/snap.properties while not calling initJAI
  • In a MySystemUtils class that I added to my project, I reproduced the initJai method with the new value for tileCacheSize and called this method in lieu of the SystemUtils one.

What do you make of this ?