The various output image formats that are currently supported all require
POV-Ray to throw away information; not only in reducing color channel
components from floats to 16- or 8-bit integers, but also in clamping the
components to the [0, 1] range.

MegaPOV supports an RGBE/.hdr output format, and while that avoids the
clamping, it still entails a loss of precision so that each pixel can be
stuffed into four bytes.

So, given that POV-Ray already bundles libtiff and supports TIFF image maps,
I am wondering why TIFF is not supported as an output format---specifically
in its floating-point form, as that covers ground that the other formats
can't handle, and so would not be redundant.

This would, of course, be a boon for HDR rendering, and I could imagine it
being useful in scientific/research contexts. It matches POV-Ray's internal
pixel format (array of COLOUR -> COLC[5] -> float[5], er, maybe toss one
channel), so you don't lose any information when using it.

I'd like to ask if there are any points against this, and if not, then if a
patch to enable fp-TIFF output would be of interest. Much of it would track
the HDR patch for MegaPOV (e.g. disabling color clipping when this format is
chosen), and most of the new code would be in source/tiff_pov.cpp.

Post a reply to this message

Daniel Richard G. wrote:
> So, given that POV-Ray already bundles libtiff and supports TIFF image maps,
> I am wondering why TIFF is not supported as an output format---specifically
> in its floating-point form, as that covers ground that the other formats
> can't handle, and so would not be redundant.

Primarily because libtiff is of frighteningly poor quality in many aspects
of anything but the most common TIFF features. Even those features supported
well are relatively hard to use compared to other image support libraries.
Not to mention, getting libtiff to compile is an adventure of its own ;-)

You are welcome to create such an export feature, but I just wonder,and I am
not sure you have asked or answered that question yourself: Which programs
(other than POV-Ray itself probably once you added it) actually support
import at any significant degree so that it would be useful? _ I honestly
know none that can internally use full float colors right now.

And, btw, are there more or fewer programs supporting the HDR formats
supported by POV-Ray 3.7 already? - I know a few, and my personal guess is
there is a way to convert from float TIFF to most HDR formats, but I just
don't know if there would be any benefit...

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
>
> Primarily because libtiff is of frighteningly poor quality in many aspects
> of anything but the most common TIFF features. Even those features supported
> well are relatively hard to use compared to other image support libraries.
> Not to mention, getting libtiff to compile is an adventure of its own ;-)

I'd like to think the library's been beaten into submission by this point,
but yeah, TIFF as a format can be pretty baroque.

> You are welcome to create such an export feature, but I just wonder,and I am
> not sure you have asked or answered that question yourself: Which programs
> (other than POV-Ray itself probably once you added it) actually support
> import at any significant degree so that it would be useful? _ I honestly
> know none that can internally use full float colors right now.

I'm not a PhotoShop user, but since you didn't mention it, I guess that
one's out. Krita (from the KDE koffice suite) can edit in float space, and
I wouldn't put it past many of the upstart shareware image-editing programs
that are out there.

Since I'm planning on using a mostly-custom toolchain, app support isn't too
big a deal for me. I just want to be able to get the data out of POV-Ray in
a [somewhat] standardized format.

> And, btw, are there more or fewer programs supporting the HDR formats
> supported by POV-Ray 3.7 already? - I know a few, and my personal guess is
> there is a way to convert from float TIFF to most HDR formats, but I just
> don't know if there would be any benefit...

Huh. I wasn't aware that the beta supported RGBE and OpenEXR---I'd looked at
the documentation (sec. 3.1.2.4.1 "Output File Type"), not the ChangeLog.

Okay, if you're putting in EXR support, then that pretty much ends the
discussion :-)  OpenEXR makes so much more sense; I just didn't want to
deal with pulling in another third-party library. I have a couple
questions:

1) Will POV-Ray 3.7 support writing EXR with 32-bit floats, in addition to
16-bit halfs?

2) How do you select EXR output in the beta? I thought the bundled
documentation would have been updated to mention this; is there somewhere
else I should be looking?

3) Out of curiosity, is there any value in writing out all five of POV-Ray's
color channels, using EXR's arbitrary-layer support?

Post a reply to this message

Daniel Richard G. wrote:
> I'd like to think the library's been beaten into submission by this point,
> but yeah, TIFF as a format can be pretty baroque.

We had hoped so, too :-(

> Huh. I wasn't aware that the beta supported RGBE and OpenEXR---I'd looked at
> the documentation (sec. 3.1.2.4.1 "Output File Type"), not the ChangeLog.

The documentation hasn't really been updated.

> Okay, if you're putting in EXR support, then that pretty much ends the
> discussion :-)  OpenEXR makes so much more sense;

Yes :-)

> 1) Will POV-Ray 3.7 support writing EXR with 32-bit floats, in addition to
> 16-bit halfs?

We have full EXR support linked in, but I have to admit I haven't actually
developed that code, nor used it myself. I think currently it cannot be
controlled what is written to the output file - I think the default is used,
but I don't know what the defaults are.

> 2) How do you select EXR output in the beta? I thought the bundled
> documentation would have been updated to mention this; is there somewhere
> else I should be looking?

