Subscribe to this thread
Home - General / All posts - New video on Tracing Areas
Dimitri


4,980 post(s)
#09-Mar-18 12:48

A new video on tracing vector areas from raster pixels has been published on the Gallery page and the YouTube Manifold channel. The accompanying project file can be downloaded from the product downloads page.

The video shows how to use Trace Areas, and also how to use a simple query to look up classification codes from one table and add them to another table by using INNER JOIN. The query for that is in the sample project, so anyone can use it to learn how to do the equivalent in 9 of relations in 8.

RonHendrickson
244 post(s)
#09-Mar-18 14:44

One of the better videos in this series. I have a question, does the Trace Areas transform get its Values field from some type of USGS pattern that says a green is a value "3" that somehow relates to a woodland, for example? In other words, where do the Values come from?

EDIT: Upon reflection and reading of the user manual on the Trace Areas, I think that since the threshold variable setting could create many variations of the Value field, there could be no set linking between colors and pattern of woodlands, reservoirs, etc. So disregard my question.

adamw

8,061 post(s)
#09-Mar-18 14:54

The values in the Value field come from the traced image, they are numeric values if the image has a single channel or numeric pairs / triplets / quads if the image has multiple channels. I think the video shows how to translate these values using the existing table that describes which numeric code is what.

Mike Pelletier


1,508 post(s)
#09-Mar-18 17:09

Some thoughts on using Trace Areas.

1. Would be nice to have an easier way to see the result vs the original image. Perhaps a quick way to toggle on/off the result or make it transparent.

2. A clearer indicator (then current bottom right) whether it is working on the displayed preview vs background work.

3. Any thoughts on where in the pipeline things like median square will be added for preprocessing the imagery before tracing? If you are considering adding just one soon then I'd vote for median square.

4. It would be nice to have a slider bar for the similarity input if it somehow could also allow fine control. Sometimes changing the input by just 1 (and probably less) can make a big difference.

adamw

8,061 post(s)
#10-Mar-18 06:09

Thanks.

Median filters are pretty close in the pipeline. We will likely add them in the next public build (so, after we wrap up the 9.0.165.x line).

We have some ideas regarding 1 and 2. As for 4, the way to get fine control out of a slider is to have a text box next to it, and we already have the text box. :-)

Mike Pelletier


1,508 post(s)
#13-Mar-18 14:48

Nice to hear some median filters are coming soon and look forward to seeing 1 and 2 improvements. Can't help but wonder if there is a better way for 4 though. I've never seen this done, but what about two sliders with one for fine control (keep text box too). Might be slick when combined with fast speed of a preview using a zoomed in area and/or restricted to selection option.

adamw

8,061 post(s)
#13-Mar-18 15:19

If we are looking for a quick way to increase / decrease a parameter, maybe we could just use up and down arrows while staying in the text box (and show up and down arrows on the right side). The increases / decreases can be smart, ie, they can obey the min / max limits, use a logarithmic scale, etc.

Mike Pelletier


1,508 post(s)
#13-Mar-18 16:41

Yes that would be a nice improvement. I attached a couple of examples from another software that combines a slider with text and arrows. Seems like this is a nice blend of tools. They sometimes use "smart" increments for the arrows, but don't offer a way to override the increment method used. Maybe an adjacent checkbox for switching to 10x finer increment for the arrows.

Attachments:
parameter.jpg

Mike Pelletier


1,508 post(s)
#15-Mar-18 17:00

After seeing Hugh's project below using GIMP, here's another parameter changing example from GIMP. Their method is space efficient with the title included in the slider area. They also have a reset button (circled red) to the right of the up/down arrows.

How about adding to the right of up/down arrows and another set of up/down arrows that are a finer increment (ie., 10x but determined by what makes sense for each parameter) and use double arrows (like this ">>" but vertical) to indicate they are finer control.

In locations where you have more vertical space than horizontal, maybe put parameter title within the slider control area like GIMP does and then just below (and adjacent) the arrows (normal and fine) on either side of the number entry. This could make the arrows larger and easier to click. This could be down to the right of the slider as well if space is available.

Thanks everyone for considering these brainstorming ideas that are free from the knowledge of how hard this would be to implement :-)

Attachments:
gimp.jpg

tjhb

8,215 post(s)
online
#15-Mar-18 17:32

