Subscribe to this thread
Home - Cutting Edge / All posts - Manifold System

9,817 post(s)
#15-Feb-21 17:28

Here is a new build.

SHA256: 02ae239305cba9b008f66a992f73ec83ef664e9076308e7004df913a0e8c008e

SHA256: 98bbe72caba2ee0ae22f2f849883da9d1a81a340ca277b42ac66a0bd946717e9

This build contains improvements for registration. The next build will contain improvements for editing, which we have been working on in parallel.


9,817 post(s)
#15-Feb-21 17:30


The Register pane supports several new registration methods:

  • 'order 1, shift + uniform scale + rotate' - affine with no shear and with scale forced to be uniform by X and Y,
  • 'order 1, shift + uniform scale' - as above plus no rotation,
  • 'order 1, projective' - a generalization of affine, called 'projective' in other products.

The Register pane allows specifying rendering options for images:

  • 'inverse, bilinear' - the image is composed by traversing the target image, finding corresponding source pixels and using bilinear interpolation on their values, this is analogous to the former 'standard' method in the Reproject Component dialog,
  • 'inverse, bicubic' - as above but with bicubic interpolation,
  • 'inverse, nearest' - as above but with nearest neighbor, used when the image stores values like classification codes that cannot be averaged,
  • 'forward, average' - the image is composed by traversing the source image, converting source pixels to the target and computing a weighted average of the results, this is analogous to the former 'direct' method in the Reproject Component dialog, the 'Pixel divisions' parameter controls quality: higher values produce results of higher quality, but are more computationally expensive,
  • 'forward, nearest' - as above but with nearest neighbor instead of averaging, this is a new option developed to allow registering images with values that cannot be averaged using any registration method, even if it is not invertible.

The 'inverse' options are only supported for registration methods that are invertible: 'order 1, affine' and modifications.

The Reproject Component dialog for images is reworked to specify the same rendering options for images as the Register pane.

The default number of pixel divisions used for the 'forward, average' rendering option in both the Register pane and the Reproject Component dialog is set to 2. This is a better default trade-off in terms of quality vs processing speed than the former value of 1.

The Register pane allows selecting fields to show in the control point list, using the menu button next to the toolbar:

  • Show Marks - (the default) shows name + coordinate mark (icon) + toggle,
  • Show Coordinates - shows name + x + y + toggle, x and y can be edited,
  • Show Errors - shows name + error + toggle, the Register pane has to show control points for a target component, any changes to control points (adding or deleting control points, changing their coordinates, toggling them on or off) as well as changes to the registration method automatically update errors.

The CoordConverterMakeWarpNumeric query function is reworked to take conversion type instead of conversion order as the second parameter, with the following values:

  • 0 = auto (currently maps to: order 1, affine),
  • 1 = order 1, affine,
  • 2 = order 1, projective,
  • 3 = order 1, shift + uniform scale,
  • 4 = order 1, shift + uniform scale + rotate,
  • 5 = order 1.5, affine + cross-product,
  • 6 = order 2,
  • 7 = order 3.

The CoordConvertTileSetDirect / Par query functions allow setting the number of pixel divisions to 0 to compose tiles using nearest neighbor instead of weighted averages.

The CoordConvertTileSetDirect / Par query functions limit the number of pixel divisions to 8 to prevent from accidentally passing an unreasonably high value due to an error and spending a lot of time performing unnecessary computations.

End of list.


9,906 post(s)
#15-Feb-21 18:11

What a great idea to align registration and projection, maths and options. Obvious now that you've done it!

It would be great to have some simple guidance, for each method, of when it might be advantageous to use it (or conversely, unwise). Examples of what data and purpose each is usually suited to.

There's only so much you can do with accurate naming, for users with limited maths.

(Probably coming in due course, will be welcome.)


9,817 post(s)
#19-Feb-21 13:22

On rendering methods:

