Hmmm, that's worth a try.  Thanks for the idea ThunderStone.

Thanks for your idea, Thunderstone... so in Matmatic that would be:

s = Surface()
s.Displacement = .012 * Color_Sub(ImageMap("MyColourPic.jpg"))

or, in nodal terms,

ImageMap -> Color_Math (Subtract) Value_1  -> PoserSurface displacement channel (.012)

Quote - Thanks for your idea, Thunderstone... so in Matmatic that would be:

s = Surface()
s.Displacement = .012 * Color_Sub(ImageMap("MyColourPic.jpg"))

or, in nodal terms,

ImageMap -> Color_Math (Subtract) Value_1  -> PoserSurface displacement channel (.012)

Nope it would be:
ImageMap -> Math_Function(Subtract) input 1 Value _1 ->PoserSufrace displacement channel (0.0012) I always make the displacement value smaller than the bump value but you got to tweak it according to your taste.

I don't think you can do subtracting with the Color_Math node....

Thanks for clarifying, Thunderstone. I'll have a go and see what I get.

Thank you, Thunderstone. So... the purpose of filtering out colour information to the bump and and displacement channels with that Subtract node is to prevent erroneous info from getting to the channels? Just trying to get my head around it... I can see the validity of having one image serve two purposes: less memory overhead. Your method would provide the greyscale without the overhead.

I know that BagginsBill will shudder at this, but I'm using Matmatic in a way he probably didn't quite have in mind: as an efficient means of creating simple materials (read: retrofit) with GC. Whilst applying a GC mt5 to a material with one ImageMap is a no-brainer, some content developers are using a more sophisticated shader, like Fabiana in her Noctia dress, which takes a bit more to incorporate GC.

hum, sorry but with all the nodes plugged to the alternate diffuse, you dont need plug your map on the diffuse color or only with a diffuse color white and a diffuse value 0, it's only to show the map in the preview !

That is the point of the diffuse_color connection.  Many individuals would like to see what is happening with the scene while in preview mode.  It is very hard to conceptualize a scene while staring at many blank objects.

That works for ImageMap, anyway. Haven't figured out a way to get node-based colouring to display... like in this shader:

Quote - Thank you, Thunderstone. So... the purpose of filtering out colour information to the bump and and displacement channels with that Subtract node is to prevent erroneous info from getting to the channels? Just trying to get my head around it... I can see the validity of having one image serve two purposes: less memory overhead. Your method would provide the greyscale without the overhead.

I know that BagginsBill will shudder at this, but I'm using Matmatic in a way he probably didn't quite have in mind: as an efficient means of creating simple materials (read: retrofit) with GC. Whilst applying a GC mt5 to a material with one ImageMap is a no-brainer, some content developers are using a more sophisticated shader, like Fabiana in her Noctia dress, which takes a bit more to incorporate GC.

Exactly just like those separate bump and displacement map will do. Also it serve if there is no bump or displacement and you don't want to go thru the expense of time and memory to create a new grayscale map. I think BB will have a fit with me also because some of the skins shaders do not have bump map and this method (I can't quite credit myself with but someone else came up with it (I think) I know I have seen it somewhere else. ) helps to give me a good realistic render.

I am having many fits here.

Let's play Socrates.

Given a value, x, what is 1 * x - 0?

What value does that give you?

Another question:

Plugging a color into a numerical Math node parameter converts the color to gray scale. The Subtract node Value_1 is what I'm talking about here.

What happens if you plug a color into some other numerical node parameter. Suppose you plug it into Bump or Displacement. What is going to happen?

A related question: If I connected 500 of these Subtract(1 * x, 0) nodes in series, what would change?

Related to that, if I connect no subtract nodes here, what changes?

Of course, I did not even begin to address whether this makes sense, from an image quality standpoints. At the moment, I'm just talking about the math.

What is 1 * 1 * 1 * 1 * 1 * x - 0 - 0 - 0 - 0 - 0?

1 x ?

