Hi,

I use POV-Ray in command line under macOS Catalina and Macports,
and run it about 2000 times, in order to render 2000 images. My
issue is when you launch `povray` in command line, it opens a
menu bar, and displays an icon in the macOS dock ...

Is there a command line option, that prevents POV-Ray from displaying
a menu bar and an icon in the dock ? Because when you launch it 2000
times, for 2000 images, the Apple Finder and the Macintosh become
unusable ... The computer keeps displaying the bar and the icon,
and you can't do anything else with the Macintosh. You have to wait
that the 2000 images are rendered ... You have to wait half an hour,
so that POV-Ray stops rendering.

There must be a solution. Because you can't do anything else, before
POV-Ray has stopped rendering ... This is very painful ...

Thanks for any help.

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

On 1/27/21 10:30 AM, Francois LE COAT wrote:
> Hi,
> 
> I use POV-Ray in command line under macOS Catalina and Macports,
> and run it about 2000 times, in order to render 2000 images. My
> issue is when you launch `povray` in command line, it opens a
> menu bar, and displays an icon in the macOS dock ...
> 
> Is there a command line option, that prevents POV-Ray from displaying
> a menu bar and an icon in the dock ? 
> 

Unsure if true with the macOS version you are running, but with 
Linux/Unix versions (which only display an icon) you can use '-d' to not 
create a preview display and icon or '--preview text' (or '-y text) to 
use the inbuilt text only mode.

Bill P.

Post a reply to this message

Hi,

William F Pokorny writes:
> Francois LE COAT wrote:
>> I use POV-Ray in command line under macOS Catalina and Macports,
>> and run it about 2000 times, in order to render 2000 images. My
>> issue is when you launch `povray` in command line, it opens a
>> menu bar, and displays an icon in the macOS dock ...
>>
>> Is there a command line option, that prevents POV-Ray from displaying
>> a menu bar and an icon in the dock ?
> 
> Unsure if true with the macOS version you are running, but with 
> Linux/Unix versions (which only display an icon) you can use '-d' to no
t 
> create a preview display and icon or '--preview text' (or '-y text) to 

> use the inbuilt text only mode.
> 
> Bill P.

My .INI file is :
"
All_Console=Off
Antialias=On
Bounding_Threshold=3
Continue_Trace=Off
Display=Off
Draw_Vistas=On
Height=640
Input_File_Name="./pacman_mod.pov"
Library_Path="/usr/share/povray-3.7"
Library_Path="/usr/share/povray-3.7/ini"
Library_Path="/usr/share/povray-3.7/include"
Library_Path="/usr/local/share/povray-3.7"
Library_Path="/usr/local/share/povray-3.7/ini"
Library_Path="/usr/local/share/povray-3.7/include"
Output_File_Name="./pacman.png"
Output_File_Type=N
Output_To_File=On
Split_Unions=On
Test_Abort=Off
Verbose=On
Width=640
Work_Threads=12
"
I don't know how I should modify it, so that is doesn't use a menu bar,
and show an icon in the macOS dock. "Display=Off" is set, so what shoul
d
I do more ? I want POV-Ray to be quiet ... The menu bar and icon are
embarrassing. That prevents from using anything else than POV-Ray :-(

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hello,

you need to find out who created that port and figure out what they did. 
The regular Unix code does not create any menu bar or icon because it 
simply knows nothing about Mac OS X.

The other thing is that you should not be starting 2000 instances of 
POV-Ray at the same time...

Thorsten

On 28.01.2021 17:05, Francois LE COAT wrote:
> William F Pokorny writes:
>> Francois LE COAT wrote:
>>> I use POV-Ray in command line under macOS Catalina and Macports,
>>> and run it about 2000 times, in order to render 2000 images. My
>>> issue is when you launch `povray` in command line, it opens a
>>> menu bar, and displays an icon in the macOS dock ...
>>>
>>> Is there a command line option, that prevents POV-Ray from displaying
>>> a menu bar and an icon in the dock ?
>>
>> Unsure if true with the macOS version you are running, but with 
>> Linux/Unix versions (which only display an icon) you can use '-d' to 
>> not create a preview display and icon or '--preview text' (or '-y 
>> text) to use the inbuilt text only mode.
>>

> I don't know how I should modify it, so that is doesn't use a menu bar,
> and show an icon in the macOS dock. "Display=Off" is set, so what should
> I do more ? I want POV-Ray to be quiet ... The menu bar and icon are
> embarrassing. That prevents from using anything else than POV-Ray :-(

Post a reply to this message

Hi,

Thorsten writes:
> you need to find out who created that port and figure out what they did
. 
> The regular Unix code does not create any menu bar or icon because it 
> simply knows nothing about Mac OS X.

That's the POV_Ray port available in Macports for macOS Catalina :

	<https://ports.macports.org/port/povray/>

I'd better build POV_Ray myself, what I already done, if there's no
peculiar option to suppress usage of the menu bar, and dock's icon.

> The other thing is that you should not be starting 2000 instances of 
> POV-Ray at the same time...

I launch POV_Ray about 2000 times, one after the other, with the use
of 12 threads (the Macintosh has 9 cores), and I must do something
else in between, because the Mac is completely monopolized. I can't
even read my email, because the Finder's interface becomes a mess ...

It's really curious that no Mac user ever noticed that peculiarity
of the Macports version. There must not be a lot of users like me :-)

> Francois LE COAT wrote:
>> William F Pokorny writes:
>>> Francois LE COAT wrote:
>>>> I use POV-Ray in command line under macOS Catalina and Macports,
>>>> and run it about 2000 times, in order to render 2000 images. My
>>>> issue is when you launch `povray` in command line, it opens a
>>>> menu bar, and displays an icon in the macOS dock ...
>>>>
>>>> Is there a command line option, that prevents POV-Ray from displayin
g
>>>> a menu bar and an icon in the dock ?
>>>
>>> Unsure if true with the macOS version you are running, but with 
>>> Linux/Unix versions (which only display an icon) you can use '-d' to 

>>> not create a preview display and icon or '--preview text' (or '-y 
>>> text) to use the inbuilt text only mode.
>>>
> 
>> I don't know how I should modify it, so that is doesn't use a menu bar
,
>> and show an icon in the macOS dock. "Display=Off" is set, so what sh
ould
>> I do more ? I want POV-Ray to be quiet ... The menu bar and icon are
>> embarrassing. That prevents from using anything else than POV-Ray :-(

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

On 1/28/21 1:37 PM, Thorsten wrote:
> Hello,
> 
> you need to find out who created that port and figure out what they did. 
> The regular Unix code does not create any menu bar or icon because it 
> simply knows nothing about Mac OS X.
> 
> The other thing is that you should not be starting 2000 instances of 
> POV-Ray at the same time...
> 
> Thorsten
> 
> On 28.01.2021 17:05, Francois LE COAT wrote:
> 
>> I don't know how I should modify it, so that is doesn't use a menu bar,
>> and show an icon in the macOS dock. "Display=Off" is set, so what should
>> I do more ? I want POV-Ray to be quiet ... The menu bar and icon are
>> embarrassing. That prevents from using anything else than POV-Ray :-(

I agree with Thorsten that finding the author of your particular port 
and asking them whether one can suppress the menu bar and icon may 
ultimately be your only option.

That said, people doing mac ports have posted unix/linux build issues to 
github - so some are using the shipped unix/linux build system. You have 
the display off - good. Somewhere you are issuing a command line like:

povray your.ini ...

It's a shot in the dark, but add '--preview text' to the command line 
and see if that helps... Try first running a single job with that 
command line. It's a unix/linux only option and not an ini settable one. 
If it isn't supported / doesn't work, it should be immediately obvious 
from one render.

Agree too that, if you are submitting 2000 jobs at once, that's likely 
as much the issue with usability as anything. Funneling jobs in over 
time would be better and doing that in a way tied to the availability of 
system resources best. I'd taken what you said to be 2000 jobs one after 
another over 30 minutes (<1s a render).

And a clarification to what Thorsten said about icons and POV-Ray as 
shipped. On unix/linux, if you are running a window manager which looks 
to generate icons from opening X11 windows, you do get them unless you 
override default(s).

Bill P.

Post a reply to this message

Hi,

William F Pokorny writes:
> Thorsten wrote:
>> you need to find out who created that port and figure out what they 
>> did. The regular Unix code does not create any menu bar or icon 
>> because it simply knows nothing about Mac OS X.
>>
>> The other thing is that you should not be starting 2000 instances of 
>> POV-Ray at the same time...
>>
>> Francois LE COAT wrote:
>>> I don't know how I should modify it, so that is doesn't use a menu ba
r,
>>> and show an icon in the macOS dock. "Display=Off" is set, so what s
hould
>>> I do more ? I want POV-Ray to be quiet ... The menu bar and icon are
>>> embarrassing. That prevents from using anything else than POV-Ray :-(

> 
> I agree with Thorsten that finding the author of your particular port 
> and asking them whether one can suppress the menu bar and icon may 
> ultimately be your only option.
> 
> That said, people doing mac ports have posted unix/linux build issues t
o 
> github - so some are using the shipped unix/linux build system. You hav
e 
> the display off - good. Somewhere you are issuing a command line like:
> 
> povray your.ini ...
> 
> It's a shot in the dark, but add '--preview text' to the command line 
> and see if that helps... Try first running a single job with that 
> command line. It's a unix/linux only option and not an ini settable one
. 
> If it isn't supported / doesn't work, it should be immediately obvious 

> from one render.

If I launch "%povray --preview text pacman.ini" in command line I have :
"
povray: cannot open the user configuration file 
/Users/admin/.povray/3.7/povray.conf: No such file or directory

Problem with option setting
povray --preview text pacman.ini
Failed to parse command-line option
"
That doesn't work. Do you have an advice ?

Thanks,

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,
I don't have a solution to your finder problem but I thought a work around could
be to render your 2000 images as if it was an animation. Then you would launch
only one instance of Pov-ray (I think, not completely sure actually how it works
on Mac). Yet, I don't know if you could easily change your
script to render the appropriate image based on the clock variable...

Pascal



Francois LE COAT <lec### [at] atariorg> wrote:
> Hi,
>
> I use POV-Ray in command line under macOS Catalina and Macports,
> and run it about 2000 times, in order to render 2000 images. My
> issue is when you launch `povray` in command line, it opens a
> menu bar, and displays an icon in the macOS dock ...
>
> Is there a command line option, that prevents POV-Ray from displaying
> a menu bar and an icon in the dock ? Because when you launch it 2000
> times, for 2000 images, the Apple Finder and the Macintosh become
> unusable ... The computer keeps displaying the bar and the icon,
> and you can't do anything else with the Macintosh. You have to wait
> that the 2000 images are rendered ... You have to wait half an hour,
> so that POV-Ray stops rendering.
>
> There must be a solution. Because you can't do anything else, before
> POV-Ray has stopped rendering ... This is very painful ...
>
> Thanks for any help.
>
> Best regards,
>
> --
> François LE COAT
> <http://eureka.atari.org/>

Post a reply to this message

On 1/28/21 4:10 PM, Francois LE COAT wrote:
> Hi,
> 
...
> 
> If I launch "%povray --preview text pacman.ini" in command line I have :
> "
> povray: cannot open the user configuration file 
> /Users/admin/.povray/3.7/povray.conf: No such file or directory
> 
> Problem with option setting
> povray --preview text pacman.ini
> Failed to parse command-line option
> "
> That doesn't work. Do you have an advice ?
> 

Hi,
My last two ideas. First, the sort of advice jr gives me. Have you tried 
just:

povray --help

at a command line? I don't hold out much hope, but maybe it would kick 
out any extra command line flags that are supported. It's what the 
straight unix/linux compile does.

And second, an idea more complicated. With X11 at least there is a null 
display utility usually used for testing. I can't remember the name... 
Ah, it's xvfb. I've never used it myself only hearing someone else 
mention it long ago. Looks like it can be installed on Ubuntu 20.04, but 
no idea if you have anything similar on macOS?

Aside: I think that configuration file message is another issue and not 
critical.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> My last two ideas. First, the sort of advice jr gives me. ...

</grin>  reminds me I meant to post re your comment (in another thread) that
'vim' has become your day-to-day editor.  first, if you want the '#for()' to
indent properly, add it to the list in line 63 of
'/usr/share/vim/vim81/indent/pov.vim'.  second, I recently "discovered" vim's
folding capabilities, great stuff, check it out (I added 'set foldmethod=marker'
in the '~/.vimrc', works equally well with Tcl.  :-))


regards, jr.

Post a reply to this message

Hi,

I can't use clock variable, in the case of my rendering. Here it is...

	<https://www.youtube.com/watch?v=vgHOseHTGXs>

The rendered image is the yellow camera, in up-right corner. Every
2000 POV-Ray scripts are different. The 2000 POV-Ray scripts are
generated reading a data file, containing series of float numbers.

I must launch POV-Ray 2000 times, one after the other, to render 2000
different scripts. That's critical, because POV-Ray replaces the menu
bar, and add its icon to the macOS dock, 2000 times successively.
That completely blocks the usage of the Apple Finder's interface.

BayashiPascal writes:
> I don't have a solution to your finder problem but I thought a work aro
und could
> be to render your 2000 images as if it was an animation. Then you would
 launch
> only one instance of Pov-ray (I think, not completely sure actually how
 it works
> on Mac). Yet, I don't know if you could easily change your
> script to render the appropriate image based on the clock variable...
> 
> Pascal
> 
> Francois LE COAT wrote:
>> I use POV-Ray in command line under macOS Catalina and Macports,
>> and run it about 2000 times, in order to render 2000 images. My
>> issue is when you launch `povray` in command line, it opens a
>> menu bar, and displays an icon in the macOS dock ...
>>
>> Is there a command line option, that prevents POV-Ray from displaying
>> a menu bar and an icon in the dock ? Because when you launch it 2000
>> times, for 2000 images, the Apple Finder and the Macintosh become
>> unusable ... The computer keeps displaying the bar and the icon,
>> and you can't do anything else with the Macintosh. You have to wait
>> that the 2000 images are rendered ... You have to wait half an hour,
>> so that POV-Ray stops rendering.
>>
>> There must be a solution. Because you can't do anything else, before
>> POV-Ray has stopped rendering ... This is very painful ...

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

hi,

Francois LE COAT <lec### [at] atariorg> wrote:
> Hi,
>
> I can't use clock variable, in the case of my rendering. Here it is...
> ...
> The rendered image is the yellow camera, in up-right corner. Every
> 2000 POV-Ray scripts are different. The 2000 POV-Ray scripts are
> generated reading a data file, containing series of float numbers.

you don't give (m)any details about how your code is structured, so my comments
are .. a shot in the dark.  :-)

if your 2000 "scripts" are simply the changing data, and you '#include' those
from a scene, then serially numbered data filenames corresponding to
'frame_number' and constructing the file name at runtime would allow you to run
a single "animation".

if you have to extract each data set one at a time, using a shell script in
conjunction with the '{pre,post}_frame_command's in the ini file might do the
trick, again, you'd only run one animation.  hth.


regards, jr.

Post a reply to this message

Hi,

jr writes:
> Francois LE COAT wrote:
>> I can't use clock variable, in the case of my rendering. Here it is...

>> ...
>> The rendered image is the yellow camera, in up-right corner. Every
>> 2000 POV-Ray scripts are different. The 2000 POV-Ray scripts are
>> generated reading a data file, containing series of float numbers.
> 
> you don't give (m)any details about how your code is structured, so my 
comments
> are .. a shot in the dark.  :-)
> 
> if your 2000 "scripts" are simply the changing data, and you '#include'
 those
> from a scene, then serially numbered data filenames corresponding to
> 'frame_number' and constructing the file name at runtime would allow yo
u to run
> a single "animation".
> 
> if you have to extract each data set one at a time, using a shell scrip
t in
> conjunction with the '{pre,post}_frame_command's in the ini file might 
do the
> trick, again, you'd only run one animation.  hth.
> 
> regards, jr.

The rendering of POV-Ray synthesis images are done in "real-time". It
depends on past data, and future parameters are unknown. I have a
POV-Ray script from which I substitute series of float numbers, that
produces 2000 different scenes, one after the other.

I can't launch POV-Ray one time, to produce 2000 images. I must launch
it 2000 times, to render 2000 images. The issue is that Macports
POV-Ray binary, changes the menu bar, and displays an icon in the dock.

The question is how to configure POV-Ray with the command-line, so that
it is quiet ? I think I'll have to build POV-Ray binary myself, from
Unix/Linux sources using `./configure; make; make install` it's simple !

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

hi,

Francois LE COAT <lec### [at] atariorg> wrote:
> ...
> The rendering of POV-Ray synthesis images are done in "real-time". It
> depends on past data, and future parameters are unknown. I have a
> POV-Ray script from which I substitute series of float numbers, that
> produces 2000 different scenes, one after the other.
>
> I can't launch POV-Ray one time, to produce 2000 images. I must launch
> it 2000 times, to render 2000 images. ...
> The question is how to configure POV-Ray with the command-line, so that
> it is quiet ? ...

looking at the ini you posted earlier, am I correct in assuming that the
generating "POV-Ray script" produces 2000 scene files named 'pacman_mod.pov'?

also, since I cannot believe that you'd invoke a(ny) program 2000 times
manually, the script must somehow tell 2nd from 23rd run.  do you run the whole
thing lot from within another script?  (o/wise how do you prevent overwriting
'pacman.png'?)

are you free to modify said POV-Ray script?  then, for instance, you could
change it to generate an array and include that from your scene, using
frame_number as index; though there'd likely be other, more efficient ways.  (I
also assume that the newly calculated data only depends on previous)

anyway, I'm fairly certain that the "problem" can be addressed w/out resorting
to compiling a new program.  :-)


regards, jr.

Post a reply to this message

Hi,

jr writes:
> Francois LE COAT wrote:
>> ...
>> The rendering of POV-Ray synthesis images are done in "real-time". It
>> depends on past data, and future parameters are unknown. I have a
>> POV-Ray script from which I substitute series of float numbers, that
>> produces 2000 different scenes, one after the other.
>>
>> I can't launch POV-Ray one time, to produce 2000 images. I must launch

>> it 2000 times, to render 2000 images. ...
>> The question is how to configure POV-Ray with the command-line, so tha
t
>> it is quiet ? ...
> 
> looking at the ini you posted earlier, am I correct in assuming that th
e
> generating "POV-Ray script" produces 2000 scene files named 'pacman_mod
.pov'?

Well, I have a model "pacman.pov" from which I generate "pacman_mod.pov"
substituting the parameters at n step. Then I render this script,
producing "pacman.png". And I move "pacman.png" to "pac%04d.png" with n.

> also, since I cannot believe that you'd invoke a(ny) program 2000 times

> manually, the script must somehow tell 2nd from 23rd run.  do you run t
he whole
> thing lot from within another script?  (o/wise how do you prevent overw
riting
> 'pacman.png'?)

It results 2000 files, from "pac0001.png" to "pac2000.png" with 2000
steps. I have launched POV-Ray 2000 times, knowing parameters from
1 to n steps. Each step n I have new parameters, but I don't know n+1.

> are you free to modify said POV-Ray script?  then, for instance, you co
uld
> change it to generate an array and include that from your scene, using
> frame_number as index; though there'd likely be other, more efficient w
ays.  (I
> also assume that the newly calculated data only depends on previous)

I can't generate an array of parameters, because I know those partially.
I'm drawing a trajectory, steps to steps, and I can't predict future.

> anyway, I'm fairly certain that the "problem" can be addressed w/out re
sorting
> to compiling a new program.  :-)

