On 2/28/22 06:47, jr wrote:
> look at attached with:
> 
>    $ hexdump -C hu_8.png | less
> 
> that what you mean?;-)
> 
> anyway, long story short, you can do in Tcl, for .png files.  install the
> 'Tcllib' package, then check out the man page (section n on my box) for 'png'.

Neat.

What particular commands and versions of TCL and Tcllib are you using?

It's been maybe 4-5 years since I played in the tcl/png sandbox but, not 
too long after tcl 8.6 was first released, I found the png support from 
within tcl/tk/tcllib buggy. Supposing you are finding it better?

I was primarily trying to load/create/modify/save actual image channel 
data but, I don't recall even the particular 'TCL' packages and commands 
I tried at the moment...

Bill P.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> What I was actually thinking was that POV-Ray could use an image format as the
> actual file format for storing the SDL text, and the editor could extract it
> from that, display it, allow for editing, and re-save into the image file
> wrapper.
>
> Why do this:
> I guess the idea was that since POV-Ray already has the ability to
> parse/interpret image file formats already, it might be possible to somehow
> embed a series of text files into the image header - like includes, etc and use
> it kind of like a zip file.
>
> Also, then we could have the image and the code that generated it all in one
> place, so they aren't separated and lost/confused.

- keeping "image and the code" in one place, along with the includes, bg
image(s) etc, would be ideal.  a project oriented approach.  and zip would be a
good format.

- hate the idea/concept of "allow for editing, and re-save into the image file
wrapper".  if anything the other way round, keep everything plain human-readable
text and include image(s) and other binary content 'base64' encoded.

anyway, thanks, have a clearer picture now of the "silly idea".


> It might also be possible to implement security by obscurity, to protect certain
> parts of code that an author might not want users casually messing with.  If you
> really wanted to edit that code, you'd have to work for it, rather than just
> "Ooops!  I broke it!"

also not keen on this.  if an author feels .. so strongly, well, then don't
publish.  simples.


> But binary copy, hexdump, Tcp, and other tools might provide a sort of
> functional work-around / proof of concept to see how a suite of files could
> potentially be used ....

why binary anyway?  what's wrong with a plain text (or utf8) encoding?


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> What particular commands and versions of TCL and Tcllib are you using?

(typed)

% set tcl_version
8.6
% package require crc32
% package require png
% png::addComment foo.png theTag theValue

and using a 'tcllib1.18' (though mean to upgrade to 1.19).


> It's been maybe 4-5 years since I played in the tcl/png sandbox but, not
> too long after tcl 8.6 was first released, I found the png support from
> within tcl/tk/tcllib buggy. Supposing you are finding it better?

guess so, cannot recall any problem(s) with 'image' and 'photo' etc.


> I was primarily trying to load/create/modify/save actual image channel
> data but, I don't recall even the particular 'TCL' packages and commands
> I tried at the moment...

fwiw 'df3util' can split PNGs into rgba (and stored in a DF3, but there's the
'export' command).

hope to post a 'compare(1)' image in the next days, showing some/much difference
for the sphere_sweep between 'povr' and stock POV-Ray.  will need to
systematically try with 'sturm' and 'tolerance' etc first though.


regards, jr.

Post a reply to this message

On 28/02/2022 12:47, jr wrote:
> hi,
> 
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> ...
>> Silly idea:   certain image formats have header sections where you can embed
>> virtually anything.   Would it be possible to have POV-Ray store scene files in
>> an image file format, with the SDL embedded in the header?  Not sure where I was
>> going with this a second ago - but just thinking about such a thing might spark
>> some new ideas about structuring scene, includes, etc.
> 
> look at attached with:
> 
>   $ hexdump -C hu_8.png | less
> 
> that what you mean?  ;-)


Really funny !
<https://en.wikipedia.org/wiki/Steganography>


-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

thinking some more..

William F Pokorny <ano### [at] anonymousorg> wrote:
> Neat.

and super-easy, _and_ since Tcl also runs on Redmond's finest, potentially of
interest to every user of POV-Ray who wants to publish/distribute an image.
therefore, imo, in a separate thread, we ("all interested parties" :-)) should
have a discussion to come up with an informal set of useful "recommended"
tags/keys. think will start one tomorrow (unless you/someone gets there first
</grin>).


@kurtz

"covered writing" indeed, as many (most?) image viewers simply ignore the info.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> - keeping "image and the code" in one place, along with the includes, bg
> image(s) etc, would be ideal.  a project oriented approach.  and zip would be a
> good format.
>
> - hate the idea/concept of "allow for editing, and re-save into the image file
> wrapper".  if anything the other way round, keep everything plain human-readable
> text and include image(s) and other binary content 'base64' encoded.
>
> anyway, thanks, have a clearer picture now of the "silly idea".

I'm not sure I care too much exactly how it gets implemented.  I was under the
impression that opening such an image file with a hex editor would result in the
text part looking like --- plain text.  It's not like plain text is "special" -
it all has to get displayed on the screen by something that interprets the ASCII
values anyway.   At least that's the way it works in my head.

