Bug #4905

automos - polar stereographic mosaic UpperLeftCornerX/Y values possibly miscalculated when user enters lat/lon range

Added by Lynn Weller 10 months ago. Updated 2 months ago.

Target version:

No anticipated impact to Isis outside of this program. Changes need to be made to the ProcessMapMosaic class, which the following programs depend upon: ringsautomos, mapmos, and obviously automos. However, the two functions which need to be modified in the class are only called from automos, and not the other applications.

Software Version:
Test Reviewer:


isis3production2017-04-25 on astrovm4 and the nebula cluster, but I think this has been as issue for several years now based on tests in older versions of isis
Test data that demonstrate the problem are here: /work/users/lweller/Isis3Tests/Automos/PStereoPadding/
proc.scr has the command line details shared below
FYI - the extraneous NULL pixels in the problem output can not be trimmed off using maptrim - output is the same as input.
This sort of problem is an issue for images of high resolution where output products are already very large (many tens and possibly hundreds of gigs in size).

Basics of problem, details below:
1) run automos on list of images (yes, these have all been properly projected to be mosaicked w/ each other), default on lat/lon range and everything else
2) run automos on same list of images, enter the lat/lon range using the values found in the output of 1)
The expectation is the files should essentially be identical, but they are incredibly different and in particular the differ in the UpperLeftCornerX/Y coordinates such that mosaic 2 (w/ entered lat/lon) is typically 2x the size of mosaic 1 and has many, many extra NULL lines at the top of the image. See the attached qview screen shot. mosaic 1 (default lat/lon) is on the left and mosaic 2 (entered lat/lon same as default lat/lon) is on the right. NULL pixels are blue.

NOTE: I am mosaicking segmented images due to their large size and high resolution. The workflow involved running segment on an LROC-NAC image to break it up into 5000 line segments, projecting each segment w/ the same map file (included in the directory) but projecting to lat/lon range of the individual segment, then ultimately passing all of the level 2 segments to automos. This is a procedure that I have been using for years for this dataset. I include mentioning this just in case it has anything to do with the problem, but it likely does not.

I ran across this mosaicking a number of images while trying to match a mosaic from a prior year (and hence using its lat/lon values), but it can be reproduced with one of my segmented LROC-NAC polar files:

Run automos and let it determine the lat/lon range of mosaic:
automos fromlist=lev2_segments.lis mosaic=M180939212LE_LatLonDefault_mos.cub

Rerun automos on same input data, this time using the Using the lat/lon range from M180939212LE_LatLonDefault_mos.cub:
automos fromlist=lev2_segments.lis mosaic=M180939212LE_LatLonUserMatchDefault_mos.cub grange=user minlat=86.790603031508 maxlat=89.287743142487 minlon=47.985306708871 maxlon=134.20144189847

Note the size differences of these two products:
-rw-r--r-- 1 lweller flagstaf 2.2G Jun 5 11:51 M180939212LE_LatLonDefault_mos.cub
-rw-r--r-- 1 lweller flagstaf 4.6G Jun 5 11:53 M180939212LE_LatLonUserMatchDefault_mos.cub

And here are there mapping groups, with differences highlighted:

Group = Mapping
ProjectionName = PolarStereographic
CenterLongitude = 0.0
TargetName = Moon
EquatorialRadius = 1737400.0
PolarRadius = 1737400.0
LatitudeType = Planetocentric
LongitudeDirection = PositiveEast
LongitudeDomain = 180
MinimumLatitude = 86.790603031508
MaximumLatitude = 89.287743142487
MinimumLongitude = 47.985306708871
MaximumLongitude = 134.20144189847
UpperLeftCornerX = 15750.0
UpperLeftCornerY = 20874.0
PixelResolution = 3.0
Scale = 10107.783474716
CenterLatitude = 90.0

Group = Mapping
ProjectionName = PolarStereographic
CenterLongitude = 0.0
TargetName = Moon
EquatorialRadius = 1737400.0
PolarRadius = 1737400.0
LatitudeType = Planetocentric
LongitudeDirection = PositiveEast
LongitudeDomain = 180
MinimumLatitude = 86.790603031508
MaximumLatitude = 89.287743142487
MinimumLongitude = 47.985306708871
MaximumLongitude = 134.20144189847
UpperLeftCornerX = 15483.0
UpperLeftCornerY = 67869.0
PixelResolution = 3.0
Scale = 10107.783474716
CenterLatitude = 90.0

