Knowledgebase:Files and formats

Topic 1

I have rendered an image with POV-Ray, but how do I save it to JPG or GIF or any other image format?

This is a typical problem of people using the Windows version of the program for first time.

POV-Ray is a raytracer which has only one purpose: To read a source file describing the scene to raytrace and then calculate it and save it to disk in a supported image format, usually TGA (and optionally PNG, BMP, etc).

POV-Ray has always had this goal, and still has, and will (desirably) never change. It's mostly command-line oriented. It supports non-essential things, like showing the image while it's rendering.

A GUI doesn't change anything. POV-Ray is still POV-Ray, with or without GUI. It takes a source code and calculates the image and saves it to disk. By default it shows the image while it's raytracing it, but that's just a secondary feature, non-essential, irrelevant. It can be turned off and POV-Ray will still make its job.

So the answer to the question is: The image is already saved on disk.

Usually it's saved in TGA or BMP format (it depends on the settings) with the same name as the source code (so if the source is named CHAIR.POV, the image will be named CHAIR.TGA or CHAIR.BMP or whatever). The location is either the same directory where the .pov-file is or else a common directory for images (which you can set up in the main povray.ini file).

End of Topic: Go Back to the Table of Contents

Topic 2

Can I convert my POV-Ray scenes to another format?

(Answer by Johannes Hubert)

For POV-Ray 2.2: Try Crossroads or if you want to convert to Moray MDL files, try POV2MDL from Thomas Baier.

For POV-Ray 3.1 and newer: There is unfortunately not much you can do. There is no real versatile program yet, that can read (and convert) POV-Ray 3.1 scripts (except for POV-Ray itself :-). Your best shots would be: POV2RIB if you want to convert to the RIB format. If you know how to program C++, you can get the ParPov C++ library from the same URL. It is a class-library for reading POV 3.1 scripts and converting them to C++ objects (it also has been used for POV2RIB).

3DWin from Thomas Baier (see the URL above) converts from the POB format to a lot of other formats. POB is a special binary POV-Ray format devised by Thomas and is written by a custom-compile version of POV-Ray 3.0 (get the POB-SDK at the same URL): This POV-Ray version reads POV-scripts and outputs POB files, which can then be converted by 3DWin. The drawback: Although all objects, textures etc. of the scene are in the POB file, they are not all recognized by 3DWin. Only triangles and meshes of triangles are recognized. Everything else in the scene is lost....

End of Topic: Go Back to the Table of Contents

Topic 3

How can I convert my scenes from format X to POV-Ray format?

You can try Crossroads by Keith Rule and 3DWin by Thomas Baier.

End of Topic: Go Back to the Table of Contents

Topic 4

How do I import all of my textures I created in 3DS Max into POV-Ray?

As POV-Ray 3.5 supports UV-mapping, textured objects used by renderers such as 3D-Studio can be used by first converting them with a proper converter. You can find a list of converters and other related software on the POV-Ray Links page.

End of Topic: Go Back to the Table of Contents

Topic 5

How can I avoid artifacts and still get good JPEG compression?

(Answer by Peter J. Holzer)

First, you have to know a little bit about how a picture is stored in JPEG format.

Unlike most image formats it doesn't store RGB values, but YUV values (1 grayscale value and two color difference values) just like they are used in a color TV signal. Since the human eye uses mostly the gray values to detect edges, one can usually get away with storing the color information at a lower resolution - an 800x600 JPEG typically has only grayscale information at 800x600, but color information at 400x300. This is called supersampling.

For each color channel separately, the picture is then divided into little squares and the cosine transform of each square is computed. A neat feature of this transformation is that if you throw away only a few of the values, the quality will degrade very little, but the image will compress a lot better. The percentage of values stored is called the quality.

Finally, the data is compressed.

Most programs only let you change the quality setting. This is fine for photos and photorealistic renderings of natural scenes. Generally, quality values around 75% give be best compromise between quality and image size.