Where (and assuming) it's helpful to have multi-speed adjustment, I think using the Ctrl key is a better way to trigger fine adjustment than to add a second widget. Similarly Shift to trigger very coarse adjustment (as in Photoshop). And Home for reset to minimum, End to set to maximum (or the reverse).

The modifier keys would control the size of increment/decrement, whether by using the up/down keys on the keyboard when inside the text box, or by clicking on the up/down widget beside it (if any).

Mike Pelletier


1,508 post(s)
#15-Mar-18 19:03

Good ideas Tim and that is the Manifold way! Still it only works for those you can remember it's there. A tooltip would help here.

It does make for a cleaner interface of course, but there needs to be a balance between squeaky clean versus demanding good memory or when that fails, being able to quickly find the needed tool.

Not sure the modifier control for the size of increment/decrement would get used much but might be useful sometimes.

hugh
153 post(s)
#14-Mar-18 18:49

looking forward to median filters and options -- meanwhile learning with this

Attachments:
TraceAreasExample.mxb

Dimitri


4,980 post(s)
#09-Mar-18 20:51

EDIT: Upon reflection and reading of the user manual on the Trace Areas, I think that since the threshold variable setting could create many variations of the Value field, there could be no set linking between colors and pattern of woodlands, reservoirs, etc. So disregard my question

No, it's still a good question.

Data like LULC rasters from USGS uses a fairly limited number of colors. That's pretty much the case when GIS packages use rasters in a way similar to how areas are used in vector layers.

So... you can trace them using the default threshold as in the video and you get the same, limited number of values. It's not like trying to trace a photographic image where there might be millions of different colors intermixed pixel by pixel.

Graeme

927 post(s)
#13-Mar-18 05:59

I was asked this morning whether we could extract how many swimming pools were in a given aerial image. Good opportunity to explore 9's new trace areas!

It seems to work on linked images from web servers, whereas 8 does not. Haven't quite figured out how to make a local image from a linked image zoomed view in 9, so brought in one created in 8. It works as outlined in the video, but currently lacking control to allow it to confine tracing to image tiles with certain characteristics, as can be set in 8's Tool Properties. With more user definable control, the additional speed shows great promise. In 8 for example, checking "match neighbors" really slows things down when tracing areas. I did this small job in 8 because of the fine control options, not yet implemented in 9.

Dimitri


4,980 post(s)
#13-Mar-18 08:18

currently lacking control to allow it to confine tracing to image tiles with certain characteristics, as can be set in 8's Tool Properties.

What characteristics did you have in mind? Value tolerance is the only one that seems to make a difference, and that's in 9 as well, called similarity. 9 always does "match neighbors" to avoid overlaps.

extract how many swimming pools were in a given aerial image. Good opportunity to explore 9's new trace areas!

That depends on what data you start with. See the discussion in the Trace Areas template in the transform templates - images topic and in the example it cites. Trace areas is not automated classification that can extract object types from raster imagery (see below). Trace areas is for picking out areas from classic "raster GIS" data sets that represent what really should be vector data as rasters.

The example (and video) shows a typical such data set, USGS LULC data. There is a world of difference between that data, which uses only about 30 colors, each of which is applied evenly throughout an entire region, and photographic data, which uses millions of colors in all sorts of interwoven, dithered, fuzzy ways.

If you start with LULC data that codes swimming pools with a specific color, as the data used in the example topic codes, say, "reservoirs", then, sure, it's quick and easy to find how many swimming pools are in the image.

But that's not a raw aerial image, that's a raster extracted from an image that's already been processed manually with much labor. If you are going to do that manually, you may as well manually trace vectors.

At the present time there are very few tools from any vendor which do automatic classification with high quality using aerial photos. They all seem to require so much prep work or adjustments after the fact that you may as well have done it manually, farming the work out to a contractor with low labor costs.

The best fully-automated technology for finding swimming pools looks like it is the same as finding tanks or missile launchers or submarine wakes or other objects that can be distinguished by visual or expanded spectra: by applying AI techniques such as training neural nets for object recognition.

That's very expensive technology. At least initially, it seems to be a better match to business models, like military sales, revolving around selling very expensive product to a very small number of customers, than to business models like Manifold retail products, revolving around selling inexpensive product to a a much broader base of customers.

Given Manifold's long history with GPU (the top choice for such AI) we obviously have irons in that fire, but to what extent any retail tools might emerge from that forge is difficult to say.

Mike Pelletier


