I am interested in creating mosaics of HiRISE images for automatic change detection.
For this I need to stick together many HiRISE images for different dates. Problem is when I open these images ‘as is’ (using their labels) in QGIS they have significant shift. This is a known issue and reason for this is uncertainty in spacecraft positioning.
I want to coregister HiRISE images that should use as a base layer CTX images. While investigating this topic I stumbled upon paper https://pdfs.semanticscholar.org/c0f0/8dcd1f48599fac0796bbad4ea014d2887b5f.pdf
where authors introduced automatic batch coregistration method based on rings.
I found this very interesting, cause I think this is what I need - I also want to coregister many HiRISE images. However authors do not provide link to source code that I can somehow examine. I wrote them a message, but they do not answer. So, my question is do guys know know any other method of batch coregistering HiRSE images? I need to do this in batch mode.
@mikita87 So how far off? If you haven’t applied fix_jp2 to the images to update the map projection make sure to do that first (not needed for polar map projected files). Assuming that is done, then yes you will see shifts per image based on uncertainties in spacecraft pointing (SPICE). You can see the impact in the technical test global HiRISE mosaic. Zoom around to see the really random offsets.
Since Forum posts are duplicated to OpenPlanetary slack, I will note Fred C. stated in slack, "This software was used to coregister HiRISE images to look at change detection in dunes: http://www.tectonics.caltech.edu/slip_history/spot_coseis/download_software.html "
which appears to the software used in your linked paper.
(1) I will point out, there is no global controlled CTX mosaic (yet). Parts have been controlled. Just warning you that if you control the HiRISE to even a semi-controlled CTX mosaic, you might need to update them at a later date. You could first control CTX to HRSC/THEMIS/MOLA yourself and then control HiRISE to new CTX location.
(2) like the team you listed, others are also working on this. For example, AutoCNET or ISIS;s findfeatures. Both might be hard to simply pick-up and use without lots of testing and I’m not sure if it has been used for HiRISE (outside of some image-to-image change detection work, see Rodriguez et al.).
(3) I have used ArcMap’s (ArcGIS Pro) which has an block adjustment toolset. Now to match across image types (even HiRISE to CTX) will be a challenge due to the illumination and resolution differences. Matching several HIRISE to HiRSE (or CTX to CTX) can work pretty well if the images are similar and there is enough overlap. Requires building a “mosaic data type” (virtual mosaic) and the tools allow you to add or remove control points interactively. Again not great for planetary image matching but has worked for batch processing.
If you are up for some manual controlling, Arc’s georef toolbar is actually pretty good (and quick). But it is again dependent on how similar the images are. It actually has an “auto reference” but it is still one image at a time.
good luck,
Trent
@mikita87 another way to do this is if you do not care about exact precision cosi corr may provide, is to use ipfind/ipmatch from ames stereo pipeline to define ground control points to then use GDAL warp to align the images, roughly approximating the auto geo-registration tool in arcgis pro. I’ve implemented it here: https://github.com/AndrewAnnex/asap_stereo/blob/8e2f38b7144d0e972320a7ca9e3a0287c2b3afca/asap_stereo/asap.py#L1752, all you would need to do is select one image as a base reference image and then align your N many hirise images to it. The “im_feeling_lucky” function will do this all in one command. There will still be some distortion between the images from viewing angles so you may have to orthorectify all of your data against a high resolution DEM first, then use ASAP’s method.
Thanks a lot for your detailed answers!
I need some time to think about and understand your suggestions and mentioned approaches, but this info is really very-very important for me.
Here is what I can say right now
@thare
Shift could vary up to hundred meters. This is just what I noticed - maybe it can be even more and my subset of the data just does not allow to see this. I assume, it could be less, but for now I can not even tell if there is some “average” value. As I see, from image to image this value could be significantly different.
I do not work (for now) with polar regions.
I didn’t know about fix_jp2 - will try it, but from what you mentioned since I do not work with polar regions this should not affect anything. Anyway, thanks for this info.
I saw posts about cosi-corr, but from what I got this is a plug-in for ENVI, which is quite costly. My initial goal is to implement this via Python/GDAL/ISIS3/etc - opensource software which I can run on remote server in batch mode. Correct me if I am wrong, but from what I got this plug-in is not what will help here, right?
The same is for ArcGis. Since it is proprietary software license restrictions should be considered - sorry i didn’t mention this from the very beginning.
Anyway, will try this as well to see what it can and can not.
What looks promising (at least from the first look) is this Autocnet and this ISIS routine. I never touched both of them until now, so maybe it is a good chance to try it.
@AndrewAnnex Again, thanks for your reply.
Need to try your approach, the only thing is if it is Arc-based solution, then, probably It will not work for me because of this my initial plan to stick to opensource tool chain. Anyway, will try!
Guys, thanks a lot for your time. I really appreciate your help. Will keep updating this topic with the progress I made
@mikita87 Just clarify, fix_jp2 is used to only correct equirectangular (equatorial) HiRISE Jp2s. It is not needed for polar HiRISE files. (BTW, I corrected ftp links to https on this page).
If it were me, I think I would try Andew’s recommendation for using “ipfind/ipmatch from ames stereo pipeline”. Then go from there to the other open-source methods like AutoCNET and ISIS.
If you have success, we would love to hear back.
@thare Thanks a lot! Will go this way and see what is the outcome
@mikita87 my solution does not use arcmap/arcgis, it is all open source and my code is all in python. It approximates what Arcgis pro does by using ipfind/ipmatch with some python code and GDAL.
@AndrewAnnex This is great! Then I will go for this approach. Thanks again
@AndrewAnnex Andrew, so after I spent some time trying to find ‘easy’ alternatives to your wrapper with ‘acceptable’ learning curve I realized, that there are no such alternatives 
I tried to find out if Autoseed from ISIS can work for me, but apparently it can not, cause it requires EDR and I want to use RDR.
So, will go your way and try to apply your wrapper to HiRISE *_RED.JP2 files.
@AndrewAnnex, @thare
So, I examined the code from ASAP and im_feeling_lucky function.
The idea looks clear to me - first call ipfind, and then call ipmatch
I tried to call this commands first from terminal to do this ‘manually’ to understand the process. Unfortunately, without success. I suspect, that my problem is in output of ipfind.
Maybe you can quickly see my problem?
Let’s say, I have three .LBL files that look like this:
Here we see, that these 3 files have intersections
So what I did was:
- created cub file for each image with pds2isis
- called
ipfind ESP_042315_1985_RED.LBL.cub ESP_046060_1985_RED.LBL.cub ESP_062530_1985_RED.LBL.cub --normalize --debug-image 1 --ip-per-tile 50
Parameters and it’s values I took from im_feeling_lucky function of ASAP
Output was following
Finding interest points in “ESP_042315_1985_RED.LBL.cub”.
Read in nodata value: 0
Normalizing the input image…
Detected 52 raw keypoints!
Found 52 points.
Running sift descriptor generator.
Writing output file ESP_042315_1985_RED.LBL.vwip
Writing debug image: ESP_042315_1985_RED.LBL_debug.png with downsample: 0.0164025
Finding interest points in “ESP_046060_1985_RED.LBL.cub”.
Read in nodata value: 0
Normalizing the input image…
Detected 41 raw keypoints!
Found 41 points.
Running sift descriptor generator.
Writing output file ESP_046060_1985_RED.LBL.vwip
Writing debug image: ESP_046060_1985_RED.LBL_debug.png with downsample: 0.0174001
Finding interest points in “ESP_062530_1985_RED.LBL.cub”.
Read in nodata value: 0
Normalizing the input image…
Detected 13 raw keypoints!
Found 13 points.
Running sift descriptor generator.
Writing output file ESP_062530_1985_RED.LBL.vwip
Writing debug image: ESP_062530_1985_RED.LBL_debug.png with downsample: 0.0177379
What worries me on this step is these debug images. They look like this:
I do not know what does this mean, but these 2 black images look like a bad sign for me
- called
ipmatch --debug-image --ransac-constraint homography ESP_042315_1985_RED.LBL.cub ESP_042315_1985_RED.LBL.vwip ESP_046060_1985_RED.LBL.cub ESP_046060_1985_RED.LBL.vwip ESP_062530_1985_RED.LBL.cub ESP_062530_1985_RED.LBL.vwip
Output was following
Matching between ESP_042315_1985_RED.LBL.cub (52 points) and ESP_046060_1985_RED.LBL.cub (41 points).
Using distance metric: L2
Matching:[****************************************************************] 100%Found 11 putative matches before duplicate removal.
Found 6 putative matches.
RANSAC Error. Number of requested inliers is less than min number of elements needed for fit. (3/4)
Attempting RANSAC with 2 of output inliers.
RANSAC Error. Number of requested inliers is less than min number of elements needed for fit. (2/4)
RANSAC Failed: RANSAC was unable to find a fit that matched the supplied data.
Matching between ESP_042315_1985_RED.LBL.cub (52 points) and ESP_062530_1985_RED.LBL.cub (13 points).
Using distance metric: L2
Matching:[****************************************************************] 100%Found 4 putative matches before duplicate removal.
Found 2 putative matches.
RANSAC Error. Not enough potential matches for this fitting functor. (2/4)
RANSAC Failed: RANSAC was unable to find a fit that matched the supplied data.
Matching between ESP_046060_1985_RED.LBL.cub (41 points) and ESP_062530_1985_RED.LBL.cub (13 points).
Using distance metric: L2
Matching:[***************************************************************.] 100%Found 4 putative matches before duplicate removal.
Found 3 putative matches.
RANSAC Error. Not enough potential matches for this fitting functor. (3/4)
RANSAC Failed: RANSAC was unable to find a fit that matched the supplied data.
So, it’s complaining on low number of detected common points.
How can I fix this?
@AndrewAnnex I see, that original idea came from this discussion https://groups.google.com/g/ames-stereo-pipeline-support/c/NVrAIQy3Gv0
It’s interesting that here https://github.com/NeoGeographyToolkit/StereoPipeline/issues/265 another method pc_align is mentioned. You also mentioned this in google groups thread, but for shading and as I see you do not use it in your im_feeling_lucky.
I suspect, that my problem is that I use RDR files for cubes generation on the first step.
The thing is that I cannot use EDR for this, cause for the area I am interested EDR is not available.
E.g. if I set search criteria like this
And
I got nothing in the result list
Whereas RDR products
For this area are available
This, of course, leads to another question why EDR/RDR availability is so different, but this is separate topic - non-related to coregistering.
So, for me only RDRs are the input data
@mikita87 Look carefully at your second screenshot. There’s a warning in red that says “Some of your selected data sets do not contain latitude / longitude data and will not return results if
location criterial is entered. See the list below.” and it lists EDRs.
By definition, if an RDR exists, then an EDR must exist because the RDRs are derived from EDRs. It’s just that the map-based search on the Mars ODE doesn’t support finding EDRs that way (I didn’t know this before now).
Edited to Add Simpler EDR Search Method:
When you search for RDRs, if you click through to the product page for one of the RDRs, you’ll see a tab called “Related Products” and it will list the EDRs for that observation. You can then just check them off, add them to your download cart and download them.
Original suggestion for downloading EDRs based on RDR Product IDs:
This is okay though! You know what the product IDs are for the RDRs, so you can figure out the URLs for the corresponding EDRs. For example, the RDR with ProductID “ESP_046929_2050” was collected during the “ESP” mission phase, and its orbit, 046929, falls within the 100 orbit range 046900-046999. Thus, the first part of the URL is https://hirise-pds.lpl.arizona.edu/PDS/EDR/ESP/ORB_046900_046999
Then, just add a directory named like the Product ID:
corresponding EDRs in https://hirise-pds.lpl.arizona.edu/PDS/EDR/ESP/ORB_046900_046999/ESP_046929_2050
The ASP Manual has an example that shows how you can download HiRISE EDRs from a list of URLs like the one above using the script hiedr2mosaic.py
@dpmayer David, thanks a lot!
Very useful info. Now I know where and how to find appropriate EDR for RDR.
One step closer to original problem of coregistering.
For now I decided to see how far I can go with RDR with applying ipfind/ipmatch for coregistering. If this will not work will stick to EDR.
Thanks a lot!
discussion moved here https://groups.google.com/g/ames-stereo-pipeline-support/c/H7TTyAUGya0