Open drschenk opened 2 years ago
First, I checked that the image was aligned properly with the distortion model and didn't see any issues. Changing the
I took a look at the data you sent us and I do not see any consistent offests related to the camera model.
I took your a-priori images and manually compared the computed limb against the observed limb similar to #4768 and did not see a consistent offset.
I then looked at your bundle adjusted network to see if there were any apparent relationships in the measure residuals and didn't see anything. You can see the gist for that here: https://gist.github.com/jessemapel/b1de8cf14d738f50eed32b55cbef960d
Finally, I compared the projected, a-priori imagery against the Voyager Ganymede basemap and didn't see anything. There's a decent resolution difference so it's possible this comparison was not very useful. It would also be good to test this with the adjusted imagery, but I need the pre-bundle adjust network to do that correctly.
So, I'm not seeing anything in the ISIS sensor model that could be causing the errors you are seeing. If you are able to send us the pre-jigsaw control network we may be able to find something else. For now, I'm going to close this as we didn't find any issues in ISIS.
hi jesse, thanks for looking into this. i keep thinking about a simple sign or positional flip in the vectors that could induce a very low but measurable error.
i dont really have a pre-jig net as it was jigsawed early on and iterated many times after. is there a way to make a version from what i have? paul
Paul Schenk (2021 AGU Fred Whipple Awardee) Lunar & Planetary Institute / USRA 3600 Bay Area Blvd. Houston TX 77058 281-486-2157 (office: tho I don't often use that)
From: Jesse Mapel @.> Sent: Monday, July 18, 2022 3:28 PM To: USGS-Astrogeology/ISIS3 @.> Cc: Schenk, Paul @.>; Author @.> Subject: Re: [USGS-Astrogeology/ISIS3] Junocam _ SPice Camera model in ISIS (Issue #4913)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
First, I checked that the image was aligned properly with the distortion model and didn't see any issues. Changing the
I took a look at the data you sent us and I do not see any consistent offests related to the camera model.
I took your a-priori images and manually compared the computed limb against the observed limb similar to #4768https://github.com/USGS-Astrogeology/ISIS3/issues/4768 and did not see a consistent offset.
I then looked at your bundle adjusted network to see if there were any apparent relationships in the measure residuals and didn't see anything. You can see the gist for that here: https://gist.github.com/jessemapel/b1de8cf14d738f50eed32b55cbef960d
Finally, I compared the projected, a-priori imagery against the Voyager Ganymede basemap and didn't see anything. There's a decent resolution difference so it's possible this comparison was not very useful. It would also be good to test this with the adjusted imagery, but I need the pre-bundle adjust network to do that correctly.
So, I'm not seeing anything in the ISIS sensor model that could be causing the errors you are seeing. If you are able to send us the pre-jigsaw control network we may be able to find something else. For now, I'm going to close this as we didn't find any issues in ISIS.
— Reply to this email directly, view it on GitHubhttps://github.com/USGS-Astrogeology/ISIS3/issues/4913#issuecomment-1188272615, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AS5WLONICQKO2POLDINMD73VUW45DANCNFSM5TWIGFTA. You are receiving this because you authored the thread.Message ID: @.***>
I would like to reopen this issue as it still remains a problem for me. I do have a little more experience with it and believe ... a simple sign or positional flip ... my solve this, but not sure which parameters need to be flipped to test. this flip solved the NH Lorri problem.
@drschenk Im a little concerned with adding a sign flip that might affect a lot of users especially if Jesse didn't find anything wrong from looking at the data you sent him. Some questions: Where did he originally get this data from? Did you send it to him? Can you share more about what kind of distortion you are seeing? Would images help convey it?
I was thinking a prototype IK could be constructed with the sign flips (I know that more than one parameter had to be changed through the kernel in the NH case) that I could use here to test. If it is incorrect then it should be changed. the effect is minor (and affects cartography in only a very minor way) but absolutely necessary to know if it is incorrect for planetary shape investigations.
the distortions come from stereo image DEM production for the JC mosaics. there were 4 of them and the stereo pairs that overlap give different vertical elevation results in the overlap areas. also jigsaw results show very similar undulations on 1000 km scales of up to 500 m that we suspect are unreal because they can't be confirmed. this is very similar to what we saw when the first Pluto images came down. in that case it was I believe the camera Z axis that was in the wrong direction in isis. I can send some maps to your email.
ISIS version(s) affected: x.y.z
Description
ive been having an issue that might be related in some way:
Ive been using ISIS to process the JC ganymede images (Ravine et al., just submitted) to register the images into mosaics and to generate DEMs from the framelets. the framelets (each containing the 3 filters) cover the disk in 4 mosaics, each constructed of 10-20 of these overlapping framelets. the ISIS parameters work fine for mapping, given that the best resolution is only ~800 m. but when i do DEMs they come out distorted and overlapping DEMs do not have similar elevation values in many cases. (I and others have also encountered higher than normal jigsaw residuals).
We encountered a problem like this with LORRI (as stuart may recall), in which the sign of 1 or 2 of the reference values had to be flipped because the incoming FITS files had a flipped x,y,z reference from what ISIS uses and that completely fixed the problem. Ive been trying a variety of alterations to the *.ti files but not hitting the right combination if there is one. could the same or a similar effect be occurring here?
the alternative is that the camera distortion is not as well known as we would like for this purpose (which is much more sensitive that simple cartographic mapping). Ive tried changing the K1, K2 values but also not hit on values that work in all stereo pairs. Ive talked with caplinger and he thinks it the best that is likely to be had from their end.
any thoughts welcome.