Elevation maps.

[wyskass]

I've always found it a bit annoying to have to probe with the Target tool in game and fly around near the ground to get an idea of the elevation topography. Working with topography is obviously a key aspect of tactical movement and positioning. Having access to good maps are an important capability and the whole NGA exists for mapping. One could argue that a proper topo is more realistic that being able to fly over the terrain at ground level as is normal in the game or use target tool from distant waypoints.

Anyway, I couldn't find any existing visualization tools for CM maps, so generated it myself. My PC is out of order right now with all my good mapping and graphics software tools but have been able to make a basic topo on my Mac. So am sharing the process for those who are interested.

The example here is from CMSF2 Semper Fi Syria, Marines campaign, from scenario 5 - Breakout. For my purposes this is enough to greatly improve situational awareness and planning. In standard green to brown topo colors of increasing elevation. Overlay on this are roads and buildings plus wooded and farmed (mud) areas for reference. You can see a few small rises in the eastern starting side which are enough for a hull down, or elevated viewing position, as well as better hidden areas. I missed noticing a couple of these useful features with just in game visual.

 

 

Workflow

This was more a proof of concept and some increased automation can make this process faster, and can be improved with better tools. Took most of the day, but much of the time for experimenting with different tools. Should be able to get a map done under 2 hours.

1. Open map in Scenario Editor and turn on cell elevation numbers display. Take screenshots of the elevation numbers. This map took 9 to cover area but higher resolution minimizes the number of files to stitch. A full screen screenshot, lets you crop these to the same size all at once for easier matching

2. Stitch these together. I experimented with automatic stitching tools, but just ended up using Gimp manually. It's a grid so easy to line up. Photoshop may be better and maybe could do auto stitch. Maybe 30 minutes to stitch and clean.

3. Color and contrast. Using Gimp (Photoshop) process the image to end up with just high contrast B&W numbers and nothing else. Select by color, invert, remove background, fill with black. This map was 8000x6400 image of a clean numbers grid.

4. OCR. I tried a few different tools, but Google Docs was by far the most accurate. Opening the image in Docs, creates a text file with all the numbers. Excel Data from Picture was unusable, which while similar number recognition, had no sense in how it assigned numbers to cells, without seeing the obvious pattern of spaces as suggestive of cells breaks. Some other online tools were worthless. I was surprised how with the cleanest possible black and white image with a grid of numbers so many OCR systems utterly failed. Yet Google Docs was so accurate.

5. Clean data. I loaded the data in a good text editor BBEdit (TextWrangler) to run Regex to find any errors and fix. You want to find anything that isn't 2 digits and a space. Looking at the image and data numbers, you can then determine the number of cells in a row. Then run a regex (grep) replace to break up into lines. End up with clean good data of the maps elevation at this point. This could be tedious if certain errors aren't anticipated. I found just a could small missing segments, but maybe hard to spot to correct.

6. Import into Excel. To create the graphic, I just set a conditional format Color Scale rule which colors from min to max values from Green->Yellow->Brown or any scale you like. Format the cell value numbers to not show. This map have 200x250 cell values.

7. Combine with features. Again took a screenshot of the resulting excel visualization, and back in Gimp (Photoshop), process the other terrain image to just extract roads and building. This was combined with the topo with pleasing and informative layer blending. This would be according to personal preference as to what map features to combine. I've used QGIS a bit which is a real mapping tool but would be overkill here, and again on my PC.

Some of the intermediate working files are too large (Gimp xcf) to upload but shared them here:  (Would have preferred PSDs)

https://drive.google.com/drive/folders/12PESzndNEc76ZaF7Zhi58yKPsFE1YOOb?usp=share_link

 

Edited April 10, 2023 by wyskass

[Dr.Fusselpulli]

Ohhh... Thanks a lot! That is useful!

[callada]

How good was Google Docs for the OCR?  Was a lot of correction necessary?  If so, maybe it'd be worthwhile to look directly at the pixel data if the elevation numbers are all the same unique color.

 

Also, is it possible to turn off the numbers over structures in the editor?

Edited April 12, 2023 by callada

[wyskass]

5 hours ago, callada said:

