"Leroy" <whe### [at] gmailcom> wrote:

>  #if(Bs="tga") tga File #end
>  #if(Bs="bmp") bmp File #end
>  #if(Bs="pgm") pgm File #end
>  #if(Bs="png") png File #end
>  #if(Bs="ppm") ppm File #end
>  #if(Bs="jpg") jpeg File  #end
>  #if(Bs="exr") exr File #end
>  #if(Bs="hdr") hdr File #end
>  #if(Bs="gif") gif File #end
>  #if(Bs="iff") iff File #end
>  #if(Bs="tif") tiff File  #end

AFAIK, you don't need any of this stuff any more, because POV-Ray automatically
determines the file type, and so those keywords can be omitted.

https://news.povray.org/povray.advanced-users/message/%3C5ba3b5f9%241%40news.povray.org%3E/#%3C5ba3b5f9%241%40news.povr
ay.org%3E

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
>
> >  #if(Bs="tga") tga File #end
> > [snip]
> >  #if(Bs="tif") tiff File  #end
>
> AFAIK, you don't need any of this stuff any more, because POV-Ray automatically
> determines the file type, and so those keywords can be omitted.
>
I was just about to say, "But what about for users of older versions of
POV-ray?"

But I just ran my own simple image_map test in v3.7.0 and without the preceding
file prefix, and it does work there as well. I had forgotten about this
simplification myself.

I wonder if the same trick has *always* been the case? In v3.6? 3.5? As far back
as I can recall, the documentation has always(?) specified that the prefix was
required.  But wait: The docs that I downloaded (separately) for v3.8xx indicate
that the prefix IS optional:

3.6.2.6.1 Specifying an Image Map--
[BITMAP_TYPE] "filename" [gamma GAMMA] [premultiplied BOOL]
     [IMAGE_MAP_MODS...]

So I guess it has always been that way. I should re-read the docs now and then!

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
>
> >  #if(Bs="tga") tga File #end
> >  #if(Bs="bmp") bmp File #end
> >  #if(Bs="pgm") pgm File #end
> >  #if(Bs="png") png File #end
> >  #if(Bs="ppm") ppm File #end
> >  #if(Bs="jpg") jpeg File  #end
> >  #if(Bs="exr") exr File #end
> >  #if(Bs="hdr") hdr File #end
> >  #if(Bs="gif") gif File #end
> >  #if(Bs="iff") iff File #end
> >  #if(Bs="tif") tiff File  #end
>
> AFAIK, you don't need any of this stuff any more, because POV-Ray automatically
> determines the file type, and so those keywords can be omitted.

I do! my version 3.7.0.RC7.mevc10.sse.win323.7 will let you do this

plane{z,0 pigment{image_map{"Uimage.tga"}} finish{ambient 1}}

but not this :

#declare I_File="Uimage.pgm";

plane{z,0 pigment{image_map{I_File}} finish{ambient 1}}
             OR
#declare PigM=function{pigment{image_map{I_File once}}}
             OR
#declare PigM=function{pigment{image_pattern{I_File}}}

I'm comparing function to image_map height_fields. I needed the macro so I would
have to rewrite the file I'm using for each height_field.

My version 3.7 for my 64bit running on win10 Acts the same.

I can write the file string directly into both of the functions above, But I was
trying  not to do that.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> > "Leroy" <whe### [at] gmailcom> wrote:
> >
> > >  #if(Bs="tga") tga File #end
> > > [snip]
> > >  #if(Bs="tif") tiff File  #end
> >
> > AFAIK, you don't need any of this stuff any more, because POV-Ray automatically
> > determines the file type, and so those keywords can be omitted.
> >
> I was just about to say, "But what about for users of older versions of
> POV-ray?"
>
> But I just ran my own simple image_map test in v3.7.0 and without the preceding
> file prefix, and it does work there as well. I had forgotten about this
> simplification myself.
>
> I wonder if the same trick has *always* been the case? In v3.6? 3.5? As far back
> as I can recall, the documentation has always(?) specified that the prefix was
> required.  But wait: The docs that I downloaded (separately) for v3.8xx indicate
> that the prefix IS optional:
>
> 3.6.2.6.1 Specifying an Image Map--
> [BITMAP_TYPE] "filename" [gamma GAMMA] [premultiplied BOOL]
>      [IMAGE_MAP_MODS...]
>
> So I guess it has always been that way. I should re-read the docs now and then!

I just found this in my docs...

