Subscribe to this thread
Home - General / All posts - Color Balance difference in images imported into M8 and M9
drtees71 post(s)
#08-Apr-19 16:44

I like to use M9's "Merge Image" function to paste together geotiffs and LIDAR files. It is fast and does not affect the resolution of the resulting images. I noticed recently that there is a distinct difference in color balance of geotiffs imported using M8 and the same geotiff imported using M9. The image imported into M9 appears muted, while the same image imported into M8 appears to have a brighter color balance. I have attached two screen captures showing the differences. I am unable to provide the source file because it is too large to post and a direct link to the source cannot be made. That said, the image is a high-resolution aerial image from 2012 (file name 'rgb_24276_025.tif') that can be downloaded from Earth Explorer (U.S.G.S. website http://earthexplorer.usgs.gov). I have noticed this on several geotiffs uploaded into N9, so the specific file is not the likely problem.

Am I missing a step in importing images into M9?

Attachments:
M8 Aerial TIF Import.jpg
M9 Aerial TIF Import.jpg

oeaulong

192 post(s)
#08-Apr-19 17:45

Well, I have duplicated this visual difference using the same file imported. I have also played with some of the Mfd9 Auto-contrast settings on each of the channels. I am assuming your goal is to achieve the same color balance in Mfd9 as you have in v.8.?

oeaulong

192 post(s)
#08-Apr-19 18:00

Ok. once imported to Mfd 9. You need to reassign the channels. With the image open, Hit Ctrl+5 to bring up the Style pane. Beneath the pull down showing "(use RGBA channels)", you will see a 2X2 square matrix button. This will change the default association of channel assignment. Choose RGB rather than the default BGR. This will correct your issue. There has already been discussion on this prior in the forum. I am just now getting back to speed on usage in the newer system. Cheers.

Attachments:
Mfd9_balancetest.PNG

drtees71 post(s)
#08-Apr-19 18:46

Thank you and you are correct! It was discussed in a previous discussion that I was a major contributor to. Having a "Senior Moment," I think!

adamw


8,584 post(s)
#01-May-19 12:52

Just in case, if the current cutting edge build of 9 still reverts channels for your images, let us know. We do not have your particular file so we cannot check, the images from various EROS data sets that we download seem to import fine - after the changes we did since the time this thread was first posted.

drtees71 post(s)
#02-May-19 17:40

I just used the latest build of M9 to stitch together several aerial images from 2002, downloaded from Earth Explorer. The images imported appeared correctly on the screen. However, the resultant merged image had switched the channels to BGR. I switched the channels back to RGB and the merged image looked correct. I then exported the image as a TIFF and loaded it into M8. The channels were back to BGR. This cannot be fixed easily in M8 (if at all).

I realize that the moniker "RGB" is backwards since the channel order is actually "BGR." However, forcing images to the "BGR" channel order appears to cause problems with other programs (such as M8) that already seem to work around the channel order issue.

From my seat, I see the issue as a choice between being right or being happy. M9 is technically being "right," but it results in me not being "happy."

Dimitri


5,460 post(s)
#03-May-19 08:21

From my seat, I see the issue as a choice between being right or being happy. M9 is technically being "right," but it results in me not being "happy."

That's a bit like saying when somebody flips a coin and your task is to guess "heads" or "tails" the choice is between being right or being happy.

That's not the choice at all. In games of chance, it is a matter of luck, not a choice between a "right" strategy and a "happy" strategy. When flipping a coin, whether you guess "heads" or whether you guess "tails," you're going to be wrong half of the time.

There is none of this "Oh, the right choice is to always guess "heads" and if people are not happy with that, too bad." Conversely, there is none of this "Oh, I wish the software would make me happy... just guesscorrectly heads or tails all of the time."

Images can be a game of chance as well, when different files use different channel ordering, and sometimes within even the same format, but the format does not say how the ordering should be interpreted.