How good was Google Docs for the OCR?  Was a lot of correction necessary?  If so, maybe it'd be worthwhile to look directly at the pixel data if the elevation numbers are all the same unique color.

Also, is it possible to turn off the numbers over structures in the editor?

Google Docs was very good. There were a few spots with an extra digit or a missing digit, but yes it was likely due to the graphics file having some anomalies. It's a big file and some pixel errors can be missed, and I did miss a few even though I thought I eliminated more than the OCR errors would suggest. The doubles and extras are easy to fix with regex on the text, but more difficult to spot missing numbers which throw off row counts. It's easier to spot and fill in Excel with the coloring on, as you can see it visually much better than trying scan the number grid.

As to numbers over structures, those are numbers of levels, and I didn't see an option to turn off. Now that you mention it, it could be a source of anomalies in the processed graphics file since the filtering is done by while text color. So there are a few things to tweak in the process and how the screenshot image is filtered and processed to get a clean grid of numbers. It looks very good now, but hard to see the few pixel errors sometimes. 

[wyskass]

11 hours ago, callada said:

How good was Google Docs for the OCR?  Was a lot of correction necessary?  If so, maybe it'd be worthwhile to look directly at the pixel data if the elevation numbers are all the same unique color.

Also, is it possible to turn off the numbers over structures in the editor?

Sound that maybe you were eluding to it, but the building numbers are indeed the source of errors as they are same colors and stay in the processed number grid. It was more apparent on the next map with much more buildings. I'm trying to find a way to hide those numbers and if not will need to be handled in image processing. 

Also a bonus, is if you supply an empty overlay file, the editor hides the terrain and you can just see the elevation numbers on black background. Yet, the buildings don't hide for some reason. Deleting the buildings for the elevation grid screenshot would work, but then there also isn't a Select all, so have to click on each one. Soa bit annoying on that part. Combining layers with difference isn't too bad, but leaves a gap sometimes in the digit. OCR may be able to still handle it, but haven't yet tested.

That said, the second map, Google Docs OCR is now garbage. I don't understand how a perfect black and white grid of numbers is difficult for OCR. We've had this technology for decades. THere is nothing in the pixels with any anomalies and yet the output is combining numbers and adding random new lines and missing whole sections of lines. 

Edited April 12, 2023 by wyskass

[callada]

5 hours ago, wyskass said:

Sound that maybe you were eluding to it, but the building numbers are indeed the source of errors as they are same colors and stay in the processed number grid. It was more apparent on the next map with much more buildings. I'm trying to find a way to hide those numbers and if not will need to be handled in image processing. 

Also a bonus, is if you supply an empty overlay file, the editor hides the terrain and you can just see the elevation numbers on black background. Yet, the buildings don't hide for some reason. Deleting the buildings for the elevation grid screenshot would work, but then there also isn't a Select all, so have to click on each one. Soa bit annoying on that part. Combining layers with difference isn't too bad, but leaves a gap sometimes in the digit. OCR may be able to still handle it, but haven't yet tested.

That said, the second map, Google Docs OCR is now garbage. I don't understand how a perfect black and white grid of numbers is difficult for OCR. We've had this technology for decades. THere is nothing in the pixels with any anomalies and yet the output is combining numbers and adding random new lines and missing whole sections of lines. 

If the building numbers aren't togglable, then that's a bit of a pain since that means the elevation numbers are OR-ed on to the map image, and we lose information.

We know the font, so we know all the possible glyphs.  We know the possible locations of all elevation numbers -- at least I think we do.  So barring building numbers, it should be "easy" enough to:

1. load the image, turn it into an array of color data
2. set any pixels that aren't (255,255,255) to (0,0,0)
3. AND all one and two digit values in known locations, store matches
4. output

For getting rid of building numbers, I'm not sure.

Maybe OR together all glyphs, and use those as a mask and discard any other white pixels outside of positions where those characters can be.  Tile-by-tile, XOR a clean tile (no elevation numbers) with the cleaned-up elevation version of the tile, and OR glyphs for each digit/number onto that until we find a match.  There will maybe be collisions depending on how the font looks.

