extract 255 colors for Each photo
If an image with only 255 indexed color values instead of a full RGB range of over 16 million colors will produce the results you want, then the job is trivially easy in Release 9: use the Trace transform to create vector areas for each color value (use a tolerance of 1) and select those which have Values that are the colors you want. Starting indexed color image with a palette of 255 colors: 
Trace applied with a tolerance of 1, and areas with Values of 45, 49, 50, and 51 selected: 
It's easy to know what colors to select by making the vector layer partially opaque so you can see the image underneath, and then alt-clicking on areas of interest to see what color value they have. Just those areas shown in brighter blue for visibility: 
Not bad despite a very poor initial image with low contrast. Note that one of the pools, a rectangular pool towards the left edge of the image, is not picked up, because the indexed color for it is more gray than blue. Choosing that gray color for selection would add much noise because that gray color is used elsewhere. But you could deal with that by adding a spatial size qualifier. One nice thing about using SQL is that you can pick areas which are both a particular color and also at least a minimum size, to eliminate noise from small areas. Note also that one other pool, in the lower right corner, is not picked up because it is empty of water and appears to have used a white or gray color for the internal surface of the pool. Another possible pool in the upper right may have a white cover. Not much you can do about that when using colors to find pools. You can also use Trace with RGB images, with a greater tolerance, which effectively picks out a range of "similar" colors, and then use elementary arithmetic on the Value vector that results to pick out what's closer to the "blue" you want. using SQL we should be able to select a volume ( clound minimum 4 points) of colors points
Yes. That's exactly what computations like in the "well known" link I provided in my earlier post do. Finding a desired "volume" in a color cube (3 channel images) or hypercube (4 channel images, like RGB+IR), is a simple matter of a few calculations on values in the channels. However, I think it would be better to take advantage of the vast experience in work with imagery. One reason people use the HSV model (Hue, Saturation, Value) is precisely to be able to choose colors by Hue, without having to mess with computations on multiple channels. The approach in 9 is simple: using the Transform - Expression template for tiles, add a one-channel tile field to the table that is a computed Hue value, rounding the value to whatever level of accuracy you want. Integers, for example, will create an image with 360 Hue values. Create a one-channel image from that tile field and apply Trace to create areas by Hue. Pick the range of Hue valued areas you want using SQL. Done. To learn the formula to get Hue from RGB, google "convert RGB to HSV formula". Here's a link showing how to do it in Java, for example. That has the advantage that it scales to 100 GB images, which consumer tools like colorSchemerStudio are unlikely to do as well. I respectfully note that while I've provided details on how to go about this task, you've not yet replied to my question if this is something you personally really need to do, and, if so where you see that as a priority compared to other things. It's OK to have casual interests or idle curiosity (makes the world a more interesting place), but it's important to always phrase those with a sense of priority. Attachments:
 pools_01.png
pools_02.png
pools_03.png
|