Houston we have a problem!
Both of the methods described above result in an issue.

Method One (Path Point)
The path route (mentioned above) I have figured out, but it leads to a new issue. Since the base image is a cloud type pattern of noise (essentially a greyscale height map), the regions of black can be in separate locations. Since these locations are eventually selected via the fuzzy select tool, I would wind up having to create a recurrent loop selecting every point on the path, in a selection additive mode.
While this is possible, the base image is 6000 x 3000 pixels, and there is the possibility of MANY of these paths. So iteration is something I am trying to avoid whenever possible.

Method Two (Intersection of Selections)
Due to the irregular shape of the clouds, and the various positions of the black pixel clusters, the region selected would have it's upper left corner of the bounding box over a non black area. This would negate the possibility of using an intersecting selection with the bounding box.
Again iterating through the pixels of the selected area is possible, but this iteration is probably going to be even worse than the path option.

This image is a partial screen capture of a much larger image. The regions in question were selected, and then saved to paths, and the paths made visible for purposes of clearly showing the issue.

Any suggestions?

Hmm. Look at your problem the other way around. Your image is 18 million pixels. You have possible 256 values. If the pixels value are completely random (and unrelated to the values of their neighbors) you'll be dealing with 70K pixels.

And what is the purpose of the fuzzy selection (because using this selection in a script is fraught with peril)? If you need to reselect pixels at a given location, create a channel, set pixels kin the channel individually, and then use the channel as a selection mask.

The purpose of this selection is to create the channel in question for future use. But small areas (just one or two adjacent pixels) need to be omited from the selection, so select by colour wont work here.


That's the reason I am trying so hard to figure this out, in a sane manner.

My earlier description of a height map wasn't an alliteration, it is literally a landmass height map. But due to data loss from source, and small isolated height changes, selecting every pixel of a given color is both unnecessary and inappropriate. The goal is to select the various shades of grey in contiguous regions to generate contour lines. Not every color needs to be selected individually however. For example if I start with black (0, 0, 0) the next step up would be (4, 4, 4) (a scale difference of 1000 ft). But since the original selection of the black would be superimposed on this as a lower color (sea floor maps) the second selection must include the previous one. The same is true for each iteration away from black.

To simplify this a layer of white (in Lighten Only mode) is layed over the greyscale. Since I have (I hope to anyway), determined the darkest point on the greyscale layer, I can then select that point on the lighten only layer, after adjusting it's color levels down 4 points (so in truth I am selecting at the darkest location, the actual lightest location. But by selecting at the darkest points each time, every selection will include the previous one.) These selections are then inverted, and saved to channels for use as masks later. Thus a mask which shows depths of 0-4000 hides 4001 and deeper, but does not hide 0-3000.

(I'm tired, I've been up all night, so I may have said some of that backwards.)

Pseudo code for this would look something like this:


In the end, 65 channels are created each one representing a mask which will show a given altitude and all points above that altitude (or if applied reversed, all points below that altitude) in 1000 foot increments.

My problem lies in identifying the clusters.

Which is why I joined Gimp Chat The home of the experts!

If I understand you correctly, it is not necessary to identify the clusters; you want to identify the levels.

Consider the following XCF file (use the "Original file" download link): http://barn.kerosenecow.net/u/saul/m/contour-map-xcf/

Starting with a solid noise rendering, I used "Colors->Posterize..." to create 6 levels (this would be changed to 65 levels for your example). I did an "Colors->Auto->Equalize" just to give a more even distribution -- this should not be done if you are using actual map data.

I then figured out the values of the six colors (i.e., 0, 51, 102, 153, 204, and 255) and, after ensuring nothing was selected, looped through them from brightest (255) to darkest (0), each time through the loop adding the region of the current color to the selection and saving the selection to a new channel. The first time through the loop, all of the white regions are selected, the second time through all of the regions with color [204, 204, 204] are added to the selection, third time [153, 153, 153], and so on.

The Script-fu code for this loop is (shades is a list of the six colors):


In the XCF file, you will see the five channels that are generated.


EDIT: I screwed up the labels of the channels in the above screenshot (there should be no '=' signs), nonetheless the masks themselves are correct and the approach should be explained sufficiently for you to confirm or deny whether this is satisfactory for your needs.

Thank you so much saulgoode!

At first glance this looks perfect! Will implement it in python and give it a shot!

While this does make the implementation much easier it still has the flaw of selected area sizes.