It's the simplest solution. If there's no command-line option to make
POV-Ray quiet, I can build a macOS/Macports version, that will be quiet.

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

Trying to guess what you're doing. The execution of the 2000 renderings is
automated in some way but you're getting your data used to create the rendering
script in real time, one image after the other, waiting new data to render the
next image, thus don't know in advance the new parameters. Am I right ?

If that's the case, and if the rendering could be delayed, you could wait until
you acquired the whole data for the 2000 images and implement a solution as
we've suggested in previous posts to render images at the end of acquisition.
But may be you need to render the image as soon as its data are acquired and use
the rendered image to acquire the next data ?

Your video really sparks my curiosity. I'm also working on project using
Pov-ray, real world data and depth images. Would you mind telling us a little
more about what you're doing ? Looks like some kind of 3D reconstruction from
data acquired by a drone ?

I also understand that finding a solution, which I have no idea of, to the
finder problem may be more practical to your use case, but, as jr, I still
believe there may be a work around. The image you render looks simple, and given
the real time constraints (either during acquisition, rendering process or
rendered image post processing) you seem to have, maybe Pov-ray is simply not
the appropriate tool to your use case ?

Hoping to be helpful,
Pascal


Francois LE COAT <lec### [at] atariorg> wrote:
> Hi,
>
> jr writes:
> > Francois LE COAT wrote:
> >> ...
> >> The rendering of POV-Ray synthesis images are done in "real-time". It
> >> depends on past data, and future parameters are unknown. I have a
> >> POV-Ray script from which I substitute series of float numbers, that
> >> produces 2000 different scenes, one after the other.
> >>
> >> I can't launch POV-Ray one time, to produce 2000 images. I must launch
>
> >> it 2000 times, to render 2000 images. ...
> >> The question is how to configure POV-Ray with the command-line, so tha
> t
> >> it is quiet ? ...
> >
> > looking at the ini you posted earlier, am I correct in assuming that th
> e
> > generating "POV-Ray script" produces 2000 scene files named 'pacman_mod
> .pov'?
>
> Well, I have a model "pacman.pov" from which I generate "pacman_mod.pov"
> substituting the parameters at n step. Then I render this script,
> producing "pacman.png". And I move "pacman.png" to "pac%04d.png" with n.
>
> > also, since I cannot believe that you'd invoke a(ny) program 2000 times
>
> > manually, the script must somehow tell 2nd from 23rd run.  do you run t
> he whole
> > thing lot from within another script?  (o/wise how do you prevent overw
> riting
> > 'pacman.png'?)
>
> It results 2000 files, from "pac0001.png" to "pac2000.png" with 2000
> steps. I have launched POV-Ray 2000 times, knowing parameters from
> 1 to n steps. Each step n I have new parameters, but I don't know n+1.
>
> > are you free to modify said POV-Ray script?  then, for instance, you co
> uld
> > change it to generate an array and include that from your scene, using
> > frame_number as index; though there'd likely be other, more efficient w
> ays.  (I
> > also assume that the newly calculated data only depends on previous)
>
> I can't generate an array of parameters, because I know those partially.
> I'm drawing a trajectory, steps to steps, and I can't predict future.
>
> > anyway, I'm fairly certain that the "problem" can be addressed w/out re
> sorting
> > to compiling a new program.  :-)
>
> It's the simplest solution. If there's no command-line option to make
> POV-Ray quiet, I can build a macOS/Macports version, that will be quiet.
>
> Thanks for your help.
>
> Regards,
>
> --
> François LE COAT
> <http://eureka.atari.org/>

