POV-Ray : Newsgroups : povray.documentation.inbuilt : BITMAP_TYPE and HF_TYPE documentation versus functionality. Server Time
18 Mar 2024 23:39:15 EDT (-0400)
  BITMAP_TYPE and HF_TYPE documentation versus functionality. (Message 1 to 10 of 11)  
Goto Latest 10 Messages Next 1 Messages >>>
From: William F Pokorny
Subject: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 7 Jan 2018 12:38:49
Message: <5a525b29$1@news.povray.org>
The BITMAP_TYPE nomenclature is used for bump_map, image_map, 
image_pattern and material_map. HF_TYPE is used for height_fields. Over 
time I think the documentation has gotten somewhat scrambled with 
respect to current functionality.

bump_map:
   http://wiki.povray.org/content/Reference:Bump_Map

height_field:
http://wiki.povray.org/content/Reference:Height_Field

image_pattern:
   http://wiki.povray.org/content/Reference:Image_Pattern

image_map:
   http://wiki.povray.org/content/Reference:Image_Map

material_map:
   http://wiki.povray.org/content/Reference:Patterned_Textures#Material_Maps

We sometimes mark BITMAP_TYPE | HF_TYPE as optional when I believe from 
3.7 onward it is everywhere optional.  When specified, this is the file 
type POV-Ray will try and read no matter the filename given or the 
output file type.

Our docs often specify the filename as "bitmap.ext" or "bitmap[.ext]" 
except for height_fields where it is "filename".  I think "filename" is 
best because that string needs to be the filename POV-Ray looks to read 
no matter format.

If the user has not specified an explicit BITMAP_TYPE | HF_TYPE, POV-Ray 
will first look for any known extension in the "filename" string.  If 
found, that extension is the image format POV-Ray will try and read.

Where the filename has no recognizable extension and BITMAP_TYPE | 
HF_TYPE has not been specified, POV-Ray will try and read the "filename" 
as whatever the current output image format is. Only the image_map 
documentation mentions this latter behavior.

There is too in some documentation - material_map for example - this note:

"Note: Earlier versions of POV-Ray allowed some modifiers before the 
BITMAP_TYPE but that syntax is being phased out in favor of the syntax 
described here."

which probably we can drop. At least for the modifiers I tried before 
BITMAP_TYPE, I got parser errors in 3.7 and 3.8.

Bill P.


Post a reply to this message

From: clipka
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 7 Jan 2018 14:21:32
Message: <5a52733c$1@news.povray.org>
Am 07.01.2018 um 18:38 schrieb William F Pokorny:

> We sometimes mark BITMAP_TYPE | HF_TYPE as optional when I believe from
> 3.7 onward it is everywhere optional.  When specified, this is the file
> type POV-Ray will try and read no matter the filename given or the
> output file type.

Both bitmap-based patterns and hight fields do indeed use the same code
to parse, and have essentially the same behaviour with respect to the
~_TYPE field (the difference being that height fields don't accept IFF
files, for reasons that are beyond me, while accepting POT files).

> "Note: Earlier versions of POV-Ray allowed some modifiers before the
> BITMAP_TYPE but that syntax is being phased out in favor of the syntax
> described here."
> 
> which probably we can drop. At least for the modifiers I tried before
> BITMAP_TYPE, I got parser errors in 3.7 and 3.8.

POV-Ray 3.7 and 3.8 still allow the BITMAP_TYPE field (but not the
HF_TYPE field) to be preceded by an arbirtary number of vectors or
numerical values; according to the warning that this will produce, this
was an old syntax for specifying the map_type, as well as apparently the
image map's orientation in space.


Post a reply to this message

From: Kenneth
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 8 Jan 2018 03:10:01
Message: <web.5a5326514e3ec03a47873e10@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

>
> If the user has not specified an explicit BITMAP_TYPE | HF_TYPE, POV-Ray
> will first look for any known extension in the "filename" string.  If
> found, that extension is the image format POV-Ray will try and read.

I didn't know this. (I've never left out the file type, so I never noticed it.)
>
> Where the filename has no recognizable extension and BITMAP_TYPE |
> HF_TYPE has not been specified, POV-Ray will try and read the "filename"
> as whatever the current output image format is. Only the image_map
> documentation mentions this latter behavior.

