Symbol Dictionary Buffer Image Colors

[CarlosColón-Maldonado]

Greetings,

I noticed that images received from the MPC's symbol dictionary class display in Java Swing components in different colors than that they appear on the JMap. This apparent anamoly does not occur in Windows, but only in Linux platforms, and it was also noticed on previous versions of Runtime. Is there a workaround to this?

[ATTACH=CONFIG]21501[/ATTACH]

[ATTACH=CONFIG]21502[/ATTACH]

[ATTACH=CONFIG]21503[/ATTACH]

[ATTACH=CONFIG]21504[/ATTACH]

[ATTACH=CONFIG]21505[/ATTACH]

[MarkBaird]

Hi Carlos,

I've checked this out in Ubuntu and I'm afraid you've got me - this is a bug!

I've raised this as an issue and it will be fixed for the next release.

In the mean time you might find the following code snippet useful:

            //get the image
            BufferedImage symbolImage = symDictionary.getSymbolImage(selectedSymbol.toString(), 150, 150);
           
            //bit shifting to swap around the Red and Blue to correct in Linux (not needed for Windows)
            for (int x = 0; x != symbolImage.getWidth(); x++) {
                for (int y = 0; y != symbolImage.getWidth(); y++) {
                  int argb = symbolImage.getRGB(x, y);
                  int abgr = (argb & 0xFF000000) | (argb & 0x000000FF) << 16 | (argb & 0x0000FF00) | (argb & 0x00FF0000) >> 16;
                  symbolImage.setRGB(x, y, abgr);
                }
              }


You will of course need to remove this code when the next release comes out otherwise your colors will be wrong again.

Mark

[Anonymous User]

Original User: coloncm

Your workaround works. I take it that all symbol images are 150 pixels in width and height. Is this correct? I had to change the parameters of the java.awt.Graphics object's drawImage method to take the component's dimensions, instead, i.e.:

g.drawImage(bufferedImage, 0, 0, getSize().width, getSize().height, null);

[MarkBaird]

The buffered image from the getSymbolImage method is created from vector data into the size of image you request.

If you were to create an image 500 x 500 then it will not appear blocky because we have sized up a smaller image.

The 150 x 150 I chose above was not related to any internal sizing of the data - it just looked good in my example 🙂

[Anonymous User]

Original User: coloncm

Good to know, and the size you chose is good enough for me, too. 😄

Recall my symbol image manipulation suggested feature to allow displaying symbols using image filters based on currency, i.e., current, stale, old and "remove me" (purgeable):

[ATTACH=CONFIG]21609[/ATTACH]

Is there a way to similarly manipulate the image being displayed by the message group layer, perhaps via the Graphic object or its layer? I know that your workaround works on image previewing on swing components, but it does not affect how they're being displayed on the JMap.

I know I may be reaching, but I must ask. :rolleyes:

[MarkBaird]

Out of the box there isn't a way of manipulating symbols in the message group layer in the way you have suggested, but you could try this which would work for point based graphics:

- Create yourself a new graphics layer on the map
- You can create a PictureMarkerSymbol which uses an image based on a buffered image from the symbol dictionary.  The buffered image can be altered as desired.
- Add the picture marker symbol to the map.

So you might have some code like this:

            BufferedImage img = symDictionary.getSymbolImage(selectedSymbol.toString(), 150, 150);
            //some code to make the image a little different in some way

            PictureMarkerSymbol pms = new PictureMarkerSymbol(img);
            Point pt = map.toMapPoint(eventInfo.getX(), eventInfo.getY());
            Graphic gr = new Graphic(pt, pms);
            GraphicsLayer gl = new GraphicsLayer();
            map.getLayers().add(gl);
            gl.addGraphic(gr);

It's not as versatile as using the message processor (unique designation labels will not display for example), but it might be worth trying.

