Data shifted half pixel NW on crop to area

tjhb

Mike,

This problem seems to be consistently reproducible in recent builds of GM 11 (64-bit) including today's build (9 Sept 2009 15:16:14).

I load an image from GeoTIFF, and an area of interest from shapefile, select the area, then export to GeoTIFF at original resolution, with cropping to the selected area feature.

After loading the image back in, I notice a half-pixel shift NW compared to the original.

With a palette image the shift is accompanied by unwelcome interpolation at class boundaries.

At first I thought it might have to do with a source image having slightly different pixel dimensions in X and Y. But apparently not: I've had the same issue with sources images with exactly square pixels.

I can send data which shows the problem if you need it, and can also test with the same data in GM 10 if that helps.

Best regards,

Tim Baigent

tjhb

I just checked my notes, and see that I've had shifts both NW and SE. For what it's worth, the NW shift occured for data in Spain, and the SE shift for data in Australia. Unprojected images in both cases, in terms of WGS84.

global_mapper

If your export pixels don't exactly align with the input pixels I would expect to see some shift, up to a pixel in size, due to the resampling required. You might try enabling anti-aliasing (interpolation) for the input layers as that will mitigate the effects of any resampling, but for palette-based files can cause a class shift.

Let me know if I can be of further assistance.

Thanks,

Mike
Global Mapper Support
support@globalmapper.com

tjhb

Thanks for explaining Mike. Can I rephrase slightly to make sure I've understood? "If your export vector boundaries don't exactly align with the input pixel edges I would expect to see some shift..."? I hope that's it.

I've worked around this, when I've needed pixels to stay put exactly, by rasterizing a georeferenced raster mask in GM from the relevant areas (the whole image extent and the smaller AOI), at the source resolution of the image, then using that to perform the crop (in Photoshop). Rasterizing just the AOI, at the same resolution, gives a worldfile for the result (and here the "metadata only" option is a great help).

Back to the immediate question. I had tried enabling the option to "keep pixel if any part is within crop area", since I thought that might avoid the shift, but it seems not to. Is there any way this option could be tweaked, so that, if it is enabled, cropped pixels will always stay exactly where they are? That would be really helpful, especially (though not only) for working with palette images, and I think it would be quite intuitive from the user end. (With the option on, there's no longer a need to shift any pixels.)

Tim

global_mapper

Tim,

The only way to avoid the shift is to ensure that your Export Bounds boundaries aligns the same as the original data so that no resampling is done. Otherwise there will be some shift as the sample locations will not be at the pixel centers and a shift will occur.

Let me know if I can be of further assistance.

Thanks,

Mike
Global Mapper Support
support@globalmapper.com

tjhb

Thanks Mike. That does make life tricky, but I'm glad to have it perfectly clear, that's good.

No chance of an option to "Always align crop to pixel boundaries"? (It's always worth asking.)

global_mapper

Unfortunately in all but the simplest case (i.e. no reprojection or rectification and only one input file) such an option isn't even necessarily possible as any warping (i.e. reprojection or rectification) of a layer or having multiple layers loaded, each with different possible alignments, would make it impossible to align an export to always sample from a pixel center.

Thanks,

Mike
Global Mapper Support
support@globalmapper.com

tjhb

Thanks for your time Mike.

Yes, quite right. I suppose I was wishing that the simplest case could be made simpler. When resampling isn't necessary, I'd just like a true cropped copy of my source image(s).

But there are workarounds for the cases where that really matters, and I don't think I've convinced even myself that an option or change to the GUI would make things clearer to the average user.

Tim