1,508 post(s)
#13-Mar-18 15:11

Much can be done without the full set of classification tools when trying to extract out of an image objects that are distinct like swimming pools. I'm wanting to pull out shadows to map trees and cliffs in a landscape dominated by low shrubs. Using tools like median filters can reduce the noise fairly well, which then allows the tracing tool to work well. Manifold's speed will be a huge help for these projects and so would quick ways to get at the best possible parameters for preprocessing filters and similarity in tracing. Please dabble in tools that helps us map easy things and leave the submarine wake stuff for another day :-)

Graeme

927 post(s)
#14-Mar-18 05:33

Value tolerance is exactly it, in 8 context. Maybe cursor level control is all that's needed in 9, shift / click to restrict CreateAreas to pixels within the tolerance setting. Currently it creates an area for everything, which could be useful like in the example, but rasters like the one used usually already exist in vector format and get rasterised as inputs for grid analysis. I don't recall going down that route at all. However extracting patterns based on a restricted colour in an aerial image, pre-processed or not, has been an approach I've used many times.

Dimitri


4,980 post(s)
#14-Mar-18 07:49

Value tolerance is exactly it, in 8 context.

Use the Similarity box to do the same in 9.

Maybe cursor level control is all that's needed in 9, shift / click to restrict CreateAreas to pixels within the tolerance setting. Currently it creates an area for everything,

Why is that a problem? If you want just one area, that is easy: Ctrl-click to select that area, Ctrl-I to invert, an press Delete to eliminate everything but the one area you want. Either way, Similarity is doing the work for you.

adamw

8,061 post(s)
#14-Mar-18 08:29

For correctness:

Similarity in 9 is playing the same role as Value Tolerance did in 8, but these parameters are not exactly the same. This is because the operations are structured differently. In 8, you have to click a pixel, and once you do that, the system traces pixels with values +/- Value Tolerance away from the value of the clicked pixel. In 9, you don't click anything and the system traces all areas in buckets of N * Similarity to (N+1) * Similarity. So, Similarity is twice less than Value Tolerance and not centered on the value of the clicked pixel (because no pixels are clicked).

Graeme

927 post(s)
#16-Mar-18 06:42

In the scenario with the pools, a single similarity setting for the whole process groups everything using that setting. Because pools (and most categories of "things") are individually variable, the result is a lot of none pool pixels get included. In the screenshot of results formatted for clear fill, and ctrl_click on obvious pools in the image, a lot of none pool pixel areas are also selected. Sure we can delete the rest, decompose the remainder and maybe select small areas based on area and delete them. Just done so - 9 example how to add a computed field showing actual areas here - and a comparison screenshot is included (blue is the 9 result cleaned up, pink imported from 8) - some good correlation, but I think more noise from the 9 result..

The 8 equivalent was done in 4 main passes of trace areas with value tolerance changed depending on the pool colour. Some none pools were also created of course and removed in a comparable work flow.

If a linked image is going to be used, it would be a very useful addition to be able to restrict TraceAreas to either the window, or event the extent of another component, or layer in a map. Adding a "make image" option would be handy here in this context, too.

2018-03-16 15:16:08 *** (root)::[Data Source]::[Google Maps Satellite] (Download tile) The remote server returned an error: (404) Not Found.

2018-03-16 15:16:08 Web request: (root)::[Data Source]::[Google Maps Satellite] (Download tile) (0.189 sec, 0 B)

Log reported errors after 3 hrs though the map window blue preview was completely filled. However, cancelled "add component" after 20 mins – no progress shown on progress bar.

9.165.5

Attachments:
TraceAreas 8_9 compare.PNG
TraceAreas9 result similarity8.PNG

adamw

8,061 post(s)
#16-Mar-18 07:05

It seems to me that images like the ones attached are way too noisy to be used with tracing directly. They have to be heavily preprocessed.

I agree that tracing individual areas by clicking them like in 8 might result in better individual shapes than tracing all areas simultaneously because you can use different values of similarity = tolerance for each area and help center the traced color range by clicking what you think would work well as a center locally. But if you are willing to do all this for each area, why not just add coordinates directly using the cursor?

artlembo

3,077 post(s)
#13-Mar-18 18:33

just used the trace area on the LULC 2006 for Virginia.

Manifold: 165s

ArcGIS: 192s

