Subscribe to this thread
Home - General / All posts - Merge Images - possible bug in calculated local X offset for output
tjhb

9,223 post(s)
#18-Feb-20 23:50

(Using Manifold 9.0.170.0, 170.3, 170.4)

Background:

When we use Edit > Merge > Merge images, the internal code handles some things automatically.

One helpful thing is that it works out local offsets for the merged image, using the full rectangular bounds of source tiles. (The source images might completely fill the combined bounds, or some parts might be empty. Either way the lower left corner of the overall bounds is used to calculate offsets.)

If we specify these values ourselves, e.g. by specifying local X and Y offsets for the merged image, the values are ignored. An automatic calculation is always used.

On the other hand, we do need to specify the target output resolution, since that is not adjusted automatically to match source imagery. By default, output resolution is taken from the X and Y local scales of the containing map. If the map uses default metrics, then output resolution will be 1 unit in X and Y, regardless of the resolution(s) of the input images. If the map uses local scales other than 1, then those scales are used. However, in either case, we can specify a target resolution manually, by setting local scales in the coord system section of the Merge Images dialog.

This is all fine, though in both respects it could probably be made simpler or more obvious. We might have to experiment a bit to see exactly how things work, but basically fine.


On the other hand, it seems there may be a bug in this process, specifically in the automatic calculation of the local X offset of the output image, for some but not all values of output resolution.

For example:

When merging images with 0.3mpx source resolution, the local X offset for the merged result is exactly correct if the target resolution is any of 1, 0.1, 0.2, 0.25, 0.4 or 0.5mpx.

But when merging the same source images with a target of 0.3mpx (the source resolution in this case), the local X offset for the output is incorrectly reduced by 0.1m. The merged image is shifted west by 10cm. The misalignment is enough to see at close zoom when compared against source data.

Different misalignments occur at different target resolutions. For example, -0.4111... at 0.6mpx, -0.111... at 0.9mpx, -0.9 at 1.1mpx, -0.4111... at 1.2mpx. (The misalignments for 0.6 and 1.2mpx are the same.)

Correcting the local X offset for the merged image to the expected value corrects the misalignment. (So: always check.)

I get this problem consistently whether merging ~100 images, ~1000 images, or two images (and regardless of their arrangement), using 9.0.170.0, 170.3 or 170.4. (There are significant differences in how maps are handled in 170.4, but they don't affect the problem described.)

The Y offsets in the results were always correct.

I will send in a report, but am posting on the forum as well, since others might trip over this in the meantime, possibly without noticing.

adamw


9,135 post(s)
#19-Feb-20 07:46

Thanks a lot for the detailed report. It seems we have all the details needed to try and reproduce the issue. We will look into it. If this is a bug (the behavior does seem weird indeed), we will fix it, otherwise we will explain what is going on.

volker

1,051 post(s)
#19-Feb-20 13:49

@Tim:

However, in either case, we can specify a target resolution manually, by setting local scales in the coord system section of the Merge Images dialog

How to do that ?

I have DOPs with a scale of 0.20cm if i merge than i got a new Image with a scale of 1m


http://www.thegisservicesector.de

tjhb

9,223 post(s)
#19-Feb-20 14:35

Attachments:
1.png
2.png
3.png
4.png
5.png
6.png
7.png
8.png

volker

1,051 post(s)
#20-Feb-20 12:59

Tim, thanks again for your step by step manual


http://www.thegisservicesector.de

adamw


9,135 post(s)
#25-Feb-20 07:44

You can also right-click an image in the list and select Use Coordinate System to use its scales (and system).

When you are merging images with 0.20cm (or was it meant to be 20cm?) pixels, the default for the resulting image might be 1m pixels because that's what the map itself uses (we aren't trying to guess the best scale for the resulting image because images might have different scales and you are free to select an arbitrary combination of them).

tjhb

9,223 post(s)
#19-May-20 01:25

This issue still arises in 9.0.172.0. It has been consistent since 9.0.170.0.

I will package up some compressible test data today, so that anyone else can reproduce the issue (or perhaps explain it).

tjhb

9,223 post(s)
#19-May-20 16:01

Here is a test project (9KB).

It contains two adjacent images, each 8000 x 12000px, in NZTM/NZGD2000.

If you merge them at native resolution (0.3mpx), then the combined image winds up with X offset 1803999.9.

It should have X offset 1804000, the same as image A.


It could be worth noting that if you do right-click -> Use Coordinate System (on either image), the suggested result is 16,000 x 12,000 pixels.

Whereas, if you click through the projection dialogs and [first select "Use default values" then] manually specify Local Offset X and Y of 0.3m, the suggested result is 16,001 x 12,001 pixels.

