Having recently updated to a new version of PoseRay (v3.13.23.587 to be 
precise), I noticed two things that I suggest to change:


(1) PoseRay does not write a "#version" statement in the scene file. As 
of POV-Ray 3.7.0, this statement is now mandatory (ideally it should 
even be the very first non-comment statement) - if such statement is 
missing, the scene is presumed to be a legacy (v3.6) scene, and certain 
features (most notably gamma handling) will operate in a compatibility 
mode. (You'll also get a waning message.)

The other is directly related to this:

(2) PoseRay writes image_map statements with a "gamma srgb" and bump_map 
statements with a "gamma 1.0"; both would be redundant if the scene 
specified "#version 3.7", and it is actually recommended to /not/ use 
these statements unless working with image files that are known to cause 
problems with POV-Ray's automatic image gamma handling. (And while I 
haven't tested it, using "gamma srgb" with high dynamic range images by 
default would actually be outright wrong, because these file formats 
default to a gamma of 1.0.)


Speaking of gamma and version, it might be helpful for users of POV-Ray 
3.6 if PoseRay would provide an option (which I'd suggest to be on by 
default) to automatically convert any non-HDR image files from sRGB (or 
whatever gamma they have according to in-file information) to a gamma of 
1.0. (Care should be taken though to prevent colour banding; dithering 
should probably solve that.)

Post a reply to this message

On 9/19/2014 9:10 AM, clipka wrote:
> Having recently updated to a new version of PoseRay (v3.13.23.587 to be
> precise), I noticed two things that I suggest to change:
>
>
> (1) PoseRay does not write a "#version" statement in the scene file. As
> of POV-Ray 3.7.0, this statement is now mandatory (ideally it should
> even be the very first non-comment statement) - if such statement is
> missing, the scene is presumed to be a legacy (v3.6) scene, and certain
> features (most notably gamma handling) will operate in a compatibility
> mode. (You'll also get a waning message.)
>
> The other is directly related to this:
>
> (2) PoseRay writes image_map statements with a "gamma srgb" and bump_map
> statements with a "gamma 1.0"; both would be redundant if the scene
> specified "#version 3.7", and it is actually recommended to /not/ use
> these statements unless working with image files that are known to cause
> problems with POV-Ray's automatic image gamma handling. (And while I
> haven't tested it, using "gamma srgb" with high dynamic range images by
> default would actually be outright wrong, because these file formats
> default to a gamma of 1.0.)
>
>
> Speaking of gamma and version, it might be helpful for users of POV-Ray
> 3.6 if PoseRay would provide an option (which I'd suggest to be on by
> default) to automatically convert any non-HDR image files from sRGB (or
> whatever gamma they have according to in-file information) to a gamma of
> 1.0. (Care should be taken though to prevent colour banding; dithering
> should probably solve that.)

thank you very much for the feedback.

(1) The version is in the scene ini file as version=3.7 and it seems to 
work as the SSLT works which is a 3.7 exclusive feature. Is using 
#version (pov) instead of version (ini) the proper approach? I used the 
one on the ini file as it was a single entry but I can move it to the 
main pov file as a #version statement. Since the inc files could be used 
on other scenes, can #version be repeated on each file or would that 
lead to problems?

(2) I will make the gamma statements optional. I found some problematic 
image maps before. I suppose gamma 1.0 is still needed for transparency 
maps. I tried a while back and I think it was giving me the wrong 
transparency unless I set the gamma to 1.0. You are right about the HDR 
images, gamma srgb will give the wrong results.

The image library I use in PoseRay is rather old and very basic, gamma 
information may not readable, and any export would have to be to jpeg or 
tga. I will look into it but this may take a long time. One workaround 
would be to select "copy all maps to the same directory" in the export 
dialog. Once all the maps are in the same place run an external program 
on them like image magick and batch process them. I think I may just 
look into this instead as it may be more powerful.

FlyerX

Post a reply to this message

Am 19.09.2014 21:54, schrieb FlyerX:

> (1) The version is in the scene ini file as version=3.7 and it seems to
> work as the SSLT works which is a 3.7 exclusive feature. Is using
> #version (pov) instead of version (ini) the proper approach?

