mapproject problem with MESSENGER MDIS image

[Michael Barker]

Hello,

I'm trying to mapproject a MESSENGER MDIS WAC image, and it's producing a mirrored double-image. The ISIS3 mapproject utility produces the correct image (see attached, with ASP result on left and ISIS3 result on right).

  mdis2isis from=EW1026170296B.IMG to=EW1026170296B

  mdiscal from=EW1026170296B.cub to=EW1026170296B.cal.cub radiometric=false

  spiceinit from=EW1026170296B.cal.cub spksmithed=true cksmithed=true

  mapproject -t isis MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif EW1026170296B.cal.cub EW1026170296B.prj.tif --suppress-output --t_srs '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +a=2444000 +b=2440000 +units=m +no_defs'

Here's the first few lines of output:

mapproject_single --query-projection MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif EW1026170296B.cal.cub  EW1026170296B.prj.tif -t isis --t_srs +proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +a=2444000 +b=2440000 +units=m +no_defs

Output image size is 37501 by 10258 pixels.

Splitting into 37 by 11 tiles.

I guess all those tiles are generated because the mirrored images are very far apart with a lot of empty space between them.

The DEM is in cylindrical projection:

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: Title: Grid imported via GDAL

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: Command: 

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: Remark: 

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: Pixel node registration used [Cartesian grid]

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: Grid file format: gd = Import/export through GDAL

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: x_min: 0 x_max: 360 x_inc: 0.015625 name: x n_columns: 23040

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: y_min: -90 y_max: 90 y_inc: 0.015625 name: y n_rows: 11520

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: z_min: -5982 z_max: 3897.00024414 name: z

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif: scale_factor: 1 add_offset: 0

+proj=longlat +a=2440000 +b=2440000 +no_defs 

I've tried it with a different DEM with the same result (although it complained about a non-standard georeference):

MSGR_DEM_USG_EQ_I_V02_prep.tif: Title: Grid imported via GDAL

MSGR_DEM_USG_EQ_I_V02_prep.tif: Command: 

MSGR_DEM_USG_EQ_I_V02_prep.tif: Remark: 

MSGR_DEM_USG_EQ_I_V02_prep.tif: Pixel node registration used [Cartesian grid]

MSGR_DEM_USG_EQ_I_V02_prep.tif: Grid file format: gd = Import/export through GDAL

MSGR_DEM_USG_EQ_I_V02_prep.tif: x_min: -7664266.36232 x_max: 7664266.36232 x_inc: 665.243152705 name: x n_columns: 23042

MSGR_DEM_USG_EQ_I_V02_prep.tif: y_min: -3832465.80274 y_max: 3832465.80274 y_inc: 665.243152705 name: y n_rows: 11522

MSGR_DEM_USG_EQ_I_V02_prep.tif: z_min: 2434018 z_max: 2443897 name: z

MSGR_DEM_USG_EQ_I_V02_prep.tif: scale_factor: 1 add_offset: 2439400 packed z-range: [-5382,4497]

+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=180 +x_0=0 +y_0=0 +a=2439400 +b=2439400 +units=m +no_defs 

I've also tried it without the "t_srs" option with the same result.

Using ASP 2.6.1.

Any help would be much appreciated.

Thanks,

Mike

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

Greetings,

I am not sure what to say.  One issue I am aware of that causes some folks grief is that ASP fell behind its version of ISIS and ISIS recently made changes to their data that broke some things. 

Maybe you can do some sanity checks first. See if you get better results if in mapproject you pass in a specific --t_projwin, so a little area on the ground. You can see if it works with other images from this mission, and perhaps with other missions related somewhat to what you are doing.

I am trying to figure out if the issue you encounter is specific to your dataset, or a bug in our code, or something about ASP and ISIS incompatibility. For now I can say that such weird things where an image is actually reversed is something I never saw before.

Oleg

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Michael Barker <mkb...@gmail.com>
Sent: Tuesday, June 2, 2020 4:38 PM
To: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] mapproject problem with MESSENGER MDIS image

 

--
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/291483dc-a0dc-46ec-9ac0-261a30adff87%40googlegroups.com.

[Michael Barker]

Hi Oleg,

Thanks for the quick reply. Indeed, when I pass the specific --t_projwin region, or cut out the region from the DEM and run mapproject on that, it works. Not an ideal solution as it requires getting the region bounds for each image prior to projection, but it could work.

I have used ASP's mapproject successfully with other MDIS WAC images at the north pole of Mercury and small, local polar stereographic DEMs, so I suppose it's possible that the problem has always been present, but I haven't noticed until now.

Thanks,

Mike

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

Mike,