Many formats do, of course, either by how the format standard is written or because of a standard tag or standard sidecar file that says "this is how the channels should be interpreted to form a visual image." Those are not games of chance, and in such cases there is no need for the software to guess or to make any distinctions between "right" and "happy." The software simply does what the standard/sidecar/etc says, gets it right, and everybody is happy.

The problem is "games of chance" formats, or people who wrongly implement standard formats: If the format does not tell you the channel ordering that is supposed to be used (and most of them do not do that), you have to guess. Whichever way you guess, just like flipping coins, sometimes you will get it wrong.

You see that especially when interoperating between different packages, because poorly-written packages that utilize poorly-specified formats often depend upon secret handshakes, and not explicit standards. They may be completely unconscious that other software operates differently, that standards exist, etc..

Example: Billy Wilson has written his own image editing program. He used a library he found on the web, he can't remember where, to read/write data to what he calls TIF format. He's pretty sure this has something to do with the "TIF" format he's heard of but maybe it's something else. But what the heck, he's going to call it TIF anyway.

Billy's new program saves channels in RGB ordering because he's heard that "RGB" images are what they are supposed to be. The library Billy used is set up for BGR ordering, but Billy changed that as an obvious mistake. The library mentions something about "tags" but since Billy doesn't know what those are he ignores doing anything with them and just lets the library do some sort of default thing with them.

So Billy's program floods his users with many, many images that have channel assignment backwards from how the library he used is supposed to work. For added chaos, Billy's program writes tags that explicitly say the channels should be interpreted differently than what they are. Think Billy cares about that? Nope.

In Billy's program they work fine. In every other program that uses the library the colors are wrong. Billy's thinks that because his program works great he obviously got it "right". His users are "happy" because when they use Billy's program everything works correctly. They get on the web to criticize all those horrible commercial programs that aren't free like Billy's, and which get it "wrong."

The above example is extreme but common. Also common are programs that use "popular" formats for images which do not contain bogus tags, but where different channels are used for different types of data. It is extremely common for programs to write particular channel orderings and then, because they assume it should be a particular way, the data works within that program but not necessarily with other programs, which take a different approach.

To interoperate with all that a program, like Manifold, has to be able to consume data in any channel ordering and to interpret that data however it should be interpreted for the data to make sense for the intended purpose, such as creating a visual display where the colors look right. That's the easy part.

I emphasize that in what follows the problem is not well-defined formats for purely visual images where channels are always in a well-defined order and intended interpretation, or formats where tags/metadata are correctly used to specify channel order and intended interpretation. The problem is the "coin toss" formats where different interpretations are possible or where tags/metadata are incorrectly used. That's Billy's World.

The hard part is what sort of user interface you want to interpret different arrangements of data. The key thing to understand about that is whatever you choose will make some users unhappy. There are two approaches:

1. The classic Windows consumer approach is to deal with a reduced number of formats and to automatically interpret different channel arrangements on a "best guess" approach that works well most of the time for those formats. This is basically sticking your head in the sand and wishing the problem away: "Oh, no problem! I'll just stick to reading those formats where there isn't any problem." That works great if you have a limited number of consumer formats and you only read files that use them correctly.

The price you pay for that approach is that it breaks down if you can work with many dozens of formats, and hundreds of sub types, like Manifold can do. Doing "secret handshake" changes behind the scenes based on what the program guesses will inflict chaos on skilled users by sometimes making changes in interpretation and sometimes not.

Manifold used to take that classic approach, modifying interpretation in a "best guess" way. That made some people happy while other folks were unhappy. So, now Manifold uses...

2. The other approach is to import the data as it is and allow whatever interpretation the user desires for displaying that data. In cases where formats or tags/metadata specify an interpretation, use that. But otherwise, leave it up to the user. If you want to be "happy," do whatever you like so you can get your way and be "happy." There's no being right or wrong, just let the user do whatever they think means "happy." If somebody isn't happy, it's easy to change to what they want with everything being done up front, totally transparent, no guess work or second guessing anybody's second guesses.

Using that approach leads to more certain success with Billy's World or other problem formats, as well as for the very, very wide range of niche or specialty formats that use variable channel ordering/interpretation. But it does so at the cost of annoying less skilled users who haven't learned how to work with such variety, or who want to do more advanced things with varied data than their current level of learning supports.