Quote - Of course, I did not even begin to address whether this makes sense, from an image quality standpoints. At the moment, I'm just talking about the math.

What is 1 * 1 * 1 * 1 * 1 * x - 0 - 0 - 0 - 0 - 0?

x-0 which is the same as x=0 hence nonsensical answer or zero (0)....

x-0 is not 0 it's x agggg!

x - 0 = x
1 * x = 1x
Right? Sheesh, I suck at math....

err unless x=0 then x-0 would be 0

Since x stands for some unknown value, subtracting 0 from x will leave x, whatever that value might be.

What I am missing is a good understanding of doing math on colours. Yes, if you break them down to tuples and then subtract, it makes sense. But connecting a pure math node (add / subtract / whatever) to an image leaves me in the dark still as to what exactly is going on.

What was being suggested was:

Surface.Bump = .0012 * Sub(ImageMap("MyColourPic.jpg"))

Sub in this case assumes Value_1 to be 1? and Value_2 to be 0? Which is the same as 1 - 0 = 1, which isn't doing anything?
Well, I plugged this all in as suggested and got the same image. Not trusting my eyes, I'm waiting for a better way to 1. validate that this way is erroneous and 2. create a greyscale image for those channels. Or do the channels just use what they need and ignore colour information anyway?

OK somehow the Socratic method failed.

You were supposed to make the following conclusion.

x - 0 = x

Using words, subtracting 0 from a quantity does nothing to that quantity. You are wasting your time calculating x - 0.

Does that help you understand my point?

I think a lot of the misconceptions and erroneous "solutions" we come up with is because we don't fully - or, in my case, don't hardly - understand how math works on images. I'm not speaking for the Ones That Know, but for those who don't, me being prominent among them. There is a distinct conceptual gap between seeing a math formula and its application to an image.
I'm not happy with "yes, I see that it works" because seeing is no longer believing, at least, to me that's true. When someone presents a concept, I want to know why. Here is where scripting nodes seemed to help a bit.
A bit.
It forms more of a connection to what is actually happening ... what are we doing to those colours.

What hasn't been gone over to my satisfaction about the method used to do gamma correction is this - and I can hear a collective groan, but hey, bear with me: I'm thick.

As I understand this, here's what needs to happen:
convert image to linear space
process image
return image back to sRGB before handing over to the renderer...

Considering this code:
colourMap = ImageMap("sweaterTx.jpg")
gamma = Add(2.2).labelled("Gamma")
gammaPow = Color_Pow(colourMap, gamma)

am I to assume that the Color_Pow() function somehow converts the image to linear space and then does the gamma math to it? Where is the conversion to linar space done?

Let's start there. I want it all to be really clear in my pointy little head, so I won't create bogus stuff like I have been.

I thought that's what I said.
x - 0 = x

IOW, you've done nothing. Was that your point?

Quote - IOW, you've done nothing. Was that your point?

Indeed, that was my point. In this scenario, plugging the color map straight into bump and displacement would do exactly the same thing. The math node isn't doing anything at all that you wouldn't get without it.

Some people may think the math node is doing the conversion to gray scale. Well, it is, but not because it is a subtract 0. It is doing that because you plugged a color into a number. Building a math node just to have a number to plug into is a useless and confusing waste of time.

The bump channel is a number. Plug the color into the number straight away.

The displacement channel is a number. Plug the color into the number straight away.