However, for images which contain very saturated colors, the lower resolution of the color channels causes visible artifacts which are very similar to those caused by low quality settings. They can be minimized by setting an extremely high quality (close to 100%), but this will dramatically increase the file size, and often the artifacts are still visible.

A better method is to turn off supersampling. The higher resolution will cause only a modest increase in file size, which is more than offset by the ability to use a lower quality setting.

The cjpeg command line utility (which should be available for all systems which have a command line, e.g., Linux, MS-DOS, Unix, ...) has a -sample to set the sampling factors for all passes.

        cjpeg -sample 1x1,1x1,1x1 -quality 75 -optimize

should be good default values which have to be changed only rarely.

End of Topic: Go Back to the Table of Contents

Topic 6

Why are there so many converters from other 3D file formats to POV, but practically no converters from POV to other formats?

It's a mistake to think that a POV-Ray file is just the same kind of data file as in most other renderers.

The file format of most renderers is just a data file containing numerical values (vertex coordinates, triangle indices, textures, uv-coordinates, NURBS data...) describing the scene. They usually are very little more than just numerical data containers.

However, POV-Ray files are much more than just data files. POV-Ray files are actually source code of the POV-Ray scripting language. The POV-Ray scripting language is by many means a full programming language (it's Turing-strong). It contains many features typical to programming languages and non-typical to data files (such as variables, loops, mathematical functions, macros, etc). It has many features to describe things in a much more abstract way than just plain numbers.

This is why converting a POV-file to a data file readable by other renderers is so difficult. The converter program would actually have to execute, that is, interpret the scripting language (in the exact same way as a BASIC or Perl source code is interpreted). Making a scripting language interpreter is a much more laborious job than just converting numerical data from one format to another.

There's also another problem: POV-Ray describes most of its objects as mathematical entities while most of other renderers just handle triangles (or NURBS or similar easily tesselable primitives). A converter would have to make some tesselation in order to convert most POV-Ray primitives to other formats. This can be a quite laborious job for a converter to make (it would have to practically implement an almost fully-qualified POV-Ray renderer).

This is why making a full-featured converter from any POV-file to any other format is an almost impossible task.

End of Topic: Go Back to the Table of Contents

Topic 7

Why are triangle meshes in ASCII format? They are huge! A binary format would be a lot smaller. If POV-Ray can read binary images, why couldn't it read binary mesh data?

It's not as simple as you may think.

You can't compare binary mesh data with image files. Yes, images are binary data, but there is one big difference: Image files use integer numbers (usually bytes, in some cases 16-bit integers), which can be easily read in any system.

However, meshes use floating point numbers.

It might come as a bit of surprise that it's far from easy to represent them in binary format so that they can be read in every possible system.

It's very important to keep in mind that POV-Ray is intended to be a very portable program, which should be compilable in virtually any system with a decent C compiler. This is not just mumbo-jumbo; POV-Ray IS used in a wide variety of operating systems and computer architectures, including Windows, MacOS, Linux, (Sparc) Solaris, Digital Unix and so on.

The internal representation of floating point numbers may differ in number of bits and bits reserved for each part of the number inside the data type in different systems. There's also the infamous big-endian/low-endian problem (that is, although the floating point numbers were identical in two different systems, they may be written in different byte-order when writing to a file).

If you try to make carelessly a patch which reads and writes floating point numbers in binary format, you'll probably quickly find that your patch only works in a certain architecture only (eg. PC) and not others.

In order to store floating point numbers so that they can be read in any system, you have to store them in an universal format. ASCII is as good as any other.

However, you are not completely out of luck when dealing with compressing mesh data. This has been done before. For example check:

http://www.geocities.com/ccolefax/pcm.html

POV-Ray 3.5 supports a new type of mesh (called mesh2) which stores the mesh data in a more compact format (similar to the one used in the PCM format described in the abovementioned link, but with a bit more syntax around it).

End of Section: Go Back to the Table of Contents