Post a reply to this message

Hi,

To explain what I'm doing I've done a WEB page that is not yet finished:

<https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/temporal_d
isparity.html>

POV-Ray is totally appropriate to show what I'm doing, because it can
represent the eight parameters I'm obtaining from the camera movement.

I obtain the eight:

- Tx horizontal translation
- Ty vertical translation
- Tz depth translation
- Rx pitch angle
- Ry yaw angle
- Rz roll angle
- Sx horizontal shear angle
- Sy vertical shear angle

and POV-Ray can represent those all. This already have been discussed in
<news://povray.advanced-users> because I'm modelling the 3D motion.

The issue here, is just to make POV-Ray quiet when I'm rendering...

BayashiPascal writes:
> Trying to guess what you're doing. The execution of the 2000 renderings
 is
> automated in some way but you're getting your data used to create the r
endering
> script in real time, one image after the other, waiting new data to ren
der the
> next image, thus don't know in advance the new parameters. Am I right ?

> 
> If that's the case, and if the rendering could be delayed, you could wa
it until
> you acquired the whole data for the 2000 images and implement a solutio
n as
> we've suggested in previous posts to render images at the end of acquis
ition.
> But may be you need to render the image as soon as its data are acquire
d and use
> the rendered image to acquire the next data ?
> 
> Your video really sparks my curiosity. I'm also working on project usin
g
> Pov-ray, real world data and depth images. Would you mind telling us a 
little
> more about what you're doing ? Looks like some kind of 3D reconstructio
n from
> data acquired by a drone ?
> 
> I also understand that finding a solution, which I have no idea of, to 
the
> finder problem may be more practical to your use case, but, as jr, I st
ill
> believe there may be a work around. The image you render looks simple, 
and given
> the real time constraints (either during acquisition, rendering process
 or
> rendered image post processing) you seem to have, maybe Pov-ray is simp
ly not
> the appropriate tool to your use case ?
> 
> Hoping to be helpful,
> Pascal
> 
> Francois LE COAT wrote:
>> jr writes:
>>> Francois LE COAT wrote:
>>>> ...
>>>> The rendering of POV-Ray synthesis images are done in "real-time". I
t
>>>> depends on past data, and future parameters are unknown. I have a
>>>> POV-Ray script from which I substitute series of float numbers, that

>>>> produces 2000 different scenes, one after the other.
>>>>
>>>> I can't launch POV-Ray one time, to produce 2000 images. I must laun
ch
>>
>>>> it 2000 times, to render 2000 images. ...
>>>> The question is how to configure POV-Ray with the command-line, so t
ha
>> t
>>>> it is quiet ? ...
>>>
>>> looking at the ini you posted earlier, am I correct in assuming that 
th
>> e
>>> generating "POV-Ray script" produces 2000 scene files named 'pacman_m
od
>> .pov'?
>>
>> Well, I have a model "pacman.pov" from which I generate "pacman_mod.po
v"
>> substituting the parameters at n step. Then I render this script,
>> producing "pacman.png". And I move "pacman.png" to "pac%04d.png" with 
n.
>>
>>> also, since I cannot believe that you'd invoke a(ny) program 2000 tim
es
>>
>>> manually, the script must somehow tell 2nd from 23rd run.  do you run
 t
