Trouble with HSV shader node in Firefly

[Ken1171]

When I use the HSV shader node in Firefly to change a texture color from red to blue, the blue shows with red speckles all over the material. It seems to only partially change the color, leaving random speckles of the original texture color showing. These speckles show in both previews and renders. The boots diffuse texture is a plain JPEG file, plugged to the HSV's "color" channel. The "hue" param has been set to "0.6", which shifts the red color to blue.

The operation works if I replace the HSV node with the new Poser 11 HSV2 node, but then it becomes incompatible with all previous Poser versions. The HSV2 node appears to only exist in Poser 11.

How can I get rid of the speckles with the HSV node? See image below for example.

 

[Pendraia]

Would you be able to recreate it using the original HSV and combining it with maybe a value brick/node or a math brick?

What function does the HSV2 brick add in? Could it be replicated using a mix/blend brick/node? I could get similar effects using a mix brick with an alpha in DS.

 

[English Bob]

Bagginsbill has this to say about HSV vs. HSV2: How to do HSL or HSV operations in a texture?

He also links to a thread at Renderosity a little further down the page where he seems to address what you want to do.

Edited to add: quick summary, HSV multiplies input hue by the hue parameter, HSV2 adds it (which is more like the behaviour you probably see in an image editor).

 

[phdubrov]

And the only Poser HSV node with neutral Hue=0.5 is Cycles node (Cycles-Color-HSV).

 

[kobaltkween]

HSV in Poser has always had problems. It really depends on your map how things react. I've had random bits like that of green, purple, and other garish colors completely unlike the rest of the map. And I've had times where that didn't happen at all. Not based on the shader, unfortunately, but the map.

If you want a backwards compatible method, you can use Component nodes to break your input into channels, then manipulate the channels to get what you want. Or just use math to combine a greyscale texture with a color. Even if you wanted fancy stuff like overlay, screen, hard light, or soft light, many of those are in the new Cycles Color Mix node, and you can easily find the equations for them online for building them as nodes.

 

[Ken1171]

Would you be able to recreate it using the original HSV and combining it with maybe a value brick/node or a math brick?

No, I have tried but it didn't work.

Bagginsbill has this to say about HSV vs. HSV2: How to do HSL or HSV operations in a texture?
He also links to a thread at Renderosity a little further down the page where he seems to address what you want to do.

I actually know how to use the HSV node - the issue itself is that, as seen in the render above, it doesn't seem to work as described. I have read through the forums, and they all seem to succeed using the old HSV node, while with me it fails. I didn't find a part where they had any issues with it. Everything seems to work over there.

HSV in Poser has always had problems. It really depends on your map how things react.

This seems be to true. I have experimented with HSV before and it has always worked, but it doesn't work with THESE particular textures I have now. I took a look on the properties of the textures where it has worked, and then on the ones where it doesn't work, and it seems they are both 24-bit JPEGs. But one has color representation with sRGB, while the other had no info on how the color is encoded. I think that's where the problem lies - the JPEG color representation or encoding.

I will investigate this in more detail, and see if I can make the original HSV node work with these textures as well. This is definitely a matter of the kinds of textures the HSV node actually supports. It's obviously not all of them.

 

[Ken1171]

And the winner is.... *** drumrolls *** Color Encoding Method!!

Like KK has mentioned above, the old HSV node does work flawlessly depending on what textures we use. Under closer examination, JPEG can use different color encoding methods when the image is compressed, and the Poser HSV node likes some better than others. The node is rather picky on how colors are encoded in the texture files. This is easy to test, by picking the original uncompressed texture in lossless PNG and plugging it into the HSV node. We can see below that the red boots are now properly converted to blue. Voila, no more random red speckles.

As another test, I have compressed the PNG colors from the original 24-bits down to only 8-bits sRGB, and the HSV node still works flawlessly with it. Everything indicates that it's the multiple ways JPEG chroma sub-sampling can encode color data that breaks it.

Problem solved for the time being. ^___^

 

[Ken1171]

One tidbit about HSV from Cycles is that the results won't show in previews like Firefly HSV does. In my computer, colors turn black when plugged into a Cycles HSV node.

 

[Semicharm]

And the winner is.... *** drumrolls *** Color Encoding Method!!

Like KK has mentioned above, the old HSV node does work flawlessly depending on what textures we use. Under closer examination, JPEG can use different color encoding methods when the image is compressed, and the Poser HSV node likes some better than others. The node is rather picky on how colors are encoded in the texture files. This is easy to test, by picking the original uncompressed texture in lossless PNG and plugging it into the HSV node. We can see below that the red boots are now properly converted to blue. Voila, no more random red speckles.