'Inverse' methods are faster than 'forward' ones, but 'forward' methods are more accurate. Map windows use 'inverse' methods for automatic reprojection, because the accuracy is good enough for dynamic screen display. For permanent reprojection it is better to use 'forward' methods. The accuracy of 'forward' methods can be controlled using the pixel divisions parameter. The old default of 1 was the minimum possible and was perhaps too low. The current default of 2 is a great sweet spot which gets most of the quality without giving up an arm and a leg in processing time. Increasing pixel divisions to 3 or higher does improve quality a little, but there are heavy diminishing returns to that (the jump from 2 to 3 has much more of an effect than the next jump from 3 to 4, etc) and processing times increase a lot as well, so maybe try 3 or 4 as an experiment if you want to improve on 2. If 'forward' is used with the 'nearest' option, the pixel dimensions parameter is controlled by the system (right now this is hard set to 2, eventually we might vary this dynamically depending on where we are in the image).

'Nearest' should be used whenever pixel values cannot be averaged, as mentioned. Eg, if an image stores classification codes such as 5 = forest, 10 = water, 15 = unknown, averaging pixels for forest and unknown can produce water, which does not make sense, and averaging pixels for water and unknown can produce something like 13.75 which does not even correspond to anything. If pixels can be averaged, it is normally better to use one of the options other than 'nearest'. For 'forward', there's only one such option, 'average', it produces weighted averages, this is very accurate. For 'inverse', the choice is between 'bilinear' and 'bicubic', the former is faster and the latter is slightly more accurate. Usually, when you want accuracy, however, you go with 'forward' anyway, so if you decided to go with 'inverse' because you are fine with losing some accuracy and just want it all to be fast, you pick 'bilinear'. This is what map windows do, too.


9,906 post(s)
#19-Feb-21 16:09

Ideal, thank you!

Mike Pelletier

1,966 post(s)
#17-Feb-21 00:10

Thanks for these excellent improvements!

I'd hate to do anything that delays the release of editing tools but I can't help wonder if it would make more sense to put control points in the target window first, rather than the source window for the purpose described below from the documentation. Seems like it would allow multiple source windows to register off one target window without having to reload. Probably good reasons for the current setup but thought I'd put this out there anyway.

One source window, multiple target windows- A source window can be chosen as the source window in more than one target window, although that may be confusing for beginners. We might do that if we have many different layers we would like to guide georegistration, and we find it convenient to arrange those many different layers in two or three different target map windows instead of having very many layers in just one target map window. We could mark matching control points in one target window, save those control points and then load them into a second target window, and then continue marking a few more control points using features visible in layers in that second target window. We can then save those control points and load them back into any other target window to be used to georegister layers in the same source window.


6,899 post(s)
#17-Feb-21 05:05

I can't help wonder if it would make more sense to put control points in the target window first,

Ah, this is a request that won't delay editing tools at all: You can do that right now if you want. :-)

Pop open the target map window and add control points. This is just the same as if it was a source. Save those control points. They're now available to use either as a source or as reference in a target.

Open your source window and add corresponding control points. Back in the target map window in the pull down box choose the source window, and then load the control points you previously saved. Now you're ready to go.

Keep in mind that saved control points are just a drawing with points in it, where each point has a name. If those names happen to coincide with the names used in a source (names like P 1, P 2, P 3,... by default), you can use them as control points for a target map.

You can even use drawings of points that show, say, cities, as targets for georegistration. Suppose you have a drawing that shows big cities in the US as points. You also have several scanned paper maps that are historical maps of the US that, along with other features, show cities. You can georegister those scanned paper maps using your drawing of US cities as points.

Open a scanned image and mark a few cities in a reasonable spread across the US, like Seattle, San Diego, a few in the middle and a few in other "corners" using their city name as names for the control points. Save those in case you ever want to georegister another, identical scanned paper map like that.

Next, drag and drop your Cities points drawing into a map. That will be your target. In the Register pane choose the scanned image to which you added control points as a source. Load the same cities points drawing as if it was a saved control points drawing. All the cities with like names will match to the relatively few control points marked in the source, and all the others will be ignored. Now you can georegister.

Hey, that would make a great video! :-)

Mike Pelletier

1,966 post(s)
#17-Feb-21 14:57