>> he whole
>>> thing lot from within another script?  (o/wise how do you prevent ove
rw
>> riting
>>> 'pacman.png'?)
>>
>> It results 2000 files, from "pac0001.png" to "pac2000.png" with 2000
>> steps. I have launched POV-Ray 2000 times, knowing parameters from
>> 1 to n steps. Each step n I have new parameters, but I don't know n+1.

>>
>>> are you free to modify said POV-Ray script?  then, for instance, you 
co
>> uld
>>> change it to generate an array and include that from your scene, usin
g
>>> frame_number as index; though there'd likely be other, more efficient
 w
>> ays.  (I
>>> also assume that the newly calculated data only depends on previous)
>>
>> I can't generate an array of parameters, because I know those partiall
y.
>> I'm drawing a trajectory, steps to steps, and I can't predict future.
>>
>>> anyway, I'm fairly certain that the "problem" can be addressed w/out 
re
>> sorting
>>> to compiling a new program.  :-)
>>
>> It's the simplest solution. If there's no command-line option to make
>> POV-Ray quiet, I can build a macOS/Macports version, that will be quie
t.

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

hi,

Francois LE COAT <lec### [at] atariorg> wrote:
> ...
> >> ...
> >> The rendering of POV-Ray synthesis images are done in "real-time". It
> >> depends on past data, and future parameters are unknown. I have a
> >> POV-Ray script from which I substitute series of float numbers, that
> >> produces 2000 different scenes, one after the other.
> >> ...
> Well, I have a model "pacman.pov" from which I generate "pacman_mod.pov"
> substituting the parameters at n step. Then I render this script,
> producing "pacman.png". And I move "pacman.png" to "pac%04d.png" with n.
> ...

I found the web page helpful, in the video I find it difficult to reconcile
movement of the indicator/pacman with the changes in orientation wrt the images
on the left (cf ~0:25, ~1:14).  concluding thought(s).  in reply to
BayashiPascal you write "The issue here, is just to make POV-Ray quiet when I'm
rendering."  with respect, disagree.  the issue I think, even not knowing the
particulars, is work-flow[*], is to work with POV-Ray, and its animation
provisions, rather than launching thousands of instances.  hope you will find a
satisfactory solution.


regards, jr.


[*] in my head/naively I'd collect the sets of eight values in a text file (CSV
style), have a few lines of 'awk' or such to convert that to an .inc file with
an array, then run an "animation" where the scene simply displays the current
video frame and the indicator gets rendered "on top".

Post a reply to this message

Hi,

Thank you very much for the web page, it looks like a very interesting research
project.

> POV-Ray is totally appropriate to show what I'm doing, because it can
> represent the eight parameters I'm obtaining from the camera movement.

Sure, Pov-ray can do that perfectly. What I meant was another rendering engine
could also do it as well, while avoiding the problem you face with Pov-ray. For
example a graphic library integrated to what you're using to launch the Pov-ray
instances would avoid creating those 2000 external processes to run Pov-ray. In
a previous comment you were writing "pac%04d.png", maybe you're using the C
programming language to generate the Pov-ray scripts and launch there rendering?
In that case, using a graphic library like, for example, OpenGL to render images
directly in the C program instead of using Pov-ray would allow you to get the
same result while avoiding the problem encountered with Pov-ray.

But, I still do not understand completely your constraints and I shall no go
further with hypothesis.

Anyway, bonne chance in your research ! :-)



Francois LE COAT <lec### [at] atariorg> wrote:
> Hi,
>
> To explain what I'm doing I've done a WEB page that is not yet finished:
>
> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/temporal_d
> isparity.html>
>
> POV-Ray is totally appropriate to show what I'm doing, because it can
> represent the eight parameters I'm obtaining from the camera movement.
>
> I obtain the eight:
>
> - Tx horizontal translation
> - Ty vertical translation
> - Tz depth translation
> - Rx pitch angle
> - Ry yaw angle
> - Rz roll angle
> - Sx horizontal shear angle
> - Sy vertical shear angle
>
> and POV-Ray can represent those all. This already have been discussed in
> <news://povray.advanced-users> because I'm modelling the 3D motion.
>
> The issue here, is just to make POV-Ray quiet when I'm rendering...
>
> BayashiPascal writes:
> > Trying to guess what you're doing. The execution of the 2000 renderings
>  is
> > automated in some way but you're getting your data used to create the r
> endering
> > script in real time, one image after the other, waiting new data to ren
> der the
> > next image, thus don't know in advance the new parameters. Am I right ?
>
> >
> > If that's the case, and if the rendering could be delayed, you could wa
> it until
> > you acquired the whole data for the 2000 images and implement a solutio
> n as
> > we've suggested in previous posts to render images at the end of acquis
> ition.
> > But may be you need to render the image as soon as its data are acquire
> d and use
> > the rendered image to acquire the next data ?
> >
> > Your video really sparks my curiosity. I'm also working on project usin
> g
> > Pov-ray, real world data and depth images. Would you mind telling us a
> little
> > more about what you're doing ? Looks like some kind of 3D reconstructio
> n from
> > data acquired by a drone ?
> >
> > I also understand that finding a solution, which I have no idea of, to
> the
> > finder problem may be more practical to your use case, but, as jr, I st
> ill
> > believe there may be a work around. The image you render looks simple,
> and given
> > the real time constraints (either during acquisition, rendering process
>  or
> > rendered image post processing) you seem to have, maybe Pov-ray is simp
> ly not
> > the appropriate tool to your use case ?
> >
> > Hoping to be helpful,
> > Pascal
> >
> > Francois LE COAT wrote:
> >> jr writes:
> >>> Francois LE COAT wrote:
> >>>> ...
> >>>> The rendering of POV-Ray synthesis images are done in "real-time". I
> t
> >>>> depends on past data, and future parameters are unknown. I have a
> >>>> POV-Ray script from which I substitute series of float numbers, that
>
> >>>> produces 2000 different scenes, one after the other.
> >>>>
> >>>> I can't launch POV-Ray one time, to produce 2000 images. I must laun
> ch
> >>
> >>>> it 2000 times, to render 2000 images. ...
> >>>> The question is how to configure POV-Ray with the command-line, so t
> ha
> >> t
> >>>> it is quiet ? ...
> >>>
> >>> looking at the ini you posted earlier, am I correct in assuming that
> th
> >> e
> >>> generating "POV-Ray script" produces 2000 scene files named 'pacman_m
> od
> >> .pov'?
> >>
> >> Well, I have a model "pacman.pov" from which I generate "pacman_mod.po
> v"
> >> substituting the parameters at n step. Then I render this script,
> >> producing "pacman.png". And I move "pacman.png" to "pac%04d.png" with
> n.
> >>
> >>> also, since I cannot believe that you'd invoke a(ny) program 2000 tim
> es
> >>
> >>> manually, the script must somehow tell 2nd from 23rd run.  do you run
>  t
> >> he whole
> >>> thing lot from within another script?  (o/wise how do you prevent ove
> rw
> >> riting
> >>> 'pacman.png'?)
> >>
> >> It results 2000 files, from "pac0001.png" to "pac2000.png" with 2000
> >> steps. I have launched POV-Ray 2000 times, knowing parameters from
> >> 1 to n steps. Each step n I have new parameters, but I don't know n+1.
>
> >>
> >>> are you free to modify said POV-Ray script?  then, for instance, you
> co
> >> uld
> >>> change it to generate an array and include that from your scene, usin
> g
> >>> frame_number as index; though there'd likely be other, more efficient
>  w
> >> ays.  (I
> >>> also assume that the newly calculated data only depends on previous)
> >>
> >> I can't generate an array of parameters, because I know those partiall
> y.
> >> I'm drawing a trajectory, steps to steps, and I can't predict future.
> >>
> >>> anyway, I'm fairly certain that the "problem" can be addressed w/out
> re
> >> sorting
> >>> to compiling a new program.  :-)
> >>
> >> It's the simplest solution. If there's no command-line option to make
> >> POV-Ray quiet, I can build a macOS/Macports version, that will be quie
> t.
>
> Thanks for your help.
>
> Regards,
>
> --
> François LE COAT
> <http://eureka.atari.org/>

Post a reply to this message

Hi,

I had a talk with Bald Eagle, that is present in this newsgroup, about
the transformations of POV-Ray, in order to render all the eight
parameters I'm obtaining. I could also use OpenGL, because it may be
more appropriate for "real-time". But POV-Ray is more realistic, and
will be more and more convenient for "real-time" photographic rendering.

The WEB page that I mentioned will be modified, because it doesn't
represent all what I wanted to explain about what I'm doing.

All this is written in C/C++ using POV-Ray and OpenCV, but I also use
shell scripts, mainly `tcsh`. And I use extensively the macOS Macports
environment, that allows to use `xv`, ImageMagick, `ffmpeg` etc. And
of course POV-Ray and OpenCV library, regularly updated.