3.4.7.6.1 Specifying an Image Map
IMAGE_MAP:
  pigment {
    image_map {
      [BITMAP_TYPE] "bitmap[.ext]" [gamma GAMMA] [premultiplied BOOL]
 If the BITMAP_TYPE is not given, the same type is expected as the type set for
output.
I think this might be wrong. I think it should be '.ext' it's talking about.
What we(I) have to do is test it.

Have Fun!

Post a reply to this message

On 3/6/23 18:36, Leroy wrote:
>> AFAIK, you don't need any of this stuff any more, because POV-Ray automatically
>> determines the file type, and so those keywords can be omitted.
> I do! my version 3.7.0.RC7.mevc10.sse.win323.7 will let you do this
> 
> plane{z,0 pigment{image_map{"Uimage.tga"}} finish{ambient 1}}
> 
> but not this :
> 
> #declare I_File="Uimage.pgm";
> 
> plane{z,0 pigment{image_map{I_File}} finish{ambient 1}}

Yes, this one of the changes v3.7 to v3.8. Christoph made updates so 
more often POV-Ray can find and digest the input image file without an 
explicit type.

It remains true, you do occasionally need to specify the file type in 
both versions depending upon run time options and the image file naming.

To re-fresh my own memory of the status in both versions(a), I created 
the attached test scene.

Bill P.

(a) - The v4.0 master branch on github currently matches v3.8 beta 2.

Post a reply to this message

Attachments:
Download 'v37_vs_v38_imagefilereadtests.pov.txt' (3 KB)

"Leroy" <whe### [at] gmailcom> wrote:
>
> I just found this in my docs...
>
> 3.4.7.6.1 Specifying an Image Map
> IMAGE_MAP:
>   pigment {
>     image_map {
>       [BITMAP_TYPE] "bitmap[.ext]" [gamma GAMMA] [premultiplied BOOL]
>  If the BITMAP_TYPE is not given, the same type is expected as the type
>  set for output.

For my previous test, I glanced over that last sentence but didn't pay
attention.

So I ran a bunch more simple tests in official v3.8.0 beta 1, with various
image_map and file-type suffixes, and intentionally mis-matched my render-file
output type-- JPEG image_map vs. Output_File_Type=N, etc. The tests all ran OK,
so it seems that the last sentence is no longer a requirement in v3.8xx.

But about the original macro here: I still cannot get it to run, despite
fiddling with various parts. I don't know if the following experiment is
helpful, but for the very beginning of the code, I added a few things to see
what would happen:

#macro Image(File)
 #local L=strlen(File);
 #debug concat("\n","L = ",str(L,0,3),"\n")
 #error
....
#end

Then, same as before...
#declare FileStr= "test image for hf png.png"
height_field{Image(Filestr)}

I half-way expected to at least get a #debug output for L=strlen(File), then a
halt to the whole process-- but no #debug message shows up, just the previous
error of "Cannot pass unitialized identifier as macro parameter..."

Leroy, does your macro *as written in this newsgroup thread* run OK on your own
system? (with the minor fix of the added parentheses, that is)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> But about the original macro here: I still cannot get it to run, despite
> fiddling with various parts. I don't know if the following experiment is
> helpful, but for the very beginning of the code, I added a few things to see
> what would happen:
>
> #macro Image(File)
>  #local L=strlen(File);
>  #debug concat("\n","L = ",str(L,0,3),"\n")
>  #error
> ....
> #end
>
> Then, same as before...
> #declare FileStr= "test image for hf png.png"
> height_field{Image(Filestr)}
>
> I half-way expected to at least get a #debug output for L=strlen(File), then a
> halt to the whole process-- but no #debug message shows up, just the previous
> error of "Cannot pass unitialized identifier as macro parameter..."
>

The secrete here is the error line

 Cannot pass unitialized identifier as macro ''parameter''...

The only macro parameter we have here is 'Filestr' ie.. Image(Filestr) FileStr
is what you declare earlier. Notice the capital S. 'Filestr' doesn't exists.
That's the only problem I see.

But I did go over the Image macro with a fine tooth comb. And found some things
that could work better. I added the "pot" image type. And put an error if no
image type was found.
 While combing I found that Image("file.ppm") works fine.

> Leroy, does your macro *as written in this newsgroup thread* run OK on your own
> system? (with the minor fix of the added parentheses, that is)

The macro runs fine on my pov 3.7 winXP. I usually don't #include a file with a
single macro on it, I copy the macro and paste it in the project I'm working on.
I've used that macro roughly 80 times on the current project. I copied it from
there and put it here. It should work fine. The examples not so much...

Have Fun!

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > But about the original macro here: I still cannot get it to run...
>
> The secrete here is the error line
>
>  Cannot pass unitialized identifier as macro ''parameter''...
>
> The only macro parameter we have here is 'Filestr' ie.. Image(Filestr) FileStr
> is what you declare earlier. Notice the capital S. 'Filestr' doesn't exists.
> That's the only problem I see.
>
Aha! I didn't even notice that mis-matched capital S; I was looking for a deeper
and more obscure problem, ha. It runs fine now. Thanks.

But take a look at your posted code at the beginning of the thread:

>
> How to use:
>
> #declare FileStr="Image.tga"
>
> height_field{Image(Filestr} ...

Oops! ;-)

Post a reply to this message

My bad!

Post a reply to this message

"Leroy" <whe### [at] gmailcom> wrote:
> My bad!
Sorry for the short short comment. I did it from my cell phone and you know I
got a call in the middle of it.
 I was careful with copying the macro and placing the examples then I changed to
'FileStr' from the 'I_file' it was named. Though it would read better. Then I
made the dumb mistake (I make this kind too often). When you said you had a
problem I was like you I and looked at the macro not the examples until the very
last.

Getting someone to understand something is harder than doing it yourself!

Have fun!

Post a reply to this message