Hi RV... I have another post coming up about bump/displacement (unless bb gets there first, if he's still around) but in the meantime...

"Convert to linear (colour) space" == "Do the gamma math"
(It's one and the same thing).

The assumption is that the colour map is done in sRGB colour space. To convert this to linear colour space, you need to anti-gamma correct it, i.e. raise the colour values to the power of your variable 'gamma', or 2.2 in this case.

Quote - am I to assume that the Color_Pow() function somehow converts the image to linear space and then does the gamma math to it?

Ummm. Gosh this is so difficult. I've seen this so many times in the last month.

I'm stumped and don't know how to answer, because the two-part question is actually two different questions, and the phrasing and coupling of these two parts either indicates a contradiction, or represents a severe misunderstanding. Meaning, if I answer your question, I will confuse some more.

So let me ignore your questions and re-state what I've said (and all the other links say).

Images you're getting from cameras are designed to be seen on a computer, using the sRGB standard.

Images coming out of your render should be designed to also be seen on a computer, using the sRGB standard.

The sRGB standard is not a linear representation of luminance. In sRGB, it is incorrect to assume that doubling the value of a pixel should cause it to be twice as bright.

The sRGB color space is not quite exactly a simple power relationship. But it is very close to that, and so we can work with Gamma Correction (GC) as our working model. Until you are comfortable with GC, it would only serve to confuse you to talk about the true 100% accurate specification of the sRGB space. (It requires considerably more math.) While straight GC is slightly wrong, it is 1000 times more wrong to do nothing at all.

Lighting calculations should be in linear space. It is correct when calculating a material's response to light that doubling the value of a pixel should represent twice the illumination. This is the fundamental principle of linear math - that x + x = 2x. It is the only kind of math that most people ever encounter. There are other kinds, and they are exceedingly difficult to manage. Anybody wanting to do any accurate shader/lighting work must do it linearly.

Therefore, when using images as data, we must convert them from sRGB to linear values. I often call this anti-GC, because the image you have was gamma corrected in order to end up non-linear. To bring it back to linear, you must do the opposite of that gamma correction, so want to anti-GC the image. The math is:

image ** 2.2

There's really no point in discussing any other gamma value, because any image you have has almost certainly been gamma corrected by the factor 2.2, whether it was hand-drawn or photographed. All discussion about the 1.8 gamm value for Mac has pretty much stopped - Apple has seen the futility of having two display standards in the modern Internet world where we all must share content.

Then we must calculate reflections (whether specular or diffuse) and refractions using the formulas that describe the universe. These formulas are all built on the fundamental premise that for any value x, whatever luminance that represents, 2x is twice that. This is necessary for things to work out conveniently, such as the simple fact that the effective diffuse reflection of a specific amount of illumination depends on angle of incidence, specifically on the cosine of the angle of incidence. Further that if I double the light intensity, the diffuse reflection also doubles.

Once all reflection/refraction modeling is complete, we end up with a linear color value after adding some things together. Before placing this into the image, this must be converted to the sRGB color space. We cheat, and use gamma correction. The formula is:

y ** (1 / 2.2)

Where y is the rendered color.

Quote - 1 * Color_Map - 0

What value does that give you?

Another question:

Plugging a color into a numerical Math node parameter converts the color to gray scale. The Subtract node Value_1 is what I'm talking about here.

What happens if you plug a color into some other numerical node parameter. Suppose you plug it into Bump or Displacement. What is going to happen?

A related question: If I connected 500 of these Subtract(1 * x, 0) nodes in series, what would change?

Related to that, if I connect no subtract nodes here, what changes?

If you plug a color into the numerical Math node granted if it's a solid color the only thing that will happen is nothing, especially if it's in the displacement or bump node.  If that's the effect you're going for, then it's better to leave it off. But if you want to add some "umph" into the existing texture that the creator so kindly forgot to provide the bump or displacement map, you can add a quickie bump or displacement node.
As for the 500 of these nodes in a series, I would imagine the effect to be negligible  after the first 2 nodes (I don't know. I am not an expert like you, BB. Half of the information I've received about the mat room came from that lil noggin of yours. The rest from tips and experience. ).

I imagine it must seem to you as difficult as explaining why 1 + 1 = 2, Bill. However, this discussion has cleared up a question or two for me, so far. I need to break down your words into my words: your concepts into mine. I suppose it's called assimilation: if I can explain your concept in my own words, I prove that I understand it. So, at the risk of boring you to tears or further frustrating you, I'm going to rehash these concepts. And thank you for your patience.

Yes, there are some misunderstandings. A partial understanding is as bad or worse than a complete lack of understanding. This is what I'm trying to eliminate with this discussion.

I see an image as a collection of pixels / coloured dots. Each dot contains colour information that can be represented as a tuple. This colour information in jpgs and I imagine pngs and tiffs all conform to a standard called sRGB. when you bring these images up in an image viewer program or an image manipulation program, they are meant to display according to that sRGB standard.

I think I can get my head around the tuple / red-green-blue concept of a coloured dot, since I have a visual representation of that in the Microsoft colour picker tool. But, I suspect that the colour picker and sRGB are only remotely related.

So, whilst these programs manage to display an image brightly and appropriately, Poser manages it differently because it has to do calculations in it, which become prohibitively complex in sRGB. So, it manages the image in linear colour space.

Linear colour space. What exactly is linear colour space? Why the term 'linear'?

You must be able to see to what degree these concepts are nebulous, based on these questions.

Quote - Images you're getting from cameras are designed to be seen on a computer, using the sRGB standard. Images coming out of your render should be designed to also be seen on a computer, using the sRGB standard. The sRGB standard is not a linear representation of luminance. In sRGB, it is incorrect to assume that doubling the value of a pixel should cause it to be twice as bright.

Ah, a clue. sRGB is a representation of luminance? just not 'linear'... which I take to mean: on a grid, the line would be straight from one point to the next. So, do I take it to understand this is what is meant by linear colour space? a means where doubling the value of a pixel does cause it to be twice as bright?

So, gamma is all about brightness, not colour. Well, I did say I was thick. Of course it's about luminance. The renders are dark. So, we're taking an image and converting it from some curved to straight luminance value. When I think "picture" I think colour, not luminance. Yet, this is what most people fail to understand: how important proper luminance management is.

Now, armed with this concept, let's look at the rest of your explanation.

Quote - The sRGB standard is not a linear representation of luminance.

Wait, so in linear space it is? Luminance! This is not about colours, it's about Luminance! So, in an image there's colour information and there's luminance information - that's needs to be converted! Right? Am I *anywhere near the right track, here?

One definition I found via googling for linear colour space: a color space in which the relationship between a pixel's digital value and its visual brightness remains constant (linear) across the full gamut of black to white.

However, CRT technology doesn't work that way:
The most important point to consider here, is that if the normalized voltage (normalized meaning the voltage can go from zero volt to one volt maximum) on the CRT electron gun is linearly increased from 0 to 1, the resulting brightness on the face of the CRT will not be perceived as linearly increasing. It will look like it takes time to get out of black and then suddenly becomes white. Looking at the 2.5 gamma graph above, it can be observed that the voltage needs to reach 75% in order for the CRT to output 50% intensity.

It appears that the luminance value going stepping from black to white on a non-gamma tube stays quite low (dark) for a while before going suddenly to quite high (bright). All has something to do with the relationship between brightness and output voltage of a CRT.

I think I understand now what I need to understand about the reason for gamma correction. The missing link was something obviously stupid: I was thinking colour, when I should have been thinking luminance.

Quote - In sRGB, it is incorrect to assume that doubling the value of a pixel should cause it to be twice as bright.

But in linear colour space - maybe they should have called it the linear luminance space, IF I'm getting this right - you can do that sort of math and at least be a little closer to your desired outcome.
Before I go barking up any more trees, this needs to be confirmed: is luminance the component of an image we are converting from sRGB to linear colour space? Is it a discreet component? or is it something that has to be calculated from the colour pixels themselves?

Don't you just HATE all these questions?

The luminance we're talking about is not the overall luminance, but the luminance of each color component in R, G, and B. Note, though, for a strictly gray-scale image those are the same thing and most explanations of GC try to demo it with shades of gray.

Your screen pixels comprise three components. In each pixel, one is red, one is blue, and one is green. The color you percieve for that pixel is controlled by the amount of red luminance, green luminance, and blue luminance, combined. The luminance is controlled by the voltage applied. The voltage is controlled by the numbers we store in each pixel component. The ratios of these RGB luminances within a pixel give rise to various hues and saturations.

GC is applied in order to produce the R, G, and B luminance calculated by our shaders/lighting model. Without GC, the intended luminance of each pixel is not actually produced - something darker is in all three components. Therefore the overall luminance is darker. But also, the overall hue and saturation is incorrect as well.

GC is directly about mis-represented luminance.

Mis-representations of luminance also produce mis-representations of hue and saturation.

Therefore, indirectly, GC is about hue and saturation as well.

Good. Thank you. That is clear in my mind.

Next question.

Gamma correction is necessary only for image files used in a shader and only for diffuse or specular channels.  [ T / F]

Since bump and displacement don't use colour information, it is not necessary to perform gamma correction on dedicated bump and/or displacement files, [ T / F]

or node-based colours and textures.[ T / F]

A confession: I've become shader-obsessed. I've been writing GC scripts to replace (and correct) more complex hair shaders and clothing shaders for everything in my closet. You wouldn't believe how many Specular_Value = 1 / Diffuse_Value = 1 shaders I see. They are going to throw me out of the forum I'm in because I won't shut up about GC. I think I need counselling.

Fortunately, I do have a blog... and will continue to share my experiences and conclusions and experiments there. The entries probably aren't completely accurate - I'd be happy with about 80% accuracy - but the results I'm getting are excitingly more vibrant and alive.
tightbytes.com/wordpress/

Forget about selling anything: I'm on a mission. And I haven't even played with AO, yet! When will it STOP??!?

Hi, RV. Following with interest still, but holding back on comments. Was expecting some guidance on displacement / bump maps and the "minus ~0.5" thing, but I guess that's for another time, since we're dealing with GC etc now.

I've developed a way of thinking about linear colour space, GC and anti-GC. It's nothing new or ground-breaking, just a way I found to think about it which helps me to grasp what I could not hold on to firmly before. That's why I've not said anything about it. It's possibly not even accurate, but it serves my purpose. It just involves doing the maths on numbers that proportionally represent actual light energy. I used my own (flexible but consistent) unit of measurement called "RGB photon-buckets" (at least, I've not heard that term anywhere else) to help me think it through. How many photons in a photon bucket? Well, how much water in a water bucket? Doesn't matter when you only count the buckets, but they must be all the same size. Ummm.... and full!

Anyway, what I really came here to say was... you mentioned in your latest blog (all of it read from start to finish, btw. You're doing good. No, that sounds patronising... I mean I think it's great stuff)... ummm, where was I? Yes, you mentioned that your purpose was to create a GC shader using Matmatic. Did you go off track? Because by the end of the page, I hadn't seen one line of ..... oh, wait, I stopped typing and went to have another look and saw your next section. hehe...

Just ignore me. Still, I'll let this go through so you know I'm here, reading with interest. You know, I think I could answer some of your questions, but it's getting so that I dare not. I'm like a bee, I sting when I need to, but it hurts me and I hate doing it, so I'm just keeping clear of danger. :O)

Hi IsaoShi, you make me feel less alone - I sense you've gone over this stretch of road yourself, and recognise those potholes in my understanding. Thanks for your insights - they are always most welcome!

There is a Poser group I belong to. The (unwritten, tacit) guiding philosophy of this group is "helping each other helps each of us". It is with this mindset that I come with these questions - annoying as I must seem to Those That Know. I feel if my understanding has gaps, others must be in the same place. And on my blog then, those questions can be addressed.

As to my blog, it's a blow-by-blow. Someone comes along and points out a glaring error, I'll correct the error (with credit given). It doesn't pretend to be an authoritative work on the subject... it's all about sharing.

The thing I love so much about scripting and why I wish more people got into it is: I feel you actually get a much clearer idea - almost like an outline, or dot-point explanation - of what a shader's doing. Even after I've cranked out a fairly elaborate GC shader for some clothing item which incorporates some of the original shader (correcting certain settings), I can go back and remember what it's mean to be doing in the script much easier than looking at a spaghetti-salad of nodes.

I'm completely lost as to what to do in order to do whatever this topic was instructing me in. Can someone dumb down this gamma correction fix for me?

If not, it doesn't matter. Poser7's math functions are beyond me, as math was and is my worst subject.

Quote - Next question.

Gamma correction is necessary only for image files used in a shader and only for diffuse or specular channels.  [ T / F]

False on many levels. You conflated several questions and asked it wrong.  Let me re-assemble the question in various forms, leaving out or adding certain words, and answer each:

Gamma correction is necessary ... for images files used in a shader ?

Incoming images are either linear (such as HDR images) already or gamma corrected which require anti-GC measures to make them linear. In no case would you want to gamma correct them. Did you mean to ask about anti-GC? Images such as JPEG photos should be anti-gamma corrected, to make them linear, if they are not already linear. HDR and EXR images are supposed to be linear already. Some are not. If it looks right, it's not linear, and you need to anti-GC it.

*[Anti] Gamma correction is necessary only for images ... ?

False. Any color parameters chosen on the basis of how they look on the screen (such as from a color picker) must be entered in linear representation, or you risk shifting hues and saturation around. For example, the color sRGB(255, 128, 64) is not the actual linear color value you should use. In order to do proper linear math with that color, you should anti-GC it. Notice I said sRGB to indicate I'm talking about the values you read off from picking or sampling a color on the screen and then examining what RGB values you got. Consider if you used that color with a 50% light. What should the on-screen color end up being, half those values? Nope, because half of those would not be half as luminous.

In general, if the color you like in your sample or color picker is X, then you should be using X ** 2.2 in the script.

By the way, in all your scripts, you keep writing very long things like:

gamma = Add(2.2)
color = ImageMap("blah blah")
gamma_pow = Color_Pow(color, gamma)

I find this incredibly tedious to read, as I have to study many characters to see what you did.

This gets the exact same job done:

ImageMap("blah blah") ** 2.2

Also, the lovely thing about this expression is that if "color" is really just a color, then you don't need any nodes, and matmatic will just do the conversion for you, for example:

IColor(255, 128, 64) ** 2.2 # will result in the linear representation of what 255, 128, 64 looks like on the screen

*[Anti] Gamma correction ... only for diffuse or specular channels.

False. It is also needed for any incoming material that is coming from gamma corrected sources. In particular, reflections coming from other GC shaders on other surfaces are in sRGB color space, not linear color space, and have to be anti-gamma corrected before you use them in calculations.

Quote -
Since bump and displacement don't use colour information, it is not necessary to perform gamma correction on dedicated bump and/or displacement files, [ T / F]

True.

Quote -

or node-based colours and textures.[ T / F]

True, assuming you anti-GC'd any colors that you fed to those nodes from outside. Remember, that includes images and colors you manually enter into parameters.

Note: Poser Pro does all the anti-GC for you. Any color parameters you enter into nodes are automatically linearized in poser Pro when you enable GC rendering.

Quote - I'm completely lost as to what to do in order to do whatever this topic was instructing me in. Can someone dumb down this gamma correction fix for me?

If not, it doesn't matter. Poser7's math functions are beyond me, as math was and is my worst subject.

Use my shaders. I take care of it. The thing going on here is RobynsVeil wants to write her own somewhat complicated shaders that do more than what I have published so far. So all this math is important and cannot be simplified. She's combining on the order of 10 colors and images in her shaders, to do dynamic makeup and stuff.

I'm trying to make an orange vase (TrekkieGrrrl's freebie).

