Hello,

Coming from a different GIS tool, it took me a bit of reading to understand how Manifold handles rasters and why the raster tables look so different. So, I do understand now the way raster images are divided into tiles, with each of them having an X and Y number.

However, I do miss some of the quick overview we could have, when opening a raster table in ArcGIS or QGIS.

Please see the images below.

Namely, I miss the fact that we had a count by pixel value, and that we could assign a type to each value (e.g. pixels of value 3 -> we have 1032 of them (COUNT), and the value 3 represents Forest (TYPE)).

Is there a way we can find similar features in Manifold 9?

That's the sort of thing you'd do with Style, especially for single channel images, where there are many, many topics and step by step examples in the User manual. Start with Quickstart - Visualize - Styling Layers for a quick overview, and then jump into the many topics in the Style book in the main User Manual section. Follow up with the numerous step by step examples in the Examples book.

I disagree with Dimitri, and I don’t think his answer is definitive, mainly because styling only uses sampling/binning rather than addressing all pixel values. (Arc may do the same with large images, I don’t know.)

The way to do this correctly is by SQL.

Well, the answer is not intended to be definitive, just a pointer to where to get started as there are, indeed, very many topics involved. But Style is where this seems to end up, so starting with the many Style topics as entry points to drill into all the many other topics is not a bad approach.

The OP will have to learn how to construct the values (shown as fields in the illustration the OP attached) that will be used to drive Style: the "See Also" topics encountered in reading the many Style topics are likely to point the way. In this case, I agree, those values that drive Style are likely to be channels computed using some SQL expression.

Respectfully (with puckish humor intended), noting that "The way to do this correctly is by SQL" is not exactly definitive, either. It would be interesting to see what a definitive, step by step guide would be for what the OP wants.

That would have to start, I suppose, with understanding that what ArcGIS calls a raster attribute table in fact seems to be a vector construction, that essentially creates a grid of points behind the scene and saves in a .dbf the attributes for each point that corresponds to a "cell" in the raster. You can certainly do that in Manifold, creating a grid of points or area objects and then using join to join the value of each pixel into the vector object, using the various join operators like "count" to do that in a single step if you like.

Given that Arc's "raster attribute table" is limited to only 65,536 "values" (I suppose they mean records) by default, it's not a big deal to do the same thing in 9. You could certainly have far larger tables like that in 9 , which would choke Arc if you optionally increased the allowed size in Arc.

But that's a different thing than keeping it a truly 100% raster thing, which apparently Arc cannot do but which Manifold could do. So is the right way to meet the OP's desire to duplicate the Rube Goldberg approach used by Arc? Or is it better to use genuinely native raster approach that is possible in 9 but not in Arc? After all, doing it in a genuinely native raster way would be far faster for very large rasters, so that's a fair question.

There's also the question that often comes up with a new user who may be trying to make progress with 9 by reasoning by analogy with something already known, to try to duplicate known workflow in 9: that's the question of whether it would make more sense to apply a more efficient 9 approach instead of duplicating an alien approach.

For that, it would be helpful to know why the OP wants to see a presentation that pretends a raster is not a raster but is a regular grid of vector points. What's the ultimate goal for using such presentations, and is there a more direct, more efficient way of using 9 to accomplish that goal? When I see such tables that are clearly the results of spatial joins between rasters and a behind-the-scenes vector, I get the strong feeling that what's really going on is a need for a spatial join between raster and vector to generate some end result. Arc can't do spatial joins like that, but 9 can, so it doesn't need a pseudo-vector intermediate display. It could well be that an understanding of the OP's ultimate goal might point the way to a much faster and easier 9 workflow, which could work with vastly bigger rasters, than what ends up being used in Arc.

It could be, of course, that the OP is learning 9 and is just curious about the differences in approaches to values within rasters used by 9, Arc, and Q. That's also a good thing to discuss, but it covers a lot of ground so maybe it's best to discuss it in the context of specific tasks.

I interpreted his question differently. I imagined using, say, Google Earth imagery, and sampling the pixels to determine land use or health of the ground cover. Using other tools a picture like this...

can be sampled pixel by pixel to identify the nature of the diseased leaf and acquire statistics from the sampling.

Attachments:
Diseased Leaf.jpg

The Style pane gives approximate counts for value intervals.

If you are interested in exact counts, you can use SQL:

--SQL9

SELECT [value], Count(*) AS [count] FROM (

  SELECT SPLIT CALL TileToValues([tile], FALSE) FROM [arizona]

) GROUP BY [value];

The above assumes your image has a single channel. You can compute counts for multiple channels, too, but the query will be slightly different.