Your right that ability to save/load control points makes it all doable. It just seems to me that that it is a bit odd that when you designate a source for the target layer, all the currently loaded control points get wiped out.

If this behavior is necessary, then it seems like perhaps it should work instead by not choosing the source layer while in the target layer but rather choosing the target layer while in the source window. That way the target window control points can be used for other source windows without reloading. It is a minor thing, but seems a bit more logical.

Bottom line is I'm extremely happy to have the register tools as they are today. Very useful and efficient tool.


6,899 post(s)
#18-Feb-21 08:08

It just seems to me that that it is a bit odd that when you designate a source for the target layer, all the currently loaded control points get wiped out.

Casual language that doesn't capture what's going on may be what makes it seem odd.

Target windows don't have control points of their own, although in casual language it is natural to refer to it that way.

By default, every window starts as a source window. With source windows you can mark control points at various locations in that source window, using whatever the coordinate system for that source window happens to be. Source windows have control points with specific names.

What changes a source window into a target window is when you tell that window to get control points from some other source window. That's what the drop down box at the top of the register pane does.

Target windows don't have control points of their own. They become a target window by declaring their role is guiding the georegistration of the specified source window by using the control points that source window defines.

To use the drone photo example, when in the Register pane for the Map Target window you choose EV-001 as the source window, you're telling the Map Target window to take the list of control points it uses from the EV-001 window.

When you click into different spots in the Map Target window, you're not creating a control point. Instead, you're marking what location in the Map Target window is supposed to correspond to the context control point that is defined in the EV-001 window and is picked by the table cursor in the Register pane list shown for the target window.

All of the control points in the list shown by the Register pane for the Map Target window are defined in the EV-001 window. If you want to add a control point or to delete a control point, you have to do that in the EV-001 window, not in the Map Target window.

Suppose you started with the map window that you planned on using as a target window, but while it was still a source window you created 100 control points at the locations of various cities. Those control points don't have any correspondence to some other source window that you want to georegister. If you like, you can save those control points as a drawing.

That's basically using the Register pane as a shortcut way to create a drawing full of points that have default names like those used by default for control points. When you create control points in a source window and then save those control points to a new drawing, that's what you are doing. You could do the same thing by just creating a drawing layer in a map and adding points to it. But then you'd have to name each point individually. Using the Register pane to do that is just a shortcut.

Suppose you now want to use that source window as a target window to guide the georegistration of some other source window. The first thing you do is tell it to use the control points from the desired source window. That's an explicit instruction saying, "throw out any control points I've created, because now I want to use control points from some other window."

When you "create control points in the target window first" you're not really doing that, since target windows don't have control points. You're just using a source window (which is what the target window is until you tell it to take control points from some other source window) as a short cut way to create a drawing of points with default names.

If you then create control points in the source window you want to georegister, and then tell the target window to use those control points to georegister that source window, if you created the control points in the source window following the pattern (the mutually visible features) of the control points that were saved, well, you can then save yourself the time of manually marking locations in the target window by importing the corresponding locations from the points drawing you created and saved eariler.

That isn't going to add control points to the target window, either. It will just scan the names used in the saved control point drawing that is being used, and when any of those names match the control points being brought in from the source window, it will use the coordinates from the saved control point drawing for those names as the locations to use for georeferencing the corresponding control points.

The whole relationship between source and target windows when it comes to georegistration is very simple and clear, but it does require grasping that key nuance that target windows don't have control points of their own, because being a target window means it is working with a list of control points from the source window that is to be georeferenced. Get your head around that one, simple idea and all the rest falls into place very simply.

But explaining that to folks who have a different mental model, one of independent sets of control points, one set for source windows and one set for target windows, takes a lot of words, as you can see above. I think that's why Manifold's documentation explains it the way it does, in a simpler way that allows people to recycle familiar concepts even if they are slightly off.

Let me close with one thing: I think it's a way more typical situation that you'd start with the source component to be georegistered, because that's the thing that has to get done. You have to use whatever are distinctive features in that source component. It doesn't matter if there are other features that are clearly visible in the proposed target, if those features aren't visible in the source component.

