Bad orthorectification using refined sensor model


I’m trying to refine the sensor model of nighttime Jilin imagery. In order to do this here is my workflow :

  • Generate .geom file using ReadImageInfo -outkwl
  • Create GCP file with QGIS georeferencer
  • Extract row,col index of pixels to match with GCP using Python
  • Refine sensor model in UTM, use SRTM z points and geoid file
  • Apply new sensor model to image using OrthoRectification “image.tif?&geom=newfile.geom” and SRTM data

The refinement seems to work OK, but the ortho result is wrong : the image is rotated 90° counter-clockwise (but not flipped !). I mean the [row,col] shape is preserved but pixel values moved as if lat and long axis were swapped.
I tried to add ?&skipcarto=true but it does not change anything since the source image isn’t projected at all.

System is Ubuntu 22.04, I tried this with several OTB versions (6.6, 7.2, 7.4).

Any idea what could cause this ? Am I doing something wrong or is it due to Jilin’s awful metadata ? Do you want me to upload some data / debug log file ?

About the RefineSensorModel app, do you plan to re-introduce it now that you’ve removed OSSIM ?

Best regards,

It seems to work if I use col,row,lon,lat order in the gcp file instead of the suggested row,col,lon,lat.

But the result is still quite wrong. I see ~ 200m shift on the Y axis. Whereas It should be ~20-30m as announced by the RefineSensorModel app.

1 Like

Dear @vidlb,

I am surprised by your result. I have never been confronted to this inversion col <-> row in the GCP file. We will need to investigate…

Yes, we are planning on reintroducing the RefineSensorModel application in a future version of OTB. An issue is open here.

Julien :slight_smile:

@julienosman thanks for your quick reply !

Yes, this is strange. I’m using rasterio.transform to obtain row,col values using x,y coordinates as exported by the qgis georeferencer. I’ve already used this function for something else and it’s working as expected.

I found this row/col thing quite confusing. Like “a row is horizontal, thus it is indexed on the vertical axis”
Are you on the same page than me here ? I mean :

  • row = Y = latitude axis
  • col = X = longitude axis

Because in the code here I read this :

        x                              = atof(line.substr(pos, nextpos).c_str());
        pos                            = nextpos + 1;
        nextpos                        = line.find_first_of("\t", pos);
        y                              = atof(line.substr(pos, nextpos).c_str());
        pos                            = nextpos + 1;
        nextpos                        = line.find_first_of("\t", pos);
        lon                            = atof(line.substr(pos, nextpos).c_str());
        pos                            = nextpos + 1;
        nextpos                        = line.find_first_of("\t", pos);
        lat                            = atof(line.substr(pos, nextpos).c_str());

From what I understand, the expected order is x,y,lon,lat so it should expect col,row,lon,lat

Is it related to the lat/lon axis permutation since GDAL 3 ?

Just a thought, pardon me if I am off topic :wink:

I don’t think this is related, since I tried with older version of OTB : 6.6 shipped with GDAL 2.2… and gave me the exact same result than 7.4 / GDAL 3.

It seems like this row/col inversion is old, but if everyone is using this RefineSensorModel app with HomologousPointsExtraction outputs, I guess the same inversion can be found there, so the process work as expected. But it fails when building the GCP file from scratch, as I did.