Land and water RGB values

[ReshiramLover 50]

Saving them in MSPaint is not working. Still only water. the 83 and 84 are not working properly. Now Photoshop CC 2017, Gimp, and MSPaint are involved and does not render properly.

Stomach.bmp

Stomach 1.bmp

Stomach 2.bmp

[CorinaMarie 29,922]

Let's go back to the files you got from the zip attached to my first post in this thread for a second. You, yourself, successfully rendered my Height Test grayscale and posted this pic:

So that tells us there is nothing wrong with the rendering part of your SC4 game.

 

The how and why of the palette or whatever getting corrupted is beyond me. @Odainsaker's explanation makes sense conceptually inasmuch as I see how a compressed or optimized palette would mess things up. So, it seems the main thing you need to discover is what causes that to happen. Since we know my height test grayscale does render correctly on your system, I suggest loading that file again in your imaging program and simply doing a Save As to create the same file with another name. Then render it in the game.

This should have two possible outcomes:

1. The duplicate you make and use works fine.
   • In this case something in the way you have created your own images is causing the problem.
2. The duplicate you make and use does not render the same.
   • In this case it is something related to the save option itself.

I feel it's important to find out which of these two are the underlying issue.

[cogeo 960]

Checked these images and here are my findings:
- All images are 8-bit grayscale and have no palette. This means that the problem is not palette-related.
- Checked their values, and Stomach.bmp has only 4 colors (elevations), from #62 to #65, the other two only 2 ones, #62 and #63.

Indeed, what would you expect to get with these? Not only they are well underwater, their values are also too close, eg #63 is only 3 meters above #62. So yes, getting an all-water map, with the stomach figure barely visible is very expected. Use the sea level cheat to (temporarily) set water level to, say, 100m (or 0m, why not?), to check whether you are getting the stomach figure anyway.

[ReshiramLover 50]

Why are they 62 and 63 when I made them 83 and 84 in Photoshop! MSPaint is messing with the color values. And there should ONLY be two colors 83 and 84

 

Edit: I created one with 83 and 84 in Photoshop and then saved a new copy in MSPaint and then reopened it in Photoshop, and they are indeed different values than what they originally were. Here is the original Photoshop version: Stomach A.bmp

 

And after saving Stomach A in MSPaint Stomach D.bmp

[cogeo 960]

Again, both files are not OK - and they are actually identical. There is a stomach figure, with a value of #63, on a background consisting of a mix of #62 and #63. #64 and #65 can be found around the oesophagus and the pylorus. It's wrong, and seems to originate from the early stages of your image-processing procedure.

[ReshiramLover 50]

Why the hell are my images saving with DIFFERENT values than what I set them to?? This makes no freaking sense! If I save it with a value of 83 and 84, it should be 83 and 84! Why are my written BMP files being manipulated??

 

Edit: PSD of my original http://www.mediafire.com/file/36wdzzq2yrb5riv/Stomach.psd

[jeffryfisher 2,176]

11 hours ago, cogeo said:

The .SC4M format (custom map format generated by SC4TF and usable by SC4M), and 16-bit PNGs use 16-bit encoding, which is double as wide, allowing for far greater range (up to some 6500m) and precision (steps of only 0.1m). You need to either use SC4TF or make an application capable of saving 16-bit PNGs, and use the SC4 Mapper to import your map, not the in-game image-import feature.

Aha, that's good news (and clarifies what rsc said above). I'd previously read that only 256 steps were available, and that terraforming/smoothing was the only remedy for the steps (which rendered coastlines in my current region largely unrecognizable). Before today I hadn't read that we could import and eventually display anything better. Since I like real-world maps, my future rendering will definitely search out 16-bit so I can dial-down the terrain "melting" in the terraforming process.

18 hours ago, ReshiramLover said:

Still not working. All water.

Kick your image editing software until it will save a pure grayscale datafile (one that does not employ a color palette). If it won't cooperate, then turn to a different program that will.

[ReshiramLover 50]

3 minutes ago, jeffryfisher said:

 

Kick your image editing software until it will save a pure grayscale datafile (one that does not employ a color palette). If it won't cooperate, then turn to a different program that will.

 