automos_polar_DefaultvsUser_LatLong.png View (131 KB) Lynn Weller, 2017-06-05 11:55 AM

Related issues

Related to ISIS - Bug #5233: automos - extra line when user enters range matching default calculated range Acknowledged


#1 Updated by Tammy Becker 10 months ago

  • Status changed from New to Acknowledged

#2 Updated by Stuart Sides 9 months ago

  • Target version set to 3.5.1 (Sprint 1)

#3 Updated by Makayla Shepherd 9 months ago

  • Assignee set to Tyler Wilson

#4 Updated by Tyler Wilson 9 months ago

  • Status changed from Acknowledged to In Progress

#5 Updated by Tyler Wilson 9 months ago

  • Impact updated (diff)

#6 Updated by Tyler Wilson 9 months ago

  • Impact updated (diff)

#7 Updated by Stuart Sides 7 months ago

  • Target version changed from 3.5.1 (Sprint 1) to 3.5.2 (2017-01-31 Jan)

#8 Updated by Tyler Wilson 7 months ago

  • Status changed from In Progress to Resolved
  • Test Reviewer set to Lynn Weller

The ISIS build (compiled on prog24) can be found here: /work/projects/isis/latest/m04905

Changed files:

$ISISROOT/src/base/objs/ProcessMapMosaic/ProcessMapMosaic.cpp and .h

I think a tester should review this code before it is handed off to a code reviewer.

#9 Updated by Lynn Weller 6 months ago

I'm testing the changes made and I think the changes need to be reconsidered because now it appears the bug I found is being introduced into the default mode of automos, sort of.

My intent was to reproduce my tests using the updated version. See data under /work/users/lweller/Isis3Tests/Automos/PStereoPadding/Fix_m04905/
The first step is to simply run automos with defaults given a list of level 2 images:

automos fromlist=lev2_segments.lis mosaic=M180939212LE_LatLonUserMatchDefault_mos_fixm04905.cub

I expected this file to be identical to what production produces, however they differ.
The TileSamples and TileLines differ; Samples and Lines differ; and the UpperLeftCornerX and Y values differ.
The new image is bigger overall and has a bigger UpperLeftCornerY value than the production version resulting in lots of null space at the top of the output mosaic almost identical to the problem I reported when the user enters a lat/lon range.

I did not run the remainder of my test since the fundamental output for automos has changed with the fixes and in a not so good way.

#10 Updated by Lynn Weller 6 months ago

  • Status changed from Resolved to Feedback

#11 Updated by Makayla Shepherd 6 months ago

  • Status changed from Feedback to In Progress

#12 Updated by Lynn Weller 4 months ago

  • Related to Bug #5233: automos - extra line when user enters range matching default calculated range added

#13 Updated by Cole Neubauer 4 months ago

In ProjectionFactory.cpp in function
Isis::Projection *ProjectionFactory::CreateForCube(Isis::Pvl &label, int &samples, int &lines, bool sizeMatch) there is a call(line 267) proj->XYRange(minX, maxX, minY, maxY) the maxY is used to set upperLeftY and the minX is used to set the upperLeftX these numbers are very off and they are used to determine number of samples and lines causing those to be off.

The proj object is initialized as a TProjection but the XYRange(minX, maxX, minY, maxY) is not calling the TProjection method. If you force it(TProjection::XYRange(minX, maxX, minY, maxY)), it calls the TProjection implementation of the method but this returns the given parameters.

I think the original call(proj->XYRange(minX, maxX, minY, maxY)) implementation has some error in it. From what I can tell the math up to this point and the math after it, up to the upperleft x and y being assigned, is correct.

#14 Updated by Cole Neubauer 4 months ago

This uses PolarStereographics::XYRange call

#15 Updated by Cole Neubauer 4 months ago

  • Assignee changed from Tyler Wilson to Cole Neubauer

#16 Updated by Lynn Weller 3 months ago

As per the request for the original input data to cam2map, please see /work/users/lweller/Isis3Tests/Automos/PStereoPadding/Fix_m04905/Input/.