Ah, I didn't notice that, as I'm normally not using the .ini file.

I think ideally each file should specify what version it actually needs 
(see below).

As for SSLT working, that's no indicator for the version setting to be 
effective: The version setting governs backward compatibility for 
features that have undergone breaking changes (such as the different 
handling of "ambient", the treatment of transparency in sky spheres, or 
gamma-adjustment of input images), but it doesn't disable new features 
(such as the "emission" keyword in finish statements, SSLT, or the 
"srgb" keyword for specifying colours).

> I used the
> one on the ini file as it was a single entry but I can move it to the
> main pov file as a #version statement. Since the inc files could be used
> on other scenes, can #version be repeated on each file or would that
> lead to problems?

The usual approach for .inc files is to wrap the file's actual content 
in a construct such as this (presuming the file name is "foo.inc"):

   #ifndef(Foo_Inc_Temp)
   #declare Foo_Inc_Temp = version;
   #version 3.70;

   // ... (actual content) ...

   #version Foo_Inc_Temp;
   #end

This allows the .inc file to indicate that it expects a certain minimum 
version (in this case 3.7.0), and request activation of backward 
compatibility (in the scope of the .inc file) if used with a newer 
version, without disrupting version requirements and compatibility 
settings in the main scene file.

The construct also prevents the actual content from being included twice.


> I suppose gamma 1.0 is still needed for transparency
> maps. I tried a while back and I think it was giving me the wrong
> transparency unless I set the gamma to 1.0.

Yes, if you're using the following construct, then POV-Ray 3.7 will 
indeed apply an (in this case typically undesired) gamma adjustment:

   #declare TransMap = pigment { image_map { ... } }
   #declare T = texture {
     pigment_pattern { TransMap }
     texture_map {
       [0.0 MyTransTexture]
       [1.0 MyOpaqueTexture]
     }
   }

This is because POV-Ray can't know that the image_map pigment will 
actually wind up in a pigment_pattern where a linear interpretation of 
the raw image data is typically desired. (This is different for 
bump_map, where linear interpretation is the norm.)

This is indeed a perfectly legit use case for the "gamma 1.0" statement.

Post a reply to this message

On 19-9-2014 16:10, clipka wrote:
> (2) PoseRay writes image_map statements with a "gamma srgb" and bump_map
> statements with a "gamma 1.0"; both would be redundant if the scene
> specified "#version 3.7", and it is actually recommended to /not/ use
> these statements unless working with image files that are known to cause
> problems with POV-Ray's automatic image gamma handling. (And while I
> haven't tested it, using "gamma srgb" with high dynamic range images by
> default would actually be outright wrong, because these file formats
> default to a gamma of 1.0.)

To be sure: Is this valid for /all/ usual formats as used by Poser for 
instance? jpg? png? tga?

with the exception of course of transparency maps as mentioned below by 
FlyerX, but I suppose also with all maps used as pigment_pattern{} ?

Thomas

Post a reply to this message

Am 20.09.2014 13:48, schrieb Thomas de Groot:
> On 19-9-2014 16:10, clipka wrote:
>> (2) PoseRay writes image_map statements with a "gamma srgb" and bump_map
>> statements with a "gamma 1.0"; both would be redundant if the scene
>> specified "#version 3.7", and it is actually recommended to /not/ use
>> these statements unless working with image files that are known to cause
>> problems with POV-Ray's automatic image gamma handling. (And while I
>> haven't tested it, using "gamma srgb" with high dynamic range images by
>> default would actually be outright wrong, because these file formats
>> default to a gamma of 1.0.)
>
> To be sure: Is this valid for /all/ usual formats as used by Poser for
> instance? jpg? png? tga?

Short answer: Yes.


Long answer:

The revised gamma handling in POV-Ray 3.7 is based on the presumption 
that each and every file format has either a documented standard, or a 
de-facto standard, for gamma encoding/precorrection. Where such a 
clear-cut standard does not exist, POV-Ray 3.7 picks one of the variants 
in common use, and documents which one that is. Unless the user 
specifies otherwise, POV-Ray will presume any input file to adhere to 
that standard (and also generate output files adhering to that standard).

