The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Attached to Project: POV-Ray
Opened by Roland Mösl - 2011-12-27
Last edited by William F Pokorny - 2017-01-22

FS#229 - Clock value into EXIF data for PNG

The best time for a picture....

I set the day time and so the position of the sun by “clock=”

Normal I document my source very good, but this time,
I forgot the clock seting for the picture of my book cover.

So I would find it very practicall to put the clock value
and other setings for rendering
into EXIF data of the picture.

Grimbert Jérôme commented on Monday, 02 January 2012, 11:10 GMT


technically, Exif & PNG do not mix.
But I guess the original poster would be satisfied if the required data was to appears in one of the comment lines of the PNG.

From portability point of view (across the various pictures format), povray has up to 4 lines of comments, each up to 80 characters (ASCII, no control characters).
So far 2 lines are used (one for the Platform, another for the compiler).

The true question is: what are the relevant settings that should be selected ?
Remember: limit is 80 ascii characters, and line feed are not allowed, so outputting the relevant ini file is out of scope.

Duplicating the command line might also be an issue: there might be some non ascii characters in it, and it might be longer than 80.

Would a single "clock= <value>" matches all uses ? (half-philosophical question for the original poster and code manager)

Chris Cason commented on Monday, 02 January 2012, 11:39 GMT
Would a single "clock= <value>" matches all uses ? (half-philosophical question for the original poster and code manager)

I can't say if it would match all uses, but it would appear to me that it's better than not having it.

Grimbert Jérôme commented on Tuesday, 03 January 2012, 21:36 GMT

Well,... there might be a good and clean way to do that, but so far, I can only find an ugly one:
frontend/animationprocessing.cpp must communicate with base/image/metadata.h, but I cannot find a reason for them to be aware of each other.

I can only find one solution so far (and I really do not like it), without rewriting the full thing (which sound a bit a headache too): put a global DBL into a dedicated workspace...

declaration in base/configbase.h (maybe not the best place at all)
setting in frontent/animation.cpp (creator of AnimationProcessing & ComputeNextFrame()), directly (ouch!)
definition in base/image/metadata.h, as well as usage.

Why I do not like it: because it implies that the frontend is on the same process (and system) as the one writing the image file.

Your thoughts ?

Grimbert Jérôme commented on Wednesday, 11 January 2012, 22:58 GMT

As I do not dare to commit in smp branch (I do not like my solution, I find it too clumsy), here (attached file) is the relevant patch (based on #5603), should someone wants to try it or make it better.

William F Pokorny commented on Sunday, 22 January 2017, 15:15 GMT

Now tracked on github as issue #210.


Available keyboard shortcuts


Task Details

Task Editing