GIMP Version: 2.10.32
Operating System: Linux
GIMP Experience: Experienced User

---

Over there, Ofnuts explained:


And I understood it, but only now have run afoul of one of its implications for heightmaps.

When I try to paste, and put into Addition mode, a range-limited layer above a GRADIENT, the relative "height" added DEPENDS on the gray levels beneath it, as of course what's expected of a PERCENTAGE addition.

However, for a heightmap, I need to be able to add grayscale layers absolutely so that, say, identical gray layers added over different regions of a gradient still result in adding the same height to the map.


I switched from 8-bit-integer mode to 16-bit-integer in order to have more than 255 shades of gray available. According to documentation, and boolean numbers, 65535 shades are available. I would suppose these might be accessible in the range of 0-65535.


Put simply, I want a gray rectangle of, say, 16-bit color 00655, to have the same height above the surrounding terrain whether pasted above a hilltop or a valley floor.

My Q. Is there a way to SPECIFY a range of colors in the Colors->Levels tool using actual 16-bit color references?

Thank you.

I found this reference, which deals with using the Opacity setting of a tool to "divide" the lowest available color (in a 16-bit mode) 010101.

I do not however see how this could be taken advantage of to set endpoints of a range, as would be needed for setting levels.

Not as far as I know. In all tools, levels are either 0-255 or 0-100% (with 2 decimals, so you have more values that the 65536 possible with 16 bits)...).

Thanks, Ofnuts.

It has the feel of an oversight to me, in the sense that in 8-bit mode, I can specify any and all of the 8-bit colors in the palette, but in 16-bit mode? ...I can specify any and all of, only, the 8-bit colors in the palette.

I'm now wondering if I can paint a layer with a 0->100% gradient (will it contain more than 255 grays?)[1] and select foreground and background colors from that layer with the color-picker tool which are have values other than in the range 1->255.[2]
[3]

[1] Well, first off, the image would have to be at least 255 pixels in one direction (up, down, diag) in order to have containers for at least 255 grays. (I just tried creating an image of 65535 px square; machine joined GIMP in a hearty laugh indeed.)
[2] I realize that I must have at least access to 1000 gray levels as my L slider admits 1 decimal point of precision; I can set values from 1.0 to 100.0 in 0.1 increments. In connection with [1] looking for or expecting 65535 gray levels for the few-thousand-pixels-per-side models I do is probably pollyannish.
[3] The problem for me is that when I stroke a heightmap with a gradient and then try to cut it out with a CNC there are discernible "steps" between gray levels in the final product, smoothed or not. I know "there are limits" to digital processing, but I'd sure like to know where they might be.

An old script that might / might-not help

https://patdavid.net/2012/06/true-pseudogrey-in-gimp/

Using the script on a RGB image (1) original 4000-something colours (2) as a greyscale 153 shades (3) using the script RGB with 1098 shades of grey

You are mistaking Gimp for an array calculator. Nobody thinks of the colors or the luminosity levels in terms of 16-bit numbers. So it's not an oversight, it is a balance between usefulness for the intended users and code maintenance.



[1]You can try with an image that has more that 256 pixels. For the histogram it's clear that you have more than 256 levels.
[2]level is 1-100 by .01, so that's 10K levels.
[3]First off, make sure that there is no dithering/super-sampling in the gradients, or, if there is, that it plays in your direction. With dithering I would expect a slightly grainy surface, and without there would be smooth areas with steps in between.

Rich2005,

YES! Thank you for a thorough-going reply: a link and a helpful image.

It took me some minutes to get my head around the usage--because the Shiny Bright Red image shot me off on a wild goose c. contemplating "how to change my workflow so that I can compose heightmaps in color so that I can convert to graymaps and use Pat David's pseudogrey filter."

(Later, I snuck back to the realization that, er, umm, I'll actually be starting at Step 2: a grayscale with 200-some grays, and wanting to increase them for smoother rendering.)

With this realization, it took me some time to FIND where the patdavid-pseudogrey.scm filter is accessed (after installing it, correctly, in my ~/.gimp-2.10/scripts/). I ran right past it a few times because it was greyed-out, and had to look at the last line of the script to hunt for it--hard--under Colors-> on the menu.

When I found it, greyed-out, I still got a helpful hint by hovering on it that it "works only on layers of type RGB". I still had the image "type" (mode) set as Grayscale.

So changing it to RGB enabled the script, and I was able to run the script. Beforehand, Colors->Info->ColorcubeAnalysis had reported 220 colors (hmm, I see I wasted 35 grays...), but afterward 1520(!).

The proof is in the pudding. I pulled the image into the CAM (computer-aided machining) file to synthesize a G-code program to cut it out and I noticed an immediate difference: the typical "stepped-gradient" look had been replace with something that looks more "sandy": much, much better.

And as I worked through all this it occurred to me I don't have to change my workflow, except to add one step at the end, to output a "semi-final" image, to be processed into a final one with the pseudogrey script.

Thank you again, Rich. I'm off the reef.

Well, I've always known I'm using GIMP in an oddball way (like Tom used the Great Seal of England in the Prince and the Pauper to crack nuts...), and also always suspected my ignorance about its underlying intention was limiting my ability to apply it efficiently. This is one of several times where I've felt the bite.

I've always thought of gray "levels" as a sequence of numbers, from dark to light or vice versa, and that although colors on a color map are arrayed as a 2D surface, when they are "desaturated" (and here I only guess at the proper term), their gray values would map onto a line--perhaps by different algorithms, not another surface. I don't know how else to think of them.



I don't understand it then; I'm trying to type in, say, '88.88' in the 'L' field of the Change Foreground Color dialog and only the first decimal place is accepted.



The latter is just what I was experiencing.

Thank you.