View attachment 30774

As another test, I have compressed the PNG colors from the original 24-bits down to only 8-bits sRGB, and the HSV node still works flawlessly with it. Everything indicates that it's the multiple ways JPEG chroma sub-sampling can encode color data that breaks it.

Problem solved for the time being. ^___^

Yeah, the original Firefly HSV node multiplies the texture color value by the node "color" value, which can lead to odd results. In your first post, it looks like parts of the JPEG texture had a color value close to 0, which would get stuck as red no mater what (x*0 = 0). Like you pointed out, it's probably caused by the way JPEG encodes chroma values. I tend to prefer PNG when possible. In some rare cases, 8 bit PNG can give better fidelity than an over compressed JPEG of the same file size.

 

[Ken1171]

I used to prefer PNG over JPEG until I ran into a problem that only PNG brings up. When they came up with the file format, they decided it was a good idea for PNG to store and use its own gamma correction, instead of using the one from host application. In Poser, this can cause PNG maps to override the gamma correction value we explicitly enter for the texture nodes, which cause them to mismatch the colors from the rest of the maps.

Some people came up with tools to remove the embedded gamma from PNG files, but there were cases where that was not enough, and the only way to make them match the colors from other maps was to convert to JPEG. If not for that, PNG would be an ideal file format.

 

[English Bob]

Interesting. I downloaded TweakPNG and went on a PNG hunt. Incidentally, PNGs made by Poser don't include the gAMA chunk - in fact they have a structure which is different from other PNGs I looked at. However that's off-topic and is probably down to the image handling library that Poser uses.

It would be a useful enhancement to Poser's map handling in the material room to include a checkbox to ignore the embedded PNG gamma; in fact that should probably be the default behaviour..?

I recall a thread elsewhere on this forum where someone was complaining that PNG maps worked differently, and this could well be the explanation. I'll see if I can hunt it down.

 

[Ken1171]

It would be a useful enhancement to Poser's map handling in the material room to include a checkbox to ignore the embedded PNG gamma; in fact that should probably be the default behaviour..?

That, and also automatically setting greyscale maps gamma correction to "1.0". It would be correct in the vast majority of cases.

 

[Semicharm]

That, and also automatically setting greyscale maps gamma correction to "1.0". It would be correct in the vast majority of cases.

Agreed, though most people use 24bit color jpeg for everything.

 

[Ken1171]

Agreed, though most people use 24bit color jpeg for everything.

What I mean is that bump, displacement, normal, and transparency maps should ALWAYS be set to gamma correction =1.0 in all cases. In MOST (but not all) cases, the same should also apply to specular maps. This is valid independently of what color depth these maps may use.

 

[Semicharm]

What I mean is that bump, displacement, normal, and transparency maps should ALWAYS be set to gamma correction =1.0 in all cases. In MOST (but not all) cases, the same should also apply to specular maps. This is valid independently of what color depth these maps may use.

How would you suggest doing that? Poser currently sets gamma on a per file basis.

 

[Semicharm]

Interesting. I downloaded TweakPNG and went on a PNG hunt. Incidentally, PNGs made by Poser don't include the gAMA chunk - in fact they have a structure which is different from other PNGs I looked at. However that's off-topic and is probably down to the image handling library that Poser uses.

It would be a useful enhancement to Poser's map handling in the material room to include a checkbox to ignore the embedded PNG gamma; in fact that should probably be the default behaviour..?

I recall a thread elsewhere on this forum where someone was complaining that PNG maps worked differently, and this could well be the explanation. I'll see if I can hunt it down.

Was this the one? Poser texture formats

 

[Ken1171]

How would you suggest doing that? Poser currently sets gamma on a per file basis.

My suggestion is that Poser should automatically default gamma correction to 1.0 when we add a texture map to those channels (bump, specular, normal, displacement and transparency). Currently, it defaults to whatever the global render settings are, which is rather useless. That's what I suggest.

 

[Semicharm]

My suggestion is that Poser should automatically default gamma correction to 1.0 when we add a texture map to those channels (bump, specular, normal, displacement and transparency). Currently, it defaults to whatever the global render settings are, which is rather useless. That's what I suggest.

Assuming it's connected directly to the channel and not already connected to a color channel as well?

 

[Ken1171]

I suppose.

 

[Semicharm]

Personally, I think the gamma override option should have been added to the image node. That way the same map can be reused with the correct gamma for specular, while another node can keep the renderer setting for diffuse.