All of this would be totally impossible to develop without the Unix
environment, simply. It also works under GNU/Linux, with the same tools.

BayashiPascal writes:
> Francois LE COAT wrote:
> Thank you very much for the web page, it looks like a very interesting 
research
> project.
> 
>> POV-Ray is totally appropriate to show what I'm doing, because it can
>> represent the eight parameters I'm obtaining from the camera movement.

> 
> Sure, Pov-ray can do that perfectly. What I meant was another rendering
 engine
> could also do it as well, while avoiding the problem you face with Pov-
ray. For
> example a graphic library integrated to what you're using to launch the
 Pov-ray
> instances would avoid creating those 2000 external processes to run Pov
-ray. In
> a previous comment you were writing "pac%04d.png", maybe you're using t
he C
> programming language to generate the Pov-ray scripts and launch there r
endering?
> In that case, using a graphic library like, for example, OpenGL to rend
er images
> directly in the C program instead of using Pov-ray would allow you to g
et the
> same result while avoiding the problem encountered with Pov-ray.
> 
> But, I still do not understand completely your constraints and I shall 
no go
> further with hypothesis.
> 
> Anyway, bonne chance in your research ! :-)
> 
> Francois LE COAT wrote:
>> To explain what I'm doing I've done a WEB page that is not yet finishe
d:
>>
>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/tempora
l_disparity.html>
>>
>> POV-Ray is totally appropriate to show what I'm doing, because it can
>> represent the eight parameters I'm obtaining from the camera movement.

>>
>> I obtain the eight:
>>
>> - Tx horizontal translation
>> - Ty vertical translation
>> - Tz depth translation
>> - Rx pitch angle
>> - Ry yaw angle
>> - Rz roll angle
>> - Sx horizontal shear angle
>> - Sy vertical shear angle
>>
>> and POV-Ray can represent those all. This already have been discussed 
in
>> <news://povray.advanced-users> because I'm modelling the 3D motion.
>>
>> The issue here, is just to make POV-Ray quiet when I'm rendering...
>>
>> BayashiPascal writes:
>>> Trying to guess what you're doing. The execution of the 2000 renderin
gs is
>>> automated in some way but you're getting your data used to create the
 rendering
>>> script in real time, one image after the other, waiting new data to r
ender the
>>> next image, thus don't know in advance the new parameters. Am I right
 ?
>>>
>>> If that's the case, and if the rendering could be delayed, you could 
wait until
>>> you acquired the whole data for the 2000 images and implement a solut
ion as
>>> we've suggested in previous posts to render images at the end of acqu
isition.
>>> But may be you need to render the image as soon as its data are acqui
red and use
>>> the rendered image to acquire the next data ?
>>>
>>> Your video really sparks my curiosity. I'm also working on project us
ing
>>> Pov-ray, real world data and depth images. Would you mind telling us 
a little
>>> more about what you're doing ? Looks like some kind of 3D reconstruct
ion from
>>> data acquired by a drone ?
>>>
>>> I also understand that finding a solution, which I have no idea of, t
o the
>>> finder problem may be more practical to your use case, but, as jr, I 
still
>>> believe there may be a work around. The image you render looks simple
, and given
>>> the real time constraints (either during acquisition, rendering proce
ss or
>>> rendered image post processing) you seem to have, maybe Pov-ray is si
mply not
>>> the appropriate tool to your use case ?
>>>
>>> Hoping to be helpful,
>>> Pascal

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

I've completed the WEB page I mentioned. This image processing is
applied to a drone flying in Vosges a few days ago. I was thinking about
to apply the same computations with the flight of Ingenuity on Mars...

<https://en.wikipedia.org/wiki/Mars_Helicopter_Ingenuity>

The autonomous drone is landing today, and we'll have video sequences =
)

Francois LE COAT writes:
> I had a talk with Bald Eagle, that is present in this newsgroup, about
> the transformations of POV-Ray, in order to render all the eight
> parameters I'm obtaining. I could also use OpenGL, because it may be
> more appropriate for "real-time". But POV-Ray is more realistic, and
> will be more and more convenient for "real-time" photographic rendering
.
> 
> The WEB page that I mentioned will be modified, because it doesn't
> represent all what I wanted to explain about what I'm doing.
> 
> All this is written in C/C++ using POV-Ray and OpenCV, but I also use
> shell scripts, mainly `tcsh`. And I use extensively the macOS Macports
> environment, that allows to use `xv`, ImageMagick, `ffmpeg` etc. And
> of course POV-Ray and OpenCV library, regularly updated.
> 
> All of this would be totally impossible to develop without the Unix
> environment, simply. It also works under GNU/Linux, with the same tools
.
> 
> BayashiPascal writes:
>> Francois LE COAT wrote:
>> Thank you very much for the web page, it looks like a very interesting
 
>> research project.
>>
>>> POV-Ray is totally appropriate to show what I'm doing, because it can

>>> represent the eight parameters I'm obtaining from the camera movement
.
>>
>> Sure, Pov-ray can do that perfectly. What I meant was another renderin
g engine
>> could also do it as well, while avoiding the problem you face with Pov
-ray. For
>> example a graphic library integrated to what you're using to launch th
e Pov-ray
>> instances would avoid creating those 2000 external processes to run Po
v-ray. In
>> a previous comment you were writing "pac%04d.png", maybe you're using 
the C
>> programming language to generate the Pov-ray scripts and launch there 
rendering?
>> In that case, using a graphic library like, for example, OpenGL to ren
der images
>> directly in the C program instead of using Pov-ray would allow you to 
get the
>> same result while avoiding the problem encountered with Pov-ray.
>>
>> But, I still do not understand completely your constraints and I shall
 no go
>> further with hypothesis.
>>
>> Anyway, bonne chance in your research ! :-)
>>
>> Francois LE COAT wrote:
>>> To explain what I'm doing I've done a WEB page that is not yet finish
ed:
>>>
>>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/tempor
al_disparity.html> 
>>>
>>> POV-Ray is totally appropriate to show what I'm doing, because it can

>>> represent the eight parameters I'm obtaining from the camera movement
.
>>>
>>> I obtain the eight:
>>>
>>> - Tx horizontal translation
>>> - Ty vertical translation
>>> - Tz depth translation
>>> - Rx pitch angle
>>> - Ry yaw angle
>>> - Rz roll angle
>>> - Sx horizontal shear angle
>>> - Sy vertical shear angle
>>>
>>> and POV-Ray can represent those all. This already have been discussed
 in
>>> <news://povray.advanced-users> because I'm modelling the 3D motion.
>>>
>>> The issue here, is just to make POV-Ray quiet when I'm rendering...

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Francois LE COAT <lec### [at] atariorg> wrote:
> Hi,
>
> I've completed the WEB page I mentioned. This image processing is
> applied to a drone flying in Vosges a few days ago. I was thinking about
> to apply the same computations with the flight of Ingenuity on Mars...
>
> <https://en.wikipedia.org/wiki/Mars_Helicopter_Ingenuity>

Nice.
I modeled a drone propeller like that ... 7 years ago?

http://news.povray.org/povray.binaries.images/attachment/%3Cweb.53dd26749e0d00ba5e7df57c0%40news.povray.org%3E/propelle
r2_dragonfly.png?ttop=432863&toff=950

Post a reply to this message

Hi,

Bald Eagle writes:
> Francois LE COAT wrote:
>> I've completed the WEB page I mentioned. This image processing is
>> applied to a drone flying in Vosges a few days ago. I was thinking abo
ut
>> to apply the same computations with the flight of Ingenuity on Mars...

>>
>> <https://en.wikipedia.org/wiki/Mars_Helicopter_Ingenuity>
> 
> Nice.
> I modeled a drone propeller like that ... 7 years ago?
> 
> <http://news.povray.org/povray.binaries.images/attachment/%3Cweb.53dd26
749e0d00ba5e7df57c0%40news.povray.org%3E/propeller2_dragonfly.png?ttop=
432863&toff=950>

Great =)

The goal is modelling the trajectory and the visible relief with a
simple video, using the images from Ingenuity's camera, like in :

<https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/temporal_d
isparity.html>

the video is <https://www.youtube.com/watch?v=MzWu7zwdJSk> Do you
remember that we talked about translate <Tx,Ty,Tz>, rotate
<Rx,Ry,Rz> and shear (or skew) angles <Sx,Sy,0> for the camera ?
Then we can deduce the trajectory, and the monocular depth.

You'll see what it gives on Mars, if you haven't seen it in a
forest, with a drone, in winter ... This is spectacular :-)

Thanks for your help.

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

