POV-Ray

I'd advocate a few more metadata items in addition:

• creation date/time
• render time
• maybe system information

As this metadata would increase file size, which a user may prefer to cut down on, and also disclose information the user may not want disclosed, the generation of this metadata should be governed by a command-line / INI-file switch, defaulting to "off".

For PNG images, the information should probably go in tEXt (or iTXt) chunks, using the following keywords:

• "Software": "POV-Ray" followed by the version number (and possibly compiler/architecture information as shown at startup)
• "Creation Time": current date/time of image output * "Source":
• "Source": Hardware on which the render was performed (if such information is available)
• (TBD): "Wall-clock" render time

It might also be interesting to get inside the image the whole set of options used to generate the image (such as AA, MB, and other renders settings)
Can be omitted : Library paths, input & output path, ini file, io-restrictions...
Purpose: being able to separate the draft render from the final one (is it AA=0.01 or just AA=0.3 ?). And eventually to replay it. Paths are not portable across systems/computers, so no need to provide that informations

Regarding the hardware & wall-clock: i do not find them useful. You cannot know if povray was not sharing the CPU with another big cruncher. And extracting hardware information might be non-portable & painful.
(Additionaly, what about a fake inside a Virtual Machine ? might turns out as a "proof" of very bad performance for povray. Not the kind of publicity one might wants.)

Preliminary test for png: creation time is done automatically as create-date, as well as modify-date
Of usable keywords (as registered, but specification seems open), Software & Comment are usable.
Software can get PACKAGE_STRING directly, Comment could be multiline.

For compatibility issue with libpng 1.2, I would recommend to AVOID iTXT (unless writing a smart #ifdef'ed code), even if it cost us to stay in ascii instead of utf-8.

In png.cpp :

static png_text p_text[]= {
{-1,"Software",PACKAGE_STRING,0},
{-1,"Comment", DISTRIBUTION_MESSAGE_2 "\n"
BUILT_FOR "\n"
 COMPILER_VER "\n"
 CXXFLAGS 
,0}
};
static int num_text =sizeof(p_text)/sizeof(png_text);
static png_textp text_ptr=&p_text[0];

End of the write function:

  if (messages.error.length() > 0)
    throw messages.error.c_str();

  for(int j=num_text;j;j--)
  {
     text_ptr[j-1].text_length=strlen(text_ptr[j-1].text);
  }
  png_set_text(png_ptr, info_ptr, text_ptr, num_text);
  png_write_end(png_ptr, info_ptr);
  png_destroy_write_struct(&png_ptr, &info_ptr);
}

More requests in  FS#134 

Would also like an option (disableable) to render some of this info onto the image itself.

"It might also be interesting to get inside the image the whole set of options used to generate the image"

Great idea!

For information, I made a summary of the possible image file format & metadata supports (at least the ones supported by povray)

There is no way for BMP (+FS window) to have metadata.
Other formats allow metadata, in one form or another.

It might be time to focus on the content we want inside the metadata.

(investigating hdr: there is already a line
SOFTWARE=Persistence of Vision Raytracer v3.7.0.beta.38
)

   Metadata.png (14.7 KiB)

After deeper analysis off the various supported file output, here come my proposal (code to be provided if nobody objects whenever I get the energy and time... as for weddings, speak now or remain silent...)
(well, until I actually code something, you have plenty of time... and code can be rejected too)

1. BMP won't get any (there is no room for that)

Metadata would consist of, only in ASCII (low range, 32-126):