For jpg, POV-Ray 3.7.0 presumes that the file adheres to the W3C 
recommendation of using the sRGB colour space and encoding function.

For png, POV-Ray 3.7.0 presumes that any encoding gamma information in 
the file header is correct: If an sRGB tag is present, the file is 
presumed to use the sRGB colour space and encoding function. Otherwise, 
if a gAMA tag is present, the file is presumed to be encoded with that 
gamma. If none of these is present, the file is presumed to adhere to 
the W3C recommendation of using the sRGB colour space and encoding function.

For tga, POV-Ray 3.7.0 presumes that the file uses the sRGB colour space 
and encoding function.

One thing that should be noted is that the above is not cut into stone: 
The policy is to adhere to official and de-facto standards, and where 
this is currently not the case POV-Ray can be considered to be wanting. 
For instance, future versions will most likely also honor colour profile 
information embedded in jpg files, but as this goes beyond mere gamma 
handling it is currently not implemented yet.

> with the exception of course of transparency maps as mentioned below by
> FlyerX, but I suppose also with all maps used as pigment_pattern{} ?

POV-Ray will apply gamma conversion to all image files that, according 
to the context in which they are used, seem to contain actual image 
data, i.e. 2d arrays of actual colour data. This includes all 
image_map{...} statements, even if they are later wrapped in something 
else like pigment_pattern{...}. (To make the rule as easy as possible, 
and also limit parser complexity, this also applies even if the wrapping 
is done in-place.)

At the same time, POV-Ray will /not/ apply gamma conversion (instead 
using the raw image data) to all image files that, according to the 
context in which they are used, seem to be "misused" as containers for 
non-colour data. This includes bump maps, but also height fields. Again, 
POV-Ray will not try to figure out what the data /actually/ ends up as; 
so if you find a way to reconstruct the original colour data from such a 
language construct, you will find that gamma conversion will not have 
happened.

In any case, a user-specified "gamma" statement will always take 
precedence. Such a statement will always be interpreted as the presumed 
gamma of the image.

Now I can't tell off the top of my head whether this will always cause 
conversion to the assumed_gamma, or whether bump maps and the like will 
still be converted to linear. IIRC the latter is the case, but I'd have 
to look it up.

Post a reply to this message

Thank you Christoph, this is more than satisfying and as a consequence I 
can leave out the gammas in the standard material files I provide for my 
Poser characters.

I would need to test it, but I guess that height_fields based on an 
image_map function may still need the gamma mention to render correctly:

function {
   pigment {
     image_map {
       tga "MyImage.tga" gamma 1.0
       map_type 0
       interpolate 2
     }
   }
}

Omitting this in the past gave different height_field results [from 
2009-2010 onwards].

Thomas

Post a reply to this message

Am 21.09.2014 09:37, schrieb Thomas de Groot:
> Thank you Christoph, this is more than satisfying and as a consequence I
> can leave out the gammas in the standard material files I provide for my
> Poser characters.
>
> I would need to test it, but I guess that height_fields based on an
> image_map function may still need the gamma mention to render correctly:
>
> function {
>    pigment {
>      image_map {
>        tga "MyImage.tga" gamma 1.0
>        map_type 0
>        interpolate 2
>      }
>    }
> }

That guess is absolutely spot-on. If (e.g. for the sake of upsampling 
with interpolation) you choose to go via a pigment function based on an 
image_map, rather than using the image directly in the height field, 
then by default the parser will treat the image like in any other 
image_map: It'll presume that the data is actual colour data, and apply 
gamma adjustment to it.

Post a reply to this message

On 22-9-2014 5:17, clipka wrote:
> That guess is absolutely spot-on. If (e.g. for the sake of upsampling
> with interpolation) you choose to go via a pigment function based on an
> image_map, rather than using the image directly in the height field,
> then by default the parser will treat the image like in any other
> image_map: It'll presume that the data is actual colour data, and apply
> gamma adjustment to it.
>

Thought so, but wanted to be sure. Thanks!

Thomas

Post a reply to this message