geographic results were pretty much identical. ArcGIS broke the data up into individual polygons, whereas the Manifold areas would need to be decomposed to accomplish the same thing. That will take many, many more minutes to perform (doing a decompose to shapes, and we are already at 4 minutes).

artlembo

3,077 post(s)
#13-Mar-18 18:37

decided to quit the decompose after 5 minutes. Canceling the operation has pretty much frozen the application up. We had this problem with earlier builds that got resolved. Manifold may have to take a look at the cancellation of the decompose operation as well.

Dimitri


4,980 post(s)
#13-Mar-18 18:39

ArcGIS broke the data up into individual polygons, whereas the Manifold areas would need to be decomposed to accomplish the same thing. That will take many, many more minutes to perform (doing a decompose to shapes, and we are already at 4 minutes).

That's the wrong way to look at it. How many minutes would it take ArcGIS to compose the many small areas into branched areas like Manifold produces?

artlembo

3,077 post(s)
#13-Mar-18 19:04

I'm not sure it is the wrong way of looking at it, rather, it's another way of looking at it :-)

Your question is completely valid:

1. take a raster, and convert it to multi-part polygons for each land use type

However, it is also completely valid to ask:

1. take a raster, and convert each landuse type to its own polygon

I guess it all depends upon what you want to do with the data once you have it.

In my case, I was interested in performing the latter. But, for cartographic purposes, it might be better to do it as the former.

Mike Pelletier


1,508 post(s)
#13-Mar-18 19:23

Mfd 8 is much faster doing spatial gymnastics with many small polygons rather than a few large polygons. Mfd 9 is probably the same. This might be a good indicator of which method's result is better.

Dimitri


4,980 post(s)
#14-Mar-18 08:10

I'm not sure it is the wrongway of looking at it, rather, it's another way of looking at it :-)

I wrote that a bit slyly. My point is that when you compare apple to oranges, don't make the mistake of thinking that only apples are the right way, so that when a process creates wonderful oranges for you that is an error. Or, the other way around.

I like both apples and oranges. I don't want to do without either. I like to have either on hand so I can get what I want when I want it.

In this comparison:

ArcGIS broke the data up into individual polygons, whereas the Manifold areas would need to be decomposed to accomplish the same thing.

You compared two different things, both of which have excellent reasons for being. Either result would require processing time to be converted into the other thing.

For example, if Arc were to do all that Manifold did in creating those bundled areas, it would have taken even longer to do that extra work, if, indeed, it is even capable of handling such big and complex areas.

Manifold goes the extra step to create branched areas because arranging data that way is intensely useful and convenient for interactive work. I love being able to just click one contour area of interest and immediately being able to format absolutely every sliver like that everywhere in the entire world, if, for example, I'm working on a map of contours for the entire world.

It's true you can accomplish the same thing with many small areas by using clever selection, I suppose in whatever ESRI has that is similar to SQL or to Manifold's selection tools, but that is a workflow that is not so point-and-click as what can be done with what Manifold delivers.

Conversely, I can see a use case for zillions of standalone area objects as contours. Which of those you choose depends on whether at this moment for this particular task you want to reach for an apple or an orange. Neither is bad, but it is a mistake to in either case say "oh, this one over here is not so good because you have to expend time to transform it into the other."

Manifold delivers the result it does now because that is so much better for point-and-click usage, for thematic formatting and for per-object formatting, as most people do contours. It is way easier and clearer for most people to work with tables that have only a few dozen records in them. That's why Manifold puts the extra effort into delivering that simplicity, compactness and clarity.

It's not clear if ESRI does not do that because either a) their work derives from older generation approaches that do not support the big values per-record such an approach requires [a real possibility given the legacy influence of, say, shapefiles...], or b) a preference for the other way, or a mix of both. But they do it differently and in a perfectly legitimate and competent way.

In making apples to oranges comparisons, it is not always so useful to consider separately the cost of converting from an apple to an orange or vice versa. For example, Manifold goes to the effort of building branched areas when the contour result is first created. If you don't want that but instead you want standalone areas, it is far easier and more efficient to build those standalone areas during the process than it is to later take a carefully constructed branched result and to decompose that into shapes.

Likewise, if ESRI went to the effort of duplicating what Manifold does it is quite likely it would be faster for ESRI to do that during the initial process of computing contours than it would be to take a result of many standalone areas and to aggregate them into a compact set of branched areas. In either case it is best to compute the result you want as part of the initial process.

