Raster Calculator pixel shift
Ice Age Mark
Global Mapper UserTrusted User
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
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
-
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
Any word on getting this fixed?
Thanks,
Mark -
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
Categories
- 12.7K All Categories
- 5.6K Features Discussion
- 342 Downloading Imagery
- 1.3K Elevation Data
- 380 Georeferencing Imagery Discussion
- 628 GM Script Language
- 53 User Scripts
- 113 GPS Features
- 414 Projection Questions
- 819 Raster Data
- 1.3K Vector Data
- 6.6K Support
- 177 Announcement and News
- 908 Bug Report
- 558 SDK
- 1.2K Suggestion Box
- 3.7K Technical Support
- 562 Other Discussion
- 129 GIS Data Sources
- 27 Global Mapper Showcase
- 233 How I use Global Mapper
- 107 Global Mapper Forum Website