On Fri, 03 Sep 2004 14:57:00 +0200, Christoph Hormann  
<chr### [at] gmxde> wrote:
> Fredrik Eriksson wrote:
>>  I now have a few questions for the POV community:
>>  - Is support for 32-bits per component floating point output desired?
>> It wouldn't take much effort to do, but I doubt it's needed/useful.
>
> That would be great if you would implement it in a portable way (i.e.  
> allowing exchange of files between different endiannesses and between  
> IEEE and non-IEEE floating point systems.  This is possible but not  
> trivial.


I'm using the OpenEXR library, so it's portable to any system that's  
portable to. If all I wanted was to output "raw" FP data, I could have  
used the code I posted in this forum on the 25th. I want the extra  
features of OpenEXR however.
Currently I'm using the 16-bit "half" output format, but OpenEXR supports  
32-bit float as well.

 From the OpenEXR website:
"OpenEXR has been ported to GNU/Linux, OS X 10.2, Win32, and IRIX. It  
should be fairly easy to port to other UNIX-like operating systems."


The header 'half.h' contains this text:

//	The implementation of type half makes the following assumptions
//	about the implementation of the built-in C++ types:
//
//	    float is an IEEE 754 single-precision number
//	    sizeof (float) == 4
//	    sizeof (unsigned int) == sizeof (float)
//	    alignof (unsigned int) == alignof (float)
//	    sizeof (unsigned short) == 2


I'm going to have a look to see if I can loosen those restrictions. I'll  
also try to see if there are any other restrictions, either implicit or  
stated elsewhere.
Hopefully, I'll be able to change those restrictions to something like:
- float has a range comparable to, or greater than, that of the IEEE-754  
single precision type
- sizeof( unsigned int ) >= 4
- sizeof( unsigned short ) >= 2




On a related note:
Does anyone have a (preferably complete) list of platforms to which  
POV-Ray has been successfully ported?
I am particularly interested in issues such as endianness (or, more  
generally, byte order), the size of primitive data types and alignment  
restrictions.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
>>
>> That would be great if you would implement it in a portable way (i.e.  
>> allowing exchange of files between different endiannesses and between  
>> IEEE and non-IEEE floating point systems.  This is possible but not  
>> trivial.
> 
> I'm using the OpenEXR library, so it's portable to any system that's  
> portable to. If all I wanted was to output "raw" FP data, I could have  
> used the code I posted in this forum on the 25th. I want the extra  
> features of OpenEXR however.
> [...]

I am not talking about OpenEXR support (to me being required to download 
9MB to add support for a new file format is quite out of question).  I 
am talking about plain binary floating point data.  I stopped studying 
your code snippet when i read:

typedef unsigned long uint32;

> On a related note:
> Does anyone have a (preferably complete) list of platforms to which  
> POV-Ray has been successfully ported?

POV-Ray should compile on any platform where a C++ compiler is available 
that supports the current standards.  So for writing portable extensions 
for POV-Ray you should comply with the standard first of all (and if you 
do it will most likely also compile and run on most platforms.

And the typedef cited above is a serious affront to the standard...

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 03 Sep 2004 16:15:05 +0200, Christoph Hormann  
<chr### [at] gmxde> wrote:
> I am not talking about OpenEXR support (to me being required to download  
> 9MB to add support for a new file format is quite out of question).


How is this any different from having to download libjpeg, or libpng?



> I am talking about plain binary floating point data.
> I stopped studying your code snippet when i read:
>
> typedef unsigned long uint32;


If you had read further, you would have seen that the code actually checks  
to see if uint32 really does have the required range. That typedef was not  
supposed to be valid across all platforms; it was meant to be replaced  
with something else on platforms where the assumption does not hold.
The code I posted was not meant as production quality code; it was meant  
as a proof-of-concept. I didn't want to expend time and effort on writing  
the machinery required to select an appropriate type for all reasonable  
and unreasonable platforms when all I wanted was to show the feasibility  
of the implementation.

By the way: Is it possible to compile and run POV-Ray on a platform where  
'long' is less than 32 bits?



> POV-Ray should compile on any platform where a C++ compiler is available  
> that supports the current standards.  So for writing portable extensions  
> for POV-Ray you should comply with the standard first of all (and if you  
> do it will most likely also compile and run on most platforms.


Again: Is POV-Ray portable to platforms where 'long' is less than 32 bits?
For that matter, is POV-Ray portable to platforms where 'int' is less than  
32 bits?

Having seen the POV-Ray source code, I am confident that the answer is  
'no' to both questions.



> And the typedef cited above is a serious affront to the standard...


No, it has implementation-defined behaviour. Even that is irrelevant if  
the range is checked/enforced.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> 
>> I am not talking about OpenEXR support (to me being required to 
>> download  9MB to add support for a new file format is quite out of 
>> question).
> 
> How is this any different from having to download libjpeg, or libpng?

Those libs are very small, so small that they are included in the 
POV-Ray distribution.  And they are much more widely tested.

Don't get me wrong - if support for a new format allows something not 
possible before that's good but i do not yet see this happening.  And 
even if it does the drawbacks are significant.

> 
> By the way: Is it possible to compile and run POV-Ray on a platform 
> where  'long' is less than 32 bits?

AFAIK the standard defines 'long' as at least 32 bit.

> 
>> And the typedef cited above is a serious affront to the standard...
> 
> No, it has implementation-defined behaviour. Even that is irrelevant if  
> the range is checked/enforced.

Then don't name it 'uint32' (which implies being 32 bit).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 03 Sep 2004 17:58:31 +0200, Christoph Hormann  
<chr### [at] gmxde> wrote:
> Fredrik Eriksson wrote:
>>  How is this any different from having to download libjpeg, or libpng?
>
> Those libs are very small, so small that they are included in the  
> POV-Ray distribution.  And they are much more widely tested.


The parts that actually need to be included are only a little over 3 MB,  
on par with the tiff library included in the POV-Ray distribution. The  
archive you can download from the OpenEXR website contains a whole lot of  
other stuff not needed to compile the library.



> Don't get me wrong - if support for a new format allows something not  
> possible before that's good but i do not yet see this happening.  And  
> even if it does the drawbacks are significant.


What other significant drawbacks do you see, other than portability  
concerns?



>>  By the way: Is it possible to compile and run POV-Ray on a platform  
>> where  'long' is less than 32 bits?
>
> AFAIK the standard defines 'long' as at least 32 bit.


As far as *I* know, the standard does not. 'long' must be at least as big  
as 'int', which must be at least as big as 'short', which must be at least  
16 bits. 'int' must also be at least as big as 'char'.
Strictly speaking, the standard does not even guarantee that the  
fundamental types have sizes that are powers of two. Is POV-Ray portable  
to systems where CHAR_BIT == 9?



> Then don't name it 'uint32' (which implies being 32 bit).


Would it have been acceptable to you if I had named it  
'uint_at_least_32_bits'?



-- 
FE

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Hormann wrote:
|>> And the typedef cited above is a serious affront to the standard...
|>
|>
|> No, it has implementation-defined behaviour. Even that is irrelevant
|> if  the range is checked/enforced.
|
|
| Then don't name it 'uint32' (which implies being 32 bit).
|
	You do know that the ISO-C99 standard defines uint32_t for an int
type that's guaranteed to be 32 bits, don't you? It's in the stdint.h
header (see:
http://www.dinkumware.com/manuals/reader.aspx?b=c/&h=stdint.html for
details)

		Jerome
- --
******************************
*      Jerome M. Berger      *
* mailto:jbe### [at] ifrancecom *
*  http://jeberger.free.fr/  *
******************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBOM3aqIYJdJhyixIRAuAzAKCGyd6LHl39FcR96J3iy+BnN6qnfwCfUK7g
1/pUJSC1lz/ckIP339DLZt4=
=fNEy
-----END PGP SIGNATURE-----

Post a reply to this message

<jbe### [at] ifrancecom> wrote:

>  You do know that the ISO-C99 standard

For obvious reasons the ISO C++ 1998 standard cannot be a superset of the
ISO C 1999 standard.  Apart from this, while some ISO C 1999 features are
widely supported already, general support is still incomplete on many
platforms.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

wrote:

> 	You do know that the ISO-C99 standard defines uint32_t for an int
> type that's guaranteed to be 32 bits, don't you? It's in the stdint.h
> header


Unfortunately, that doesn't help much since C++ is based on C90. Some  
C++ compilers provide C99 compatibility as an extension, but then we're  
back at the portability issue.

In this case however, it's a non-problem, since POV-Ray won't work on  
platforms where 'int' is smaller than 32 bits anyway.



-- 
FE

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:

> Well, duh. If an object is 1/10000 of the image's width, then of course it
> should be nearly invisible!

Yeah of course. This is why in reality there are never any stars visible in the 
night-sky ;-)

Lutz-Peter

Post a reply to this message

Christoph Hormann wrote:
> Vincent LE CHEVALIER wrote:
> 
>>
>> Is it possible to have HDR output with 3.6 ? I couldn't find anything 
>> about this in the doc...
> 
> 
> HDR output is supported in MegaPOV 1.1.
> 
> 
> Christoph
> 
Ok ! I'll have a look at it.

-- 
Vincent

Post a reply to this message