What about:
http://textbundle.org/
https://www.macsparky.com/blog/2014/11/the-textbundle-format/

I posted about this idea a while back - there was some other file format that
sort of acted like concatenated text files....   maybe it was a 'nix format...
I can't remember.


> > It might also be possible to implement security by obscurity, to protect certain
> > parts of code that an author might not want users casually messing with.  If you
> > really wanted to edit that code, you'd have to work for it, rather than just
> > "Ooops!  I broke it!"
>
> also not keen on this.  if an author feels .. so strongly, well, then don't
> publish.  simples.

Right, but the idea is just to make the code available and usable, but not right
there in the editor where it can easily be inadvertently corrupted.  I often
write spreadsheets with "locked" cells - but the password is sitting right there
in a documentation tab in case someone wants to edit it in the future.   But in
daily use, they can't get messed up by accident, which is easy to do.

I would like a project-oriented format/editor.  Open the project, and the main
file is in the first tab (Maybe the second, if there's a documentation tab) and
the includes and image files are available in other tabs.
OpenOffice allows use of hyperlinks in the spreadsheet, which I've used to
navigate around a sheet or between tabs.  It would be cool to specify image
filenames, and be able to click on those and get a preview, then "go back" and
edit the SDL.  Working on some code and need to find out what some value an
Lvalue has?   Click it and you jump back to the last #declare for that Lvalue.

But I think just starting off with the basic bundle idea would solve a lot of
organizational and archival issues.

> > But binary copy, hexdump, Tcp, and other tools might provide a sort of
> > functional work-around / proof of concept to see how a suite of files could
> > potentially be used ....
>
> why binary anyway?  what's wrong with a plain text (or utf8) encoding?

How do you keep the different text/SDL files separate, and maybe even package
images for mapping together?   Isn't a zip a binary format?

Post a reply to this message

Le 2022-03-01 à 12:06, kurtz le pirate a écrit :

> 
> Really funny !
> <https://en.wikipedia.org/wiki/Steganography>
> 
> 

We see some obvious example of that in MANY movies from the 1950's to 
1980's when someone use some aperture mask to reveal a hidden message in 
a letter.
I've seen at least one movie where we see a character actually writing 
such a message.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > - keeping "image and the code" in one place, along with the includes, bg
> > image(s) etc, would be ideal.  a project oriented approach.  and zip would be a
> > good format.
> >
> > - hate the idea/concept of "allow for editing, and re-save into the image file
> > wrapper".  if anything the other way round, keep everything plain human-readable
> > text and include image(s) and other binary content 'base64' encoded.
> >
> > anyway, thanks, have a clearer picture now of the "silly idea".
>
> I'm not sure I care too much exactly how it gets implemented.  I was under the
> impression that opening such an image file with a hex editor would result in the
> text part looking like --- plain text.  It's not like plain text is "special" -
> it all has to get displayed on the screen by something that interprets the ASCII
> values anyway.   At least that's the way it works in my head.

I suggested 'hexdump' because it is "safe", ie no stray control characters to
mess with yr terminal/console.  for comfortable viewing one could use
'png::getComments', or even simply:

  $ strings -n7 foo.png | less


> What about:
> http://textbundle.org/
> https://www.macsparky.com/blog/2014/11/the-textbundle-format/

see below.


> I posted about this idea a while back - there was some other file format that
> sort of acted like concatenated text files....   maybe it was a 'nix format...
> I can't remember.

unsure.  are you thinking of "literate programming"?  cf Knuth.


> > > It might also be possible to implement security by obscurity, to protect certain
> > > parts of code that an author might not want users casually messing with.  ...
> > also not keen on this.  if an author feels .. so strongly, well, then don't
> > publish.  simples.
>
> Right, but the idea is just to make the code available and usable, but not right
> there in the editor where it can easily be inadvertently corrupted.  I often
> write spreadsheets with "locked" cells - but the password is sitting right there
> in a documentation tab in case someone wants to edit it in the future.   But in
> daily use, they can't get messed up by accident, which is easy to do.

sure.  use a viewer like 'less' and only invoke the editor (by pressing 'v')
when intending to edit.  something like an .inc or other data one could make
read-only.


> I would like a project-oriented format/editor.  Open the project, and the main
> file is in the first tab (Maybe the second, if there's a documentation tab) and
> the includes and image files are available in other tabs.

though not using it at present, isn't that much like 'qtpovray's interface?


> OpenOffice allows use of hyperlinks in the spreadsheet, which I've used to
> navigate around a sheet or between tabs.  It would be cool to specify image
> filenames, and be able to click on those and get a preview, then "go back" and
> edit the SDL.  Working on some code and need to find out what some value an
> Lvalue has?   Click it and you jump back to the last #declare for that Lvalue.
>
> But I think just starting off with the basic bundle idea would solve a lot of
> organizational and archival issues.

yes.  think 'fossil'.  seriously.  as long as the project is a single directory
tree, that will address half of your needs.  (g)vim and a 'tags' file for
navigation will provide the other half.


> How do you keep the different text/SDL files separate, and maybe even package
> images for mapping together?   Isn't a zip a binary format?

and each fossil "repository" is a single file too, ie the same convenience
handling/backing up.


regards, jr.

Post a reply to this message

On 3/1/22 07:55, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> What particular commands and versions of TCL and Tcllib are you using?
> 
> (typed)
> 
> % set tcl_version
> 8.6
> % package require crc32
> % package require png
> % png::addComment foo.png theTag theValue
> 
> and using a 'tcllib1.18' (though mean to upgrade to 1.19).
> 

Thanks.

Forgot TCL breaks the patch level out... What does the shell command:

echo 'puts [info patchlevel];exit 0' | tclsh

give you?

> 
>> It's been maybe 4-5 years since I played in the tcl/png sandbox but, not
>> too long after tcl 8.6 was first released, I found the png support from
>> within tcl/tk/tcllib buggy. Supposing you are finding it better?
> 
> guess so, cannot recall any problem(s) with 'image' and 'photo' etc.
> 
> 
>> I was primarily trying to load/create/modify/save actual image channel
>> data but, I don't recall even the particular 'TCL' packages and commands
>> I tried at the moment...
> 
> fwiw 'df3util' can split PNGs into rgba (and stored in a DF3, but there's the
> 'export' command).
> 

Thanks for the reminder. At the time I was aiming for a set of new 
commands in my TCL SDL wrapper.

Aside: I found out at some point the netpbm pam RGBA format is, less the 
short pam header and the addition of a short DF3 header, an exactly DF3 
equivalent file layer/plane. This means you can create / manipulate DF3s 
quickly with that tool set too.

> hope to post a 'compare(1)' image in the next days, showing some/much difference
> for the sphere_sweep between 'povr' and stock POV-Ray.  will need to
> systematically try with 'sturm' and 'tolerance' etc first though.
> 

I'm interested in the results you see from compare. I'm not a big 
imagemagick user.

--- sphere_sweep...

The povr sphere_sweep is substantially different in implementation being 
one of the shapes which leans on the generic inbuilt solvers. I did a 
large amount of work on those solvers some years ago.

There are at least a dozen numerical and control issues in that shape 
alone in POV-Ray proper. Much fixed or made much better in povr - but 
issues remain. Ultimately, I believe the code for sphere_sweeps needs to 
be completely re-written!

With sphere_sweep 'tolerance' my recollection is it does nothing in povr 
because in POV-Ray proper results are unstable due - another half dozen 
reasons.

First up, being the sphere_sweep is one our shapes where transforms get 
flattened (removed) if possible to improve performance. However, you 
cannot always flatten depending upon the particular transforms. This 
means the 'numerical meaning' of the 'tolerance' values (also things 
like no_bump_scale) are not themselves stable depending upon user scene 
transformations. Yep, this might be why the tolerance value was brought 
out as a control originally.

...And sturm...

In official POV-Ray releases, across many shapes, you are not always 
truly turning the sturm based solver on and off!

IIRC. The sphere_sweep sturm is always on internally (the polynomial 
orders are beyond 4) - excepting linear sweeps where it's hard coded 
always off (an unfortunate choice).

There's a general issue in official POV-Ray where, for auxiliary 
internal polynomials (ie inside tests), POV-Ray isn't changing to a 
sturm solver in a way aligned with the mainstream ray-surface solvers 
for some shapes - and sphere_sweep is one. Probably done for better 
performance too or, maybe believing the fixed solvers are 'always' the 
better choice. In any case, mixing solver approaches is not the best for 
'numerical alignment.'

In general! With povr, sturm off always uses a fixed solver where 
polynomial order allows it. Where sturm on, povr's version of the sturm 
solver is always used or, if the order is >4 'sturm on' will sometimes - 
as with sphere_sweeps(1) - mean use a 'better' sturm based solver.

(1) IIRC. It's currently doing order reduction after each root is found.

The takeaway is sturm behavior in sphere_sweeps is mostly fixed in 
official POV-Ray. In povr 'sturm on' always means "use a better sturm 
based solver."

Encyclopedia sets worth of detail when you get into the solvers... My 
head spins round and round! :-(

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/1/22 07:55, jr wrote:
> > ...
> > % set tcl_version
> > 8.6
> > ...
> Thanks.
>
> Forgot TCL breaks the patch level out... What does the shell command:
>
> echo 'puts [info patchlevel];exit 0' | tclsh
>
> give you?

8.6.5 (also have a 8.6.1 still).


> ...
> Aside: I found out at some point the netpbm pam RGBA format is, less the
> short pam header and the addition of a short DF3 header, an exactly DF3
> equivalent file layer/plane. This means you can create / manipulate DF3s
> quickly with that tool set too.

interesting, thanks.


> > hope to post a 'compare(1)' image in the next days, showing some/much difference
> > ...
> I'm interested in the results you see from compare. I'm not a big
> imagemagick user.

will need a couple of days or so.  read about sturm + sphere_sweep in
'revisions.txt', hence wanting to re-run + try things first.



@Cousin

the included-with-the-os Pinball was my .. vice, in the 3.11 heydays.  :-)


regards, jr.

Post a reply to this message