something about map projection

[Zhen Yang]

Hi everyone!
I found some problem. But the problem description is too long, so I wrote it as an office document and uploaded it as an attachment.

[Oleg Alexandrov]

> (1) When I used mapproject to the original image, the result of map projection seems to have been
cropped, with a smaller range than the original image, shown as follows.  

If your DEM is larger than the footprint of the image on the ground, mapproject should not crop. Granted, there can always be a bug, but I haven't seen such an instance for a while. You can always reach out privately with a testcase and I could take a look.

If the bug is a bounding box determination issue, you can use mapproject with --t_projwin to tell it to use your own bounding box, but hopefully it should not be needed. 

I also wonder what ASP version you have. I think I fixed something like that in version 3.2.0, the latest release, at some point. 

>  By comparing the pixel density of the same building, it can be seen that it seems to be down sampled by the original image, shown as follows.  The --tr is set to be 2.5, it is
also the GSD of ZY3 start 2, so I think the image resolution should be consistent.

You can try mapprojecting with no ground sample distance at all, and see what mapproject picks by itself. It usually finds the "native" ground sample distance. You can also set --tr to 2.0 and 1.5, and see if there is any difference in quality or noise.

>  Last, I found that the DEM genet by mapprojected image seems to be seriously blurred compared to genet by original image and PCI.  I think this may be due to the lower resolution of the image after map projection.

From your picture it looks the other way around, that with mapprojection the result looks more detailed. Maybe the caption is not in the right place.

You can try as before, to determine the native mapproject resolution, then ensure that both the left and the right image get mapprojected with the very same resolution (this is in the doc), then run parallel_stereo, If you are curious, you can try also smaller grid size for --tr, such as 75% of what you are using, and see if it makes a difference.

All these experiments can be done on very small clips, using the --t_projwin option in mapproject.

On Sun, Aug 6, 2023 at 11:45 PM Zhen Yang <csuya...@gmail.com> wrote:

Hi everyone!
I found some problem. But the problem description is too long, so I wrote it as an office document and uploaded it as an attachment.

--
You received this message because you are subscribed to the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/e119c648-a612-4246-95ee-a384e2c906b1n%40googlegroups.com.

[Zhen Yang]

Dear oleg,
Thanks for your reply. The version of ASP I used is 3.2.0.
For question (1): today I tried to unset the para --t_srs(its "+proj=eqc +units=m +datum=WGS84" before), and unset the para --tr, then I get a complete map projection image, the result is as follows, so I think maybe the wrong set of para --t_srs caused the crop of the map projection image?


For question (2): I visualized incorrectly, the 'run-L.tif' showed in that picture is not for the --tr 2.5, it's for the --tr 3.6. However, another question comes out. I am doubt that while the map projection image is cropped, but the 'run-L.tif' genet by this cropped image is complete, shown as follow.

For question (3): I used the new complete map projection map to rerun ASP with the same para, and I will upload the new result after it finished.

[Oleg Alexandrov]

>  However, another question comes out. I am doubt that while the map projection image is cropped, but the 'run-L.tif' genet by this cropped image is complete, shown as follow.

It is a little odd that your input image is cut, but then later the L.tif image is not cropped. 

This code did not change for a long time. I am guessing maybe there is some mistake. Anyhow, if you encounter issues, let us know.

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/bcbce653-8b5c-48d7-8f08-bbaf69d76cc1n%40googlegroups.com.

[Zhen Yang]

I think there may be indeed some issues with map projection. I visual the DEM used for projection, the original image, and the map projection image with ArcGIS. Discovered that the original image can overlap well with DEM; However, the map projected image cannot overlap well with the DEM. The next step, I will try to read the code of map projection part and find out why these issues happen.

In addition, I exported the longitude and latitude boundaries of the original image as the -- proj-win parameter input into the mapproject program and found that this parameter seemed to have no effect. The results obtained were consistent with those without setting this parameter, the result map projection image have a different boundary.

[Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]]

The original image must not overlap with the DEM unless it is already georeferenced. We assume the original images are raw, acquired in orbit, not positioned on the planet. Maybe that is the source of your problems.

ASP cannot use orthorectified images. We do orthorectification ourselves, with mapproject. 

Now, maybe your image is raw but there is knowledge of its corner coordinates, and that can be used by ArcGIS to overlay it. 

> The next step, I will try to read the code of map projection part and find out why these issues happen.

Our code is a pain to read. The logic is very simple though. For each point on the DEM, trace a ray up to the orbit hitting the camera sensor, and borrow from the image the pixel intensity. That gets copied to the ground DEM point as a new value. So, mapproject simply takes an orbital image and pushes it down coloring the DEM surface with the image texture. 

Any time you get a problem like this, the source of it is inconsistency between image and camera for that image.

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Zhen Yang <csuya...@gmail.com>
Sent: Wednesday, August 9, 2023 7:40 PM
To: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] [BULK] Re: something about map projection

 

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/b163ab16-ce08-40f5-a8e7-7d8e73dd5ef0n%40googlegroups.com.

[Zhen Yang]

Thanks for your reply, Oleg.
---->Now, maybe your image is raw but there is knowledge of its corner coordinates, and that can be used by ArcGIS to overlay it.
From this, I tried to put the original image in a separate folder and then open it using ArcGIS. At this point, the image can no longer overlap with DEM. I guess ArcGIS obtained the geographic boundary information of the image from the corresponding XML file when opening the image, and then projected the image into this range, thus overlapping it well with DEM.

However, I still have a question. After performing map projection, the projected image cannot overlap well with DEM, but the "run-L. tif" produced by stereo can overlap with DEM. The parameters used for my map projection are as follows.

mapproject -t rpc --ot UInt16 \
--bundle-adjust-prefix ~/BATest/run \
~/DEM.tif \
~/****-FWD.tiff \
~/****-FWD.rpb \
~/left_mapproj.tif

[Oleg Alexandrov]

> After performing map projection, the projected image cannot overlap well with DEM, but the "run-L. tif" produced by stereo can overlap with DEM. The parameters used for my map projection are as follows.

This is a little unexpected, especially given that you used bundle adjustment. This operation makes the cameras self-consistent, but can make the consistency with the DEM worse as there is no DEM constraint. 

So, I am not sure what is going on with your data. 

A simple thing to do would be to bundle-adjust the cameras, run stereo, get a DEM, then align that one with your underlying DEM with pc_align (https://stereopipeline.readthedocs.io/en/latest/tools/pc_align.html#pc-align). Then, an alignment can be applied to the cameras too (https://stereopipeline.readthedocs.io/en/latest/tools/pc_align.html#applying-the-pc-align-transform-to-cameras).  

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/1713b6ba-d8ac-4834-9ee1-60ec70a7acf0n%40googlegroups.com.

[Zhen Yang]

Thanks, oleg, I will try this next. 
You mentioned BA above. Then I opened the BA log, I found the following warning when reading the original image: Warning: read_gdal_georeference(): WARNING! Resource file ~/***-FWD.tiff contains a non-normal georeference. I don't know if this warning will have any impact on the results, what's more, other programs that need to read the original image also have this warning, including mapproject.

[Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]]

>  WARNING! Resource file ~/***-FWD.tiff contains a non-normal georeference.

Something is unusual about your image georeference (ground coordinates) when you get this warning. It is likely harmless if this is meant to be a raw image and some kind of georefrence is attached to it, to help with visualization, perhaps.

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Zhen Yang <csuya...@gmail.com>

Sent: Thursday, August 10, 2023 7:25 PM

To: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>

Subject: Re: [EXTERNAL] [BULK] Re: something about map projection

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/a663f7d8-c109-4240-b94a-8b03fcdadec8n%40googlegroups.com.

[Zhen Yang]

Ok, thanks.