Like I said, I already tried three different programs all with the same results. Plus only Photoshop has the pen tool and shapes to make these water and land easier

[cogeo 960]

23 minutes ago, jeffryfisher said:

Kick your image editing software until it will save a pure grayscale datafile (one that does not employ a color palette). If it won't cooperate, then turn to a different program that will.

As noted above, the problem is not the palette (the images do not have a palette anyway), it's the wrong elevation values.

 

3 hours ago, ReshiramLover said:

Why the hell are my images saving with DIFFERENT values than what I set them to?? This makes no freaking sense! If I save it with a value of 83 and 84, it should be 83 and 84! Why are my written BMP files being manipulated??

Well, if you save it with values of 83 and 84, you should be getting 83 and 84! Don't know, I don't have PS installed, maybe check if you accidentally involve some palette usage in the intermediate steps of your processing. Otherwise, an option like automatic image enhancement, or automatic contrast adjustment, auto-correct image etc etc could be the culprit. It could help, if you break your image-processing procedure into steps, and examine the outcome of each step separately (don't know PS, but I must have some "Dropper" tool, to examine pixels' values - for paletted images it should display the palette index number, in addition to the RGB value).

[APSMS 1,893]

It can't be that hard to open these files into paint and use the bucket tool to change their values en masse, to quickly check whether or not a change to the correct values is saved by the program

[Odainsaker 2,137]

9 hours ago, ReshiramLover said:

Why the hell are my images saving with DIFFERENT values than what I set them to?? This makes no freaking sense! If I save it with a value of 83 and 84, it should be 83 and 84! Why are my written BMP files being manipulated??

 

Edit: PSD of my original http://www.mediafire.com/file/36wdzzq2yrb5riv/Stomach.psd

Opening that file with an admittedly much older Adobe Photoshop 7.0 for me brought this message:

Trying first the "Use the embedded profile" choice and later the "Convert document's colors to the working space" choice naturally resulted in large swings in the gray values used in the image while working as well as when saved as BMPs and reopened in other applications.  I don't get this message with later versions of Adobe Photoshop, where I understand much of this was automated with "Dot Gain 20%" made a default in deference for CMYK printing, while gamma settings are typically used for RGB screen display.  Color profile management and gamma matching is definitely not my forte, but it may be that the color profile (default "Dot Gain 20%" versus "Gray Gamma 2.2") on your installation of Photoshop maybe something to look into, especially as color profile management can vary across applications, and we are seeing here different applications consistently re-tweaking your colors into mismatches, with just about all of our programs reading something far different than what your file shows in your Photoshop.  Otherwise, the file Stomach.psd and its layers saved for me as a normal grayscale BMP that would work in SimCity with a normal grayscale color table, but the gray values ultimately outputted to the save file do not match what we know you are intending.

Still, we know CorinaMarie's posted BMP worked, so rather than trying to create a new image in your Photoshop from scratch with all the additional variables that entails, it may be useful to just instead start with her image in your Photoshop and see if you can manipulate and save it such that it still works.  If it afterwards still works, then we know the issues you are having may be something in the way your own images are being created.  If it doesn't still work, then there is something needing adjusting with your setup or workflow within Photoshop.

 

[CorinaMarie 29,922]

2 minutes ago, Odainsaker said:

Opening that file with an admittedly much older Adobe Photoshop 7.0 for me brought this message:

I received nearly the same in my even older Photoshop Elements 2.0. If I tried to convert it came up all white.

 

@ReshiramLover:

Here's the thing. I use PSE to create my grayscales but I never even save them as .psd. I go directly to .bmp when I save them. (Yes, I have to change the default choice each and every time.) So, it seems the bottom line is that creating a .psd first and then trying to output that later as .bmp might be the entire underlying problem.

[Odainsaker 2,137]

@CorinaMarie I get all-white images when I try to "read composite data" rather than discard it in a message warning about discarding "unknown data encountered in layer 'Shape 1'."  I suspect it may be because ours are old versions of Photoshop unfamiliar with newer data saved by newer versions.

 

However, of the three options in  the "Embedded Profile Mismatch" message, my result was like this:

1.  "Use the embedded profile (instead of the working space)"