Out if interest, are these display styles (current / stale / old) part of the 2525C standard?  (excuse the question, but I'm not a 2525C expert)

Mark

[Anonymous User]

Original User: coloncm

Thanks for the code snippet; I really appreciate it. Luckily, I won't need affected symbols to display labels because my application requires use of labels only on temporary drawings. I'll give it a world and let you know how it works out.

While I am not in liberty to write much about it here, I can tell you that most military-fielded systems provide for functionality that allows connected elements report the currency of their location via messsaging:

1. A "current" state of an element's symbol on the map means that they are timely reporting their location changes or at specified intervals, even if it hasn't changed.

2. A "stale" state means that they have not reported their location for a specified configurable amount of time (sort of like a second chance to report in). This lets observers know that they may still (but may not) be there,

3. An "old" state means that they have not reported their location for a specified configurable amount of time (sort of like a last chance to report in). This lets observers know that they are likely not there, and

4. A "delete" state means that they are no longer reporting their location and there is a likelyhood that they are not at the last reported location (not online). This state is normally used by fielded systems to "purge" (remove) their situational awareness (symbols) from their common operating picture (map) so that only recent data is viewed for operational purposes.

However, this functionality is not driven by MIL-STD 2525-Series but by standard operating procedures and/or military doctrine. Agencies differ in that respect. Clear as mud? 😉

My suggested feature was to allow users of the API implement image filters, perhaps three or four concrete known classes or a single interface, for modifying the displaying of symbols while leaving the time and motion functonality up to them (because it will differ).

Out of curiosity, can the graphics layer on your code snippet also be one the message group layer manages?

[MarkBaird]

It's always good to hear how developers are using the API - this helps is to make the product better!  The forum requests have resulted in a few items of functionality recently, so keep the ideas coming.  We can't do everything though...

Going back to the use of the graphics layer in the message group layer...  my initial thoughts here were that you should avoid doing this, but then I thought about the issue of the draw order of the graphics.  I've checked this out and the feeling is that using one of the existing graphics layers in the message group layer is okay.  However (I'm sure you were expecting this!!!), I wouldn't try manipulating the 2525C graphics (removing for example), and don't try removing graphics layers from the message group layer (the latest version of the API does a reasonable job preventing you from doing this). 

Hope that helps.

Mark

[Anonymous User]

Original User: coloncm

Hi Mark,

I agree that it's good to have a forum were users of your API can give you feedback. I'd think of it as a gold mine.

I wouldn't dream of removing Graphic objects let alone their containing layers off the message group layer, but rather have the API do it's thing as it was intended. Can Graphic objects be replaced by id without major repercusions of the MPC (e.g., a refresh would recover it, its layer would stop working, etc.)? It seems that it would be the only way the image could displayed as I'd like it to be.

I thought I'd throw this in since it pertains to symbol image deviation (not involving labels or modifiers). MIL-STD-2525-Series manuals address the visualization of "Status", which refers to whether a warfighting symbol exists at the location identified (i.e., status is "present") or will in the future reside at that location (i.e., status is "planned, anticipated, suspected," or "on order"). Regardless of affiliation, present status is indicated by a solid line and planned status by a dashed line. The frame is solid or dashed, unless the symbol icon is unframed, in which case the icon itself is drawn dashed. Planned status cannot be shown if the symbol is an unframed filled icon.

The setting of a STATUS/OPERATIONAL CONDTION (Position 4 of SIC) using the current MPC, including previous versions, does not have an affect on symbols' frames.

You'll find a link of this here and also appears on Table III, "Present and planned status for tactical symbols" (Page 18), of MIL-STD-2525C.

[CarlosColón-Maldonado]

I have received more details that might further explain the need for "display styles" of symbols for depicting currency. While I said that this functionality is not driven by MIL-STD 2525-Series, agencies have used Table IX, "Tactical symbol display hierarchy" (Page 35), to modify military symbols using a variety of attributes in order to keep them within standards.

[ATTACH=CONFIG]21680[/ATTACH]

While I am not aware of other agencies, most fielded systems of the Department of the Army have used Frame: ON, Fill: OFF, and Icon: ON (older systems black or white and most recent ones default colors). Right now, only the first option is available.

Hope this helps,