If this works, it would only require a no-elevation-numbers and with-elevation-numbers version of the map as input.

edit: the masking part might be unnecessary or even bad... I may take a swing at some of this when I get a moment

Edited April 12, 2023 by callada

[Vacillator]

Forgive me if I'm asking the obvious, but have you looked at @Butschi's work?

 

[wyskass]

2 hours ago, callada said:

If the building numbers aren't togglable, then that's a bit of a pain since that means the elevation numbers are OR-ed on to the map image, and we lose information.

We know the font, so we know all the possible glyphs.  We know the possible locations of all elevation numbers -- at least I think we do.  So barring building numbers, it should be "easy" enough to:

1. load the image, turn it into an array of color data
2. set any pixels that aren't (255,255,255) to (0,0,0)
3. AND all one and two digit values in known locations, store matches
4. output

For getting rid of building numbers, I'm not sure.

Maybe OR together all glyphs, and use those as a mask and discard any other white pixels outside of positions where those characters can be.  Tile-by-tile, XOR a clean tile (no elevation numbers) with the cleaned-up elevation version of the tile, and OR glyphs for each digit/number onto that until we find a match.  There will maybe be collisions depending on how the font looks.

If this works, it would only require a no-elevation-numbers and with-elevation-numbers version of the map as input.

edit: the masking part might be unnecessary or even bad... I may take a swing at some of this when I get a moment

Yes true, good thinking. But the process you describe is pretty much the difference or subtract blending setting for 2 layers included in major image editing software, but in a general sense. When I took the 2 layers which is what you described, I was able to quite well eliminate the extra text pixels of the building numbers. It left only a very few single missing pixels which both images used. A bit more tweaking with the image editor could do it well. 

Though, while automation is nice and surely preferable, manually deleting each building for the screenshots, eliminates this problem altogether, and really just a take a couple minutes of clicking. Not too bad

But the bigger problem is the terrible inconsistency of OCR. I'm currently trying to figure out how the same process on 2 maps or even just smaller images can vary wildly. I've been trying to make the images exactly the same settings and process and cannot figure out how one can be read almost perfect and another close to garbage. it's very puzzling especially with how clean and similar formatted different grids are, so am testing different setting permutations, but it's starting to get increasingly frustrating. Different resolutions, number densities, image sizes, contrasts, color spaces etc, and no clear pattern yet. I wish I had my PC working because Acrobat Pro OCR has always been the best.

[wyskass]

2 hours ago, Vacillator said:

Forgive me if I'm asking the obvious, but have you looked at @Butschi's work?

 

Yes, thanks, I did see that when searching about mapping. It's just that I'm looking for the reverse direction process. I haven't yet needed to code anything for this, and wasn't trying not getting into a project, but yes there maybe be some useful code around data to editor interface that could be used the other way. It promised to be working well with a simpler process, until I started with another map and the OCR fell apart for some reason, I haven't yet identified. 

 

[Vacillator]

Yes I suppose I was thinking a bit of backwards and forwards might help one way or the other.  Great work by the way and good luck.

[MHW]

I applaud this experiment and @wyskass's resourcefulness. Using Google Sheets for OCR is clever.

More generally, topography would be much easier to read if CM supported terrain shadows (hills throwing shadows—even rough, static shadows that were overlaid on the terrain at load time) or cartographic ways of providing information like hillshading (stylized shadows that mapmakers use to help indicate relief) and hypsometric tinting (changes in color from low elevations to high). 

I find it tremendously useful to have additional map design cues like changes in tile color or bands of rocks/vegetation that aren't entirely naturalistic, which exist mainly to make the map legible. Personally, I'll put brown grass at high elevations and green grass at lower, and add bands of sand or red to help define terrain features. The NTC Mojave maps are excellent at this, whether as a style choice or because that's how the landscape really looks.

 

[callada]

After a bit of Python fumbling around trying to see how easy the "OCR" process might become (I am a numpy newbie)...

This is Avanti! from CMFI (I never win this scenario).  I loaded all of the font characters and then directly compared each of them at pixel offsets for one- and two-digit numbers.  You can see holes where the buildings are, and also missing holes where there probably should be some.  This was redundant, perhaps, but fun.  It can spit out elevation data as well, I just chose to turn it back into an image.