The image opened in Photoshop with a stomach of RGB 75 layered over a grainy field loosely of RGB 75 and 76 (but actually CMYK 68,62,61,51 and CMYK 68,61,60,50).  When exported as a BMP, it becomes a stomach of RGB 63 on a grainy field of largely of RGB 62 and RGB 63.  This is similar to what others here mention seeing in their own programs and to what has been previously posted.  In SimCity, this will all be underwater.

2.  "Convert document's colors to the working space"

The image opened in Photoshop with a stomach of RGB 67 (but actually CMYK 64,56,55,32) layered over a grainy field also uniformly called RGB 67 (but actually largely of CMYK 64,56,56,32 and CMYK 64,57,56,33).  When exported as a BMP, it becomes a stomach of RGB 85 on a grainy field of mostly RGB 83 and RGB 84.  The broader range and finer differences of CMYK are obviously getting munged down for the 256-range of grayscale, however, this fuzzily gets us suspiciously close to what I think was meant for the original image to become in SimCity:  a stomach shaped island in a sea at the threshold of sea level.

3.  "Discard the embedded profile (don't color manage)"  (The default option)

The image opened in Photoshop with a stomach of RGB 75 layered over a grainy field loosely of RGB 75 and 76.  When exported as a BMP, it becomes a stomach of RGB 63 on a field of largely of RGB 62 and RGB 63, much like option 1.  As this is a default option which was later automated, it might be expected that it would be similar to what everyone else is also seeing, much like in option 1.

 

Given that very basic choosing between these color profile options when opening the PSD file gets me results similar to what we have been previously seeing as well as similar to what might be expected or intended, I am growing confident this is the right track, though I don't dare try to explain too deeply dot gains versus gray gamma.  My general understanding is that Dot Gain is a setting meant to compensate colors for ink image printing, but most printers will do their own such adjustments automatically on-the-fly, while gamma is a setting to optimize colors for displays, and Gray Gamma 2.2 is common for images shared online and likely for images shared across computers or programs.  Either setting will shift an image seemingly brighter or darker, or stretch out or contract the value range.  A long time ago, I tweaked my monitors and Photoshop preferences and wondered at gamma settings, but nowadays this is often buried and automated in default settings and it hasn't seemed to bubble up in SimCity mapmaking despite how many different people with different programs have been making maps all these years.

 

If the above is the case, we can adjust color management in Photoshop from the top menu:

Edit-->Color Settings

There will be general preset Settings with a mix of specific settings for Working Spaces and Color Management Policies.  Either choose from a general preset or individually tweak the specific options, but, which ever way is chosen, we need here "Working Spaces:  Gray" to be set to "Gray Gamma 2.2" rather than "Dot Gain 20%."

Or...

We can instead specify a color setting on a case-by-case basis when first creating a New image.  Within the dialogue box presented when a new image is initially made, choose a Color Mode (such as "Grayscale"), and from any "Advanced" dropdown, choose a Color Profile (such as "Gray Gamma 2.2").  Photoshop's Color Management Policies under the program's Color Settings normally default to preserve any embedded color profile with or without warning, so a New image with a custom color profile should keep that custom color profile regardless of how Photoshop is setup.

 

  Edited June 6, 2017 by Odainsaker  

[ReshiramLover 50]

I still have not figured it out. Still at a loss! I tried everything in this thread. Even tried PNG and SimCity 4 will not accept this image! ALL programs claim that it is 8-bit grayscale but SimCity 4 "thinks" otherwise. I tried JPG and it manipulates the values like it does with BMP.

 

Anything else?

[Odainsaker 2,137]

The PNG image just posted still has the same previous embedded color profile as was previously mentioned.  Just changing between types of saved file formats is futile until this underlying issue is resolved.  Photoshop still sees the image as having the color profile "Dot Gain 20%" and then processes it under its color management schemes to appear lighter for ultimate use on a printing press, but the image is actually darker than we think it is.  When a matching "Dot Gain 20%" color management scheme is not being used, such as in another graphic editor customized a different way or in SimCity 4, the image will be read as darker than we saw it in Photoshop.  The PNG image colored profiled this way, when turned into a BMP or JPG and rendered in SimCity, will render as all underwater.  As we are not intending to print this grayscale image on a printing press anyway, we should not be using "Dot Gain 20%" as a color management profile.