Regardless though, in either case, the actual result has 16,001 x 12,001 pixels. That and the resulting X offset are both incorrect.

Attachments:
20200520 Test merge b.mxb

adamw


9,135 post(s)
#19-May-20 16:30

Thanks a lot, we'll take a look.

We had what might have been a similar issue in re-projection which we fixed, we'll check Merge as well.

tjhb

9,223 post(s)
#19-May-20 16:53

I hoped you might say that. :) The projection fixes rang a bell.

Rounding is horrid even for amateur cases. Real programmers have to deal with binary artefacts and denormalization as well. [And IEEE.] Yuck [meaning that my head could not cope, I wish it couid].

tjhb

9,223 post(s)
#19-May-20 21:12

There was a comment recently wishing that the Merge dialog had an Edit Query button.

My guess is that you aren't doing this in SQL, but in straight C, an exception. No SQL, no objects, no nothing. That's why there's no button already. And part of why it is pure-metal fast.

But if that guess is wrong, and you are doing Merge in SQL, well, an Edit Query button would be really useful, to be able to make customizations and mess it up properly.

tjhb

9,223 post(s)
#19-May-20 21:38

(If it is in SQL, there must be a lot of pragmas. Might be just too complex for users to customize safely.)

adamw


9,135 post(s)
#20-May-20 09:34

We are doing Merge using internal code, not SQL, exactly. I explained why briefly - because the number of involved components is frequently large and so traditional SQL boils down to multiple repetitions of the same (fairly big) boilerplate for each image, which makes the query big, difficult to read, difficult to adjust, plus very inefficient because images end up being merged sequentially rather than in parallel, because each image is merged using separate statements. We *could* extend our SQL with functions that would in the end express the merge between multiple images as a single function call and might do this in the future. If we do that, we will add the Edit Query button to the Merge dialog.

adamw


9,135 post(s)
#20-May-20 11:41

Whereas, if you click through the projection dialogs and [first select "Use default values" then] manually specify Local Offset X and Y of 0.3m, the suggested result is 16,001 x 12,001 pixels.

This is actually correct - if the above means that you set local scales to 0.3 (I suppose you intended to write 'Scale' instead of 'Offset') and leave local offsets at 0.

We have 0.3 m pixels that start from 1,804,000, that is, pixel 0 extends from 1,804,000 to 1,804,000.3, the next pixel extends from 1,804,000.3 to 1,804,000.6, etc, and we are telling the system - hey, please put these pixels onto the coordinate system that starts from 0. In the coordinate system that starts from 0, 1,804,000 is in the *middle* of pixel 6,013,333, because 1,804,000 does not divide into 0.3 evenly. That produces a shift in pixels between the target image and the source image, and the shift results in one extra pixel added.

What's wrong is that even if you set the coordinate system of the target image to that of one of the source images, which are correctly aligned between themselves, the operation still produces an extra pixel. We will fix this.

tjhb

9,223 post(s)
#21-May-20 03:16

Adam,

Thanks very much for this explanation, and for the fix, astonishly quick.

My first tests (with a larger dataset) shows perfect alignment. So far I have used the "right-click -> Use Coordinate System" method.

At first I was slightly puzzled. While the X offset of the merged image matched the key input image exactly, its Y offset was 9.6m further north. But this is just due to different internal tiling schemes. The source images had a tile scheme starting at the top left corner (no doubt because that is the way the imported data happened to be laid out, as you explained in this thread). The result image is tiled starting from the lower left corner (arguably more natural). So the position of invisible pixels of padding, needed in this case to make up whole tiles, is opposite.

In general, "Use Coordinate System" does not mean that we should expect local offset values for the merged image to match local offsets of the key source image. Its offsets will be used to calculate the alignment of output pixels. But besides the possible removal of invisible padding, offsets must be adjusted if we choose a key image which is not at the lower left corner of the combined Rect. There might be no image in that position, or we might just happen to choose the upper left image, or some image in the middle. Manifold just handles these cases. If all source images have the same resolution, and their pixel boundaries are aligned to a common scheme, then we can pick whichever key image we like.

For the current tests, merged pixels are now exactly registered to source pixels. No interpolation was necessary, so there is no possible loss of sharpness. Great.

I'll post back after checking other methods, i.e. what happens if we specify both target scales and offsets manually (not leaving offsets at 0, 0, for the reason you have explained); or if we apply target scales and offsets to the containing map so that these are inherited.

Thanks again for nailing this!

Manifold User Community Use Agreement Copyright (C) 2007-2019 Manifold Software Limited. All rights reserved.