I'd therefore respectfully suggest that perhaps the workflow that starts by marking control points in the source as the primary activity, and then only as those points are marked moves on to marking corresponding locations in the target, is probably easier both to do and to teach than first marking locations in the target.

Mike Pelletier

1,966 post(s)
#18-Feb-21 23:15

Thanks Dimitri for the effort to explain the current thinking behind the setup. It certainly works fine once you have your head around it, which isn't that difficult. Still I'm not convinced that it is better, than what I was suggesting. To place control points you have to look in both the source and target in order to find appropriate spots. Thus, calling them control points in the source and not the target is a nuance that won't stick well in people's heads or be intuitive. Using a source as a target for future sources seems far less likely a scenario then using a target (typically a map) for other sources.

With the current setup, perhaps a bit more guidance in the register pane might help people. Maybe add the preface "Target for: xxx" in the dropdown bar at the top of the Register pane.


9,817 post(s)
#19-Feb-21 14:26

With source / target control points, we had the following choices: (1) while in the target window, specify source (the way we did it), or (2) while in the source window, specify target.

We did (1) because with (2) the process would be somewhat clumsy. Eg: open target window, place control points, open source window, select target window, place control points. Now you want to register source to target. Where do we do this? We are currently in the source window with the target window selected. If we try to register from the source window (say, the pane shows registration controls while in the source window, unlike currently), then the preview does not work - the result of the registration is in the coordinate system of the target window, showing it in the source window does not make much sense, it does not line up with anything. So, we want to switch to the target window to perform the registration, and this is just unintuitive - you first have to be in the source window to specify the target window, and then you have to switch to the target window (may have to find it first) to actually perform the registration.

On to the post - are you looking to register multiple components to the same target, is that why you want the target control points to persist? If so, maybe when you switch from source 1 to source 2, we can simply keep target control points with matching names. This likely won't save much time, because the process would be: open source 1, place source control points then save them, open target, select source 1 as the source, place target control points, register source 1, open source 2, load source control points, switch to target window, select source 2 as the source --- this is where we will save a step, which would have been: load target control points --- register source 2, repeat. But still something?

Mike Pelletier

1,966 post(s)
#20-Feb-21 00:20

Thanks for this explanation Adam and I'm glad the decision between 1 and 2 has been thoroughly thought threw. Don't really want to take up more of anyone's time with this but to be clear usually when I place points it is back and forth between both the source and target, so I don't see 2 as being more clumsy. Thankfully, I'm not typically registering many images at once so I don't think that is much of a consideration, at least for me. Whatever is most clear and intuitive for the most people is best!


9,817 post(s)
#19-Feb-21 14:32

In addition to the above:

Actually, if we have multiple components that we want to register to the same target control points, and if these components can also share the same source control points, there is an easy way to register them all one by one without much of a fuss: put all components to be registered into the same window (put them into a map and open it, or just open the first one and drag and drop the rest from the Project pane), place source control points, open the target component, specify the first window as the source in the Register pane, place target control points, then register layers one by one each time switching the layer to register in the pane.

202 post(s)
#17-Feb-21 18:13
The next build will contain improvements for editing, which we have been working on in parallel.

I hope we are not yet done with registration, since there still some important things missing.

The most important thing missing is snapping to entities when adding control points. You could instead add points to a drawing and load them as control points, but that would be totally unproductive.

Regarding errors, you cannot save them outside the pane. If you want to keep them for a report, you would have to type them manually. Instead, there could be a button to copy a simple report to the clipboard, or when performing registration the errors' report could be saved in the result component description or to a comments component. I suppose all the above would be very easy to implement.

Equally important is that the total registration error, that is a indicator if the total quality of registration, is missing. Also separate x and y errors are useful when one wants to fine tune control points. Currently, a lot of decimal digits of the errors are visible, while 3 are enough when one is registering a drawing in linear units (meters etc). So there is probably space to show x and y errors next to the total error for each point.

Finally, triangulation method for images can only be applied when all of the image is covered with control points, something that not practical possible in real situations.


