POV-Ray : Newsgroups : povray.general : I was wrong, image_pattern looks useful. Attn: Bald Eagle. Server Time
4 Dec 2024 21:41:28 EST (-0500)
  I was wrong, image_pattern looks useful. Attn: Bald Eagle. (Message 1 to 5 of 5)  
From: William F Pokorny
Subject: I was wrong, image_pattern looks useful. Attn: Bald Eagle.
Date: 12 Mar 2023 12:29:11
Message: <640dfdd7$1@news.povray.org>
Hi Bill,

In some height_field thread I mentioned image_pattern was a 'different 
beast'.

This morning I looked at it again - and you're right - it fits with the 
height_field discussion in that it looks like an image_map alternative 
which converts a color pixels to grey on the fly. I'll have to play with 
the option.

Aside: I found only two uses in the sample stuff shipped with POV-Ray, 
One each in the portfolio allnormals.pov and allpatterns.pov code. The 
first has:

#declare Image_pattern = normal {
	pigment_pattern{image_pattern { png "mtmandj.png" }}
2}

which has me curious as to why both pigment_pattern and image_pattern 
are getting used as I think that will run the color to grey conversion 
twice. Maybe the image_pattern code creates a smaller internal image 
format? Hmm, but then what three channels does pigment_pattern use...

The second allpatterns use is:

#declare Image_pattern = pigment {image_pattern { png "mtmandj.png" }}

which looks useful.

Anyhow. I wonder if I was remembering some functionality other than 
image_pattern from 20 years back. There is too material_map, maybe I was 
wrongly thinking of that when I first blabbered about image_pattern. :-)

Bill P.


Post a reply to this message

From: Bald Eagle
Subject: Re: I was wrong, image_pattern looks useful. Attn: Bald Eagle.
Date: 12 Mar 2023 13:45:00
Message: <web.640e0f36d55ff79a1f9dae3025979125@news.povray.org>
I think you're right, and wrong again at the same time.

> In some height_field thread I mentioned image_pattern was a 'different
> beast'.

You did, and now you've provided some more interesting data, but IIRC, you were
bringing that up in a conversation with Kenneth Walker, not me.   :D


Post a reply to this message

From: William F Pokorny
Subject: Re: I was wrong, image_pattern looks useful. Attn: Bald Eagle.
Date: 12 Mar 2023 15:52:31
Message: <640e2d7f$1@news.povray.org>
On 3/12/23 13:43, Bald Eagle wrote:
> I think you're right, and wrong again at the same time.

Ah, usual my state of affairs then... :-)

Bill P.


Post a reply to this message

From: Kenneth
Subject: Re: I was wrong, image_pattern looks useful. Attn: Bald Eagle.
Date: 14 Mar 2023 04:20:00
Message: <web.64102d83d55ff79a9b4924336e066e29@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> I think you're right, and wrong again at the same time.
>
> > In some height_field thread I mentioned image_pattern was a 'different
> > beast'.
>
> You did, and now you've provided some more interesting data, but IIRC, you were
> bringing that up in a conversation with Kenneth Walker, not me.   :D

(sorry if this is mistakenly wandering off-topic:)
There is also something in the link below that proved useful to *me* in 2020
(near the end of the thread), about pigment_pattern vs image_pattern, with the
former actually being more 'user-friendly' when coding complex textures. Near
the middle of the thread, IVE mentioned the reason, in response to a question I
had (not about height_fields though.)

https://news.povray.org/povray.binaries.images/thread/%3Cweb.5f73b631268cd3c2d98418910%40news.povray.org%3E/?mtop=43184
8


Post a reply to this message

From: William F Pokorny
Subject: Re: I was wrong, image_pattern looks useful. Attn: Bald Eagle.
Date: 14 Mar 2023 19:11:47
Message: <6410ff33$1@news.povray.org>
On 3/14/23 04:17, Kenneth wrote:
> There is also something in the link below that proved useful to*me*  in 2020
> (near the end of the thread), about pigment_pattern vs image_pattern, with the
> former actually being more 'user-friendly' when coding complex textures. Near
> the middle of the thread, IVE mentioned the reason, in response to a question I
> had (not about height_fields though.)

Thanks for the pointer! I vaguely remember the thread and I gave it a 
re-read. I've been playing with image_pattern vs image_map.

It certainly pays to defined a pigment containing either the image_map 
or image_pattern once and to thereafter reference that pigment. If your 
eventual use is 'grey' via pigment_pattern or a function's .gray I think 
  the two image inputs are mostly interchangeable. I see little 
difference for storage. There looks to be a slight performance advantage 
to using image_pattern in the once defined pigment especially with the 
function's reference being then .red. The function wrapper itself 
slightly slower the pigment_pattern.

FWIW. My test code is at the core roughly:

//---
#declare Pim = pigment { image_map { "as789.png" } }
#declare Pip = pigment { image_pattern { "as789.png" gamma srgb } }
#declare FPim = function { pigment {Pim} }
#declare FPip = function { pigment {Pip} }

#declare P000 = pigment {
//  color Red
//  image_map { "as789.png" }
//  image_pattern { "as789.png" }
//  Pim
     Pip
     //---
//  pigment_pattern { Pim }
//  pigment_pattern { Pip }
//  function { FPim(x,y,z).gray }
//  function { FPip(x,y,z).red }
//  color_map { [0 red 0] [1 red 1] }
}
//---

Bill P.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.