Project

General

Profile

Bug #4905

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

Added by Lynn Weller 6 months ago. Updated 18 days ago.

Status:
In Progress
Priority:
High
Assignee:
Category:
Applications
Target version:
Impact:

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:

Description

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:

M180939212LE_LatLonDefault_mos.cub
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
End_Group

M180939212LE_LatLonUserMatchDefault_mos.cub
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
End_Group

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

History

#1 Updated by Tammy Becker 6 months ago

  • Status changed from New to Acknowledged

#2 Updated by Stuart Sides 6 months ago

  • Target version set to 3.5.1 (Sprint 1)

#3 Updated by Makayla Shepherd 6 months ago

  • Assignee set to Tyler Wilson

#4 Updated by Tyler Wilson 6 months ago

  • Status changed from Acknowledged to In Progress

#5 Updated by Tyler Wilson 6 months ago

  • Impact updated (diff)

#6 Updated by Tyler Wilson 6 months ago

  • Impact updated (diff)

#7 Updated by Stuart Sides 4 months ago

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

#8 Updated by Tyler Wilson 3 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
$ISISROOT/src/base/apps/automos/automos.cpp

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

#9 Updated by Lynn Weller 3 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 3 months ago

  • Status changed from Resolved to Feedback

#11 Updated by Makayla Shepherd 3 months ago

  • Status changed from Feedback to In Progress

#12 Updated by Lynn Weller 30 days ago

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

#13 Updated by Cole Neubauer 28 days 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 28 days ago

Update*
This uses PolarStereographics::XYRange call

#15 Updated by Cole Neubauer 18 days ago

  • Assignee changed from Tyler Wilson to Cole Neubauer

Also available in: Atom PDF