The new image format letter codes are E and H respectively.

> 3) Out of curiosity, is there any value in writing out all five of POV-Ray's
> color channels, using EXR's arbitrary-layer support?

I don't think so ... RGBA should contain all useful information. The
difference of filter and transmit is primarily useful internally when
rendering. Of course, it really depends if you want any "special effects".
Certainly someone could come up with an imaginative way to use such a
feature, be it useful or not ;-)

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
>
> The documentation hasn't really been updated.

Okay, well... you can see the downsides of that ;-)

> > 1) Will POV-Ray 3.7 support writing EXR with 32-bit floats, in addition to
> > 16-bit halfs?
>
> We have full EXR support linked in, but I have to admit I haven't actually
> developed that code, nor used it myself. I think currently it cannot be
> controlled what is written to the output file - I think the default is used,
> but I don't know what the defaults are.

I'd guess that 16-bit halfs would be the preferred default, given that the
format was practically developed to support that (it's what ILM uses for
production work). I would really like to see 32-bit float support in there,
however, available from a +FHn modifier.

> > 2) How do you select EXR output in the beta? I thought the bundled
> > documentation would have been updated to mention this; is there somewhere
> > else I should be looking?
>
> The new image format letter codes are E and H respectively.

+FE = RGBE, +FH = EXR, then. Huh, conflict with MegaPOV there, but I like
that EXR gets to use the letter H.

> > 3) Out of curiosity, is there any value in writing out all five of POV-Ray's
> > color channels, using EXR's arbitrary-layer support?
>
> I don't think so ... RGBA should contain all useful information. The
> difference of filter and transmit is primarily useful internally when
> rendering. Of course, it really depends if you want any "special effects".
> Certainly someone could come up with an imaginative way to use such a
> feature, be it useful or not ;-)

That's more or less what I thought. Having the output capture the full pixel
information would be a classy touch, just to keep the door open to
potentially clever uses.

Kind thanks for the information! Like so many others, I eagerly await the
production release of 3.7.

Post a reply to this message

Daniel Richard G. wrote:
>> The new image format letter codes are E and H respectively.
> 
> +FE = RGBE, +FH = EXR, then. 

No, it is E = EXR and H = HDR

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Daniel Richard G. wrote:
> >> The new image format letter codes are E and H respectively.
> >
> > +FE = RGBE, +FH = EXR, then.
>
> No, it is E = EXR and H = HDR

Ah, understood. I got tripped up by "respectively."

Post a reply to this message

Daniel Richard G. wrote:
> 
> I'd like to ask if there are any points against this, and if not, then if a
> patch to enable fp-TIFF output would be of interest. Much of it would track
> the HDR patch for MegaPOV (e.g. disabling color clipping when this format is
> chosen), and most of the new code would be in source/tiff_pov.cpp.

Tiff support is indeed something that could use improvements very well - 
not only as far as the 32 bit float variant is concerned - 16 bit 
integer is currently not supported either (although it is trivial to 
convert from PNG of course) - just like grayscale variants i think. 
This is of course not only meant for the output but also for input 
(while more than 16 bit is rarely necessary there it can be convenient). 
  Of course for reading the endless number of tiff variants that exist 
makes it quite difficult.

If anyone is turned off by the libtiff ugliness - CImg 
(http://cimg.sourceforge.net/) recently got a libtiff interface which 
could provide useful hints when implementing such a feature.

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
>
> Tiff support is indeed something that could use improvements very well -
> not only as far as the 32 bit float variant is concerned - 16 bit
> integer is currently not supported either (although it is trivial to
> convert from PNG of course) - just like grayscale variants i think.
> This is of course not only meant for the output but also for input
> (while more than 16 bit is rarely necessary there it can be convenient).
>   Of course for reading the endless number of tiff variants that exist
> makes it quite difficult.

After seeing OpenEXR in there, I'm almost wondering if TIFF input support
isn't a bit of a third leg, especially given the library compilation
issues. Is there anything TIFF can do, that the other supported formats
can't do better and in a more standardized form---at least for the set of
features that POV-Ray can use?

It seems to me that one could realistically discuss deprecating (and
eventually dropping) TIFF support from POV-Ray, to move away from what has
always been a problematic format (and library). Image map files could be
converted to another form without any loss in the process. Of course,
backward compatibility with old scenes would be an issue, and I'm not aware
of what the policy is on this beyond the #version source-compatibility
directive.

Post a reply to this message

Daniel Richard G. wrote:
> [...]
> 
> It seems to me that one could realistically discuss deprecating (and
> eventually dropping) TIFF support from POV-Ray, to move away from what has
> always been a problematic format (and library). Image map files could be
> converted to another form without any loss in the process.

Well - that's true for most of the formats supported.  The variety of 
formats that can be used is mostly a convenience.

Note that image files (for reading) can be used in POV-Ray for different 
things than image maps.  For some of them Tiff is a common format but 
OpenEXR is not.

Christoph

-- 
Views of the Earth: http://earth.imagico.de/
Images, include files, tutorials: http://www.imagico.de/
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message