As we were playing around with image_maps and height_fields, I was 
reminded there is support for the keywords 'repeat' and 'offset' in the 
image_map and bump_map code.

These look useful to me in that they can accomplish what we usually do 
with scale and translate, without an actual transform. Anyone know why 
they are, since v3.7 at least, hidden from users? Or have I again missed 
some documentation?

Attached an image with traditional 'once' map on the left. In the middle 
using repeat <2,2> (how many/much in 1x1) and offset <0.5,0.5> 
(accounting for 2x repeats in 1x1).

On the right we go with repeat <3,3> only and add in the two repeat/flip 
tiling warps. I don't believe we can as easily accomplish this kind of 
tiling effect another way.

Aside: Those image_map repeat values can be any non integral positive 
(>0) float too.

Bill P.

//---
#declare Pigment00 = pigment {
     image_map { "p189crop.jpg"
         repeat <2,2>
         offset <0.5,0.5>
         map_type 0
         once
         interpolate 2
     }
   //warp { repeat x flip x }
   //warp { repeat y flip y }
}
//---

Post a reply to this message

Attachments:
Download 'imap_repeat_offset.png' (457 KB)

Preview of image 'imap_repeat_offset.png'

William F Pokorny <ano### [at] anonymousorg> wrote:
> As we were playing around with image_maps and height_fields, I was
> reminded there is support for the keywords 'repeat' and 'offset' in the
> image_map and bump_map code.
>
They're still there in v3.8, in the docs at "3.6.2.5.5 Warp"

I remembered 'repeat' and 'offset', but not 'flip'.
>
> Attached an image with traditional 'once' map on the left. In the middle
> using repeat <2,2> (how many/much in 1x1) and offset <0.5,0.5>
> (accounting for 2x repeats in 1x1).

The  middle image shows only one smaller image_map; should there be two instead?

I just tried this warp {repeat...} stuff on the function height_fields that
we've been discussing recently-- to try another way to eliminate the 'mirror
flipping in z' of the HF result. It WORKS! (with a certain configuration of the
warp items that's not yet understandable to me)-- and successfully takes the
place of the (1-y) fix that's required when the function is used later. The same
warp construction works for BOTH an image_map-to-function-to-HF, as well as
typical patterns like 'onion' and granite' (the only patterns I've tested so
far). Thanks for suggesting this; now we have *multiple* ways to fix the HF
mirroring flaw.

Example 1:
#declare somb =
function{
     pigment{
         image_map{png "...MY_IMAGE..." once}
         warp{repeat -y offset -y flip -y} // OR warp{repeat -x flip y}
            }
        }

Example 2:
#declare somb =
function{
     pigment{
         granite scale 2
         warp{repeat -y offset -y flip -y}
            }
        }

Post a reply to this message

On 3/3/23 02:02, Kenneth wrote:
>> As we were playing around with image_maps and height_fields, I was
>> reminded there is support for the keywords 'repeat' and 'offset' in the
>> image_map and bump_map code.
>>
> They're still there in v3.8, in the docs at "3.6.2.5.5 Warp"

The warp's repeat, offset and flip are handy, but the repeat and offset 
keywords and code in the image_map and bump_map are not related except, 
more than a bit, conceptually.

I'll have to play though with negative values with those three in warps 
- never tried it. (What does THIS button do!) :-)

Bill P.

Post a reply to this message