6,899 post(s)
#18-Feb-21 07:15

I don't think anything major like georegistration is ever "done" since there are always new ideas and refinements, with plenty of existing ideas like snapping in the queue as well. :-)

Your new ideas in the post are great... don't forget to send them in as suggestions. I've sent in some similar ones, like suggesting the standard grid context menu (copy, paste, etc) be added to the grid used in the Register pane.

Refreshing suggestions can also be important even for prior suggestions, like...

triangulation method for images can only be applied when all of the image is covered with control points,

... because many other people might think that's not a priority given the new availability of thin-plate spline (which works great for images that are not totally enclosed by control points). You could note why it is you would prefer triangulation in some cases to thin-plate spline.

202 post(s)
#18-Feb-21 11:27

My comment was written because that I got the (possibly and hopefully wrong) impression that there will be a pause in registration work. Especially for snapping to vectors, you cannot practically register a drawing or register to a drawing without it, so moving to other things before snapping is added, no matter how important other things are, is like leaving registration in the middle of the road.

Regarding thin-plate spline transformation I don't know yet how it works in practice. As far as I understand, it forces source and target points to coincide, like triangulation, while it performs a 2nd order affine to what lies between points, while triangulation performs ad 1st order affine to what lies between. If this is the case, for practical applications that triangulation works fine (scanned paper maps locally distorted from age or scanning), thin-plate spline transformation will indeed work fine too without any visible difference from triangulation, having the advantage of covering all of the image, plus providing information for errors. So maybe triangulation as it works in M8 is indeed less necessary.


6,899 post(s)
#18-Feb-21 13:24

is like leaving registration in the middle of the road.

I think you're overselling that a bit.

I wouldn't worry about it, since snapping is already there today in georegistration... it just doesn't move the cursor before you actually click to mark the control point. Try it with snapping on (you can right click and call up the snap context menu and all that...), and you'll see the control point appears based on the snap. Manifold wouldn't do that and then just leave it as is, especially not with a lot of work on Editing going on that naturally involves snaps as well.

Tidying up small details like snapping is not a big deal, not compared to the really huge infrastructure work that's been done on georegistration for things like a new non-modal pane, the rendering options, different register methods, errors, and previews. I think it's a natural time for a pause on the big things, to give people a chance to digest what's there, but that doesn't mean small details won't continue to get polished in a routine way.

Regarding thin-plate spline transformation I don't know yet how it works in practice

A good example of where people need time to digest what's been added. That's become my favorite method for georegistering rasters, like distorted scanned paper maps, so I'd highly recommend it. See what you think and I bet you'll deprioritize triangulation. Thin-plate spline is used in the georegistration video at to great effect, where the scanned paper map is distorted in a variety of ways, not being internally consistent (low accuracy cartography) in the first place.


9,817 post(s)
#19-Feb-21 14:45

Thanks! Quick response:

Snapping when placing control points - will do (this is actually kind of working already, it's just that the snap reticule isn't showing, we'll finish it).

Copying error values - will do.

Producing a report of all error values - maybe, why not, perhaps copying it into the clipboard, like you say.

Separate X and Y error values - maybe, that's an interesting idea.

Showing total registration error - do you mean maximum error? Plus, perhaps, mean?

Allow triangulation to cover part of an image - will probably do, we agree that getting just nothing until you covered the entire image is annoying.

As Dimitri says, we are always willing to tune things up, so if you come up with more, don't hesitate to send suggestions, etc.

202 post(s)
#19-Feb-21 15:05

Total registration error is what is called Total RMS error in arcmap. I don't know for sure how arc calculates it, but I think it is just the average of the errors of the points. It is useful as a simple indicator of the total quality of the registration when adding, moving and deleting points to see what works best.


9,817 post(s)
#19-Feb-21 15:33

Got it. That's not an arithmetic average, it's slightly more complex, but nothing difficult. Will do.


9,817 post(s)
#19-Mar-21 13:20

Just wanted to say that we didn't forget about these things and some will appear in the near future.

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