Here are the steps to recreate the level 2 files that went into the automos program:
- Break the level 1 image into segments consisting of 5000 lines each. This is done due to the length of the images and the fact that they are polar - space saving measure.
segment from=M180939212LE.lev1.cub nl=5000 overlap=5

  • Project each segment to polar stereographic at 3m/pixel using the segments lat/lon range. This is done for each segment.
    cam2map from=M180939212LE.lev1.segment1.cub to=M180939212LE.segment1.lev2.cub map=/home/lweller/Tools/LROC/ pixres=map lonseam=continue interp=bilinear

  • Repeat the automos tests
    automos fromlist=lev2.lis mosaic=M180939212LE_Updated_LatLonDefault_mos.cub
    automos fromlist=lev2.lis mosaic=M180939212LE_Updated_LatLonUserMatchDefault_mos.cub grange=user minlat=86.79057791854 maxlat=89.287764273931 minlon=47.985056784144 maxlon=134.20085559275

The output of cam2map (*segment*lev2.cub) are input to automos. I have reproduced the above steps under the ../Input/ directory and have rerun the automos tests as well since the lat/lon range of this input data might be a tad different than the previously supplied test data. Because this post is so old and was from an ongoing project (now complete - meaning at some point, the original data will be deleted), the input to the level 2 files supplied for testing are no longer available (a jigsaw updated product that has since been improved). The currently supplied version of the cam2map input files ultimately result in an automos mosaic that is still fundamentally incorrect.

#17 Updated by Cole Neubauer 2 months ago

Thank you for getting me the extra data, Lynn.

After looking at this with Stuart neither of us could find where this was going wrong. This is going to have to be moved back to acknowledged. I am going to put my notes up in case I am not the one to pick it back up after this current sprint is over so the person that does can have a good starting point.

The automos call with user parameters specified follows the following(important) executions, these may vary if the code described has been updated:
Line 70-75 of automos.cpp
Where the code splits depending on whether the user specified their own lat lon range or not.
Line 355 of processmapmosaic.cpp
The setoutputcube call used in automos.cpp above
Line 392 of processmapmosaic.cpp
Projection is created, this will use PolarStereographic.cpp calls for any virtual calls that are implemented
Line 398 of processmapmosaic.cpp
proj->XYRange call this is polarstereographics XYRange
Line 326 of polarstereographic.cpp
XYRange function. This is where it tries to determine the min and max x,ys. It does this by testing the intersections of the min and max lat and lons with a call to XYRangeCheck(lines 329-332). Then it rotates by shifting the lon 90 degrees using XYRangeCheck(lines 342-343) to test any shifts that go between the minlon and maxlon. At the end(lines 352-355) it sets the parameters x,ys to the min and maxs found in XYRangeCheck. These x,ys is where the upper left corner gets it's point, the min x and max y.
Line 1077 of TProjection.cpp
XYRangeCheck called from above. This calls SetGround on line 1084 this will be polarstereographic.cpp call.
Line 199 of PolarStereographic.cpp
This is where the actual x,y calculations happen based on the lat lons passed in.
The formulas needed are in the Map Projections-A Working Manual
Note: We do our math in radians the book does it in degrees
If for some reason there has to be new data for this ticket the moon
is the best target for the data because it is a sphere. This makes
the Eccentricity = 0 and greatly simplifies the calculations to
compare. It also makes the Planetographic and Planetocentric
conversions equal. The PolarStereographic calculations can be found
on page 161.
phi = latitude in radians
lambda = longitude in radians
centerlon = center longitude in radians
a = Equatorial Radius
k = scale at center (almost always 1, in this case it is)
t = tan(pi/4 - phi/2)
p = 2 x a x k x t
x = p x sin(lamba - centerlon)
y = -p x cos(lamba - centerlon)

The formulas appear to be correct and the image from the default run of automos does not use the lat lons in any way to create the space to hold the mosaic. This is why we thought we might find the problem in cam2map as it may have been putting the lat and lons onto the label incorrectly. We did not find anything that seemed wrong in cam2map either so at this point we are out of ideas of where the issue could be.

#18 Updated by Cole Neubauer 2 months ago

  • Status changed from In Progress to Acknowledged
  • Assignee deleted (Cole Neubauer)

Also available in: Atom PDF