• Software name, up to 40 bytes
• Software version, as a short (with major as short/100, minor short%100) and a letter. (a string presentation might be substituted according to the output format, but the information is basically "XX.YY c"
• Date & Time of creation (from local clock, from year on 4 digits to second)
• 4 consecutive lines of up to 80 bytes each (what you want in these lines is still opened to discussion)

Mandatory evolution of file format: Targa must evolve from version 1 to version 2 (adding a 26 bytes footer, and a 498 bytes extension area)

Rational for this proposal:

• Jpeg will get all the metadata in marker JPEG_COM, as one string (support upto 65535 bytes), with local line feed to separate the metadata and label inside the text to introduce each pieces of information.
• Exif is NOT used for Jpeg (it's far too complex: marker APP1 must be right after SOI marker, and then a lot of structures must be pushed to provide mainly numeric-only data that are unavailable from a raytracer)
• PNG: Sofware & Version (as text) get into Software key, Date & time are automatically done by the libpng, remaining goes in the Comment key (as concatenation with line feed)
• PPM: Everything is dumped as many comment lines (# ), introduced with label similar to the jpeg one; Max length of a line is 1024
• Openexr : Everything goes into the header, the version is textual: Comments, Software, Date & Time
• hdr (Radiance .pic format in fact) : SOFTWARE= is already present (might be updated), multiples lines of COMMENT= should be ok, DATE= & TIME= also (the header is ended by an empty line)
• targa (compressed or not): In version 1, metadata is way too short, only the ID area could be used (but its purpose is to identify the picture, not its making, and it's ascii and at most 255 bytes). Version 2 provides the Extension area, which gives a lot of fields.

The stronger constraint come from the targa fields: they are fixed size, with mandatory 0 at fixed places, and padding with nulls or spaces is required when not meaningful.
It's where the 40 & 80 limits (as well as 4 lines) come from.
There is a possibility to put in targa a developper area, but we better do not. (it won't be accessible from other programs)

There is other fields in targa Extension area, but mapping them into png seems a bit gross (in fact, short of Software & Comment, the standardisation for png's keys is an enigma).
If you have a particular battle-horse field from Targa you want as metadata, please suggest the PNG mapping (as other files format would just have "some text")

Please notice, the proposal is for 4 lines of 80 chars, it is not exactly the same as 320 chars.

Final note: we have an issue with the version numbering, at least for beta... how can it be solved ?

Specification of Targa (1991)

Despite my attachment to it (targa being the main format we used back in the old days of POV), I am not sure if it even really matters if we don't add metadata to the TGA output. I really don't think many people will use it anymore, and if it's forcing constraints onto the other image metadata, then we could just leave metadata support for it out.

Don't worry for targa... it now write version 2 file (and hopefully, I got the right gamma value)

Here come a tar of updated files (+one new include) to have metadata in all but one output file format (the missing one is BMP, which does not allow them).
hdr, jpeg, openexr, png, ppm & targa.
The files go in source/base/image

The content of meta data is defined in metadata.h (a class that I'm not very happy with, the constructor is worthless, all functions are statics)
The Version field in targa is not used, the software identification string contains it.

You get Software, 4 comment lines (which are truncated to 80 only for targa) and the current time (when writing the file).
Feel free to change the customisation to the data you want as metadata.
(but keep each comment to less than 1000 char or you will need to protect ppm)

Have a nice day.

   meta.tar.bz2 (24.2 KiB)

change #5166 (#5163 + #5165) have been provided.

Should be tested in beta 40

The windows version is generating a meta information about the rendering date which seems bogus:
it reports the local wall clock as Zulu (UTC/GMT), whatever your timezone!

For instance, I rendered at around 14:00 (my timezone is France, GMT-1 in winter, GMT-2 in summer)
and I get a picture with the following metadata (only copying the Render Date):

Render Date: 2010-12-09 14:00:09Z

I would have expected
Render Date: 2010-12-09 13:00:09Z
or
Render Date: 2010-12-09 14:00:09+0100
or
Render Date: 2010-12-09 14:00:09+01:00

(I'm only one hour off... but Australia has a bigger shift)

I have not yet checked for Unix from sources.

Oops, yes - I messed that up with change #5210. Will fix.

PNG tIME chunk was broken, too (using local time instead of GMT as per file format spec).
Fixed with #5251.

Tested with beta 41.

Render Date: 2010-12-30 10:14:38Z

For a picture rendered at 11:14 local time, gmt+1, so it's ok.