I put the orange color into the Diffuse_Color. I add the diffuse and specular, then gamma correct.

I get a tremendous shift in hue and saturation. Luminance is right, but the color is all wrong.

Imagine that orange was actually from a color map. See the problem? The RGB (255, 128, 64) value we see as orange is only that color when viewed on a monitor. The actual amount of red, green, and blue is wrong from a linear color representation standpoint. As a result, everything gets shifted around when we gamma correct at the end.

There's no difference between using a simple orange color everywhere and using a color map filled with orange. They both need to be dealt with the same way. That orange is not actually 255, 128, 64. The only time that is the right number is to get that p;articular color to show on your screen. That is not the actual numerical value in linear color space.

Quote - > Quote - 1 * Color_Map - 0

What value does that give you?

Another question:

Plugging a color into a numerical Math node parameter converts the color to gray scale. The Subtract node Value_1 is what I'm talking about here.

What happens if you plug a color into some other numerical node parameter. Suppose you plug it into Bump or Displacement. What is going to happen?

A related question: If I connected 500 of these Subtract(1 * x, 0) nodes in series, what would change?

Related to that, if I connect no subtract nodes here, what changes?

If you plug a color into the numerical Math node granted if it's a solid color the only thing that will happen is nothing, especially if it's in the displacement or bump node.  If that's the effect you're going for, then it's better to leave it off. But if you want to add some "umph" into the existing texture that the creator so kindly forgot to provide the bump or displacement map, you can add a quickie bump or displacement node.
As for the 500 of these nodes in a series, I would imagine the effect to be negligible  after the first 2 nodes (I don't know. I am not an expert like you, BB. Half of the information I've received about the mat room came from that lil noggin of yours. The rest from tips and experience. ).

