image_align for HiRISE

[mikita belikau]

Latest release of ASP has a very nice feature like image aligning. 

Nearly a year ago I tried to implement similar thing which was described here https://groups.google.com/g/ames-stereo-pipeline-support/c/H7TTyAUGya0/m/2Sm2KvxOAwAJ

My results back then were not even close to what is implemented in image_align. `

So, I just tried to align 2 overlapping HiRISE images (converted from .LBL to .tiff) and it worked like a charm! I am really impressed. I ran image_align with just default params and it did it's job perfectly!

Overlap for the images was at the Bottom/Top areas

 

Then I tried to run image_align for the images, that have a tiny small area of overlap at the left/right side

This time it didn't work. I believe because of the fact that overlapping is too narrow.

So, then I tried to play a bit with params and run this

image_align ESP_044939_1990_RED_TIFF.TIFF ESP_044873_1990_RED_TIFF.TIFF -o ESP_044873_1990_RED_TIFF_ALIGNED.TIFF --alignment-transform similarity --ip-per-image 3000000

For me just similarity and big amount of ips per image was able to produce some result. Other types - no. In addition, I tried to reduce tile size, but it didn't get this param.  

And so, this time output was a bit weird.

Instead of this (here reference image is on the right and 'alienable' is on the left)

Output was like this

This is weird (even though I am happy that it did even this). 

So, what id it is basically, it took left image ('alienable') and aligned it, but cut it to the extent of the right image (reference image). Quality of the aligned part is okaish I'd say (not that impressive as for the first pair of images, but still), but I don't get why it cut the image.

Can somebody point me out what I can try to make it not cut the image? 

P.S. I tried many combinations of parameters, and only command above was able to produce output for me.

[Oleg Alexandrov]

I am glad that the image_align tool worked for you when you had solid overlap.

It does make sense that when there is little overlap, it would struggle, and also that adding a lot more interest points solved it. 

I also don't understand why you got that black triangle. 

I hope you can do some more experiments. First, note that the tool is meant to take the right image and make it aligned to the left. So, when you stack them, you likely need to first plot the right aligned image (what the tool outputs), and then on top of it the left unaligned image. Here, by left image I mean the first image passed to the tool. 

Second, you can try to crop some clips out of the left and right image, and see if you have more luck aligning those. With small clips it would be easier to find relevant interest points to align. If no luck, and if you can share with me the clips and the command you use, I can try to reproduce it.

Third, the problem may be the no-data value. Ideally this value is defined and then it is treated as transparency. But if it is treated as a black picture, maybe that explains what you see here.

Anyhow, home something works out.

--
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/fd0c6235-d958-4579-86e9-fe1a43e35f69n%40googlegroups.com.

[Oleg Alexandrov]

After thinking about it some more, it actually makes sense that the image_align tool cuts off one image. 

You see, the goal here is to keep the first image fixed, and align the second image to the first image. If the second aligned image goes way to the left of the first image, it has to be cut for it to align to the first image. Otherwise alignment can't happen. If left-most pixel in first image is (0, 0), and after alignment, the right aligned image also has its pixel (0, 0) be at the same location as in in the left image, any pixels to the left of that in the right image must be thrown out as they would correspond to negative pixels.

What should work for you, is to align the images in reverse. So, earlier, if aligning B.tif to A.tif ends up in B.tif moving left and getting cut when it goes further left than A.tif, then, if you align A.tif to B.tif, then A.tif moves right to match B.tif, and doesn't get cut. 

Long term, I am not sure what a good solution is. Maybe the software should not only respect the current rule, that the left image is kept fixed, but can allow both images to move, so the left image should be padded on the left to accommodate the right image moving left of the original left boundary of the left image. 

[mikita belikau]

Oleg, thanks a lot for your answers! As usual - detailed and solid.

Actually, yes, I will try to keep the order from left to right for reference/alignable images.
What just made me think that utility should work regardless of what is left and right is the case that I tried first 


Here there are no left and right - just up/down (top/bottom).
Just accidentally the left (top) image has extent that is sits in the west from the right (bottom). 
And for the utility, as I understand, it still looks for the western parts (left) and treats it as the one that is supposed to be a reference image.
And that made me think that image_align should work just analyzing the order of the args regardless of the west/east real positions of the images.

Anyway, I will try to change now the order.

And for your last question: for me personally it would be really great if next version of the utility could work just based on the args positions. That would add more flexibility for sure.
But as a quick 'solution' I think, just updated documentation of the arguments would be great, cause for top/bottom overlap for me this was not clear.

Again, thanks a lot for the hints. Will try this and update the topic with what I have

[Oleg Alexandrov]

I added a clarification in the introduction. The cut to the second image will also happen if after alignment portions of it move also higher than the first image, not just more to the left of it.

Given that the goal of the tool is to align the second image to the first, it works as advertised. What you want, and what would make sense, is to to allow both images to move, to ensure that the end result is two images on top of each other, without any cutting. I will think about this more.

For now, one could judge based on the sign of the translation which is saved in the output transform file if the transform from second to first image moves left or right, and one may choose to call the tool in reverse. This could be a part of a script, maybe.

You received this message because you are subscribed to a topic in the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ames-stereo-pipeline-support/Q9nI-lkL_uU/unsubscribe.
To unsubscribe from this group and all its topics, 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/7c3daf3b-9d68-479f-acf1-7db6771d6d7bn%40googlegroups.com.