Therefore the best way if you are interested in apples is to compare how fast Manifold and ESRI are at creating apples, and if you are interested in oranges, likewise how fast Manifold and ESRI are at creating oranges.

To emphasize, neither apples nor oranges are "better" than the other. They both have their uses.

dyalsjas96 post(s)
#13-Mar-18 19:17

I have been trying to derive a slope areas drawing from the Garrett County, MD DEM.

The Slope transform worked, providing an image with values from 0 to approximately 82, so I'm presuming that's degrees of slope.

I would like to option to have slope calculated a a percentage, but that's another feature request.

Running the Trace transform on the output slope image fails quickly with an error message that there are too many areas (20000).

To simplify the image, I ran the Round to decimals transform, specifying 0 decimals.

I ran the trace transform again (after a reboot) and Manifold processed the image for approximately 20 minutes before failing; returning the following error message.

Invalid data buffer size

The error message is not reflected in the Manifold log, but the log does have the following error messages:

018-03-13 15:09:10 *** Failed to load library: nvcuda.dll

2018-03-13 15:09:11 *** Failed to load library: cuda.dll

Unfortunately, I do not have an NVidia graphics card with CUDA cores (that's my next buy).

Finally, I tried the Contour Areas transform (with Steps set for 1).

After the same amount of time processing as the Trace transform, the Contour Areas transform failed with the same error:

Invalid data buffer size

The Manifold log showed the same two error messages as well, Failed to load library: nvcuda.dll and Failed to load library: cuda.dll

Any thoughts?

tjhb

8,215 post(s)
online
#14-Mar-18 07:53

Hope to help you with this tomorrow, given Art's data (thanks Art).

Unless someone else has figured it out by then.

Are you using a subject, or all of Art's data? If a subset, could you post a rough AOI drawing (or just a screenshot)?

dyalsjas96 post(s)
#14-Mar-18 10:26

Thanks for the continued interest. My efforts to create a subset of the garrett15_1m DEM that I could upload got delayed by a wonderful visit from Mom.

From below, it seems that Adam spotted the error I was getting; said it would be fixed.

After the fix is implemented to the trace areas transform, I would appreciate working with you to automate the process of deriving a drawing of user defined slope categories from a DEM.

Dimitri


4,980 post(s)
#14-Mar-18 08:28

I'm presuming that's degrees of slope.

Correct:

Slope

Appears for single channel images. Treating the pixel values as heights to imply a surface, compute the inclination in degrees of the surface at the pixel's position and save as a pixel value from 0 to 90 .

If you are trying to create too many bins...

Running the Trace transform on the output slope image fails quickly with an error message that there are too many areas (20000).

To simplify the image, I ran the Round to decimals transform, specifying 0 decimals.

... use a higher value of Similarity. No need to alter the original data.

By the way, it's difficult to debug if you don't tell us what version of Manifold you are using, and other relevant info about your system. That's a big help in debugging. For example, if you are working with a 1 GB image and you have 20 MB of free space on your disk in a 32-bit Windows system the debugging hunt might start with different considerations than for a different system configuration.

dyalsjas96 post(s)
#14-Mar-18 10:11

Sorry to leave out useful info; I'm using the latest cutting edge build, 9.0.135.5

Yes, I was attempting to run the transform on the full garrett15_1m DEM from Art.

System is an AMD Ryzen 7 1850, 64Gb RAM, temp folders, data, and .map are stored on a 1Tb SSD with 70% free space.

dyalsjas96 post(s)
#14-Mar-18 16:34

Running Windows 10 Pro x64 with updates (including the March 2018 update that Microsoft needs to fix).

adamw

8,061 post(s)
#14-Mar-18 08:33

We have been able to reproduce the "Invalid data buffer size" error with Trace Areas. We will fix it.

We will try to reproduce it with Contour Areas as well.

Failing to load CUDA DLLs is not an issue.

As Dimitri says, instead of Round to Decimals with 0 decimals and then Trace Areas with 0 similarity, you could have just run Trace Areas with 1 similarity. (So, the process is: Slope -> Trace Areas with similarity being 1 or, say, 10 -> and on garrett15_1m this currently fails with an error which we will fix.)

dyalsjas96 post(s)
#14-Mar-18 16:33

I'll try running the trace areas with 1 similarity on the cutting edge build after the "Invalid data buffer size" error is fixed. Thank you for the advice on a more efficient way to accomplish the task.

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