Op 3-3-2023 om 00:19 schreef William F Pokorny:
> //---
> #declare Pigment00 = pigment {
>      image_map { "p189crop.jpg"
>          repeat <2,2>
>          offset <0.5,0.5>
>          map_type 0
>          once
>          interpolate 2
>      }
>    //warp { repeat x flip x }
>    //warp { repeat y flip y }
> }
> //---
> 
Interesting stuff I need to look into. As a reminder maybe: adding gamma 
1 to the image_map is still essential and makes a difference whether you 
use it or not

   image_map { "p189crop.jpg" gamma 1

-- 
Thomas

Post a reply to this message

On 3/4/23 07:49, Thomas de Groot wrote:
> adding gamma 1 to the image_map is still essential and makes a 
> difference whether you use it or not

The latter part about it making a difference can certainly be true.

It only needs to be 'gamma 1', if the file was created in a linear color 
space(a). The default output and input is 'gamma srgb' in v3.8/v4.0 - 
excepting hdri file formats at 'gamma 1' and netpbm formats which use 
'gamma bt709' by default(b).

The above a lie, if you want to use odd file gammas for effect. You can, 
for example, specify a 'gamma <value>' and stick whatever you want in 
there for a positive value.

That said. Practically, it's true the majority of the image files coming 
from models we pick up somewhere out and about are written in the linear 
color space. For those you do need to always use 'gamma 1' because they 
were written with the expectation they'd be read as 'gamma 1' files.

Bill P.

--- More detail...

(a) - There was/is a bug in the v3.8/v4.0 branches were png files were 
being written without the srgb block unless the render was invoked with 
file_gamma=srgb. It's fixed in povr, I do not know the current status in 
v3.8 beta 2 or v4.0 master. The block is something you can see - or not 
- by editing a png file. Amongst the gibberish, look for the text 'sRGB' 
almost immediately following 'gAMA' near the top. If you see it, you 
have the sRGB block.

If you don't see and are using v3.8/v4.0 defaults you should code 'gamma 
srgb' while reading / using such POV-Ray created pngs. And/or be sure to 
use file_gamma=srgb on writing pngs.

(b) - Yes, there was another bug POV-ray v3.8/v4.0 which is patched in 
povr for netpbm file formats of .ppm and .pgm. The gamma wasn't 
defaulting properly on write or read - I cannot remember which at the 
moment.

---
Aside: With both (a) & (b) bugs, the reality is you might see the 
differences or not depending on stuff. Ignorance is bliss until the 
truck runs you over. A lot of truth too in, "if it looks good, it is 
good."

A test I sometimes run is to write file formats from povr, then 
immediately read that file back in sort of a SDL povr/POV-Ray image 
display tool where I again write the image file using a different name 
from the first written. I now have two files I can compare image to 
image which should be very near identical. Once in a while they're not.

Post a reply to this message

Ah! Thanks for the reminder of these details indeed. I seem to recall 
that Christoph mentioned these long ago... I use v3.8 beta 2 as a rule 
and I think it is not different on these matters. Poseray conversions 
from Poser files standard adds gamma srgb to the image_maps and gamma 1 
to the bump_maps.

-- 
Thomas

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/4/23 07:49, Thomas de Groot wrote:
> > adding gamma 1 to the image_map is still essential and makes a
> > difference whether you use it or not
>
> The latter part about it making a difference can certainly be true.
>
> It only needs to be 'gamma 1', if the file was created in a linear color
> space(a).

I'm wondering if you meant 'non-linear' there? I certainly don't want to get
into THAT 'can of worms' again re: linear-vs-non-linear (painful memories of
Ive's reaction in the distant past, ha.) It's just that, in my own way of
thinking, an image from the internet that is typically encoded(??) with a gamma
of 2.2 or sRGB is what I call non-linear (rightly or wrongly.) And when used for
a height_field in POV-ray, it needs 'gamma 1' added, to reconstruct the intended
linear nature of the image's brightness values-- so that we get a nice linear HF
slope from the black-to-white brightness values.

Maybe this is just my own screwy way of describing the situation, in a way that
makes sense only to me.
>
> The above a lie, if you want to use odd file gammas for effect. You can,
> for example, specify a 'gamma <value>' and stick whatever you want in
> there for a positive value.

Yes! Some interesting effects can be achieved that way, with height_fields at
least. There is actually no imposed limit to the value.
>
> That said. Practically, it's true the majority of the image files coming
> from models we pick up somewhere out and about are written in the linear
> color space.

non-linear? :-D (see pedantic explanation above)

Post a reply to this message

On 3/5/23 15:41, Kenneth wrote:
...

Linear(c).

> It's just that, in my own way of
> thinking, an image from the internet that is typically encoded(??) with a gamma
> of 2.2 or sRGB is what I call non-linear (rightly or wrongly.)

For the typical jpeg and png formats on the web, yes.

> And when used for
> a height_field in POV-ray, it needs 'gamma 1' added, to reconstruct the intended
> linear nature of the image's brightness values-- so that we get a nice linear HF
> slope from the black-to-white brightness values.

Maybe, kinda.

Unless mangling the image file for effect(b), you want to read the image 
file with the same gamma correction(a) used when it was created to get 
again the same, internal, linear rgb values that existed prior to the 
image being written.

There is no 're-construction' when using a gamma correction of 1.0. At 
'gamma 1.0' you are reading (or writing) the image doing no gamma 
correction(a) at all. The values internal to the image file are directly 
transferred to POV-Ray's internal, linear rgb space - whether they were 
written to the image file with gamma correction or not.

Again. The up front rule is to read image files using the same gamma as 
was used when they were written/created(b).

Bill P.

(a) - Where the gammas involved are other than 1, on image read/input we 
are actually applying the inverse gamma correction to that used during 
write to get back to the linear, rgb space internal to POV-Ray.

(b) - Other than mangling for effect, there is one other time you might 
want to apply the 'preview display gamma' correction on an image read... 
Suppose you've written an image file from POV-Ray with file_gamma=1.0.
When you view this file with whatever viewing tool outside of POV-Ray it 
will appear darker than it appeared in POV-Ray's preview window. POV-Ray 
gamma corrects with the display gamma setting prior to preview as it 
would correct prior to writing to a file using the file_gamma value.

If you want to see this image in POV-Ray's preview window in the same 
way other image viewers will display it, you need to apply the display 
window's gamma correction (the default is srgb) during the image 
read/input. What we are really doing is applying the inverse gamma srgb 
to an as written linear gamma file - so the forward, srgb, preview 
window gamma correction ends up back in the linear color space as you 
preview it in POV-Ray... :-)

(c) - For what happens typically with respect to images used with 3d 
models, it's just my impression from a relatively limited set of 
personal experiences. I've certainly not done an exhaustive survey! ;-)

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/5/23 15:41, Kenneth wrote:

> Linear(c).
>
I thank you for your gentle explanation. ;-)  I intend to read and re-read it,
until it hopefully sinks in.

I don't know what my trouble is with this particular subject, but I have the
most *difficult* time in trying to reconcile my 'viewpoint' with the actual
FACTS as you have laid them out (and probably Ive as well, I hate to admit...
in-between his rantings!) At *some* point, I surely hope that a light-bulb
finally turns on in my head and I see the error of my ways.

Currently, my own theory makes sense to me-- flawed as it is-- and so far, I
have not run into a 'paradigm-shifting' situation when rendering scenes in
POV-ray. But it irks me greatly that my way of perceiving this subject is not...
right.

I continue thinking about it! ...

Post a reply to this message