Even the first two do nothing. That was what I was trying to get across. If 500 of them do nothing, why would 1 do something?

First off, thank you for being so precise and so clear in your answers, where my questions were - because of my ignorance - nebulous due to (as you put it) conflation... neat word. The information in these last few posts have done more than you would ever believe to bring the process out of the fog. I had to know the why - this cleared it all up! Thank you again, Bill.

As to my incredibly wordy code: I agree... makes writing code almost pointless... just string the bloody nodes together, it's quicker, right?

May I ask you a quick question? Just one more? Please? (sheesh, I'm annoying, even to ME!)

When I do this stuff:
gamma = Add(2.2)
color = ImageMap("blah blah")
gamma_pow = Color_Pow(color, gamma)

I have three nodes that I can dictate .inputscollapsed and .pos to by name:

gamma.inputscollapsed = 1
color.inputscollapsed = 1
gamma_pow.inputscollapsed = 1

and similarly do positioning on the material room floor. However, if I:

ImageMap("blah blah.jpg") ** 2.2

...I get all kinds of nodes I have no idea how to reference so I can tidy things up. Call me pedantic, but I like things working right and tidy too. With emphasis on the former. Is there a way to do so from within a script that you know of?

When you use infix operators, matmatic will pick a node to implement it, same as if you said it explicitly.

colorWithGC = Color_Pow(ImageMap("blah.jpg"), 2.2)
#or
colorWithGC = ImageMap("blah.jpg") ** 2.2

colorWithGC is a node - it got made the same either way

therefore we can do

colorWithGC.inputscollapsed = 1

You could also make a handy function to collapse the inputs on anything:

def collapse(x):
    x.inputscollapsed = 1
    return x

Having that, you could say:

colorWithGC = collapse(ImageMap("blah.jpg") ** 2.2)

Puzzled.

I was quite certain that if I did "to the power of" maths, it would generate additional nodes that I couldn't re-label or reference. However, now they seem to stay in place, except for the ImageMap node, which seems to have a mind of its own.

Here's the whole script: it's not long. I'm converting a dress texture to GC. I carefully recreated the connections that existed before, except now there's anit-gamma / gamma processing code. Also, instead of connecting to Diffuse_Value, I connect to Alt_Diffuse. Those values I have changedA lot of the original shader is questionable, even to my limited understanding. So, ignoring some of the values for the moment (my biggest issue is the s.Reflection_Value = 3):

def makeSurface(region):
  # Colour / other Maps
  dispBumpMap = ImageMap("VDRflwr_rpd01D.jpg").labelled("Disp-Bump Map")
 
  # !!!!!!!!!!!!!!!!!!! CHANGED
  # convert to linear colour space - this node does not obey '.pos =' directives
  linearColourMap = ImageMap("VDRflwr_rpd03.jpg").labelled("linear ColourMap") ** 2.2
  
  dressClr = IColor(45, 17, 94) #Purple
  venClr03 = IColor(127, 127, 127) #Grey
  venClr04 = IColor(177,153, 200)
  # For the reflection channels
  venClr02 = IColor(205, 198, 255)
 
  if region == "flower":
    reflClr = IColor(0, 0, 255) #Blue
  if region == "dress":
    reflClr = IColor(142, 242, 255) #Light Blue
 
  setWeave = Weave(
    Color_1 = WHITE,
    Color_2 = venClr02,
    Base_Color = BLACK * linearColourMap,
    U_Scale = 1,
    V_Scale = 1, 
    Height = 3, 
    Bias = .3, 
    Gain = .5).labelled("Sets Weave")
  setRefl = SphereMap(reflClr * setWeave).labelled("Sets Reflection")
  setDiff = Diffuse(dressClr * linearColourMap, .7).labelled("Sets Diffuse")
  

!!! Changed - had labels indicating what these nodes did... now they just say Color_Pow

Convert back to sRGB

  gamma = setRefl ** (1 / 2.2)
  gamma2 = setDiff ** (1 / 2.2)
  
  # Arrange nodes
  gamma.inputsCollapsed = 1
  gamma2.inputsCollapsed = 1
  linearColourMap.inputsCollapsed = 1
 
  gamma.pos = 250, 50
  gamma2.pos = 250, 75
  linearColourMap.pos = 250, 100   # doesn't stay there - goes right off the screen
  
  setDiff.pos =  500, 100
  setRefl.pos =  500, 200
  setWeave.pos =  500, 300
 
  dispBumpMap.pos = 720, 300
   
  
  
  # Make the actual surface
  s = Surface(1,0,0,0)
  s.Highlight_Size = .25
  s.Translucence_Color = venClr03 * gamma
  s.Reflection_Color = venClr04 * gamma
  s.Reflection_Value = 3 * gamma
  s.Bump = dispBumpMap * .03
  s.Displacement = dispBumpMap * .006
  s.Alternate_Diffuse = gamma2
  return s
  
outputs += [
  "-Flower", makeSurface("flower"),
  "-Dress", makeSurface("dress"),
#  "-Borders", makeSurface("borders"),
#  "-Ribbon", makeSurface("ribbon"),
]

Just whenever you get to it is fine, Bill... I realize you're an incredibly busy man, and this nonsense must be really frustrating to you. Thanks again for your patience.

And one could somehow also create a function that would do the same thing with position, incrementing some variable? Kinda like:
nodePos = 10

def nodePosition(x):
  x.pos = nodePos + 25
  return x

linearColourMap = nodePosition(ImageMap("blah.jpg") ** 2.2)

I'm thinking the value of nodePos would increment with each call of nodePosition? Or am I getting By Reference mixed up with By Value again? In Python, it's always by reference, right?

Attached Link: LCD and CRT Monitor Calibration Software

"This program will help you to calibrate your LCD or CRT displays without any hardware devices for 6500K gamma 2.2. "

check it out

Carefully re-reading your fine manual - the one that came with Matmatic - which revealed this:

"Arithmetic involving just colors or numbers is entirely performed inside Matmatic. No nodes are generated for these."

Pretty unequivocal. So, I conclude that if I've got some maths nodes I didn't set out to generate, that there's a flaw somewhere in my code. This is distinctly possible. Now, as to creating names for basically maths nodes:

**"... if you're trying to find a particular step, or you want to document the tree for people who are not using Matmatic, you can change the labels on the nodes. Every node has an attribute called label. Set it to anything you want. Another way, more inline during expressions, is to call the node method .labelled(desiredlabel). This sets the label and returns the node, so you can use it in expressions. Example:

R = sqrt((x * x).labelled("X sqrd") + (yy).labelled("y sqrd")).labelled("radius")     "*

I'll just shut up now and sort out where I went wrong with my code.