The only problem I could imagine is if two files have the same name but
different file extensions. I've actually done this with some image files, but
just as tests (.png vs. jpeg versions, for example.) In which case, I suppose
the jpeg file would be chosen... alphabetically? My own opinion is that, by
leaving out any mention of BITMAP_TYPE or HF_TYPE in the docs, new users might
*possibly* run into a problem due to leaving out the file extension-- and not
know why. (I honestly can't think of a problematic file-type example-- other
than the one Clipka mentioned-- but who knows?)

I can also imagine that, in the 'new' scenario, new users who see an 'old' scene
file-- one with "my_image.jpg" in it, for example-- may scratch their heads
about why the file type was included like that-- when the docs no longer mention
it.


[Just playing 'Devil's advocate' here.]


Post a reply to this message

From: Jim Holsenback
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 8 Jan 2018 06:22:30
Message: <5a535476$1@news.povray.org>
On 1/7/2018 12:38 PM, William F Pokorny wrote:
> The BITMAP_TYPE nomenclature is used for bump_map, image_map, 
> image_pattern and material_map. HF_TYPE is used for height_fields. Over 
> time I think the documentation has gotten somewhat scrambled with 
> respect to current functionality.
> 
> bump_map:
>    http://wiki.povray.org/content/Reference:Bump_Map
> 
> height_field:
> http://wiki.povray.org/content/Reference:Height_Field
> 
> image_pattern:
>    http://wiki.povray.org/content/Reference:Image_Pattern
> 
> image_map:
>    http://wiki.povray.org/content/Reference:Image_Map
> 
> material_map:
>    
> http://wiki.povray.org/content/Reference:Patterned_Textures#Material_Maps
> 
> We sometimes mark BITMAP_TYPE | HF_TYPE as optional when I believe from 
> 3.7 onward it is everywhere optional.  When specified, this is the file 
> type POV-Ray will try and read no matter the filename given or the 
> output file type.
> 
> Our docs often specify the filename as "bitmap.ext" or "bitmap[.ext]" 
> except for height_fields where it is "filename".  I think "filename" is 
> best because that string needs to be the filename POV-Ray looks to read 
> no matter format.
> 
> If the user has not specified an explicit BITMAP_TYPE | HF_TYPE, POV-Ray 
> will first look for any known extension in the "filename" string.  If 
> found, that extension is the image format POV-Ray will try and read.
> 
> Where the filename has no recognizable extension and BITMAP_TYPE | 
> HF_TYPE has not been specified, POV-Ray will try and read the "filename" 
> as whatever the current output image format is. Only the image_map 
> documentation mentions this latter behavior.
> 
> There is too in some documentation - material_map for example - this note:
> 
> "Note: Earlier versions of POV-Ray allowed some modifiers before the 
> BITMAP_TYPE but that syntax is being phased out in favor of the syntax 
> described here."
> 
> which probably we can drop. At least for the modifiers I tried before 
> BITMAP_TYPE, I got parser errors in 3.7 and 3.8.

i'll follow up when i have more than a few moments ... which hasn't been 
very often lately


Post a reply to this message

From: clipka
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 8 Jan 2018 11:57:18
Message: <5a53a2ee@news.povray.org>
Am 08.01.2018 um 09:05 schrieb Kenneth:

>> Where the filename has no recognizable extension and BITMAP_TYPE |
>> HF_TYPE has not been specified, POV-Ray will try and read the "filename"
>> as whatever the current output image format is. Only the image_map
>> documentation mentions this latter behavior.
> 
> The only problem I could imagine is if two files have the same name but
> different file extensions.

No, POV-Ray would actually try to load a file of the name /without/ any
file extensions.

On Windows, files virtually always have a file extension, even though
the Windows Explorer is trying to hide them from the user by default.

Windows makes no attempt to hide those file extensions from /programs/
though; to the contrary, a program trying to opening a file by name
/must/ specify the extension.

When you specify a filename without extension in POV-Ray, the program
does this by guessing the extension, based on the file type keyword.

If the file type keyword isn't specified either, POV-Ray is lost, and
can only guess that the user might intend to load a file that has no
extension at all.


Post a reply to this message

From: Kenneth
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 8 Jan 2018 13:15:01
Message: <web.5a53b45c4e3ec03a47873e10@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> My own opinion is that, by
> leaving out any mention of BITMAP_TYPE or HF_TYPE in the docs, new users might
> *possibly* run into a problem due to leaving out the file extension-- and not
> know why.

My apologies; I was confusing BIT_MAP type with the filename extension. I'll
follow up later; I'm currently digging out my car from the snowstorm that hit
the U.S East Coast...


Post a reply to this message

From: Kenneth
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 8 Jan 2018 20:40:01
Message: <web.5a541c494e3ec03a47873e10@news.povray.org>
I wanted to clearly understand all of this behavior (in Windows), so I made an
image_map test-- the four permutations of using (or not using) BITMAP_TYPE and
the image's file extension... along with a chosen Output_File_Type in my
resolution .ini file.

TEST 1 should be with Output_File_Type=N  (to match the .png image used below.)
TEST 2 should be with Output_File_Type=J (or B,P,T etc.-- to purposely mismatch
the input image type.)

RESULTS: TEST 1 works successfuly with all four examples.
         TEST 2 fails on the last example-- a mismatch between image
                type and Output_File_Type.

---------------
#version 3.71;
global_settings {assumed_gamma 1.0 max_trace_level 5}

camera {
  perspective
  location  <.5, .5, -2>
  look_at   <.5, .5,  0>
  right     x*image_width/image_height
  angle 67
}

// Typical use. This *always* works, of course.
box{0, <1,1,.01>
    pigment{image_map{png "MY_IMAGE.png"}}
    scale .5
    }

// BITMAP_TYPE but no file extension.
// This works with both TEST 1 and TEST 2
box{0, <1,1,.01>
    pigment{image_map{png "MY_IMAGE"}}
    scale .5
    translate .5
    }

// No BITMAP_TYPE but with the file extension.
// This works with both TEST 1 and TEST 2
box{0, <1,1,.01>
    pigment{image_map{"MY_IMAGE.png"}}
    scale .5
    translate 1
    }

// No BITMAP_TYPE or file extension.
// This works with TEST 1 but fails with TEST 2.
box{0, <1,1,.01>
    pigment{image_map{"MY_IMAGE"}}
    scale .5
    translate 1.5
    }


Post a reply to this message

From: Jim Holsenback
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 4 Feb 2018 14:45:58
Message: <5a7762f6$1@news.povray.org>
On 1/8/2018 6:22 AM, Jim Holsenback wrote:
> On 1/7/2018 12:38 PM, William F Pokorny wrote:
>> The BITMAP_TYPE nomenclature is used for bump_map, image_map, 
>> image_pattern and material_map. HF_TYPE is used for height_fields. 
>> Over time I think the documentation has gotten somewhat scrambled with 
>> respect to current functionality.
>>
>> bump_map:
>>    http://wiki.povray.org/content/Reference:Bump_Map
>>
>> height_field:
>> http://wiki.povray.org/content/Reference:Height_Field
>>
>> image_pattern:
>>    http://wiki.povray.org/content/Reference:Image_Pattern
>>
>> image_map:
>>    http://wiki.povray.org/content/Reference:Image_Map
>>
>> material_map:
>> http://wiki.povray.org/content/Reference:Patterned_Textures#Material_Maps
>>
>> We sometimes mark BITMAP_TYPE | HF_TYPE as optional when I believe 
>> from 3.7 onward it is everywhere optional.  When specified, this is 
>> the file type POV-Ray will try and read no matter the filename given 
>> or the output file type.
>>
>> Our docs often specify the filename as "bitmap.ext" or "bitmap[.ext]" 
>> except for height_fields where it is "filename".  I think "filename" 
>> is best because that string needs to be the filename POV-Ray looks to 
>> read no matter format.
>>
>> If the user has not specified an explicit BITMAP_TYPE | HF_TYPE, 
>> POV-Ray will first look for any known extension in the "filename" 
>> string.  If found, that extension is the image format POV-Ray will try 
>> and read.
>>
>> Where the filename has no recognizable extension and BITMAP_TYPE | 
>> HF_TYPE has not been specified, POV-Ray will try and read the 
>> "filename" as whatever the current output image format is. Only the 
>> image_map documentation mentions this latter behavior.
>>
>> There is too in some documentation - material_map for example - this 
>> note:
>>
>> "Note: Earlier versions of POV-Ray allowed some modifiers before the 
>> BITMAP_TYPE but that syntax is being phased out in favor of the syntax 
>> described here."
>>
>> which probably we can drop. At least for the modifiers I tried before 
>> BITMAP_TYPE, I got parser errors in 3.7 and 3.8.
> 
> i'll follow up when i have more than a few moments ... which hasn't been 
> very often lately

http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0

click in the "diff" link to see what's been changed


Post a reply to this message

From: William F Pokorny
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 5 Feb 2018 06:44:33
Message: <5a7843a1$1@news.povray.org>
On 02/04/2018 02:45 PM, Jim Holsenback wrote:
> On 1/8/2018 6:22 AM, Jim Holsenback wrote:
>>
>> i'll follow up when i have more than a few moments ... which hasn't 
>> been very often lately
> 
> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0
> 
> click in the "diff" link to see what's been changed

For all but the height_field page - which already has the optional 
indicator brackets around HF_TYPE - we should add braces [] around 
BITMAP_TYPE to indicate those specifications are also optional.

There is also sometimes text which needs to be changed too - or perhaps 
as well deleted. The material_map section for example has:

"After the required BITMAP_TYPE keyword is a string expression 
containing the name of a bitmapped material file of the specified type."

When today BITMAP_TYPE is not required and it is not in fact completely 
necessary to indicate the type by the filename if your input type 
matches POV-Rays current output type. This relates to the hierarchy of 
methods POV-Ray uses to determine the file type to read. I attempted to 
outline what happens. Today we today best describe it all in our 
image_map documentation though the fact BITMAP_TYPE is optional is not 
indicated there-in - as yet.

Not sure repeating POV-Ray's type decision hierarchy in every 'map' 
section is necessary though - perhaps get it right / flush it out in the 
image_map doc with some method to reference it from the others?

Bill P.


Post a reply to this message

From: Jim Holsenback
Subject: Re: BITMAP_TYPE and HF_TYPE documentation versus functionality.
Date: 6 Feb 2018 06:44:04
Message: <5a799504$1@news.povray.org>
On 2/5/2018 6:44 AM, William F Pokorny wrote:
> On 02/04/2018 02:45 PM, Jim Holsenback wrote:
>> On 1/8/2018 6:22 AM, Jim Holsenback wrote:
>>>
>>> i'll follow up when i have more than a few moments ... which hasn't 
>>> been very often lately
>>
>> http://wiki.povray.org/content?title=Special:RecentChanges&hidebots=0
>>
>> click in the "diff" link to see what's been changed
> 
> For all but the height_field page - which already has the optional 
> indicator brackets around HF_TYPE - we should add braces [] around 
> BITMAP_TYPE to indicate those specifications are also optional.

done ...

> 
> There is also sometimes text which needs to be changed too - or perhaps 
> as well deleted. The material_map section for example has:
> 
> "After the required BITMAP_TYPE keyword is a string expression 
> containing the name of a bitmapped material file of the specified type."

changed required to optional

> 
> When today BITMAP_TYPE is not required and it is not in fact completely 
> necessary to indicate the type by the filename if your input type 
> matches POV-Rays current output type. This relates to the hierarchy of 
> methods POV-Ray uses to determine the file type to read. I attempted to 
> outline what happens. Today we today best describe it all in our 
> image_map documentation though the fact BITMAP_TYPE is optional is not 
> indicated there-in - as yet.
> 
> Not sure repeating POV-Ray's type decision hierarchy in every 'map' 
> section is necessary though - perhaps get it right / flush it out in the 
> image_map doc with some method to reference it from the others?
> 
> Bill P.


Post a reply to this message

Goto Latest 10 Messages Next 1 Messages >>>

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