I took the PNG just posted directly above and ran it through Photoshop and changed the image's color profile.  Different versions of Photoshop have the menu command in different places, mine was here:

Top Menu-->Edit-->Convert to Profile...

(I have another version of Photoshop which instead had the command here:  Top Menu-->Image-->Mode-->Convert to Profile...  Your mileage may vary.)

Once the command has been found and selected, the Convert to Profile dialogue box should appear:

It showed that the current PNG image had a Source Space Profile set as "Dot Gain 20%", a setting optimized for use with a black & white printing press and a default setting of some versions of Photoshop geared for professional printing services.  I chose the Destination Space field to use the Profile:  "Gray Gamma 2.2", the setting commonly used for monitor displays and generally shared internet images.  Window's users will typically use Gray Gamma 2.2, though I understand Mac users typically have a different gamma setting, 1.8.  All the many different color profile settings have their own special graphic art and imaging purposes, but we just want the most universally generic profile for our computers for SimCity.

After the conversion as complete, I saved the converted image as a BMP, and then sent it off to import into SimCity 4:

We can see that it renders with a stomach-shaped land surrounded by "water" at the threshold of sea level.  As the original PSD file showed that the "water" was a granular pattern of colors using values that skirt above and below SimCity's default sea level, the granular beach-like render would be the expected result.  I do not know exactly why the city tile edges reconcile so poorly like that, and can only guess that it is because we are using values so close to the threshold of SimCity sea level that the game doesn't know whether to reconcile up or down.  Regardless, the result is in line with what we would expect given what was seen in the original PSD file:  a stomach-shaped land just above a surrounding composite water set to just skirt above and below the threshold of sea level.

It think this makes it clear that the issue is in the gray space profile of the original PSD image and/or in the working gray space of the Photoshop program used to create it.  What the Photoshop program is set up to use as a color management profile preference, what the grayscale images are initially created with, and what SimCity 4 is expecting all need to match.

 

[ReshiramLover 50]

Why would it be granular when I used the color fill option?? That render is not at all correct.

 

And the Photoshop options you told me are incorrect. There is no convert to profile anywhere! Just a drop down list of modes. There is nothing in Photoshop CC 2017 that has what you are telling

[ReshiramLover 50]

I found the gray gamma 2.2 at an odd spot, but SimCity 4 still won't use the image even with Gray Gamma 2.2

 

[Odainsaker 2,137]

That latest PNG image actually does indeed work, and I just successfully imported it into a new SimCity 4 region without making any changes to it.  This is what resulted while using a 16x16, all-blue config.bmp to define the city tile borders:

Again, I can't speak to the awful edge reconciliation of the large city tiles, which is an issue unto itself, but SimCity 4 on my system at least did accept the grayscale PNG image file as is.

This was the config map I used, which the imgur host turned from BMP to PNG, but which you can use again if you resave it as a BMP:

The most likely stumbling block now is the procedure used to import the map into SimCity.  There are specific steps that should be done to import any map successfully into SimCity 4, which are carefully detailed here.  It will require a config.bmp, in this case one 16x16 pixels in size such as I used, and if you are making a custom config.bmp in the same Photoshop that created the grayscale map, you will need to make sure that your Photoshop preferences are again not causing anything peculiar to happen to the config.bmp as was happening to the grayscale map.  "SimCity 4 still won't use the image..." is too vague:  Can you navigate to the image in SimCity, does SimCity freeze, does it create an error message, does it crash to desktop, does it seemingly process the map indefinitely, or does it create a map still underwater?

 

 

 

[ReshiramLover 50]

When I select the PNG, nothing happens

[CorinaMarie 29,922]

2 minutes ago, ReshiramLover said:

When I select the PNG, nothing happens

