WARNING ossimRpcModel::lineSampleHeightToWorld

[feriousrs]

Hello,

I'm currently using CARS on a series of WorldView-3 (WV03) tristereo images. I don't have any Ground Control Points (GCP) for my Region of Interest (ROI), and I encountered the following warning. Is everything okay with the processing?

WARNING ossimRpcModel::lineSampleHeightToWorld: Max number of iterations reached in ground point solution. Results are inaccurate

[feriousrs]

And when the algorithm calculates epipolar grids, it seems to get stuck at this stage because there is no further output after this message: Computing epipolar grids ...: 100% [**************************************************] (2s)

[dyoussef]

Hello @farshad-golparvar,

How did you create your regions of interest?

[feriousrs]

@dyoussef I didn't employ any shapefile to define the Region of Interest (ROI). Instead, I selected a small tile from the WorldView-3 (WV03) panchromatic image, created geometry and color information for that tile, and imported it into the algorithm.

[dyoussef]

Is WV data part of the spacenet challenge? if so, can you give me the data names so that I can reproduce the problem?

[feriousrs]

No, this is unrelated to that dataset. Do you have any insights into what might be causing this problem? If you need any further information, please let me know, and I'll be happy to provide it

[dyoussef]

Can i download your data? or can you try to follow this procedure (adapting it to your data) : https://github.com/CNES/cars/issues/21#issuecomment-1882759382?

[dyoussef]

Hello @farshad-golparvar,

Can you send me your data? if i can't access it, it'll be difficult to help you and we'll have to close the issue. As i said, the issue #21 shows how to run cars on WV data: have you been able to try applying it to your data?

[feriousrs]

Hello @dyoussef,

Thank you for your thoughtful response and consideration. I have successfully managed to complete the initial phase of the program and generate a geom file using RPB (or xml) files on my own. However, I have encountered some questions and errors in the subsequent stages of the code [sensor_to_dense_dsm_step_by_step.ipynb] while working with my dataset.

Q1. Is initial elevation file (SRTM) necessary to run this code without problem? Q2. Do I need to change CRS of the input dataset to EPSG:4326 because my dataset is in UTM CRS? Q3. I tried the CARS with tiff images which had Geo-information metadata like EPSG, RPC, Corner Coordinates and other normal information which can be seen with gdalinfo. But I ran into serious problems and logical errors in the first steps and CARS could not find any overlapped area between stereo images. After I removed this metadata from tiff file without changing my geom file the problem was solved. How do you see this issue? is it because of the tiff metadata or I did something wrong? Q4. How does the cars-starter manage color information when creating a configuration file? Q5. When constructing a config file with cars-starter for three-stereo images, all possible pairs are not taken into account, and only the first image is considered with the other two as a pair. What are your thoughts on this? Can I manually add the third pair? Is this scientifically sound?

Error1: In the Dense Matching step and computing disparities using Pandora I received the following errors:

Note: The samp_off and line_off values are negative. I'm uncertain whether this will be useful to you or not.

Error2: I encountered unusual errors when using local_dask or mp as the orchestrator, preventing me from utilizing this feature. I don't have the error image at the moment, but I can reproduce it.

[dyoussef]

Hello @farshad-golparvar,

Thank you very much for these very precise questions. I'll try to answer them as best i can:

Q1. The initial elevation is not mandatory, but without it, the search for homologous points takes more time, as we have no a priori in this case.

Q2. CARS input images must be sensor-level images. So there's no reason to change the CRS. Perhaps you're referring to the "epsg" option in the configuration? In fact, it's not very clear that this information is requested "asinput", because this EPSG corresponds to the EPSG of the DSM produced... We'll change that in a future release.

Q3. This ties in with question Q2... Since you were talking about OSSIM problems, I assume you're using CARS with the Orfeo Toolbox? You're right: the Orfeo Toolbox is mistaken between projection information and the information contained in a sensor-level product.

There are some image products, called “ortho-ready”, that should be processed carefully. They are actual products in raw geometry, but their metadata also contains projection data. In that case, you can hide the map projection from the Orfeo ToolBox by using extended filenames. Instead of using the plain input image path, you append a specific key at the end: "path_to_image?&skipcarto=true" https://www.orfeo-toolbox.org/CookBook/recipes/optpreproc.html#beware-of-ortho-ready-products

Because we wanted an easy-to-install Python library, and to avoid these problems, we're replacing the geometry part with a new library we've developed: SHARELOC: https://github.com/CNES/shareloc. It's already included, but for the moment it's not performing well enough: we'll be releasing a new version in April that will solve these performance problems.

Q4. cars-starter is a really simple tool for initiating a configuration file, but it doesn't handle color images, for example. The color image must be the same size as the image used to create the 3D: to achieve this, pan sharpen: https://cars.readthedocs.io/en/stable/recipes.html#make-a-simple-pan-sharpening and then add this image to the "color" field.

Q5. It's a very arbitrary choice to combine secondary images with the first image (https://github.com/CNES/cars/blob/master/cars/starter.py#L124). But as I was saying, cars-starter is just a tool to start a configuration. The benefits of combining or not combining images depend above all on the acquisition conditions. If you have three images, I'd advise you to use the nadir-most image as a paired reference with the other two. Adding the third pair can improve the result because the B over H ratio is larger.

Error1: It's true that it's strange that the samp_off and line_off values are negative. Do you think you can send me the data?

Error2: Dask is a software that's evolving a lot. We sometimes find it hard to keep up. I advise you to use multiprocessing in orchestration for the time being (this will be the default mode in the next version of cars).

[dyoussef]

I close this issue because it has been inactive for 3 weeks. Do not hesitate to reopen the issue if you have any further questions