> Bald Eagle writes:
>> Francois LE COAT wrote:
>>> I've completed the WEB page I mentioned. This image processing is
>>> applied to a drone flying in Vosges a few days ago. I was thinking ab
out
>>> to apply the same computations with the flight of Ingenuity on Mars..
.
>>>
>>> <https://en.wikipedia.org/wiki/Mars_Helicopter_Ingenuity>
>>
>> Nice.
>> I modeled a drone propeller like that ... 7 years ago?
>>
>> <http://news.povray.org/povray.binaries.images/attachment/%3Cweb.53dd2
6749e0d00ba5e7df57c0%40news.povray.org%3E/propeller2_dragonfly.png?ttop=
432863&toff=950> 
>>
> 
> Great =)
> 
> The goal is modelling the trajectory and the visible relief with a
> simple video, using the images from Ingenuity's camera, like in :
> 
> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/temporal
_disparity.html> 
> 
> 
> the video is <https://www.youtube.com/watch?v=MzWu7zwdJSk> Do you
> remember that we talked about translate <Tx,Ty,Tz>, rotate
> <Rx,Ry,Rz> and shear (or skew) angles <Sx,Sy,0> for the camera ?
> Then we can deduce the trajectory, and the monocular depth.
> 
> You'll see what it gives on Mars, if you haven't seen it in a
> forest, with a drone, in winter ... This is spectacular :-)

I recently worked a little further on the trajectory of the drone...

     <https://www.youtube.com/watch?v=3PdUvGDCbQc>

Instead of using uniquely Ry (yaw) and Tz (translation), I also used
Tx (translation) and Rz (roll) to reconstruct the trajectory. I couldn't
use Ty (translation) and Rx (pitch) because it is not looking like a
valid camera displacement. I have no real explanation.

But the aspect of the drone's trajectory is looking better ...

Thanks for your help.

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

>> Bald Eagle writes:
>>> Francois LE COAT wrote:
>>>> I've completed the WEB page I mentioned. This image processing is
>>>> applied to a drone flying in Vosges a few days ago. I was thinking 
>>>> about
>>>> to apply the same computations with the flight of Ingenuity on Mars.
..
>>>>
>>>> <https://en.wikipedia.org/wiki/Mars_Helicopter_Ingenuity>
>>>
>>> Nice.
>>> I modeled a drone propeller like that ... 7 years ago?
>>>
>>> <http://news.povray.org/povray.binaries.images/attachment/%3Cweb.53dd
26749e0d00ba5e7df57c0%40news.povray.org%3E/propeller2_dragonfly.png?ttop=
432863&toff=950> 
>>>
>>
>> Great =)
>>
>> The goal is modelling the trajectory and the visible relief with a
>> simple video, using the images from Ingenuity's camera, like in :
>>
>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/tempora
l_disparity.html> 
>>
>>
>> the video is <https://www.youtube.com/watch?v=MzWu7zwdJSk> Do you
>> remember that we talked about translate <Tx,Ty,Tz>, rotate
>> <Rx,Ry,Rz> and shear (or skew) angles <Sx,Sy,0> for the camera ?
>> Then we can deduce the trajectory, and the monocular depth.
>>
>> You'll see what it gives on Mars, if you haven't seen it in a
>> forest, with a drone, in winter ... This is spectacular :-)
> 
> I recently worked a little further on the trajectory of the drone...
> 
>      <https://www.youtube.com/watch?v=3PdUvGDCbQc>
> 
> Instead of using uniquely Ry (yaw) and Tz (translation), I also used
> Tx (translation) and Rz (roll) to reconstruct the trajectory. I couldn'
t
> use Ty (translation) and Rx (pitch) because it is not looking like a
> valid camera displacement. I have no real explanation.
> 
> But the aspect of the drone's trajectory is looking better ...

I worked on the sixth flight of the "Ingenuity" helicopter on Mars...

	<https://www.youtube.com/watch?v=pKUAsuXF6EA>

Unfortunately, there was an incident with the dated flight information
and the video sources from the NASA aren't so good for processing :-(
I wish we will have a color video, from the second embedded camera :-)

Thanks for your help.

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

>>> Bald Eagle writes:
>>>> Francois LE COAT wrote:
>>>>> I've completed the WEB page I mentioned. This image processing is
>>>>> applied to a drone flying in Vosges a few days ago. I was thinking 

>>>>> about
>>>>> to apply the same computations with the flight of Ingenuity on Mars
...
>>>>>
>>>>> <https://en.wikipedia.org/wiki/Mars_Helicopter_Ingenuity>
>>>>
>>>> Nice.
>>>> I modeled a drone propeller like that ... 7 years ago?
>>>>
>>>> <http://news.povray.org/povray.binaries.images/attachment/%3Cweb.53d
d26749e0d00ba5e7df57c0%40news.povray.org%3E/propeller2_dragonfly.png?ttop
=432863&toff=950> 
>>>>
>>>
>>> Great =)
>>>
>>> The goal is modelling the trajectory and the visible relief with a
>>> simple video, using the images from Ingenuity's camera, like in :
>>>
>>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/tempor
al_disparity.html> 
>>>
>>>
>>> the video is <https://www.youtube.com/watch?v=MzWu7zwdJSk> Do you
>>> remember that we talked about translate <Tx,Ty,Tz>, rotate
>>> <Rx,Ry,Rz> and shear (or skew) angles <Sx,Sy,0> for the camera ?
>>> Then we can deduce the trajectory, and the monocular depth.
>>>
>>> You'll see what it gives on Mars, if you haven't seen it in a
>>> forest, with a drone, in winter ... This is spectacular :-)
>>
>> I recently worked a little further on the trajectory of the drone...
>>
>>      <https://www.youtube.com/watch?v=3PdUvGDCbQc>
>>
>> Instead of using uniquely Ry (yaw) and Tz (translation), I also used
>> Tx (translation) and Rz (roll) to reconstruct the trajectory. I couldn
't
>> use Ty (translation) and Rx (pitch) because it is not looking like a
>> valid camera displacement. I have no real explanation.
>>
>> But the aspect of the drone's trajectory is looking better ...
> 
> I worked on the sixth flight of the "Ingenuity" helicopter on Mars...
> 
>      <https://www.youtube.com/watch?v=pKUAsuXF6EA>
> 
> Unfortunately, there was an incident with the dated flight information
> and the video sources from the NASA aren't so good for processing :-(
> I wish we will have a color video, from the second embedded camera :-)

If you read the comment from the NASA about the 8th flight of Ingenuity:

<https://mars.nasa.gov/technology/helicopter/status/308>

you understand that there was no color camera acquisition for the 7th
and the 8th flight on Mars. This was due to the incident on the 6th
flight, and a conflict between acquisition of the two embedded cameras.
Let's hope for subsequent flights of the helicopter, that NASA has fixed
the horodating problem. Let's hope we will have a color video from Mars.

Thanks for your help.

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Francois LE COAT <lec### [at] atariorg> wrote:
> Hi,
>
>
> If you read the comment from the NASA about the 8th flight of Ingenuity:
>
> <https://mars.nasa.gov/technology/helicopter/status/308>
>
> you understand that there was no color camera acquisition for the 7th
> and the 8th flight on Mars. This was due to the incident on the 6th
> flight, and a conflict between acquisition of the two embedded cameras.
> Let's hope for subsequent flights of the helicopter, that NASA has fixed
> the horodating problem. Let's hope we will have a color video from Mars.
>
> Thanks for your help.
>
> Best regards,
>
> --
>
> <http://eureka.atari.org/>


Well done ! :-)
I hope too there will be colors for the next videos.
Your system seems to work quite well. Do you have the data for the actual
trajectory and can you quantify the accuracy of your reconstructed trajectory ?
Are you working directly with the Ingenuity team, or just using their public
data ?

Bonne continuation :-)

Pascal

Post a reply to this message

Hi,

BayashiPascal writes:
> Francois LE COAT wrote:
>> If you read the comment from the NASA about the 8th flight of Ingenuit
y:
>>
>> <https://mars.nasa.gov/technology/helicopter/status/308>
>>
>> you understand that there was no color camera acquisition for the 7th
>> and the 8th flight on Mars. This was due to the incident on the 6th
>> flight, and a conflict between acquisition of the two embedded cameras
.
>> Let's hope for subsequent flights of the helicopter, that NASA has fix
ed
>> the horodating problem. Let's hope we will have a color video from Mar
s.
> 
> Well done ! :-)
> I hope too there will be colors for the next videos.

Oh, yes! We could only see static colors images for the moment. If it
moved, we could better have a representation of Ingenuity's motion.

> Your system seems to work quite well. Do you have the data for the actu
al
> trajectory and can you quantify the accuracy of your reconstructed traj
ectory ?

I have no "ground truth" about how the camera moves. NASA has data from
various sensors, because there is an IMU that is embedded. The comment
is explaining for the sixth flight, that those sensors are drifting...
"
If the navigation system relied on the IMU alone, it would not be very
accurate in the long run: Errors would quickly accumulate, and the
helicopter would eventually lose its way. To maintain better accuracy
over time, the IMU-based estimates are nominally corrected on a regular
basis, and this is where Ingenuity’s navigation camera comes in. 
For the
majority of time airborne, the downward-looking navcams are taking 30
pictures a second of the Martian surface and immediately feeding them
into the helicopter’s navigation system.
" <https://mars.nasa.gov/technology/helicopter/status/305>