I presume you mean when you are going to render the map in the game. I've seen a bug where my initial click on the grayscale will not put the file name in the box. What I do is single click the config.bmp then click the grayscale image and it'll then allow it to be selected. (I put my grayscale image right in the region folder I'm working with, btw.)

[Odainsaker 2,137]

For this problem I have no idea why it wouldn't work, but I admit I am finding the import menu dialogue box that appears when using the CRTL-Alt-Shift-R key-combination to be quirky.  In my case, the resulting dialogue box will not let me select and browse into the My Documents folder, and so I cannot navigate to My Documents/SimCity 4/Regions/ when trying to import any customs maps.  I can click on the folder and highlight it, but the game doesn't open it or otherwise respond.  Apparently, SimCity 4's old menu navigation in the import map dialogue box cannot cope with folders that have a space in the folder name under some versions of Windows, and "My Documents" with a space is virtually chiseled in stone under Windows.  After some trials, I have found I have to do a personal workaround:  stick all my grayscale images in some other convenient folder under a path with no spaces that the dialogue box will let me open and then import them from there, as it is not actually mandatory that the grayscale image to be in the Regions folder.

You may have to do some similar trial and error on your end with this one, of which a quick one might be to check for spaces in any folder or file names.

 

[jeffryfisher 2,176]

19 minutes ago, Odainsaker said:

In my case, the resulting dialogue box will not let me select and browse into the My Documents folder...  Apparently, SimCity 4's old menu navigation in the import map dialogue box cannot cope with folders that have a space in the folder name

Oh, I can't believe that without thorough examination. On any recent computer, it's much more likely that you have a permissions problem. What version of Windoze are you fighting against, and what kind of admin privs are attached to the user-account you were using?

However, if spaces are really a problem, then, then there should be a place to fat-finger the full path. Type it in (or paste it from Windoze-Explorer) surrounded by double-quotes.

[Odainsaker 2,137]

That's what I thought too, as the user directories that the dialogue box won't navigate into look to all be system-based folders of some sort.  However, it's only those system-based user folders that have spaces in their names that won't open, while other folders that should also logically be similarly system-protected but have no spaces in their name are still accessible.  Non-system folders with spaces in their names still work normally.  All this while logged on with the Win 7 administrator's account and also specifically running the original disc SimCity 4 Rush Hour program as an administrator.  Oddly enough, SimCity 4 can navigate into My Documents when finding a saved region to load; it's only the import map dialogue box that won't cooperate.  Even typing any path in the offered field will not work, and does not work in ways that make me think the field actually was not designed to take full paths and can only show the names of selected valid files.  Others have had this problem, but I do not know how widespread it is or what specific conditions or program versions come into play, and it may yet in the end under the tangle still indeed be a particular issue of permissions.  I chalk it all up to the quirks of using a cheat command to tweak a 14-year-old program that predated this operating system by six years and UAC by four, hence the trial and error to find successful workarounds.  Rendering with grayscale images just saved on the desktop or in a temp folder works just as well for me and is easier than trying to troubleshoot this peculiar instance.

In a similar vein, there is some quirk that is preventing ReshiramLover from proceeding to render with a selected PNG image, one that has been shown to now work.  A quick and easy start to weed out quirks is to begin with simple filenames, simple paths, and simple filetypes, but the trial and error will have to be on their end.

[jeffryfisher 2,176]

3 hours ago, Odainsaker said:

Rendering with grayscale images just saved on the desktop or in a temp folder works just as well for me and is easier

That sounds like a good work-around. It's been so long since I rendered my last region that I can't remember what working directory I used. I may well have worked in an "easy" location and then moved the results.

[CorinaMarie 29,922]

4 hours ago, jeffryfisher said:

I may well have worked in an "easy" location and then moved the results.

Same for me initially. I used C:\x as my working folder. It was only later I decided I really wanted the grayscale right in my region folder in my documents so when I back up that whole folder I get the base map too. My game is on a dedicated XP Pro machine with only an Admin account (and no internet connection) so that's prolly why I don't have navigation problems.

[rsc204 21,868]

Perhaps disabling UAC may help, albeit temporarily. However it's probably safer to just put the image in another folder.

[ReshiramLover 50]

My image is in <User directory>\SimCity 4\For Region\

 

Should not be a permissions issue.

 

And I still do not have an answer for the uneven terrain.

[jeffryfisher 2,176]

7 hours ago, ReshiramLover said:

I still do not have an answer for the uneven terrain

Depending on the terraforming tool you use, there may be some erosion and other effects applied to give the terrain an organic look. You might be able to control what it does and how.