In such cases, for example, if a user wants to merge different data from different sources that use different channel orderings and/or different interpretations, well, it's up to the user to make whatever decisions or alterations they want before merging.

You can, of course, wish for a super-duper merge tool that combines both merge functionality and interpretation editing capability into the same tool, putting controls for such alterations into the merge process. Whether you think that makes sense or not depends on whether you want the same functionality duplicated in different places, or whether you believe that user interfaces are easier to learn if they stay modular, without many different dialogs trying to duplicate the work of other dialogs and thus adding to complexity.

There are many cases in GIS where merging different types of data requires some thought and skill on the part of the operator. That's what you get when you allow the great variety and richness of data sources that something like Manifold provides. The good news about images is that they tend to be very simple compared to other "merge different things" tasks.

For, example, suppose you just want to merge files of city names and locations from many different countries into one table. There you might have to deal with the fun where the city name/location tables provided by different countries might use completely different collations for the Name field, for example, a Portuguese Brazilian collation from one, a Spanish Mexico in another, a German Swiss collation in a third, a French France collation in a fourth and so on. How do you combine so many different sort orders for different languages into a single field in a single table?

drtees71 post(s)
#03-May-19 19:10

Wow! I honestly do not have time to read all of this. I suspect that the thrust of my "happy or right" comment is being missed. I appreciate that Manifold does such an excellent job at adhering to formats and protocol. The program (especially M8) is so easy and intuitive to use that I have made converts of former ESRI adherents who work with me.