That is great to know. So it is a bug in our computation of the domain of the mapprojection that manifests itself only in some circumstances. Not surprising. Sometimes I do wish that Earth (and Mercury) were flat (even better, a rectangle!), so we don't have deal with such things. :)

I don't know how hard is for you to package for me your DEM and the offending cube in some tarball, and then I can take a look in the next several days. I guess the data is public, but it would make much job much easier if I have access to a ready-made dataset. (For a change, we are actually funded to do ASP work recently, so finally some bugs can be taken care of.)

Thanks.

Oleg

---

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Michael Barker <mkb...@gmail.com>

Sent: Wednesday, June 3, 2020 5:01 AM

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

Subject: [EXTERNAL] Re: mapproject problem with MESSENGER MDIS image

 

--

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/3606c66e-c4b0-49ea-b03f-d4be3a7292fe%40googlegroups.com.

[Mike Barker]

Here's a link to a tarball with the files:

EW1026170296B.IMG - original IMG

EW1026170296B.cal.cub - calibrated ISIS cube file

MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif - offending DEM

test.tif - this is the cut-out DEM that worked without --t_projwin

EW1026170296B.cal.map.cub - the ISIS mapprojected image, for reference

I'm using ASP 2.6.1 and isis 3.5.2.

The offending DEM worked with this --t_projwin param:

mapproject -t isis MSGR_DEM_USG_SC_I_V02_rescaledKM_ref2440km.tif EW1026170296B.cal.cub EW1026170296Bb.prj.tif --suppress-output --t_srs '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +a=2444000 +b=2440000 +units=m +no_defs' --t_projwin 4094083.90015 1132994.93286 4431395.12817 1409152.93579

You have 10 days from 03-Jun-2020 to download the file(s) from the following URL:

https://opendrive.gsfc.nasa.gov/shortauth/o/rdYM7sG1

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

I got the download. I can confirm the problem, and it shows up also with the latest development build. Your DEM seems to span the whole of Mercury, which likely confuses our determination of extent of the map projected image somewhere. 

It will take me some time to figure this out, as we need to make our build work after a long hiatus from this project. I will let you know when I put a fix, in the meantime, hopefully your approach of specifying explicitly the extent of the map-projected image could work. 

Thank you for the report.

---

From: Mike Barker <mkb...@gmail.com>
Sent: Wednesday, June 3, 2020 10:09 AM
To: Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC] <oleg.al...@nasa.gov>
Cc: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: Re: [EXTERNAL] Re: mapproject problem with MESSENGER MDIS image

 

[Mike Barker]

Thank you for the prompt replies!

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

I put a fix for your mapproject issue. The reason mapproject was thinking your image covered so much real estate is because your DEM was spanning the entire planet, and mapproject was peeking through the planet to ogle at suitable pixels on the other side (not nice, I know).  Now there is a check for that. 

The build at

  https://byss.arc.nasa.gov/stereopipeline/daily_build/

has the fix. This build also supports the latest ISIS, at 4.1.0.

Oleg

---

From: Mike Barker <mkb...@gmail.com>
Sent: Wednesday, June 3, 2020 2:34 PM

[Mike Barker]

Great, thanks! Sometimes it is useful to pass in a global DEM, so that will be a big help.

[Gianluca Chiarolanza]

Hi everyone!

I am facing an issue very similar to the one originally raised by the author of this thread several years ago.

The major difference from the original post is that I am using global images of Ganymede acquired by JunoCam which, contrary to the MDIS images from the original thread, also show the limb of the planet as well as the outer space.

As a DEM I am using a "flat" global mosaic of Ganymede centered to lon 0°.

The left side of the image is where the planetary limb and outer space is present. The portion of the image approximately corresponding to the outer space has been converted to "null" values.

I get no problems when using ISIS cam2map. However,  when using ASP's mapproject, a mirrored version of the planetary region located next to the limb is present in the mapprojected image. This is shown below.

The --t_projwin option can solve the problem but, as in the original author's case, it is not ideal here given that several other images must be processed.

If you wish to replicate the effect, you may download the lev-1 cube and the global flat dem from HERE.

I hope you can give a look to and perhaps fix this issue, or suggest workarounds. Thank you!

Kind regards,

Gianluca

[Oleg Alexandrov]

Thank you for the report. This was a bug as well. Points behind the planet were seen. I added a fix. This does not affect performance of regular mapprojection as only comes in if it is detected that a corner of the output mapprojected image extent is hidden behind the planet.

I tested with this .cub file and with a CSM .json file made from the cub and with various clips and change of projection and seems to be doing the right thing.

The fix will be in build 2026-05-06 sometime tomorrow (at https://github.com/NeoGeographyToolkit/StereoPipeline/releases). 

To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/58e9b4bb-381f-47cf-a751-66fe43285578n%40googlegroups.com.