Global Mapper v25.0

Raster Calculator pixel shift

Ice Age Mark
Ice Age Mark Global Mapper UserTrusted User
edited November 2014 in Raster Data
Howdy,


Two issues with the Raster Calculator:


1) How do I get rid of the one pixel shift in the "calculated" image?


2) What is the correct way to script more than one formula? The documentation says use a separate one for each band, but doesn't show how to accomplish that.


Thanks much,


Mark

Comments

  • DMcKittrick
    DMcKittrick Global Mapper Trainer Trusted User
    edited September 2014
    Mark,

    Is the entire calculated layer offset by one pixel. I just tested the NDVI calculation with Landsat 8 imagery and there was no such offset.

    To apply multiple formulas using a script, simply add a new command line (APPLY_FORMULA) for each band.

    I hope this helps.

    - David McKittrick
    Senior Applications Specialist
    Blue Marble Geographics
  • JeffH@BMG
    JeffH@BMG Global Mapper Developer Trusted User
    edited September 2014
    Hi Mark,

    Here's a sample "APPLY_FORMULA" script command that uses multiple formulas:
    GLOBAL_MAPPER_SCRIPT VERSION="1.0"
    APPLY_FORMULA FILENAME=* FORMULA="IF(B1<21760, B1*0.765+5120, B1)" FORMULA="IF(B2<21760, B2*0.765+5120, B2)" FORMULA="IF(B3<21760, B3*0.765+5120, B3)" OUTPUT_BIT_DEPTH=16 BAND_BIT_DEPTH=16
    

    It's just as David said. :)

    best regards,

    ~Jeff
  • Ice Age Mark
    Ice Age Mark Global Mapper User Trusted User
    edited October 2014
    Gentlemen,


    Thanks for the info on using formulas in scripts. I figured it out all ready by trial and error that it was PARAMETER="VALUE", ... ; and not PARAMETER="VALUE;VALUE...", or some other combination. The example given would be perfect in the script help.


    Regarding a pixel shift; I load any Geotif, zoom with no re-sampling to where I can see individual pixels, and create a "calculated" image with the raster calculator. (In this case I was experimenting with Henry's shadow lightening formula.) Then I set the image swipe tool for the calculated image to compare some individual pixels. When I swipe, the pixels are not aligned. I've tried several different images and projections. The shift is of the entire image


    I'm still on [Global Mapper v15.2.9 (b090314) [64-bit] - REGISTERED], but I discovered it while using the v16 two-week trial, which has now expired. It was common to both versions.


    Thanks very much,


    Mark
  • JeffH@BMG
    JeffH@BMG Global Mapper Developer Trusted User
    edited October 2014
    Hi Mark,

    The APPLY_FORMULA documentation in GM 16 does say that you need separate formula parameters, but an example would be clearer, for sure.

    I haven't been able to replicate the pixel-shift problem in GM 16 so far. Any possibility of making a small GeoTIFF file and formula specification that exhibits the problem?

    thanks,

    ~Jeff
  • Ice Age Mark
    Ice Age Mark Global Mapper User Trusted User
    edited October 2014
    Howdy,


    I've upgraded to V16 and done this with several images, so it should reproduce. Load a raster image, zoom in to where individual pixels are clearly visible (no re-sampling), enter a formula for each band, and produce a "calculated" image. Immediately choose the image swipe tool, and swipe the "calculated" image. (Don't export and re-import to test) The pixels do not line up. Here is a screenshot of what I see by keeping the swipe. (Maybe it's the image swipe tool?) If you're not seeing this, what could be unique that I'm doing and need to change?


    Thanks for checking again,


    Mark

    Global Mapper v16.0.3 (b100314) [64-bit] - REGISTERED

    Formula used:
    B1*1.02
    B2*1.02
    B3*1.02
  • JeffH@BMG
    JeffH@BMG Global Mapper Developer Trusted User
    edited October 2014
    Hi Mark,

    Still not able to reproduce this. I took a small image (712x812 pixels, 16 bit RGBA) and applied your formulas to it. Image swipe looked ok (I had never used the tool before), and I exported to GeoTIFF, and looked at it in a general purpose file comparison program that I use for development but that has an image comparison tool (BeyondCompare) and it all looked good too.

    Just for fun, I then applied an identity calculation (formulas "B1", "B2", "B3", "B4") to it. Again, the image swipe looked ok, and when I exported it and looked at it in BeyondCompare, it came out binary-identical to the original.

    So I'm a little puzzled. As I say, if I could get hold of a sample image that exhibits the problem, that might shed some light.

    best regards,

    ~Jeff
  • Ice Age Mark
    Ice Age Mark Global Mapper User Trusted User
    edited October 2014
    Hello Jeff,


    I gave specific steps to reproduce this, including:


    "Immediately choose the image swipe tool, and swipe the "calculated" image", and "(Don't export and re-import to test)"; and you replied "and I exported to GeoTIFF, and looked at it in a general purpose file comparison program".


    The shift occurs when viewing the calculated image BEFORE it's exported using the image swipe tool.


    Any image I use exhibits this.


    Thanks for trying it one more time,


    Mark
  • JeffH@BMG
    JeffH@BMG Global Mapper Developer Trusted User
    edited October 2014
    Hi Mark,

    I did both things, actually: "Image swipe looked ok", meant that I did try the image swipe tool, but didn't see what you had reported. The verification of the export at least tells me that it's nothing to do with the pixel calculations per se; that leads me to believe that whatever you're seeing would be something wrong with the display of the the calculated image, somehow. Why that would be, I don't know. I will give it another try, again, so we'll see, but really I'm looking for some difference between what I'm doing and what you're doing. Is it a difference with the source image? Is it the way that I'm using the image swipe tool? I'm just not sure yet. Any clues you could provide would help.

    thanks,

    ~Jeff
  • JeffH@BMG
    JeffH@BMG Global Mapper Developer Trusted User
    edited October 2014
    I guess I should ask the further question, rather than assuming the answer: if you save out the calculated timage, then load it back in, does it appear shifted relative to the original?

    thanks for your patience,

    ~Jeff
  • Ice Age Mark
    Ice Age Mark Global Mapper User Trusted User
    edited October 2014
    Jeff,


    Sorry to have dropped this, I was away, then forgot about it. Also sorry for not providing that pertinent bit of information. When I export and re-import the calculated image, all is fine. That's what led me to suggest it could possibly be a problem with the image swipe tool; though with more thought now, I don't know if that's plausable.


    Anyway, I'm still getting the shift with the V16 10-21-14 build, but only with the image swipe tool while viewing the un-exported image. This isn't hanging me up, I just bumbled across it while checking the results of individual pixels after applying a formula, before I exported. It doesn't seem like it should be doing this. When many adjacent pixels are very similar in color, it's hard to compare them 1 for 1 with a shift.


    Thanks again,


    Mark
  • Ice Age Mark
    Ice Age Mark Global Mapper User Trusted User
    edited November 2014
    Any word on getting this fixed?

    Thanks,

    Mark
  • JeffH@BMG
    JeffH@BMG Global Mapper Developer Trusted User
    edited November 2014
    Hi Mark,

    I went through another cycle of trying to reproduce this, to no avail. Are there any other clues that you might provide?

    * Does the image need to be large, or does it do this for small images?

    * Is the shift in the horizontal or vertical direction or both, and what direction is it (e.g., is the calculated image shifted to the left or the right relative to the original?)?

    * Is the shift visible across the entire image (e.g., is it visible on both the left and right sides?)? Does the shift go away if you pan or zoom the image?

    I tested this with the sample that Henry posted, and another TIFF that I had handy (in full, and on smaller samples). No avail.

    Anything might help to get a toehold on this one. In the meantime, I've opened up a bug ticket for this one, #14767, and we'll report back here if there's any movement.

    Thanks, and best regards,

    ~Jeff