Here's my result on 8th flight <https://www.youtube.com/watch?v=CRUh37x
pLT4>

> Are you working directly with the Ingenuity team, or just using their p
ublic
> data ?

I'm using public data. And those are extracted from real Mars data
acquired with the helicopter. NASA is not transmitting videos with
30 images/second. I have to deal with it. This is fantastic to work
on martian images, nevertheless :-)

> Bonne continuation :-)

Thanks for your interest.

> Pascal

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

> BayashiPascal writes:
>> Francois LE COAT wrote:
>>> If you read the comment from the NASA about the 8th flight of Ingenui
ty:
>>>
>>> <https://mars.nasa.gov/technology/helicopter/status/308>
>>>
>>> you understand that there was no color camera acquisition for the 7th

>>> and the 8th flight on Mars. This was due to the incident on the 6th
>>> flight, and a conflict between acquisition of the two embedded camera
s.
>>> Let's hope for subsequent flights of the helicopter, that NASA has fi
xed
>>> the horodating problem. Let's hope we will have a color video from Ma
rs.
>>
>> Well done ! :-)
>> I hope too there will be colors for the next videos.
> 
> Oh, yes! We could only see static colors images for the moment. If it
> moved, we could better have a representation of Ingenuity's motion.
> 
>> Your system seems to work quite well. Do you have the data for the act
ual
>> trajectory and can you quantify the accuracy of your reconstructed 
>> trajectory ?
> 
> I have no "ground truth" about how the camera moves. NASA has data from

> various sensors, because there is an IMU that is embedded. The comment
> is explaining for the sixth flight, that those sensors are drifting...
> "
> If the navigation system relied on the IMU alone, it would not be very
> accurate in the long run: Errors would quickly accumulate, and the
> helicopter would eventually lose its way. To maintain better accuracy
> over time, the IMU-based estimates are nominally corrected on a regular

> basis, and this is where Ingenuity’s navigation camera comes in
. For the
> majority of time airborne, the downward-looking navcams are taking 30
> pictures a second of the Martian surface and immediately feeding them
> into the helicopter’s navigation system.
> " <https://mars.nasa.gov/technology/helicopter/status/305>
> 
> Here's my result on 8th flight 
> <https://www.youtube.com/watch?v=CRUh37xpLT4>
> 
>> Are you working directly with the Ingenuity team, or just using their 

>> public
>> data ?
> 
> I'm using public data. And those are extracted from real Mars data
> acquired with the helicopter. NASA is not transmitting videos with
> 30 images/second. I have to deal with it. This is fantastic to work
> on martian images, nevertheless :-)
> 
>> Bonne continuation :-)
> 
> Thanks for your interest.
> 
>> Pascal

Here is the first color image sequence from 9th flight on planet Mars:

	<https://www.youtube.com/watch?v=0ug5BgZeNK4>

The algorithm driving Ingenuity is pushed to the limits...

	<https://mars.nasa.gov/technology/helicopter/status/314>

I really look forward to look at a real film from this color camera!

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

I've run into the same problem.  The regular Mac release of POVRay is a GUI
tool.  Usually that's nice, but occasionally I want the command line interface
and there isn't any way to get to it.
For example, FreeCAD has a "render" tool that can feed scene descriptions to
ray-tracers such as POV-Ray.  It does so by creating the .pov file and then
invoking POVRay as a command line utility.  But on Mac that doesn't work because
it can't be configured to be told what to do using Unix command line arguments
-- even though Mac OS is a Unix.
Some graphics applications have a command line switch to say "turn off GUI"
(like "-batch" or the like); it would be useful for POVRay to offer something
along those lines.

Post a reply to this message

Hi,

pkoning writes:
> I've run into the same problem.  The regular Mac release of POVRay is a
 GUI
> tool.  Usually that's nice, but occasionally I want the command line in
terface
> and there isn't any way to get to it.
> For example, FreeCAD has a "render" tool that can feed scene descriptio
ns to
> ray-tracers such as POV-Ray.  It does so by creating the .pov file and 
then
> invoking POVRay as a command line utility.  But on Mac that doesn't wor
k because
> it can't be configured to be told what to do using Unix command line ar
guments
> -- even though Mac OS is a Unix.
> Some graphics applications have a command line switch to say "turn off 
GUI"
> (like "-batch" or the like); it would be useful for POVRay to offer som
ething
> along those lines.

Thanks for reporting your experience with POV-Ray in command line.
Because I use binaries from Macports, I don't know who I should
contact, in order to use POV-Ray port. Is there a mailing-list?

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

I've made a WEB page about 18th flight of Ingenuity over planet Mars:

It's possible to reconstruct visible relief, and trajectory from the
Ingenuity drone, using a simple video sequence. The monocular disparity
is obtained by matching images with a reference, measuring optical-
flow. The trajectory is obtained using parameters of the perspective
transformation describing successive images...

<https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/trajectory
.html>

Since April 19, 2021, the Ingenuity helicopter sent to Mars hasn't
stopped flying over the planet. It was expected taking off only
5 times, to demonstrate that it was possible. In fact, we are in
February 2022, and a final realization of 19th flight over Mars, was
attempted. The measurements we take correspond to 18th flight over
planet Mars, dated 15 December 2021.

The localization of the piloting assistance camera which is obtained,
is not perfect. The lens of this camera has a radial distortion, what
is not taken into account by the perspective kinematics model.

>> BayashiPascal writes:
>>> Francois LE COAT wrote:
>>>> If you read the comment from the NASA about the 8th flight of Ingenu
ity:
>>>>
>>>> <https://mars.nasa.gov/technology/helicopter/status/308>
>>>>
>>>> you understand that there was no color camera acquisition for the 7t
h
>>>> and the 8th flight on Mars. This was due to the incident on the 6th
>>>> flight, and a conflict between acquisition of the two embedded camer
as.
>>>> Let's hope for subsequent flights of the helicopter, that NASA has f
ixed
>>>> the horodating problem. Let's hope we will have a color video from M
ars.
>>>
>>> Well done ! :-)
>>> I hope too there will be colors for the next videos.
>>
>> Oh, yes! We could only see static colors images for the moment. If it
>> moved, we could better have a representation of Ingenuity's motion.
>>
>>> Your system seems to work quite well. Do you have the data for the ac
tual
>>> trajectory and can you quantify the accuracy of your reconstructed tr
ajectory ?
>>
>> I have no "ground truth" about how the camera moves. NASA has data fro
m
>> various sensors, because there is an IMU that is embedded. The comment

>> is explaining for the sixth flight, that those sensors are drifting...

>> "
>> If the navigation system relied on the IMU alone, it would not be very

>> accurate in the long run: Errors would quickly accumulate, and the
>> helicopter would eventually lose its way. To maintain better accuracy
>> over time, the IMU-based estimates are nominally corrected on a regula
r
>> basis, and this is where Ingenuity’s navigation camera comes i
n. For the
>> majority of time airborne, the downward-looking navcams are taking 30
>> pictures a second of the Martian surface and immediately feeding them
>> into the helicopter’s navigation system.
>> " <https://mars.nasa.gov/technology/helicopter/status/305>
>>
>> Here's my result on 8th flight 
>> <https://www.youtube.com/watch?v=CRUh37xpLT4>
>>
>>> Are you working directly with the Ingenuity team, or just using their
 
>>> public
>>> data ?
>>
>> I'm using public data. And those are extracted from real Mars data
>> acquired with the helicopter. NASA is not transmitting videos with
>> 30 images/second. I have to deal with it. This is fantastic to work
>> on martian images, nevertheless :-)
>>
>>> Bonne continuation :-)
>>
>> Thanks for your interest.
>>
>>> Pascal
> 
> Here is the first color image sequence from 9th flight on planet Mars:
> 
>      <https://www.youtube.com/watch?v=0ug5BgZeNK4
>
> 
> The algorithm driving Ingenuity is pushed to the limits...
> 
>      <https://mars.nasa.gov/technology/helicopter/s
tatus/314>
> 
> I really look forward to look at a real film from this color camera!

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

Francois LE COAT writes:
> To explain what I'm doing I've done a WEB page that is not yet finished
:
> 
> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/temporal
_disparity.html> 
> 
> 
> POV-Ray is totally appropriate to show what I'm doing, because it can
> represent the eight parameters I'm obtaining from the camera movement.
> 
> I obtain the eight:
> 
> - Tx horizontal translation
> - Ty vertical translation
> - Tz depth translation
> - Rx pitch angle
> - Ry yaw angle
> - Rz roll angle
> - Sx horizontal shear angle
> - Sy vertical shear angle
> 
> and POV-Ray can represent those all. This already have been discussed i
n
> <news://povray.advanced-users> because I'm modelling the 3D motion.
> 
> The issue here, is just to make POV-Ray quiet when I'm rendering...