BTW, the input is currently just a pixel-perfect cropped version of the map at 16x16 zoom.

[wyskass]

On 4/12/2023 at 6:57 PM, MHW said:

I applaud this experiment and @wyskass's resourcefulness. Using Google Sheets for OCR is clever.

More generally, topography would be much easier to read if CM supported terrain shadows (hills throwing shadows—even rough, static shadows that were overlaid on the terrain at load time) or cartographic ways of providing information like hillshading (stylized shadows that mapmakers use to help indicate relief) and hypsometric tinting (changes in color from low elevations to high). 

I find it tremendously useful to have additional map design cues like changes in tile color or bands of rocks/vegetation that aren't entirely naturalistic, which exist mainly to make the map legible. Personally, I'll put brown grass at high elevations and green grass at lower, and add bands of sand or red to help define terrain features. The NTC Mojave maps are excellent at this, whether as a style choice or because that's how the landscape really looks.

 

Yea, the two aspects of elevation are the editor import/export of data and the in game visualization. 

Providing an import/export should be a trivial feature if they chose to add it, as they store the grid already in the scenario file. Translating from a csv would be easy. It may be possible to hack out the grid from the scenario binary by looking at the hex number patterns, but I'm not too keen to get into that.

As to the in game, with shading it may be complicated by the time of day and sun which they use for shadows. At night there are none, but as soon as sun comes up the hills are definitely more visible. Of all these options providing at least export or just a small step further a topo map by the scenario designer if data was exportable. That would be easiest. 

[wyskass]

On 4/12/2023 at 9:43 PM, callada said:

After a bit of Python fumbling around trying to see how easy the "OCR" process might become (I am a numpy newbie)...

This is Avanti! from CMFI (I never win this scenario).  I loaded all of the font characters and then directly compared each of them at pixel offsets for one- and two-digit numbers.  You can see holes where the buildings are, and also missing holes where there probably should be some.  This was redundant, perhaps, but fun.  It can spit out elevation data as well, I just chose to turn it back into an image.

BTW, the input is currently just a pixel-perfect cropped version of the map at 16x16 zoom.

That's interesting. So you traversed the image and compared the subset of pixels for each number grid? How did you determine which font type matches the font they use? Did the font loading give you an image for each character? They it sounds like comparing each grid to a number value for that same font, should show no difference if the digit matches? 

Could you share the script?

[wyskass]

So installed Acrobat Pro, and now am able to get perfect OCR. There does seem to be a maximum size so the elevations grid needed to be broken into 4 pieces.

To get good results, it was also required to use the 2nd closest zoom in the editor to space out the elevation numbers more, to indicate the distinct 2 digit numbers for OCR, so as not to pick up just all single digits.

It only took a couple minutes to delete the buildings, then at that zoom and my resolution, was 12 screenshots to stitch. Then process to black and white, black on white background, then cut into 4. 

Each grid png, opened in Acrobat and running OCR, allowed direct output to excel and each number and grid placements was exactly correct. Then I combined the 4 pieced into one spreadsheet and ran the color formatting as originally.

As suggested, there may be a better process with some coding to make it easier to batch a bunch of the maps.

 

Edited April 14, 2023 by wyskass

[callada]

7 hours ago, wyskass said:

That's interesting. So you traversed the image and compared the subset of pixels for each number grid? How did you determine which font type matches the font they use? Did the font loading give you an image for each character? They it sounds like comparing each grid to a number value for that same font, should show no difference if the digit matches? 

Could you share the script?

This is a total mess and doesn't work quite right, so more of a POC: https://gist.github.com/spdral/0afee5917714bf01d4e647a3822d1c77

 

[SchnelleMeyer]

On 4/14/2023 at 11:30 PM, callada said:

This is a total mess and doesn't work quite right, so more of a POC: https://gist.github.com/spdral/0afee5917714bf01d4e647a3822d1c77

 

Callada, this is very interesting to me. I have been looking for a way to output the heightmap data of a CM map into a greyscale heightmap. Could you please detail the steps of how to use your Python script? What does it need as input files?