That said, I work in a field that often has very short deadlines to produce products. I download and import a lot of TIFFs, often requiring several of them to be stitched together in order to represent an area of interest (I don't use image servers because I need to import legacy aerials on a frequent basis). M9's merge feature is so much easier than doing the same work in M8, that I would prefer to use M9 entirely. However, M9's functionality in producing layouts is not as mature as M8, which requires me to export my results from M9 to M8. That exported image comes into M8 with the channels reversed regardless of how I set it up in M9. There is no way to correct this in M8. That is the source of my "unhappiness."

As an end user, I expect that GIS material (drawings, images, surfaces, etc.) that I import will display correctly. If it doesn't, I expect that I can resolve the issue quickly. As with images, there is an expectation that the image will appear relatively the same whether viewed in Manifold, Windows Picture Viewer, QGIS, Geoviewer, ArcGIS, or whatever. If all of these programs display an image with the correct color balance but one does not, then the end user has to make a decision on which programs to use. It no longer matters if the one program displaying the image is technically correct if the resultant image being displayed is chromatically wrong. It is not helpful if that program allows the color balance to be corrected, but that correction on export means that other programs will not be able to display the image correctly.

Please understand that the end user of Manifold (especially those of us who do read the manual) are likely proficient in GIS to various degrees, but are not programmers, nor especially well versed in how the myriad GIS and image formats are designed. We do not need to be. We do have an expectation of some consistency in how they are handled, especially in the way images are presented.

tjhb

8,771 post(s)
#03-May-19 20:14

I will write some quick steps to do what you need correctly.

If you can attach an example image or two, so much the better.

I will want you to test the steps and report, please.

drtees71 post(s)
#04-May-19 00:20

Thank you. I will try to set up a Dropbox link for the images.

drtees71 post(s)
#04-May-19 00:50

Here is a Dropbox link to a selection of aerial images downloaded from Earth Explorer. The TIFFs are projected Washington State Plane North (NAD83). I imported the images that start with "rgb" into M9, created a map, and placed the images into the map. These came in with the correct color balance when I just did it; however, that is not always the case. I used the Edit-Merge Images function to stitch them into a single image with the default name of "image.tiff". Opening the resultant image in M9 showed the colors reversed. I used Style to have M9 display the image as RGB instead of BGR. The image then looked correct. I exported the image (the file in the Dropbox link) and then imported it into M8. The colors were reversed. I then tested whether using Styles to force the image to display RGB had any effect (i.e., I did not alter the color balance in M9). The file named Image-2 is the result. This file still loads up in M8 with the colors reversed.

I just looked at the properties of one of the base images and the resultant merged image. The base image has a field named StylePixel. The merged image does not have this field. Not certain if that is an important clue here.

Thank you for taking the time to help me sort this out.

https://www.dropbox.com/sh/k20y7q1l6tf4ci2/AABLUD_MgsJnF0k_4RHwcfSaa?dl=0

adamw


8,584 post(s)
#06-May-19 10:28

Klaus had a similar issue in a different thread, here is my reply which explains what is going on. Dimitri is talking about the same thing.

We are considering adding three things:

1. Extend the merge dialog for images to detect when all merged images use the exact same channel mapping, and automatically assign the resulting image the same mapping. This will help cases when you are merging a set of similar images which use non-default channel mapping (eg, RGB).

2. Extend the merge dialog for images with an option to convert data to 8-bit RGB / RGBA / BGR / BGRA. This will help cases when you are merging a set of images with varying formats (mixing RGB and BGR or mixing different palette images - the only way to merge them sanely is to translate color codes in each image separately), and this will produce an image that would export with the channel order you want.

3. Add a transform or tool that would take an existing image and produce an 8-bit RGB / RGBA / BGR / BGRA version of it. This is so you don't have to merge a single image when you want to apply style info to data and produce static colors.

For now, you can (a) set channel mapping in the merged image to RGB using the style pane, and (b) export the merged image to PNG instead of TIFF, this will apply style info during the export and produce unambiguous color values that 8 will read and display similarly to 9.

Dimitri


5,460 post(s)
#06-May-19 10:31

Wow! I honestly do not have time to read all of this.

Sigh... if you never take the time to learn how to get what you want when working with a wide variety of data, you'll encounter unnecessary frustration when growing beyond very simple formats or very simple uses of more complex formats.

As an end user, I expect that GIS material (drawings, images, surfaces, etc.) that I import will display correctly.

That's a perfectly reasonable expectation for simple formats where there isn't an error in the data, and where the format is so simple there is little or no variability in how it is used.

Manifold does exactly that: such formats (very many) import and display correctly. If anything, Manifold can handle more formats than, say, PhotoShop, in that way. If it doesn't in some particular case, that's a bug to report so the problem can be immediately fixed.

But suppose you want to up your game from the consumer mindset. Suppose you want your software to be able to read data from more complex or non-standard formats that simple, consumer software cannot handle? Suppose you want your software to be able to repair errors in data?

In that case, your software has to give you the options to do whatever you want. Manifold does that as well, using very simple controls that let you do whatever you want.

We do have an expectation of some consistency in how they are handled, especially in the way images are presented.

If you mean automatic consumption of different formats, that works for simple data in typical in typical consumer settings. The thing imports and an image appears... very consistent.

But totally automatic function is an unrealistic approach for the very wide range of data encountered in GIS. That's why software that works with sophisticated formats has so many options (look at GDAL options, for example). When you grow beyond simple consumer formats or simple use of more complex formats, you need more options to allow you to handle the great variability, including possible errors in the data, encountered with those more complex formats. There, Manifold provides very great consistency in how the controls work.

The issue isn't simple consumer data. That works right all the time.

The issue isn't even more complex data that doesn't have errors in the data. That, too, works right 99% of the time.

The issue is more complex data where the variability of options the format itself allows makes interoperability more complicated, requiring some thought on the part of the user, or where the data has errors in it. To deal with such cases requires greater skill correctly to use the more sophisticated options required to do interoperability or to fix errors.

You're positioning this as if Manifold is taking some artificial position about what is "right" that is somehow different from what makes sense. That's not at all true. Manifold consumes all of the usual formats in the usual way.

For those formats which have errors in them, where somebody wrote a format that explicitly tells a lie about what the image is supposed to be, Manifold has easy means to fix such gross errors, or where there are other non-standard uses of the format (the "Billy's World" thing).

The bottom line is that Manifold takes no religious position about what is "right"... the data is what it is and you can use it however you like. That gives you the power to fix problems in data and to take advantage of a very wide range of data sources.

By the way, dealing with errors in data or a very wide range is not unique to Manifold. GDAL provides a very wide range of tools as well. But just like Manifold, if you don't read the instructions for using GDAL you won't be able to take advantage of the power and flexibility it provides.

drtees71 post(s)
#06-May-19 16:46

I appreciate the clarifications. I would like to provide some context to my initial statement about not having the time to read all of your initial response to my post. I do take time to read and learn, but I am also working a job that frequently requires me to provide a quick turn-around on complex reports. During such times, I don't have the luxury of extensive study to figure out why a useful feature in M9 provides results that are substantially different from what I used to get in M8. In those cases, a quick work-around followed by an explanation of why M9 functions the way it does is much more beneficial to me. I can use the work-around now and consume the explanation later when time permits.

To recap what I understand the essential issue to be is that the problem is likely the result of vendors taking liberties in how TIFF files are coded. Adam suggested exporting to PNG after fixing the color balance of a resultant image merge in M9. I will try that on future projects. I have been sticking with TIFF formats mostly because of problems I have had in the past with importing PNG files into other programs. Not all of the programs I interact with import PNG natively and, sometimes, import the image incorrectly. TIFF formatted images have been more likely to import correctly into the stable of programs I interact with. While the resultant file from a TIFF import can be overlarge, I can significantly reduce the size of the final product (typically a PDF) using compression and optimization.

Dimitri


5,460 post(s)
#07-May-19 07:35

the problem is likely the result of vendors taking liberties in how TIFF files are coded. Adam suggested exporting to PNG after fixing the color balance of a resultant image merge in M9.

In the "quick workaround" department: the vendors are probably providing legal TIFFs... it's just that TIFF is a very broad standard that allows many variations.

When imported into Manifold, the import preserves the structure used. The presumption is that people coded it that way for a reason, so what they chose to do should be preserved. That allows you to edit the image in Manifold and then export it for use in the originating package with the same arrangement it had on import, so it will continue to make sense as originally intended in whatever was the originating package.

Exporting as PNG is a quick and dirty way of forcing a single channel arrangement in the data even when dealing with a variety of different images that have different arrangements. If you wanted to stay in TIFF, you could easily create a query or two (one short line each) to arrange images that use channel arrangements you don't like into images that all use the same channel arrangement, which you prefer. That query would alter the data, in terms of altering the order of tuple components in the int8x3 or whatever is used in the data type. It's totally trivial (see examples working with RGB and CIR, etc.).

If you want a standard, single arrangement of channels in the data, any image that comes in with something different you change to however you want it. Then you can merge all those and export to a TIFF that has that same arrangement.

drtees71 post(s)
#07-May-19 18:23

And now it comes around full circle! I have managed to survive for many years with M8 not having to create scripts or queries (including earlier versions going back to M4.5). I do understand that one of the powers of M9 is scripting, as shown by many of the posts by others. When my workload eventually lets up (or "if"), I will need to knuckle down and learn SQL scripting.

But circling back to your last paragraph, I have tried to "change" the channels to what I wanted using Styles. For what ever reason, those changes appear to be internal to the particular project in M9. Changing the channels in the base images before merging does not extend to the resultant merged image. Changing the channels in the merged image does not carry through to an exported TIFF. Is there a step I am missing that would permanently change the channel order?

tjhb

8,771 post(s)
#08-May-19 00:53

This is a case where it's important to get the terminology right.

I have tried to "change" the channels to what I wanted using Styles.

The scare quotes are "correct". You can't change channels using Styles. You can only change how they are displayed (styles).

As Adam put it in the thread he referred you to above:

Our images separate data from interpretation of data. Pixel values stored in tiles are data. Style properties direct how that data gets converted into colors for display.

So these statements are not correct...

Changing the channels in the base images before merging does not extend to the resultant merged image. Changing the channels in the merged image does not carry through to an exported TIFF.

...because the channels have not been changed, only the styles. You are aware of this--it is exactly what you mean by your question

Is there a step I am missing that would permanently change the channel order?

Yes. Dimitri has answered already (in his second-to-last paragraph), but it is worth spelling it out in full.

Let's say you have an 3-band image in BGR order and you want to recode it as RGB. (Again, this is about how the data channels are stored, not about Style or display order.) I am going step by step.

Open up an SQL Command window. (View > New Command Window > SQL, or on a US keyboard Ctrl-~ or strictly speaking Ctrl-`.)

The function to rearrange channels in an image has this syntax

TileChannels(<tile>, <value/valuexN>): <tile>

This syntax is what you see in the Query Builder panel, bottom left. Function(arguments): return type. Every function is there, as well as statement definitions, data types, operators... as you see. It can be searched and filtered.

TileChannels takes two arguments (an existing tile field or tile expression, and a single value* or valuexN), and returns a new tile.

(*The single value is apparently included for completeness. Switching one channel with itself is of rather limited use.)

The existing tile field is in the table for the image. (Usually called Tile, though it could be something else.)

The valuexN argument is to define a new channel order. For a 3-channel image we need a valuex3, a triplet of values, or a 3-vector. This is made using

VectorMakeX3(<value>, <value>, <value>): <valuex3>

(There are VectorMakeX2 and VectorMakeX4 functions too, as you can see in the Query Builder.)

Channels are numbered from zero, so to switch the first and third channels we need

VectorMakeX3(2, 1, 0)

(You can evaluate this expression on its own: select the text and press Alt-Shift-Enter. You'll see the result in the Log panel at the bottom of the window. Great for sanity checking as you write.)

So far, then:

TileChannels([Tile], VectorMakeX3(2, 1, 0))

(The [ ] around Tile are not necessary because Tile contains no spaces. But they are not a bad habit regardless. For example, say you had a long query and needed to replace 20 instances of [Tile] with [Tile 2], but leave alone [Tile 1] and all function names containing "Tile". Without [ ] that is a lot of pointless typing.)

The SQL above doesn't yet do anything. It is not yet an SQL statement, only an SQL expression. We want to change existing data, and for that we need an UPDATE statement, which defines a table to be changed (UPDATE), what field to change (SET), and the new value (=). (You can update more than one field, even more than one table, at the same time. Here just one.)

If the table for your image is named Image Tiles, then the UPDATE statement is

UPDATE [Image Tiles]

SET [Tile] 

= TileChannels([Tile], VectorMakeX3(2, 1, 0))

;

If you Run that, it will switch the first and third channels. (If you run it again, it will switch them back.)

The image will initially become blank, because pyramids need to be rebuilt. You can either do this via the Messages route (F7), or include it in the SQL:

TABLE CALL TileUpdatePyramids([Image])

;

(That assumes an image name Image. Note that this time it is not the image table, but an image drawn from it.)

Then you will (probably) want to update Styles. You can do that in SQL as well if you really want to.

Last thing: if you close a Command window, its contents are gone. If you want to keep the query text, use Edit > Save as Query from the Command window before closing, or work in a Query window from the beginning.

Dimitri


5,460 post(s)
#08-May-19 07:58

Tim provides a great description of how to do that in a query. Note that this is not a "script," it's just an SQL query, which is a lot simpler than a script.

But the query is so trivially simple, there is an even easier way: use the Transform panel. Here's how:

Suppose your image has data channels in order 0, 1, 2 and you want to re-order them so they are 2, 1, 0.

1. Open the image where you want to rearrange data channels.

2. Open the Transform panel, choose Tile as the target field, and click on the Expression tab.

3. In the Expression tab, enter:

TileChannels([Tile], VectorMakeX3(2, 1, 0))

4. As soon as you enter that expression, the transform panel will show a preview (assuming you are zoomed in far enough so that there are not so many pixels in view that preview cannot work. See the Example: Zoom In to See Transform Previews for Big Images topic.).

You can now use the action button at the bottom of the Transform panel to either click Update Field (the default) to alter the data channel arrangement "in place", or you can switch the action button to Add Component, so when you click it a copy of the image with the rearranged channels will be created.

For another example of using expressions like the above, see the Example: Transform Elevation Image to Flatten Bathymetry to Zero topic.

I like the previews, by the way, since it makes it easy to get it right. Suppose you know you want all of your image to use RGB channel orders. OK. Open an image, in the Style panel use the Assign Channels button to choose RGB and press Update Style. If the image looks weird, you know the data channels were not in RGB ordering. No problem. Click the expression tab and then enter the expression above. Tinker with the numbers used as arguments for VectorMakeX3, trying (0, 1, 2) or (2, 1, 0) or whatever until the preview looks right. That's the arrangement to use. Press Update Field and you're done.

One more thing: this discussion is about 3 channel images. If you are using 4 channel images then instead of VectorMakeX3 you'll use VectorMakeX4 with four numbers, as in...

TileChannels([Tile], VectorMakeX4(2, 1, 0, 3))

The fourth channel is usually alpha or, with NAIP images, near infrared.

Dimitri


5,460 post(s)
#08-May-19 16:36

There's a new video and a new topic showing how to rearrange channels using that expression.

drtees71 post(s)
#08-May-19 22:51

Thank you, again! I will try out these examples, hopefully in the coming week. It is obvious that M9 is harnessing the power of SQL and that I am hampering myself by not learning to use that power. Time for this old dog to learn some new tricks!

That said, I doubt that I would have intuitively made a connection with the SQL command "vectormakex3" for use on a raster image since a raster image is not a vector. I believe I understand that the terminology is internal to an SQL function to provide a direction of work to be done on specific elements of the raster image.

I would like some additional clarification on terminology, though. I played briefly with tiles in M8, but backed away from that function because it seemed to transform an image into an impressionist painting. If I am understanding what is happening in M9, every pixel is treated as a tile. Is this essentially correct?

Dimitri


5,460 post(s)
#09-May-19 06:27

I believe I understand that the terminology is internal to an SQL function to provide a direction of work to be done on specific elements of the raster image.

No, it's a somewhat different thing. The names of things can only seem intuitive in familiar contexts, so you can't reason by analogy to what the name sounds like, at least not when working with new and unfamiliar contexts.

For example, these days virtually everyone is so familiar with how internal combustion engines work that a term like "spark plug" is somewhat self-documenting. But suppose it is 1900 and virtually nobody knows what an internal combustion engine is? A "plug" is like a "cork," in that it plugs, or prevents, a leak. In 1900 it would have been logical to guess a "spark plug" is something that stops a spark, and not something that initiates a spark.

Once you learn a new structure, then the names experts pick to describe the parts of the thing will be more intuitive and self-documenting.

"Vector" in physics implies a direction, but in math and tech it also means an ordered set, a list of numbers, a tuple. A vector created from the three numbers 3, 4, and 7 in set theory would be written {3, 4, 7}. It is a single thing that has three component parts, where those three component parts are welded together in the given order: 3 first, 4 second, and 7 third. I think the etymology of the term is that the order of the numbers counts: {7, 3, 4} is not the same vector as {3, 4, 7}, just like the direction of the vector in physics counts.

To see how the name of the function makes sense and is self-documenting, look at what it does (Don't guess: read what the function does in the SQL Functions topic) and look at the context of what the other function involved wants.

The TileChannels function takes two arguments: the tile on which it operates, and the vector, a <valuexN>, that specifies what channels go where. The definition in the SQL Functions topic is more advanced in that it shows TileChannels can take either a vector, a <valuexN>, or a scalar, a <value>, that is just a single number. TileChannels is a flexible function that is not tied to only the original number of channels. It can use just one channel, or more than one.

Manifold expressions use SQL syntax because SQL is by far the most widely known way to tell programs that work with data what you want. Functions likewise use very generic syntax.

There are ways of writing literal values for some data types, such as putting text values inside quotes "this is a literal text", but other constructs are more abstract. So you can't just provide a literal vector value using set notation of {3, 4, 7} to write something like TileChannels([Tile], {3, 4, 7}) ... which would mean, "create a tile where each pixel is a three-channel tuple, and take those parts of the tuple from an eight-channel tile called [Tile], using the fourth channel of Tile for the first channel of the new tile, the fifth channel of Tile for the second channel of the new tile, and the eighth channel of Tile for the third channel of the new tile."

Instead, we have to wrap the list of numbers which specify the desired list within a helper function, MakeVectorX3, which creates a three-part vector from a list of numbers. So the above example would be correctly written:

TileChannels([Tile], MakeVectorX3(3, 4, 7))

The use of MakeVectorX3 is simply to create a vector argument for TileChannels which we cannot write in ordinary text.

Manifold could be broadened to allow the specification of vector literals using set nomenclature, so that constructions not requiring a helper function could be written, such as:

TileChannels([Tile], {3, 4, 7})

... but that syntax would take Manifold further away from compatibility with SQL and programming syntax as generally used. Better to stay as close as possible to common use.

As to how you learn about all these different functions in the first place, well, you read the documentation, including the various examples. You also play with Transforms to do various things, and you press the Edit Query button to see what SQL a particular transform template uses.

If I am understanding what is happening in M9, every pixel is treated as a tile. Is this essentially correct?

No. A tile is a rectangular group of pixels. See the discussion in the Images topic, under the Storing Rasters in Tables heading.

You can see how tiles work in action in Examples topics like this one.

adamw


8,584 post(s)
#08-May-19 11:48

TileChannels takes two arguments (an existing tile field or tile expression, and a single value* or valuexN), and returns a new tile.

(*The single value is apparently included for completeness. Switching one channel with itself is of rather limited use.)

Passing a single value makes TileChannels work like TileChannel, extracting a single channel from potentially multi-channel data. The number of channels in the tile returned by TileChannels does not have to coincide with the number of channels in the original tile.

Eg:

--SQL9

? TileJson(TileChannels(TileMakeNew(3, 3, VectorMakeX3(160, 192, 255)), 1))

nvarchar[

 192, 192, 192,

 192, 192, 192,

 192, 192, 192

]

...extracted channel #1 (so, the second one, because channel numbers are zero-based) from a 3-channel tile.

Or:

--SQL9

> ? TileJson(TileChannels(TileMakeNew(3, 3, 255), VectorMakeX4(0, 0, 0, -1)))

nvarchar[

 255, 255, 255, 0, 255, 255, 255, 0, 255, 255, 255, 0,

 255, 255, 255, 0, 255, 255, 255, 0, 255, 255, 255, 0,

 255, 255, 255, 0, 255, 255, 255, 0, 255, 255, 255, 0

]

...filled the first 3 channels with the original channel #0, and added an extra channel filled with zeros.

tjhb

8,771 post(s)
#11-May-19 02:53

Thanks for the correction Adam. I should have thought harder.

I can see where my confusion came from--I had made a really bad inference, which had other ramifications as well.

So my mistake and your correction taught me something useful, which I will post about soon.

Mistakes are helpful when you have a great teacher.

tjhb

8,771 post(s)
#11-May-19 04:31

To add briefly what my confusion was:

I had tried to UPDATE a tile field for an image (table) by truncating four channels to three, but consistently received the error

Invalid key field value.

After checking available BTREE indexes (necessary for the UPDATE) and trying changes to the code, I came to the notion that either (a) it is not possible to use TileChannels() with a number of indexes less than the number of channels in the tile, and/or (b) that it is not possible to UPDATE a field of type TILE with a tile of different dimension (number of channels) than it currently has.

Adam pointed out above that part (a) was wrong:

The number of channels in the tile returned by TileChannels does not have to coincide with the number of channels in the original tile.

Happily, part (b) was wrong too--which is what I want to show in a separate post, because adding or removing channels in an existing tile field it is a useful thing to be able to do.

(We can always add another tile field, of course, and it can even be a computed field. But sometimes we want to change the dimension of an existing tile field, and we can do that.)

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