Here is what was done with a sequence at Mont Saint-Michel...

	<https://www.youtube.com/watch?v=zd_ZXEgX8tw>

There are three parts to the video, corresponding to three measures
of the optical-flow: IODP, Farneback and DualTVL1. This gives three
measures of different monocular depth (Temporal Disparity), quality
growing. What is shown is that one can as well see the relief of a
scene, with two eyes in stereo, or with one eye in mono through
movement.

Let's experiment... You can either see the relief by closing one eye
moving, or with both eyes without moving. Movement (as with TV, and
without glasses) allows you to perceive the relief! There is no need
to be equipped with a virtual reality headset (VR).

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

Francois LE COAT wrote:
>> To explain what I'm doing I've done a WEB page that is not yet finishe
d:
>>
>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/tempora
l_disparity.html> 
>>
>>
>> POV-Ray is totally appropriate to show what I'm doing, because it can
>> represent the eight parameters I'm obtaining from the camera movement.

>>
>> I obtain the eight:
>>
>> - Tx horizontal translation
>> - Ty vertical translation
>> - Tz depth translation
>> - Rx pitch angle
>> - Ry yaw angle
>> - Rz roll angle
>> - Sx horizontal shear angle
>> - Sy vertical shear angle
>>
>> and POV-Ray can represent those all. This already have been discussed 
in
>> <news://povray.advanced-users> because I'm modelling the 3D motion.
>>
>> The issue here, is just to make POV-Ray quiet when I'm rendering...
> 
> Here is what was done with a sequence at Mont Saint-Michel...
> 
>      <https://www.youtube.com/watch?v=zd_ZXEgX8tw>
> 
> There are three parts to the video, corresponding to three measures
> of the optical-flow: IODP, Farneback and DualTVL1. This gives three
> measures of different monocular depth (Temporal Disparity), quality
> growing. What is shown is that one can as well see the relief of a
> scene, with two eyes in stereo, or with one eye in mono through
> movement.
> 
> Let's experiment... You can either see the relief by closing one eye
> moving, or with both eyes without moving. Movement (as with TV, and
> without glasses) allows you to perceive the relief! There is no need
> to be equipped with a virtual reality headset (VR).

Here is a similar demonstration with a sequence at Notre-Dame...

     <https://www.youtube.com/watch?v=F_J0l_B5A2s>

With these conditions, the drone is flying in a transverse direction.
The monocular depth (temporal disparity) is therefore measured
horizontally. The trajectory is reconstructed in a birdview, at a
constant altitude. There is a yaw rotation (Ry). The four shown
displacement components are <Tx,Ty,Tz,Ry>. All mosaics representing
perspective registration measure have an inter-correlation index
that is not below 60%.

Thanks for your help.

Regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

Francois LE COAT writes:
> I've made a WEB page about 18th flight of Ingenuity over planet Mars:
> 
> It's possible to reconstruct visible relief, and trajectory from the
> Ingenuity drone, using a simple video sequence. The monocular disparity

> is obtained by matching images with a reference, measuring optical-
> flow. The trajectory is obtained using parameters of the perspective
> transformation describing successive images...
> 
> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/trajecto
ry.html> 
> 
> 
> Since April 19, 2021, the Ingenuity helicopter sent to Mars hasn't
> stopped flying over the planet. It was expected taking off only
> 5 times, to demonstrate that it was possible. In fact, we are in
> February 2022, and a final realization of 19th flight over Mars, was
> attempted. The measurements we take correspond to 18th flight over
> planet Mars, dated 15 December 2021.
> 
> The localization of the piloting assistance camera which is obtained,
> is not perfect. The lens of this camera has a radial distortion, what
> is not taken into account by the perspective kinematics model.

We are in August 2023, and the Ingenuity helicopter still flies over
Mars. There's no GPS satellite system on the planet, and a very little
atmosphere compared to Earth, but it is localizing itself with a
grey-scale camera that points to the ground, and it works like that...

Here is a video <https://www.youtube.com/watch?v=TP_ojUa6XtU>

The image processing computations are obtained from interpolation
performed at <https://twitter.com/stim3on/status/1419414689998594051>
by Simeon Schmauß. That's because video are too sparse when it is
transmitted down the JPL/NASA Laboratory at Caltech University...

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

Francois LE COAT writes:
>> I've made a WEB page about 18th flight of Ingenuity over planet Mars:
>>
>> It's possible to reconstruct visible relief, and trajectory from the
>> Ingenuity drone, using a simple video sequence. The monocular disparit
y
>> is obtained by matching images with a reference, measuring optical-
>> flow. The trajectory is obtained using parameters of the perspective
>> transformation describing successive images...
>>
>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/traject
ory.html> 
>>
>>
>> Since April 19, 2021, the Ingenuity helicopter sent to Mars hasn't
>> stopped flying over the planet. It was expected taking off only
>> 5 times, to demonstrate that it was possible. In fact, we are in
>> February 2022, and a final realization of 19th flight over Mars, was
>> attempted. The measurements we take correspond to 18th flight over
>> planet Mars, dated 15 December 2021.
>>
>> The localization of the piloting assistance camera which is obtained,
>> is not perfect. The lens of this camera has a radial distortion, what
>> is not taken into account by the perspective kinematics model.
> 
> We are in August 2023, and the Ingenuity helicopter still flies over
> Mars. There's no GPS satellite system on the planet, and a very little
> atmosphere compared to Earth, but it is localizing itself with a
> grey-scale camera that points to the ground, and it works like that...
> 
> Here is a video <https://www.youtube.com/watch?v=TP_ojUa6XtU>
> 
> The image processing computations are obtained from interpolation
> performed at <https://twitter.com/stim3on/status/1419414689998594051>
> by Simeon Schmauß. That's because video are too sparse when it is
> transmitted down the JPL/NASA Laboratory at Caltech University...

Ingenuity made its 55th flight on August 12, 2023, what demonstrates the
robustness of the control GNU/Linux system, including in particularly
hostile conditions, an unknown environment and minimal supervision,
because the helicopter is almost autonomous, very very far from
everything somewhere in space.

Best regards,

-- 
François LE COAT
<http://eureka.atari.org/>

Post a reply to this message

Hi,

Francois LE COAT writes:
>>> I've made a WEB page about 18th flight of Ingenuity over planet Mars:

>>>
>>> It's possible to reconstruct visible relief, and trajectory from the
>>> Ingenuity drone, using a simple video sequence. The monocular dispari
ty
>>> is obtained by matching images with a reference, measuring optical-
>>> flow. The trajectory is obtained using parameters of the perspective
>>> transformation describing successive images...
>>>
>>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/trajec
tory.html> 
>>>
>>>
>>> Since April 19, 2021, the Ingenuity helicopter sent to Mars hasn't
>>> stopped flying over the planet. It was expected taking off only
>>> 5 times, to demonstrate that it was possible. In fact, we are in
>>> February 2022, and a final realization of 19th flight over Mars, was
>>> attempted. The measurements we take correspond to 18th flight over
>>> planet Mars, dated 15 December 2021.
>>>
>>> The localization of the piloting assistance camera which is obtained,

>>> is not perfect. The lens of this camera has a radial distortion, what

>>> is not taken into account by the perspective kinematics model.
>>
>> We are in August 2023, and the Ingenuity helicopter still flies over
>> Mars. There's no GPS satellite system on the planet, and a very little

>> atmosphere compared to Earth, but it is localizing itself with a
>> grey-scale camera that points to the ground, and it works like that...

>>
>> Here is a video <https://www.youtube.com/watch?v=TP_ojUa6XtU>
>>
>> The image processing computations are obtained from interpolation
>> performed at <https://twitter.com/stim3on/status/1419414689998594051>
>> by Simeon Schmauß. That's because video are too sparse when it is
>> transmitted down the JPL/NASA Laboratory at Caltech University...
> 
> Ingenuity made its 55th flight on August 12, 2023, what demonstrates th
e
> robustness of the control GNU/Linux system, including in particularly
> hostile conditions, an unknown environment and minimal supervision,
> because the helicopter is almost autonomous, very very far from
> everything somewhere in space.

*Ingenuity over planet Mars*
In Mastodon by Simeon Schmauß at 2023/10/07
#Ingenuity #Perseverance #Mars2020 #Mars #NASA #Solarocks

<https://www.youtube.com/shorts/gV0iPwSCFBY>

Here is a look back at Ingenuity's 59th flight on Mars, as captured by
the Mastcam-Z on the Perseverance Rover.

In this view, I've heavily enhanced the dust blown away during takeoff.
You can also see dust devils moving in the background!

Best regards,

-- 
François LE COAT
<https://eureka.atari.org/>

Post a reply to this message