These altitudes will eventually have contour lines drawn around their perimeter. And since the final image is being printed at professional photographic quality (300 dpi) this means the contour lines require a minimum width of 4 pixels to be discernible. Whether these lines are printed partially overlapping, or entirely within their own altitude, the net total is 8 pixels lost to contours along each axis (x and y). So a selection which includes an area which is not a minimum of 9 continuous pixels square, of the same color level, simply disappears beneath the contour lines. In fact a region of 16 pixels of continuous color is only marginally visible.

So the problem is eliminating the smaller areas from the selection, or selecting only areas of sufficient size to allow the rendering (in print form) to be meaningful. This is why I originally opted to try to use the fuzzy select, across various known dark points.

The data set is essentially accurate enough to be used for scientific purposes, but is in fact only being used aesthetically. It is essentially a work of art. It is for this reason that smaller areas can be omitted, and assumed to be part of the lower elevation (with the exception of the absolute black and absolute white which mark the deepest and highest points respectively). So posterizing to 65 after normalizing to fill in the histogram, are valid options; and have in fact been part of the plan all along. Unfortunately this still leaves areas which should not be selected.

Since at this point it seems that selecting the specific points is infeasible due to script safety and performance issues, the alternative is to try to remove those areas. Blurring has been tried, but distorts the continental shelves and coastline to much, as it tends to round these features off and make them too regular. Using selection grow ans shrink on a select by color also yields these types of results, although it does effectively eliminate smaller areas when you shrink a selection by 8 and then regrow it by 8, but the corners all tend toward circles.

Any one have any other ideas I can try?

(Worst case scenario I iterate all of the pixels once, and at each one I scan 8 more in the +/- x and +/- y directions to determine which areas are at least 16 wide. After all it would only have to be done one time....but it seems so sloppy!, and OMG would it be slow! )

What I have done for someone with the same problem is:

- obtain a selection
- obtain a path form the selection
- remove all the strokes under a given size (perimeter, but computing an area is also doable)
- obtain a selection from the new path

Of course, selection->path->selection doesn't return exactly the original selection but it is usually close enough. For a more accurate result, just grow the selection obtained from the cleaned-up path by a couple of pixels, and intersect it with the original selection. This gives you the original selection, minus the isolated spots.

But if you are trying to draw level lines, stroking the obtained paths is the way to go...

The issue that first comes to mind with that is similar to the original problem of using selecting by color in the first place.

If I select by color, I have already selected areas which are both valid and invalid for use (large enough and not large enough). So when I save teh selection to a path I have a single path object which contains multiple entities. If that doesn't make sense than try this:
new layer
filters->render->clouds->plasma (smaller your image the more turbulence you want just for the example)
colors->desaturate (choose the one with darkest results)
colors->posterize (any value over 64 should suffice)
select by color (threshold 0)
select->save to path
path dialogue-> make the path visible

Gimp sees one path, but visually it is many. Anything less than 16x16 is small enough it needs to be ignored. So I guess the real problem is separating/splitting the selection(s) by sizes.

As for your idea about calculating area, I have a script (by isoimage over at cartographersguild.com) which shows area and perimeter of selection, but unless I can separate the parts of the selection by size, it is not useful.

The path is made of several distinct "strokes". There is an API to obtain their length, but if you have performance problems you can approximate the perimeter/area of the strokes by just using the polygon obtained from the anchor points. You can also bluntly consider that any stroke above some number of anchors is going to be big enough to be kept (this skips the length computation for many strokes especially those that would take more time to compute).

See attached script.

Having spent a few days perusing these forums I realize that what I am about to say is nothing new.

ofnuts, YOUR ARE A GENIUS!

I was totally unaware that it was possible to select individual paths (strokes) from a path. In fact this whole vectors thing is new to me!

A 16 x 16 selection would have a perimeter of 64, so assuming an irregular shape, using a perimeter of around 40 should be perfect!

On a side note (because I am going to use something like this script thank you ever so much) is the same type of extraction possible with selections attained via select by color? (If possible no exemplar code is needed, but a point to the procedure would be nice... )

Also, your python-fu shows you know the python bindings way better than I do. Do you perhaps know of a thorough set of documentation for the classes and members (public API stuff)?

The origin of the path is completely irrelevant to the script...



Just experimenting with the Python-fu console. Use type(object) and dir(object) to list attributes/methods, these are mostly a rather thin layer over PDB functions (same parameters(*), except the object itself of course).

(*) with the usual difference that in Python you use the objects directly instead of their IDs (there are a couple of exceptions to this).

My path-related scripts, with a short write-up on Paths:

http://gimp-path-tools.sourceforge.net/

Dooh... Of course, apply the same technique... Although I was referring to using the selection object directly as in :

But since it can be done via the paths, it really isn't needed. I just wondered if I had overlooked something obvious (again)