 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
With a lot of test images and reuse of scenes I loose track of command line
settings, camera settinges etc.
For a future version of POV-Ray it would be nice to write meta information to
the resulting image file.
#meta{
global settings
ini settings / switches
active_camera
user:"some text"
user:"some more text"
EXIF
IPTC
}
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13.04.2025 8:41, ingo wrote:
> For a future version of POV-Ray it would be nice to write meta information to
> the resulting image file.
So far, you can manually write tEXt to PNG. I personally use TweakPNG,
as a result even a web preview for my POVThread contains full text for
isosurface used as basic element - it's small but took a lot of time to
tweak, so I just didn't want to loose the exact parameters ;-)
BTW this would not work with ident-based Python-like format discussed
here: tEXt loses formatting but keeps braces ;-)
--
Ilyich the Toad
https://dnyarri.github.io/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"ingo" <nomail@nomail> wrote:
> With a lot of test images and reuse of scenes I loose track of command line
> settings, camera settinges etc.
>
> For a future version of POV-Ray it would be nice to write meta information to
> the resulting image file.
agree. Bald Eagle argues[*] for including the scene code itself among the meta
data, worth considering since it could be stored compressed and wouldn't take
much additional space.
[*] sorry, no ref.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmail com> wrote:
> hi,
> Bald Eagle argues[*] for including the scene code itself among the meta
> data, worth considering since it could be stored compressed and wouldn't take
> much additional space.
>
For that I would prefer an editor with build in support for fossil (and some
more), so we can have infinite redo and a tag for when an image is rendered. Of
course that editor also has the ability to read the scene file from the image
(and if it not exists create it ......)
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> agree. Bald Eagle argues[*] for including the scene code itself among the meta
> data, worth considering since it could be stored compressed and wouldn't take
> much additional space.
>
> [*] sorry, no ref.
Here's one of them:
https://news.povray.org/povray.binaries.images/message/%3Cweb.6076506a6a35d6561f9dae3025979125%40news.povray.org%3E/#%3
Cweb.6076506a6a35d6561f9dae3025979125%40news.povray.org%3E
To be 100% accurate, I argue for the OPTION or ABILITY to write the scene file
into the image.
Also useful would be to disable overwrite of the default output filename and
instead start writing Filename(1).png, Filename(2).png, etc.
Long time povvers know the dangers of rapid editing and rendering during scene
development.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Also useful would be to disable overwrite of the default output filename and
> instead start writing Filename(1).png, Filename(2).png, etc.
Yes, that's an other one.
(An early version of 3DStudio had a `+` button to save the source file and thus
the rendering with an incremented number.)
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/13/25 14:07, jr wrote:
>> For a future version of POV-Ray it would be nice to write meta information to
>> the resulting image file.
>
> agree. Bald Eagle argues[*] for including the scene code itself among the meta
> data, worth considering since it could be stored compressed and wouldn't take
> much additional space.
But what if your scene, like mine, is split into several
included files?
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
tTh <tth### [at] noneinvalid> wrote:
> But what if your scene, like mine, is split into several
> included files?
Of course.
This is but a (simple) first step in implementing a suite of features.
What if you have meshes and HDRI light probes, and uv mapped image files, and
.....
We just proceed forward, one step at a time.
The simplest is just capturing that tricky equation, the thing that needed to be
twice differentiated, or meticulously translated to POV-Ray's crippled function
VM. The laboriously developed texture that just captures that look. Whatever.
Now it's saved as a part of the image that gets posted, and it's archived and
backed-up.
Then we can explore tar, gz, zip, 7z, and many other ways of collecting together
all of the elements to faithfully re-render any given scene.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
tTh <tth### [at] noneinvalid> wrote:
> On 4/13/25 14:07, jr wrote:
> > ... scene code itself among the meta data ...
> But what if your scene, like mine, is split into several
> included files?
I suspect what BE has in mind is pretty close to Tcl "starkit"s, that is, some
underlying VFS which allows mounting zips / archives. then it'd simply be your
whole project, with its own internal (sub-)directory structure, in a single
file; which I'd prefer, personally, but the "blob" could of course also be
embedded. so much depends on what decisions will be taken wrt a future POV-Ray.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> Tcl "starkit"s,
https://sqlite.org/appfileformat.html
https://sqlite.org/affcase1.html
What if one did something like the above. The database would contain the
complete current and past project in one file. Beside that one would have the
complete set of current versions as text files in the working dir(s). One could
feed POV-Ray the current text file(s) or the database and it would extract the
current version and render it.
Several of the editors out there are very configurable (language servers et al),
I think one could write a program that makes the construct above feasible. With
a dedicated POV-Ray editor it should be no problem at all to work this way.
In similar vain for the documentation. Stick it in a database based ebook like
thing. When one "installes" an include file, its documentation should be added
to the database so it is available in the help reader. Keywords to the index and
with full text search and may be made available in the language server.
SQLite files are not small, but 7zip can do wonders to them (for distribution)
Just thoughts,
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
