Re: [hugin-ptx] Re: new c++ code for environment images and reprojection

['Kay F. Jahnke' via hugin and other free panoramic software]

On 08.06.24 22:51, 'chaosjug' via hugin and other free panoramic 
software wrote:


Some more info can be found here:
https://ffmpeg.org/ffmpeg-filters.html#v360
https://ffmpeg.org/ffmpeg-filters.html#sendcmd_002c-asendcmd


Thanks as well for these links! I've read through the documentation, and 
it looks like ffmpeg is extremely capable when it comes to producing a 
video from an environment. It knows a lot of output projections, and it 
even does cubemaps! That took me quite some programming, and I did not 
cover other cubemap formats like 3:2 - only 1:6 and six single images. 
Dual fisheye format also turns up - that's another candidate I have in 
mind to include in envutil, both as input and output. I did some work 
with dual fisheyes in lux after someone sent me some sample images from 
a Xiaomi mi sphere camera but didn't take it any further then - just 
made a PTO to use the camera's image as input to lux.


I tried your example to produce the pan video here, and it worked, but I 
think maybe there's an issue. I get this message:


[vost#0:0/libx264 @ 0x558d9c0040c0] More than 1000 frames duplicated

And the video seems to stagger a  bit - like jump in small increments 
from one view to the next, rather than panning smoothly. Maybe the yaw 
angle is calculated in integer arithmetic instead of floating point? 
Just a guess. I've played a bit with the cmd.txt, but I can't seem to 
get rid of the duplicate frames.




--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/54b68828-36ca-4ba7-91ec-816fd4f2b642%40yahoo.com.

Re: [hugin-ptx] Re: new c++ code for environment images and reprojection

['Kay F. Jahnke' via hugin and other free panoramic software]

On 08.06.24 22:51, 'chaosjug' via hugin and other free panoramic 
software wrote:

Hi,

ffmpg is capable to do this in one go. It's been a while since I did this so I 
must admit that I don't
completely understand what I did, but this should create a 360° rotation pan of 
a panorama image:

ffmpeg -loop 1 -i panorama_image.jpg -vf 
"sendcmd=f=cmd.txt,v360=input=e:output=flat:ih_fov=360:iv_fov=180:h_fov=120:v_fov=88.5:w=1920:h=1080:pitch=-10:reset_rot=true:interp=cube"
 -t 72 -vcodec libx264 -crf 25 -r 50 -pix_fmt yuv420p output.mov


Hey, cool, I'm always impressed by just how versatile ffmpeg is!
Let me make two points:

- The method to use a sequence file is perfectly general, it can process 
any sequence of images taken from the same virtual camera location. 
envutil also reprojects to six different projections, so I think it's 
got a wider range of applications. The 360 degree pan I suggest is 
merely a simple example which is easy to generate with a loop in bash.


- My problem just now is how to pump frames into a video in C++, to 
avoid the single-image route. The ffmpeg code I use is twenty years old, 
can you maybe suggest something else? It should really be quite simple. 
I looked around some, and was quite disappointed not to find a 
ready-made piece of code which simply 'eats' C arrays of image data and 
combines them into a video. It doesn't have to be ffmpeg - I use that 
code because OIIO 'pulls it in' anyway, so I don't have to add another 
dependency, but I wouldn' mind that, either. Ultimately, of course, I 
hope that OIIO improves their ffmpeg plugin to not only read from but 
also write to videos. That would be my favourite outcome.


Currently, the video output from envutil doesn't seem to be good for 
many video players, so I suggest using the single-image path if the 
video doesn't work. That's to be able to compare the different 
anti-aliasing filters in a moving image - I hope that my new approach of 
'twining' compares quite well!


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/6930d612-14ea-40db-a477-9adb6b8c1d7a%40yahoo.com.

Re: [hugin-ptx] Re: Question about Lux and PTO files

['Kay F. Jahnke' via hugin and other free panoramic software]

On 27.04.24 11:04, David W. Jones wrote:



On April 26, 2024 10:35:22 PM HST, "'Kay F. Jahnke' via hugin and other free panoramic 
software"  wrote:


I think 'Panini Perspective Tool' made an attempt ...


I think I found their site:

<https://github.com/lazarus-pkgs/panini>


well found - I last saw their site on sourceforge. I tried the AppImage. 
They have a menu point to open a PT file, but then it only pops up a 
small window 'to be implemented'. So much for that...


And I tried a full spherical, it did not work right. But you see what 
they were aiming at.



Not very active. The most recent AppImage is 0.73 from 2019. Didn't see 
anything about a 'pro' version.


Seems to be all FOSS now. Even though I never managed to get it to work 
for me, it was an inspiration. Also mathmap, remember that?


https://www.complang.tuwien.ac.at/schani/mathmap/

I once wrote to them telling them thank you and that they were an 
inspiration, but nothing ensued.


Now I have lux. I think I'm better off.



--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/ed76e089-5973-4faf-aef9-c7d42cccf61a%40yahoo.com.

Re: [hugin-ptx] Re: Question about Lux and PTO files

['Kay F. Jahnke' via hugin and other free panoramic software]

On 27.04.24 10:21, David W. Jones wrote:


I agree, lux is an achievement. It's the only image viewer besides Hugin that 
can view PTO files.


I think 'Panini Perspective Tool' made an attempt or at least a claim - 
didn't they come up with a 'pro' version after some time asking for 
money? I managed to build it from the last freely available sources for 
a while, but it never worked for me... especially the PTO viewing never 
did what I wanted. Maybe because I tried to get it to run on Linux.



For lux to function fully as a *viewer* for PTO files, I think it needs to 
apply the PTO file's crop settings. It can have an option to use (or not use) 
the crop settings.


Okay, point taken. Maybe in a future lux version.

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/a259f459-ccc0-47b7-b2d7-8c72223fe06c%40yahoo.com.

Re: [hugin-ptx] lux 1.2.2 released

['Kay F. Jahnke' via hugin and other free panoramic software]

On 24.04.24 18:19, mpgve... wrote:


had some time and did some testing comparing enblend/nona vs lux.
these results are from the same system with the same set of images, 
results on your system are different ;)


image quality was good, sometimes a bit better, sometimes a bit less, 
depending on lighting conditions that make the need for blending important.


Nice to hear you're happy with the image quality! I suppose the size 
issue has sorted itself out with specifying the compression?


i didn't like that lux out of the box worked with a preview full screen, 
it made it impossible to use the system (without a 2nd monitor) while it 
was running.


try this:

lux --fullscreen=no --window_width=320 --window_height=200 --stitch=yes 
*.pto


then you'll only get a small window displaying the current PTO in the 
headline and showing a view to the currently stitched PTO which does not 
take much CPU time. You can even pass -n to show nothing but the lux 
logo. I'd like to figure out a way to run without a visible window, but 
with lux being a viewer, a lot depends on the window and it's hard to do 
without it.


while i run nona -g(pu) this only has an speed advantage if i start more 
than one script, i gives the system time to sync those operations and 
creates more headroom on the cpu for that 3rd script running.


Looks like lux is coming out quite well. I see that the call to exiftool 
eats up a lot of time. This comes as no surprise, because AFAICT 
exiftool doesn't simply modify the metadata in the image but makes a copy.


i set one instance Nona -g/Enblend/Exif at 100, the other values are 
related to that.
Lux/Exif is just a bit faster than 2 instances of Nona -g/Enblend/Exif 
running the same set.


When part of the work can be delegated to the GPU, that's usually the 
fastest way to go. lux is completely CPU-based. If you want to push your 
system to the limit, it may even be possible to have lux and 
nona/enblend run in parallel: lux will push the CPU to the limit, and 
nona/enblend can access the GPU where they can. You can tell lux to use 
only a specific number of threads for rendering, so if you have four 
cores, you could use --snapshot_threads=3 to leave one core free to 
handle the CPU load of the other processes and have lux render with 
three threads.


Thanks for sharing your insights! Depending on the precise nature of 
your stitches, you may be able to slash processing time with lux. What 
you get is the defaults, but lux is very configurable.



--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/1f440708-bee2-4f3b-ae63-0bd53a190c4a%40yahoo.com.

Re: [hugin-ptx] lux 1.2.0 released > 1.2.2

['Kay F. Jahnke' via hugin and other free panoramic software]

On 23.04.24 22:21, Maarten Verberne wrote:


I did a small test, my first impression is that it's quicker.


If your panoramas are not very large and you have enough memory, using 
lux should be faster, because it can keep everything in memory and does 
not need temporary files. It's also fully multithreaded and exploits the 
SIMD units of modern CPUs. The nona/enblend toolchain can use the GPU, 
though, which may be faster for some of the processing.



in the pto states that jpg compression should be 100% (no compression)


lux does not look at these settings in the PTO. It only looks at a few 
data in the PTO and ignores the rest. The default compression rate for 
JPEGs in lux is 90%, if you want a different compression, you must tell 
lux on the command line, e.g. with --snapshot_compression=100 if you 
want 100%. Here's a quote from the lux documentation:


  please be aware of the fact that lux only processes a subset of
  PTO format:

  - orientation (yaw, pitch, roll only, *not* translation)
  - horizontal field of view
  - exposure value
  - projection (only those projections known to lux, and not 'mosaic')
  - lens correction parameters
  - vignetting control parameters
  - source image cropping
  - source image masks
  - stacks (in animated sequences, only the 'stack parent' is displayed)

but the resulting jpg files are a factor 4 smaller in size than with my 
nona/enblend combo and actually have a filesize close to a single 
original jpg image of the 2.
this might be due to the fact that nona first generates very large tiff 
files, but i'm not sure if there might be something else.


Try with 100% compression and see if the difference is still large. lux 
and nona/enblend use completely different processing, lux does not use 
panotools. When you have the 100% output from lux, look at it critically 
(e.g. is the resolution and sharpness good enough for you, are the 
colours okay, is the blending correct) - don't expect a drop-in 
replacement. lux may be better or worse for a given image set, and 
output from lux can be quite different from what you get from the 
panotools tool chain, e.g. due to the fact that lux does not use seam 
optimization but stitches with seams derived from a data model 
resembling a spherical voronoi digram.


i still need to do a full test to see how they actually look and the 
script runs, but like i wrote, that's for this weekend


Good luck!

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/fd0498ac-b579-4d83-a70b-535218af2465%40yahoo.com.

Re: [hugin-ptx] lux 1.2.0 released > 1.2.2

['Kay F. Jahnke' via hugin and other free panoramic software]

On 23.04.24 09:35, Maarten Verberne wrote:


for me, the text editing way is much easyer because i only have the 
folder and image number that i need to change and i can automate that.


When I fuse brackets, I also put each bracket in a separate folder. Then 
I run a script which visits all these folders and runs align_image_stack 
there, producing a file 'bracket.pto' in that folder. Then I can either 
call lux right then to fuse the bracket, or defer until later.

Maybe you can use a similar scheme.

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4ff4ec6e-79a4-457e-92cf-e51330196eb8%40yahoo.com.

Re: [hugin-ptx] lux 1.2.0 released

['Kay F. Jahnke' via hugin and other free panoramic software]

On 22.04.24 12:29, Maarten Verberne wrote:

all those similar pto files just for the imagenumber does sound a bit 
excessive.

but hey, if that's the way.


There's nothing stopping you from modifying the PTO files as text files 
with any old text processing tool. But lux needs a PTO file which does 
not contain any placeholders or such.


I'll take your post as an inspiration, though, and think about ways how 
to make templating possible with lux. I already have some (undocumented) 
code which I think could be bent to the task - I'll post again if I can 
figure something out. It will probably need additional command line 
parameters or a .lux file wrapping the .pto



You'll have to refer to exiftool decumantation for that.


I did, but i wasn't clever enough to make it work. let's leave it there ;)


Yes, exiftool is quite a mouthful. This is another thing on my list - 
I'd like to have settings in lux which pick a given set of attributes 
from the source file(s) and move them to the target. I already handle 
EXIF metadata (you can have a selection displayed in the status line), 
but so far the only metadata I write to the output are the ones 
describing the geometry and cropping of the image. In my scripting, I 
use something like this to propagate the metadata:


exiftool -overwrite_original \
 -tagsFromFile "$SOURCE" \
 -All:All \
 '-DateTimeOriginal>FileModifyDate' \
 "$TARGET"

Just make a single PTO first, see how it stitches with lux, and if you 
get the knack of it, you can try several in one go. Good luck!




i've just downloaded lux 1.2, but one imageset is no test for me, so i'm 
going ahead with making a bunch of pto files.
only than can i compare different light conditions throughout the day 
and see how it runs as i would use it.


Making PTO files with scripting tools from the hugin toolset is not 
difficult. I use pto_gen, cpfind and autooptimiser. I prefer making a 
new PTO for every batch of images, to be sure the registration is 
correct. And when I fuse stacks, I use align_image_set, which can also 
expert PTOs.


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/e2bd62d2-c92b-49ba-8d61-5467df742e4c%40yahoo.com.

Re: [hugin-ptx] lux 1.2.0 released

['Kay F. Jahnke' via hugin and other free panoramic software]

On 22.04.24 11:21, Maarten Verberne wrote:


the command line is like this, with use of gpu for nona:

set nona="%ProgramFiles%\Hugin\bin\nona.exe"
set enblend="%ProgramFiles%\Hugin\bin\enblend.exe"

     %nona% -g -o out -m TIFF_m template.pto 
%Rfolder%/%date%/IMG_%imagenr%.JPG %Lfolder%/%date%/IMG_%imagenr%.JPG

     echo Done Nona
     %enblend% -o %outputname%-IMG_%imagenr%.JPG --compression %jq% 
out.tif out0001.tif

     echo Done Enblend, next file?


For lux, you need a PTO file as input if you want to stitch. I don't now 
about the templates and things you're using.



and lux replaces both nona and enblend?
something like?

set lux="%ProgramFiles%\Hugin\bin\lux.exe"

%lux% -g --stitch=yes %Rfolder%/%date%/IMG_%imagenr%.JPG 
%Lfolder%/%date%/IMG_%imagenr%.JPG template.pto -o 
%outputname%-IMG_%imagenr%.JPG


So, first you have to make the PTO - there are panotools scripting 
programs to make one from a set of images - and then you feed the PTO to 
lux. But it does replace the 'warping' with nona and the merging with 
enblend.


I know it's in hugin, but never understood how to employ exiftool via 
cmd and f.i. copy the left image exif data to the enblend output file.


You'll have to refer to exiftool decumantation for that.


i don't have any memory issues (yet), and i feel in a daring mood :)
I will try single and multi instances out and let you know, this might 
take some time though


Just make a single PTO first, see how it stitches with lux, and if you 
get the knack of it, you can try several in one go. Good luck!


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/9d054688-d3b5-4f3c-adde-6da3254af742%40yahoo.com.

Re: [hugin-ptx] lux for Linux as AppImage

['Kay F. Jahnke' via hugin and other free panoramic software]

Until now, I've only released new lux binaries when I released a new 
version, or if there was a 'special' reason - like a new experimental 
build. With my switch to AppImage, I'll offer more recent AppImages 
which are made straight from the master branch - not quite 'nightlies', 
but builds reflecting the status quo right when they are made. You can 
find these builds here:


https://bitbucket.org/kfj/pv/downloads/lux-master-x86_64.AppImage

The one I just uploaded already fixes a bug in lux 1.1.7, which produced 
a 'hanging' thread when lux was terminated due to an unrecoverable error.


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b51c9cfe-ba0e-1034-3ddd-7e6676238851%40yahoo.com.

Re: [hugin-ptx] lux for Linux as AppImage

['Kay F. Jahnke' via hugin and other free panoramic software]

On 16.07.23 04:19, David W. Jones wrote:


Regarding lux. The non-appimage version runs here, with its
non-intuitive way of handling mouse movements and image banding that
bugs the heck out of me.


Maybe your user experience can be improved? I feel that a UI close to 
360cities' QTVR mode is the best way to interact with, especially, full 
sphericals. Admittedly, this may take some time to learn if one isn't 
already familiar with it. What you mean with image banding I have no idea.


There once was a time when users felt they were part of a community. 
They would work with a program, and if something irked them or they had 
ideas what could be made better they would contact the developers and 
tell them. For developers, this feedback was valuable, because they 
often don't interact with the software from a user's point of view, 
because they are 'too much inside' the program and it's inner workings. 
And there were others in the community who'd help with technicalities 
like packaging, to keep such administrative tasks off the back of the 
developers, so that they could concentrate on the software's functionality.


So why am I using past tense? Because I feel these times have passed. 
I've been developing lux for several years now, and I feel there is no 
community feedback - apart from a few posts full of harsh critcism 
giving my program a bad name. I've seldom heard from anyone who actually 
said they liked something I made - they all just download it and I have 
no idea what happens then. Do they try it once then throw it away 
because they don't get it? Keep using it all the time so happily they 
never even think about it? They sure seem to take it for granted that 
someone would sit down and off-handedly re-implement the Burt 
image splining algorithm in their spare time and have no problem with 
ignoring the fact because, hey, it's been implemented before and we have 
used that for years why would we change...


And everyone takes for granted that, on top of developing the software, 
I do all the documentation, packaging, distribution and maintenance as 
well. Only if something is amiss, there may be a faint echo along the 
lines of 'your program is crap, xy does this much better' if their 
attention span isn't so short that they immediately proceed to the next 
promising stimulus.


If you have specific points in the user interface you'd like to discuss, 
why don't you just ask? It's quite possible that some things you'd like 
to have are already there and can be had by changing a few parameters. 
And, if not, how about asking for a feature? Rather than just 
complaining in a thread about a different issue (AppImages) that the UI 
bothers you. I feel you tend to give negative criticism. Can you 
recommend a good multi-platform panorama viewer which does everything to 
your liking?



I think lux would be more useful as a library usable by other programs
(like Hugin, Krita, GIMP, Blender, Inkscape) to tap GPU power for
remapping and rendering.


This is actually a good point. I don't agree lux would be more useful 
that way, but I think that some of my back-end code would come in handy 
in some of the programs you mention. But the core feature of lux is that 
it's rendering on the CPU, not the GPU.


There are always two aspects to using a library: the library provides 
features, a program uses them. I can make a beautiful library to no 
effect if noone uses it. Since you mention hugin, I proposed to make lux 
part of the hugin bundle. No interest. The proposal was shot down. So 
how do you think the hugin crew would react if I proposed to them to use 
functionality of a hypothetical lux library? I can't see that happening.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/0911d333-f62e-1745-a028-a65fcf113b38%40yahoo.com.

Re: [hugin-ptx] lux for Linux as AppImage

['Kay F. Jahnke' via hugin and other free panoramic software]

On 14.07.23 20:28, Harry van der Wolf wrote:

> Using ./lux-1.1.6-x86_64.AppImage
> ~/128GB/Afbeeldingen/1JTG/1tifpanos/2003-0713-0608\
> zomervakantie-Thisted-0725-0728_Thisted-038-Thisted-051-overall.tif
> does work.
>
> Using ./lux-1.1.6-x86_64.AppImage
> "~/128GB/Afbeeldingen/1JTG/1tifpanos/2003-0713-0608
> zomervakantie-Thisted-0725-0728_Thisted-038-Thisted-051-overall.tif"
> doesn't work.
>

On 14.07.23 20:40, Harry van der Wolf wrote:


You use:
$APPDIR/usr/bin/lux -w $APPDIR/usr/share/lux/fonts/NotoSans-Regular.ttf "$@"

Please try with:
$APPDIR/usr/bin/lux -w 
$APPDIR/usr/share/lux/fonts/NotoSans-Regular.ttf ${1+"$@"} &


I have doubts whether the tilde will work as expected inside the double 
quotes. If you use /home/... instead of the tilde, embedded ws is no 
problem with "$@". According to this:


https://unix.stackexchange.com/questions/151850/why-doesnt-the-tilde-expand-inside-double-quotes

inside double quotes, the tilde has no special meaning, so the second 
invocation you attempt will try and find file names containing literal 
tilde characters. If you try your invocation containing a tilde inside 
double quotes with plain lux, it won't work either. I think your second 
invocation (the one labeled 'doesn't work') is incorrect in the first place.


There are two good ways to deal with complicated file paths with lux:

1. cd to the folder and use relative names instead

2. echo the files and use lux in streaming mode:

  ls ~/awful\ folder\ with\ spaces/*.JPG | lux -

Note the trailing '-' in lux' argument list. This switches it to 
'streaming mode' where it accepts image file names from stdin. If these 
names contain ws, it's no problem.


Knowing streaming mode is good anyway - I often work up a set of images 
in a folder, which then contains mixed file names like IMG_1234.JPG, 
IMG_1234_IMG_1236.jpg and IMG_1234.lux.1.jpg. Then I make a file list, like


ls *.JPG *.jpg | sort > file.lst

Then, later on, to look at the image, I do

lux - < file.lst

For a slide show, throw in arguments like

--show_status_line=no --slide_interval=4 --slideshow_on=yes

Streaming mode is a cool tool to go through entire directory trees, as 
well. Try:


find ~/Pictures -name '*.jpg' -print | lux -d1 -

All of the above should work with the AppImage instead of plain lux' as 
well. The AppImage makes an attempt to 'blend in' an behave exactly as 
the contained binary would.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/1de837b7-a3e3-269b-ae93-221d8f0c2595%40yahoo.com.

Re: [hugin-ptx] lux for Linux as AppImage

['Kay F. Jahnke' via hugin and other free panoramic software]

I fixed the issue with passing filenames with white space on the CL and 
built a fresh AppImage on a Kubuntu 18.04 LTS VM, which should make the 
AppImage usable on even more platforms. You can download the new 
AppImage here:


https://bitbucket.org/kfj/pv/downloads/lux-1.1.6-x86_64.AppImage

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/cd48832f-3a07-bf14-8032-93b5d7d08650%40yahoo.com.

Re: [hugin-ptx] lux for Linux as AppImage

['Kay F. Jahnke' via hugin and other free panoramic software]

On 14.07.23 09:48, 'Kay F. Jahnke' via hugin and other free panoramic 
software wrote:

On 14.07.23 09:29, Harry van der Wolf wrote:

One remark: when specifying files or a single pano on the command 
line, it doesn't accept spaces in paths or file names. Not even when I 
enclose them in double or single quotes.


Ah, so you get that as well. I had similar problems yesterday, then 
forgot about it. Maybe I need to do some finessing in the AppRun script; 
I simply pass on arguments with $@. Thanks for pointing me to this 
issue. Luckily, when selecting images with lux' own file-select dialog 
(press 'F'), white space in the file name isn't a problem.


Silly me, of course I have to pass the args on with "$@" (with quotes).

I'm just now setting up a VM with ubuntu 18.04 to run a build on the 
recommended 'oldest still-supported ubuntu LTS release', then I'll build 
the AppImage again there and upload the new build.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/6ebd6752-9cb9-1aa8-342f-b25e992bfb38%40yahoo.com.

Re: [hugin-ptx] lux for Linux as AppImage

['Kay F. Jahnke' via hugin and other free panoramic software]

On 14.07.23 09:29, Harry van der Wolf wrote:

i tried it on my Chromebook under the builtin linux which is Debian 11. 
I tried creating a pano, viewing a pano and did some bracketing. That 
all works fine. I completely stopped with panos and bracketing so I had 
to take some old series.


I'm glad I got you back into it ;)
Thanks for trying it out!

One remark: when specifying files or a single pano on the command line, 
it doesn't accept spaces in paths or file names. Not even when I enclose 
them in double or single quotes.


Ah, so you get that as well. I had similar problems yesterday, then 
forgot about it. Maybe I need to do some finessing in the AppRun script; 
I simply pass on arguments with $@. Thanks for pointing me to this 
issue. Luckily, when selecting images with lux' own file-select dialog 
(press 'F'), white space in the file name isn't a problem.


And the remark about the app image being  "big". Those persons do not 
understand that you can create a universal 64bit intel for many 
platforms in one go which saves the developer a lot of time 
when developing open-source for his users (aa\nd him/herself of course). 
One developer can support a lot of users in one app image build run. 
Obviously they still work from floppy disks as modern systems have huge 
amounts of disk space. And then they produce a single (tif) pano of 
200~250 MB based on raw/tif images of 20~50 MB each. And when you record 
a 4k movie at a 100 MBps you have a video of 1GB after a minute.

What is that compared to a "small" appImage?


Indeed, it's next to nothing. The lux AppImage is about as large as some 
single (JPG) images from my Canon Powershot G9X Mk. II.


I have had the same questions/remarks for two of my appImages where 
users simply only look at their own environment without even looking at 
the "shocking" size of the images and videos they produce.


So you use AppImage as well. I like what I've seen from it so far. The 
docu is a bit hard to grasp initially, but the process is really quite 
simple. I think I'll invest a bit more time to bring my AppImages up to 
their standards for AppImageHub and distribute it for Linux like that. 
seems like a huge time-saver and should increase lux' visibility.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/8243092f-cd03-f56d-940c-786a3386c473%40yahoo.com.

Re: [hugin-ptx] lux for Linux as AppImage

['Kay F. Jahnke' via hugin and other free panoramic software]

On 14.07.23 00:04, David W. Jones wrote:

So sad to hear this. I've never been able to get AppImages, Flatpaks et 
al to work on my Debian 11 system. And the idea of a whole huge AppImage 
just for one pretty small application like Lux just seems like way overkill.


Oh, well.


What is this silly lament? Did you try? Actually, I can tell that you 
did not, because the download counter on my download page is still zero. 
So you just seem to have preconceived notions. And what do you mean by 
'huge'? The AppImage weighs in at 11.7 MB, which is less than the MacOS 
dmg and the windows installer (both 13.8). In fact, these latter two use 
a similar technology to the AppImage. The AppImage I distribute was 
actually built on debian 11, so here's a good chance for you to get your 
first AppImage to run on your system. Just a hint: after downloading, 
you have to set the execute permission. Then just execute it.


I'm also not sure what you mean by 'a pretty small application'. You 
surely can't mean it's functionality, so maybe you mean it's size? The 
Linux binary is 25 MB, and the packaging shrinks the data to less than 
half, even though it bundles a fair amount of libraries with it.


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b92d7125-b3bf-6ca0-9987-da0db4e78207%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

I use hugin for producing panoramic photos and thought I could use lux as a 
quick way to make jpgs using the hugin-produced .PTOs and original (sub)images. 
For 2D output rectilinear quickly becomes unwieldy as the size increases, and 
for architecural images spherical is really not a good choice.


I see, so it's about stitching a PTO file and producing an image which 
'looks nice' as a whole, rather than being good to view with a panorama 
viewer. For that purpose, using hugin/enblend is probably the better 
choice, but the process (create remapped partials first, then stitch 
them) is indeed a bit circuitous, compared to lux' integrated process.


When I look at the way how lux handles a PTO file specifying an 
unhandled projection (like Panini) in the p-line, I admit it's 
'ungraceful' - the p-line is only relevant for stitching, lux could 
display the PTO in any of the target projections it can handle, and a 
failure would only be necessary if the user actually requested stitching 
to the p-line, like when pressing 'Shift+E' or using --stitch=yes. I'll 
keep that in mind for the next version. Thank you for your input, sorry 
I can't be more helpful right now.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f710128b-8b23-a8d1-21fe-59fcfaa5560c%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

I just discovered Lux (on an M1 mac) – great work, thanks!


You're welcome! 1.1.6 is also out now (there's a separate thread on 
hugin-ptx with the release notes) and there's an M1 binary for that as well!


Any hope of supporting more projections? I regularly use panini 
projections for wide panoramas which now cause Lux to exit ungracefully.


If I remember correctly, Panini is not simply a single straight 
geometrical reprojection but quite a complex affair. It's made to make 
the result, printed out as a poster or such, look pretty, but it's not 
such a good candidate for fast reprojection in a panorama viewer, where 
every cycle counts when you're trying to produce the 60fps for smooth 
animations.


Where does the Panini cause you trouble? Are you trying to stitch a PTO 
to Panini projection or do you want to display a stitched image which is 
already in panini projection?


If you want to make your panorama lux-friendly, best stitch to 
spherical. If you're using hugin, tell it to supply your output with 
GPano metadata - lux can read them, and you'll get the correct geometry 
without fiddling.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/df46a2d2-cad5-5c49-a879-5473567a364c%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Dear all!

After a fair amount of testing and tweaking, I am now happy with my 
rendering back-end using the highway SIMD library. Vc, which I have used 
for intel CPUs until now, has better support for older CPUs: it offers 
dedicated AVX (without the '2') support and the 'fallback' mode is 
faster than when I use it with highway - but such CPUs are becoming 
increasingly rare and using lux with them is no fun, anyway. What tips 
the scale for me is AVX512 support. Vc does not produce actual AVX512 
instructions, instead it falls back to emitting AVX2 instructions, so 
there is not much to be gained in the rendering code which relies on the 
SIMD library - some other code which relies on autovectorization may 
benefit, but that's not so relevant. highway, on the other side, *does 
support AVX512*, and a friend of mine who has a CPU with AVX512 has run 
a test of the Vc version against the highway version of the code. The 
performance gain was more than 50%!


The binaries on my download page are all done with Vc (except for the 
macOS ARM64 build, which also uses highway because Vc does not produce 
native ARM NEON code). For those of you who have AVX512 on a windows 
machine, I now offer a lux-portable ZIP compiled with the highway 
backend, so you can see what a difference the SIMD backend makes! It 
would be nice if this binary could see a bit of testing, just to be sure 
the change of SIMD backend does not introduce unwanted behaviour which 
has escaped my scrutiny! I am considering switching to the highway 
backend altogether with the next lux version. Please find the ZIP file here:


https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.1.5_portable_with_highway.zip

Apart from AVX512, this build supports the fallback ISA (no SIMD), 
SSE4.2 and AVX2. The console output will tell you which CPU was detected.


Kay


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/9ae5c9e4-835c-9c20-c339-214c2fd64dfb%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 11.02.23 um 13:35 schrieb Robert Clausecker:


The location of dependencies is configurable when building the port, so
I cannot rely on just /usr/local.  While it is probably possible to
hack something for this, I'm not too keen on messing around with your
already fairly complex build scripts.  Will wait for the next Highway
release


Fair enough. They seem to release every two months or so.


(I've already tested with the latest git commit of Highway;
your port works fine with it).


Ah, that's good to know, thanks for the info! One worry less :D

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/477c54f9-24d6-a727-135c-e7c5c70792d1%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 10.02.23 um 15:50 schrieb Kay F. Jahnke:


You *can* fix it.


Not convinced? Here's my reasoning: You're build relies on the freeBSD 
highway package. Fulfilling the dependency means that highway will be 
installed in a specific location (e.g. /usr/local). Therefore you know 
that highway is available and accessible, and you don't need the CMake 
code to locate it.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/eada7171-cc32-500d-ddc2-ecb2b70c826e%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 10.02.23 um 13:18 schrieb Robert Clausecker:


Okay, I checked again: the feature you depend on is not part of Google
Highway 1.0.3, which is the newest published version.  Looks like it
went in just a few days after the release. I will therefore not be able
to package lux 1.1.5 until a Google Highway version with this feature
has been released.


Well, why don't you just apply the patch then? It's a simple fix and 
will work. Then it will work just fine with hwy 1.0.3.


If you don't want to use highway because you insist on using the CMake 
code I added recently to find it you could still build the Vc version, 
even though it may produce less 'true' SIMD code on some platforms.



I cannot fix this as I'm not going to bundle a second copy of Highway
just to build your package.  We'll have to wait until a new Highway
version is released.  Please avoid depending on unreleased features in
dependencies.  Makes it much harder to actually use your software.


You *can* fix it. All it takes is this patch to the CMakeLists.txt in 
the lux root folder:


diff --git a/CMakeLists.txt b/CMakeLists.txt
index 013a122..af5f18c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -598,17 +598,17 @@ endif()

 # highway has added code to find it with cmake config mode

-if(USE_HWY_LIBRARY)
-  find_package(HWY CONFIG REQUIRED)
-  if (HWY_FOUND)
-message(STATUS "find_package: HWY_FOUND = true")
-  endif()
-
-  if(NOT "${HWY_INCLUDE_DIR}" STREQUAL "")
-message(STATUS "HWY_INCLUDE_DIR = ${HWY_INCLUDE_DIR}")
-include_directories(${HWY_INCLUDE_DIR})
-  endif()
-endif()
+# if(USE_HWY_LIBRARY)
+#   find_package(HWY CONFIG REQUIRED)
+#   if (HWY_FOUND)
+# message(STATUS "find_package: HWY_FOUND = true")
+#   endif()
+#
+#   if(NOT "${HWY_INCLUDE_DIR}" STREQUAL "")
+# message(STATUS "HWY_INCLUDE_DIR = ${HWY_INCLUDE_DIR}")
+# include_directories(${HWY_INCLUDE_DIR})
+#   endif()
+# endif()

 set(required_libraries vigraimpex sfml-window sfml-graphics 
sfml-system exiv2)



--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f9d07bd1-7600-7824-320d-e14c079cf92c%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 09.02.23 um 22:16 schrieb Robert Clausecker:


How is this information “deployed” if not by placing a file somewhere?
CMake specifically asks for a file to be provided in the error message.
Here is the list of files installed for the devel/highway package:

https://cgit.freebsd.org/ports/tree/devel/highway/pkg-plist

Where is this information deployed?  If it is not there, where would it
be if it was there?


The list above does not contain all the files which should be deployed 
on the target machine. If I do a 'make install' on my machine with hwy 
master, it installs these files as well:


-- Installing: /usr/local/lib/cmake/hwy/hwy-config-version.cmake
-- Installing: /usr/local/lib/cmake/hwy/hwy-config.cmake
-- Installing: /usr/local/lib/cmake/hwy/hwy-config-relwithdebinfo.cmake

This is what I mean by 'deploy'. If you like, I can send you the files. 
Maybe you can ask the maintainer of the highway port to look at the 
matter - I suspect that these three files have to be added to the list. 
When they are present, CMake should find your highway install with 
CONFIG mode, as it's done in may lux CMakeLists.txt



The default location stuff is too fragile.


I agree, that's why I requested the addition of code to make highway 
findable with CMake. I'd like to stick with CMake for configuration. lux 
1.1.4 did rely on the default location, and the patch I proposed to you 
off-list yesterday evening would do just the same. Once the hwy port is 
updated, you can switch back to the unpatched version. I did not mean to 
propose a permanent solution, it's just to get you going with the 1.1.5 
build if the finding-hwy issue can't be resolved otherwise.


Kay



--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/1e203534-a220-b16f-27d2-512fb3bcb0f1%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 09.02.23 um 19:20 schrieb Robert Clausecker:
FreeBSD's package is 1.0.3, which is the most recent version, released 
Jan 19.
However, it does not ship this file.  Maybe I can just grab it from 
upstream.


It's not a file, cmake deploys the necessary information when you do a 
'make install' on the target machine. The separate find-file was 
dismissed as superfluous when deploying like that. I think it would be 
easier if you simply patch out the bit in may CMakeLists.txt which looks 
for highway.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/968007f1-1f9a-70b8-efff-0b358f66a4b1%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 09.02.23 um 18:30 schrieb Robert Clausecker:

One problem I noticed: the configuration fails to find the HWY cmake file.

CMake Error at CMakeLists.txt:602 (find_package):
   Could not find a package configuration file provided by "HWY" with 
any of

   the following names:

     HWYConfig.cmake
     hwy-config.cmake



To clarify further: this is the discussion leading to the decision to 
adopt finding with config mode in highway:


https://github.com/google/highway/issues/1084

The code went into their repo as of:

commit 2ea983105e69f0d8daa7b5e8ea1bcf8fb8ecaea3
...
Date:   Tue Jan 17 11:33:20 2023 +0100

Generate and install a HWYConfig.cmake file

This will be needed by cmake user consuming HWY.

Also remove FindHWY.cmake since not needed in a cmake-based
build tool setup.



--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/bc383b33-0b74-11fa-81c6-21bebd53632d%40yahoo.com.

Re: [hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 09.02.23 um 16:49 schrieb Robert Clausecker:

I was planning to update the FreeBSD package today, but noticed that you 
didn't upload the source code for 1.1.5 anywhere.
If this was not intentional, please let me know once you got around to 
do so!


Robert, the master in the repo and the binaries are already 1.1.5 (see 
pv_version.h), but I wanted it to 'hang around' for a little while 
before I assign the 1.1.5 tag, in case anyone notices bugs. I've just 
assigned the tag, does it now work for your build?


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/7341b2ef-0a9d-7e15-66f9-3b5bb4ec7375%40yahoo.com.

[hugin-ptx] lux image and panorama viewer: version 1.1.5 released

['Kay F. Jahnke' via hugin and other free panoramic software]

Dear all!

I've released lux 1.1.5. Again, most changes are 'behind the scenes', 
but there is important new functionality as well: lux now looks at the 
EXIF metadata of 'ordinary' rectilinear photographs and figures out the 
field of view. With that datum, 'normal' camera images are now displayed 
*with automatic perspective correction*. This is especially useful for 
panorama work: If you take out snapshots from rectilinear images, these 
snapshots will now automatically be geometrically correct and can be 
'fed back into' a panorama. This is good for, e.g. nadir patches. lux 
will also recognize a range of panoramic images made with the 'panorama' 
function of smartphone camera apps, using a heuristic to recognize such 
images, which typically don't have the required metadata and, therefore, 
were displayed as flat stripes up to 1.1.4. Introducing such features 
is, of course, a gamble - there's bound to be images where the detection 
doesn't work or goes wrong, but I've tested it with all image types I 
could get hold of and hope that it will work 'most of the time'. Of 
course you can still override the automatics.


Another feature worth mentioning is the .lux.ini file. If you put a file 
with that name (yes, it has a leading dot!) in your home folder, lux 
will look for parameters which it will adopt for the entire session, 
just as if you had passed them on the command line. The syntax is simple 
- in every line, you put one long option name, followed by '=' and the 
intended value, without any white space around the '=' sign. This is 
standard .lux syntax, as described in the documentation.


Apart from these new features, a great many small improvements and bug 
fixes should improve the user experience, while the user interface 
hasn't changed very much.


There's good news for Mac users: I was given an intel Mac, and so I 
could now do building and packaging for the mac myself, and I've made 
some progress - I could build a lux 1.1.5 package for intel-based Macs. 
I already mentioned with the release of 1.1.4 that lux can now use 
highway for time-critical rendering code, and this made it possible to 
build a lux version for 'apple silicon', which uses native ARM NEON SIMD 
instructions for speed similar to AVX2 on intel machines. A friend has 
built lux 1.1.5 with this backend on an *M1 mac* and made a package, 
which you can find alongside the i86 package on my download page:


https://bitbucket.org/kfj/pv/downloads

There are also a windows installer, a ZIP file with a portable windows 
version, a .deb file for ubuntu 20.10 and one for debian11, plus updated 
documentation in HTML format.


The MacOS versions are still not well-integrated with the system, and I 
haven't yet managed to create a 'universal binary' which will run on all 
macs. Finder integration is also largely missing: using 'open with lux' 
on images won't pass the filenames on to lux, so it's best to start lux 
and use it's own file select dialog. When running lux in full-screen 
mode, the file select dialog may be hidden behind lux' display - you may 
have to switch to it's window manually. lux on macs will use automatic 
rendering quality adjustment by default to cope with the typically high 
resolution on macs.


Enjoy!




--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/c1831084-9d5a-dd38-085c-b4ad14f9bcd2%40yahoo.com.

Re: [hugin-ptx] lux FOSS panorama and image viewer: 1.1.0 pre-release available

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 04.03.22 um 17:13 schrieb Robert Clausecker:


I've now started working on the packaging.


Great!

Could you tell me which git commit your prerelease is based on?  I need 
something to work off.
I noticed that your master branch is still on a 2021-12-15 state and 
development seems to be
happening on the associated_alpha branch.  Which branch or commit should 
I use for the packaging?

Ideally you could tag a prerelease so I can directly work off that.


I apologize for the moving target. I found a few bugs in the pre-release 
version I offered in binary form which I have ironed out in the last few 
days, and just now I have pushed a commit which is - hopefully - good:


https://bitbucket.org/kfj/pv/commits/a7e0d3a039766cb3b3651e672211ad9729b563c3?at=associated_alpha

or, a7e0d3a in short.

I have also set an annotated tag: 1.1.0-pre-2

I hope this is what you need for your packaging effort.

I now intend to consolidate the code - I have the feature level I want 
for 1.1.0, but I'd like to have the code in use for some time to see if 
more bugs crop up. Once I'm confident that all is well, I'll merge the 
associated_alpha branch back into master and release 1.1.0.


Normally I work straight to the master branch, but with the move to 
associated-alpha processing I was not sure my ideas would actually work 
out, so I left the master branch at some 'safe' state. Luckily, so far, 
it seems that the move worked as intended, and this made it possible to 
add source image masking and stacking using the new code.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/9b55d118-8171-d7ff-5bc8-e50839b4e5b5%40yahoo.com.

Re: [hugin-ptx] lux FOSS panorama and image viewer: 1.1.0 pre-release available

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 28.02.22 um 17:45 schrieb Robert Clausecker:

Am 28.02.22 um 17:41 schrieb 'Kay F. Jahnke'


Have you built the code on freeBSD already? I think this shouldn't be 
too hard, with the CMake process and few dependencies. If you have, 
please let me know - it would be the fourth OS running lux!


I have not made any attempts in this regard, but I want to start in the 
next few days.  If I find any problems, I'll go ahead and report these 
to you so you can maybe add patches in time for the 1.1.0 release.


If you like, you can go via lux' issue tracker on bitbucket if you find 
anything amiss. Everyone can post there, you needn't be a member.


I made the .deb using CMake, maybe it can also build packages for 
freeBSD? By all means, use the clang++ C++ compiler - so far it's made 
a big difference speed-wise. And if you want to recreate today's 
binaries, they are made from the associated_alpha branch, which I 
haven't merged back into master yet.


FreeBSD ports are compiled with the system's compiler, which is clang 
these days.  The ports build system is external to the packages and 
hooks into your CMake build scripts, so no changes on your part will be 
required.  I'll let you know once I get something done.


Great! What I was hinting at is that the CMake script for lux can do the 
entire package-building process as well, so once you can build the 
binary, maybe you can get CMake (via cpack) to build a freeBSD package - 
the debian packages made that way aren't 'good enough' for the distro (I 
know because I maintain my vspline package on debian), but it's a start 
and you have something which you can give to people to try it out before 
it makes it's way into the repo.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4e6597d5-9b3c-5d8e-fa4c-7cbf9a730107%40yahoo.com.

Re: [hugin-ptx] lux FOSS panorama and image viewer: 1.1.0 pre-release available

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 28.02.22 um 12:11 schrieb Robert Clausecker:


I am interested in packaging this software for FreeBSD.  Unfortunately,
we already have a package named lux (www/lux) in our Ports collection,
so I cannot name yours lux.  What package name do you think would be
most appropriate?


How about lux-pv? For lux panorama viewer - that's if you're into short 
package names. Or lux-viewer for something longer and less cryptic. But 
bear in mind that what I've uploaded today is just a development 
snapshot, so bear with me a little longer until I release 1.1.0 proper. 
I just did a lot of internal rewiring, so it may take a while to settle. 
The code is becoming fiendishly complex. I hope to see a bit of use and 
maybe the odd bug report. Just viewing images and panoramas should be 
unproblematic, though, because the changes were more to the PTO 
processing part of the code.


Have you built the code on freeBSD already? I think this shouldn't be 
too hard, with the CMake process and few dependencies. If you have, 
please let me know - it would be the fourth OS running lux! I made the 
.deb using CMake, maybe it can also build packages for freeBSD? By all 
means, use the clang++ C++ compiler - so far it's made a big difference 
speed-wise. And if you want to recreate today's binaries, they are made 
from the associated_alpha branch, which I haven't merged back into 
master yet.


Keep us posted on how it goes, thanks for your interest in lux!

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/5e6fd85d-a437-4437-ba40-f035da0e6484%40yahoo.com.

Re: [hugin-ptx] Re: lux - FOSS multiplatform image and panorama viewer

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 14.10.21 um 10:25 schrieb David W. Jones:

Tried to install the DEB package on Debian Buster (Debian 10) on my 
laptop because it's the only machine in the house with real graphics 
hardware (NVidia).


We've had these problems before with your debian11. Really, the .deb 
package is for ubuntu - I use 20.04 LTS. Re. debian11 you posted on Jun 
5, 2021, 11:25:05 AM, on this thread, and Harry responded with this 
proposition:


* begin quote

This happens more often with manually installing debian packages.

So you do a "sudo dpkg -i lux-.dpkg" and get this error.
What you now should do is a:
"sudo dpkg --configure -a"
followed by:
"sudo apt-get -f install"

That should fix it.

* end quote

Did that work for you last time around? If so, maybe try it again.

BTW - you don't need special graphics hardware, because lux is 
CPU-based. GPU load is not very large, processor graphics will usually 
suffice. What you *do* want is a reasonably powerful CPU - I'd recommend 
four cores and AVX2 or better.


If you don't get the .deb to install, please compile from source. lux 
now uses cmake, and the build process is simple, just follow the 
instructions on the bitbucket page (find the chapter 'Building lux on a 
debian-based system')


Kay



Got these results:

Preparing to unpack lux-1.0.9a-amd64.deb ...
Unpacking lux (1.0.9-0git) ...
dpkg: dependency problems prevent configuration of lux:
  lux depends on libc6 (>= 2.29); however:
   Version of libc6:amd64 on system is 2.28-10.
  lux depends on libexiv2-27 (>= 0.25); however:
   Package libexiv2-27 is not installed.
  lux depends on libgcc-s1 (>= 4.0); however:
   Package libgcc-s1 is not installed.
  lux depends on libstdc++6 (>= 9); however:
   Version of libstdc++6:amd64 on system is 8.3.0-6.
  lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
   Package libvigraimpex11 is not installed.

dpkg: error processing package lux (--install):
  dependency problems - leaving unconfigured
Errors were encountered while processing:
  lux

The machine that's running Debian 11 (which presumably has newer 
versions of libc6) doesn't have real graphics hardware in it (just the 
old Intel glorified framebuffer).


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/22b15541-cc6f-ebf2-2ec6-b293e78cdba1%40yahoo.com.

Re: [hugin-ptx] Documentation of Fields in PTO i-lines

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 21.09.21 um 18:23 schrieb T. Modes:

kfj schrieb am Dienstag, 21. September 2021 um 11:28:33 UTC+2:

- The cropping area of the two circular fisheye images is not placed
correctly, parts of the image which show the inside of the lens are
inside the cropping area, some content is cut off so much that the
output has black areas. The cropping area it's too small and
off-center.


This assistant may need some fine-tuning for a specific model, as 
already written. The dual lens assistant was meant as a starting point, 
not as final product.


I hope my observations will help improve it.



- the assistant produces two separate hfov values for the two images,
but both cameras in the device have identical hfov, so the second
i-line
should have v=0. The only thing that differs are d and e, and y, p, r
for the second image

I doubt that the two lenses have really identical hfov - at least at a 
pixel scale. So the idea was to take the deviation between the two 
lenses into account.


Producing hfov values which are 20 degrees apart is definitely wrong. I 
suspect that the assistant relies on too few control points. If you want 
to stick with separate v values for the two i-lines, my suggestion would 
be to try something like this:


start out with the same v for both i-lines (so v=0 in the second one) 
and optimize for y,p,r,d,e in the second image. This gives you a good 
base to start from to detect pixel-level differences in v for the two 
cameras, because with the initial result you can generate more and 
better CPs. Once you have these, you can decouple v and see if your 
optimization gets any better. I tried that, and with 27 CPs and v 
decoupled the difference the optimizer produced was a mere .003 degrees.


Typically, the overlap in this type of device is small and in an area 
where the lens does not 'behave well', so hoping to get the lens 
characteristic right by optimizing based on (too few) CPs in this 
overlap region is likely to produce suboptimal results, especially if 
the initial guess which cpfind needs to find good CPs is not very 
accurate. I am convinced that assuming equal FOV is a better initial 
guess, at least as a starting point.



Some models will have more deviation, other are similar.


I'd be curious to see measurements from others working with these 
devices. I'd assume that the differences you get from device to device 
result from slight differences in how the individual cameras are mounted 
in the device, and are reflected in the outcome of the optimization for 
y,p,r,d and e, while the hfov should come out very similar, and widely 
different values are most likely wrong.


I hope to get more sample images in the near future, also from a 
different device, and I've also asked for samples with the camera yawed 
by 90 degrees which would help greatly in working out the fov issue. 
I'll post again when I have the data.


Kay


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4362c06d-344e-efdb-4e53-35f78529717d%40yahoo.com.

Re: [hugin-ptx] Documentation of Fields in PTO i-lines

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 20.09.21 um 20:12 schrieb T. Modes:

kfj schrieb am Montag, 20. September 2021 um 10:19:39 UTC+2:

Okay, what's the 'dual lens assistant' and where can I find it?

Start with new project and add single image. Then run user defined 
assistant:

Edit>User defined assistant>Assistant for dual lens images


Okay, thanks, I found it.

The result is disappointing:

- The cropping area of the two circular fisheye images is not placed 
correctly, parts of the image which show the inside of the lens are 
inside the cropping area, some content is cut off so much that the 
output has black areas. The cropping area it's too small and off-center.


- the assistant produces two separate hfov values for the two images, 
but both cameras in the device have identical hfov, so the second i-line 
should have v=0. The only thing that differs are d and e, and y, p, r 
for the second image


- CPs are few and far between, half of them high in the sky and in the 
lawn near the nadir. Adding additional CPs with the CP tool in the 
overlap and +/- 30 degrees off the horizon helps.


This is the assistant-generated PTO (p-line and i-lines only:

# hugin project file
#hugin_ptoversion 2
p f2 w6496 h3248 v360  k0 E14.2769 R0 n"TIFF_m c:LZW r:CROP"
m i0

# image lines
#-hugin  autoCenterCrop=1 cropFactor=1
i w6912 h3456 f2 v402.651775543405 Ra0 Rb0 Rc0 Rd0 Re0 
Eev14.2769324951933 Er1 Eb1 r0 p0 y0 TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0 a0 b0 
c0 d-1615.03702730985 e3.9466693357031 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0 
S113,3569,108,3356 Vm5 n"image.jpg"

#-hugin  autoCenterCrop=1 cropFactor=1
i w6912 h3456 f2 v383.086221346944 Ra=0 Rb=0 Rc=0 Rd=0 Re=0 
Eev14.2769324951933 Er1 Eb1 r0.144827568515012 p-0.223075234348641 
y166.756224026178 TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0 a=0 b=0 c=0 
d1605.72455893899 e16.1069820972669 g=0 t=0 Va=0 Vb=0 Vc=0 Vd=0 Vx=0 
Vy=0  S3334,6790,120,3368 Vm5 n"image.jpg"


For comparison, here's a manually reworked PTO file for the same image 
which produces a near-perfect stitch:


# hugin project file
#hugin_ptoversion 2
p f2 w6496 h3248 v360  k0 E14.2769 R0 n"TIFF_m c:LZW r:CROP"
m i0

# image lines
#-hugin  cropFactor=1
i w6912 h3456 f2 v392.926531308803 Ra0 Rb0 Rc0 Rd0 Re0 
Eev14.2769324951933 Er1 Eb1 r0 p0 y0 TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0 a0 b0 
c0 d-1597.21304025071 e2.31010096005214 g0 t0 Va1 Vb0 Vc0 Vd0 Vx0 Vy0 
S4,3460,97,3345 Vm5 n"image.jpg"

#-hugin  cropFactor=1
i w6912 h3456 f2 v=0 Ra0 Rb0 Rc0 Rd0 Re0 Eev14.2769324951933 Er1 Eb1 
r0.123583351129881 p0.0411329889565548 y165.690011847671 TrX0 TrY0 TrZ0 
Tpy0 Tpp0 j0 a0 b0 c0 d1602.86788254359 e14.1561252521546 g0 t0 Va1 Vb0 
Vc0 Vd0 Vx0 Vy0  S3457,6913,103,3351 Vm5 n"image.jpg"


The assistant-generated PTO was made with hugin Pre-Release 
2020.1.0.a7e93b18e270, so maybe the assistant has improved with newer 
versions.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/55485f44-46e7-ab81-6b9c-4a3a98943366%40yahoo.com.

Re: [hugin-ptx] Documentation of Fields in PTO i-lines

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 19.09.21 um 19:52 schrieb T. Modes:

kfj schrieb am Sonntag, 12. September 2021 um 13:04:25 UTC+2:

  Now it's clear. I was also a bit miffed that hugin would silently
consume my PTO with a C field to a PTO with an S field, when the two
have quite different meaning.

And  I could be a bit miffed that you ignored the dual lens assistant 
which does all the steps needed for such images.


Okay, what's the 'dual lens assistant' and where can I find it?

(Maybe it needs some fine-tune for a specific model, but in principle it 
does all steps needed.)


My criticism was that the C field was silently changed into an S field, 
which has different meaning. Maybe emitting a diagnostic would be 
appropriate?


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/a10284f1-c673-a46d-df8b-0510ab6c966e%40yahoo.com.

Re: [hugin-ptx] Documentation of Fields in PTO i-lines

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 12.09.21 um 11:47 schrieb Bruno Postle:

PTOptimizer.txt is for PTOptimizer, which is a standalone tool that is 
independent of Hugin. The nona.txt file describes the behaviour of the Hugin 
stitcher.

Panotools supports both 'C' and 'S' image parameters, they do similar things, 
describing the rectangle of interest in the photo, but are not interchangeable.

'C' parameters discard all data outside the rectangle, and then all image 
parameters (angle of view, lens distortion) relate to this new image boundary. 
This is a model that makes a lot of sense if all your photos are digitised with 
a flat-bed scanner - the cropped-out areas are not part of the photo.

'S' parameters set the area outside the rectangle to 'transparent', but the 
image parameters still relate to the original image frame. This model makes 
more sense with digital cameras where all the pixels have come from the sensor, 
just that some of them are not wanted (in Hugin there is a lot of overlap with 
the masking functionality, which came much later).

It is not straightforward to convert from a project that uses one method to the 
other method, so it makes sense for a GUI tool to support one only (since you 
don't need both). This is the original schism between Ptgui and Hugin - Ptgui 
uses 'C' and Hugin uses 'S'.

So if you are importing a Ptgui project into Hugin, you need to re-optimise 
lens parameters because the C parameters have been silently converted to S.


Thank you, Bruno, for the explanation. I stumbled upon this because I 
was working on images done with a Xiaomi Mi Sphere 360 - these images 
have two circular fisheye images next to each other, and I wanted to 
mask them so that I could use the image twice, once for the left half of 
the sphere and once for the right half, with, otherwise, identical lens 
parameters. I hoped to use 'C' which would have made the job simple.


With 'S' I could create correct masks, but I had to introduce differing 
horizontal shift (d parameter) for the two half-images. So I needed two 
separate lenses. I also had to assign a hfov of over 360 degrees (for 
the whole image, the (square) half-images have about 193 degrees fov). 
All of this made the optimization a bit tricky...


I succeeded in the end, but I was wondering what the 'C' was all about. 
Now it's clear. I was also a bit miffed that hugin would silently 
consume my PTO with a C field to a PTO with an S field, when the two 
have quite different meaning.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/48f49185-037a-44d4-dd81-cb057f438098%40yahoo.com.

Re: [hugin-ptx] Re: lux - FOSS multiplatform image and panorama viewer

['Kay F. Jahnke' via hugin and other free panoramic software]

Dear all!

I'm happy with the level of functionality in lux 1.0.9, and since I've 
seen no complaints - either here or as issues on the bitbucket page - I 
can only assume that lux users agree ;)


I'm now taking the time to consolidate: I'm going through the various 
options (as represented by command line arguments), looking at each in 
turn, trying out whether they (still) work as intended, debugging as I 
go along, and producing more documentation. I have started on a new HTML 
document, which gives a lexical listing of lux options - rather than the 
more thematic grouping in the README file - and this is progressing 
nicely and has already reached the letter 'F'. You can find the source 
code of this document as restructured text in the repo, and an HTML 
rendition on my bitbucket.io page:


https://kfj.bitbucket.io/lux_options.html

I'll update the HTML version as lux_options.rst grows. I thought it a 
good idea to announce this text early, and I'd like to invite you to 
have a look at the text, and to comment on it - especially if I don't 
make sense or use my own jargon - as a developer, I may have come to use 
terms which make sense for me, but aren't comprehensible without 
explanation.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4de56e01-473d-f5e6-d6eb-961eebdcf4a5%40yahoo.com.

Re: [hugin-ptx] Re: lux - FOSS multiplatform image and panorama viewer

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 10.06.21 um 19:18 schrieb T. Modes:



kfj schrieb am Mittwoch, 9. Juni 2021 um 09:04:59 UTC+2:


My intention is to have this bahaviour: if the .pto extension is
already
assigned (like, to hugin), and lux is installed afterwards, the first
doubleclick on a .pto after the installation of lux should result in a
dialog which offers the user to keep this association or change it to
another candidate. After the choice is made, the next time someone
doubleclicks on a .pto, it's opened with the application the user has
selected. I think this is perfectly reasonable. Other Windows users,
please comment.


Hugin registers 2 verbs for pto files: open and stitch.


I don't understand what you mean by 'registers 2 verbs', can you please 
explain? what are 'verbs' in this context? And with what are they 
registered?


I don't how this interacts with the OpenWithProgID. But this may be a 
reasonable approach.


I think that the installer behaves like I intend (see above). Can you 
please confirm that it does not unconditionally overwrite any existing 
associations? If it does, something is wrong and I'll have to change it.



Thomas, you're good with windows. Why don't you help lux along? It
would
be easy for you the help make the installer do precisely the right
thing, you know about stuff like the registry, which is alien to me
as a
linux person. I've published the .iss script on bitbucket, and if you
find fault with it, why don't you change it? You can send in a patch,
and I'll consider it - and so can everyone else. The file is in the
scripts section:

https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss



Sorry, but I don't have experience with this scripts. So I can't help here.


But it's easy! You can help, and it's no big deal. The section of the 
script which deals with the extension associations merely modifies the 
registry. For lux and the .pto extension, this is what happens:


Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType: 
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags: 
uninsdeletevalue


Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto"; ValueType: 
string; ValueName: ""; ValueData: "Lux Panorama Viewer"; Flags: 
uninsdeletekey


Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto\DefaultIcon"; 
ValueType: string; ValueName: ""; ValueData: "{app}\{#MyAppIconName},0"


Root: HKA; Subkey: 
"Software\Classes\{#MyAppName}.pto\shell\open\command"; ValueType: 
string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""%1"""


Root: HKA; Subkey: 
"Software\Classes\Applications\{#MyAppExeName}\SupportedTypes"; 
ValueType: string; ValueName: ".pto"; ValueData: ""


This is plain registry modification, to clarify, I'll 'decode' the first 
line for you:


Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType: 
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags: 
uninsdeletevalue


This means:

set HKA's subkey Software\Classes\.pto\OpenWithProgids to contain the 
string "Lux Panorama Viewer.pto" and remove it when lux is uninstalled


And, to be less verbose: The second and third one merely register the 
app name and icon for the association, the fourth one specifies how to 
invoke the executable and the fifth one says that lux does support .pto 
files.


So the five lines doing the extension association (as MS suggests it for 
W10) are easy to understand: they make a few registry changes. AFAICT 
the changes do not 'step on hugin's toes', and this is where you could 
help: just look at the registry changes and give me your opinion.



I tested Lux again, but it does not match in my workflow.


Fair enough.

When opening a pto file it is slower and takes more memory than Hugins 
preview. So I'm faster with Hugin.


That observation is correct. In order to provide smooth animation, lux 
uses interpolators which take up a lot of memory and take time to build. 
There are a few flags to lower memory consumption, but especially for 
views taking in several images (like, from .pto files), memory 
consumption and setup time can be high.


I tried to address your criticism that lux is unresponsive during 
startup - now you get the splash screen and the status line tells you 
what is loaded and built, and if you lose patience, you can press 
'Escape' and it will stop and terminate after processing the current 
partial image. So now you can interact (if drastically) and you aren't 
confronted with an unresponsive program and a white screen during startup.


Let me remind you: you shouldn't really compare lux to hugin in that 
respect: lux is primarily a panorama *viewer*. It has some capabilities 
to deal with .pto files, but it really shines where you have a 
ready-made panorama to display, like a single full spherical. I made it 
to *look at* panoramas. That it can also make panoramas is a new 

Re: [hugin-ptx] Re: lux - FOSS multiplatform image and panorama viewer

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 08.06.21 um 19:17 schrieb T. Modes:



kfj schrieb am Dienstag, 8. Juni 2021 um 18:50:42 UTC+2:

It's likely that a windows system doesn't have
associations for some of these extensions (especially .pto, .lux and
.exr), in which case the doubleclick should even work without the
dialog.


If Hugin installer is used, it register the pto files with Hugin.
I would appreciate if you would keep this association intact instead of 
unconditional overwrite it.


It doesn't. I think simply overwriting existing associations is no 
longer possible with windows 10 - especially unconditional overwrites 
simply aren't allowed anymore.


It was my impression that on Windows 10 a new association with an 
extension results in a dialog when a file with this extension is next 
doubleclicked, and the dialog offers the user to choose a new 
association as the standard or keep the old one. Only if the association 
was *not present previously*, the new program will open a file with this 
extension when it's doubleclicked *without an intervening dialog*. When 
I tested the installer, I saw this behaviour on my windows 10 pro 20H2 
install. Did you actually test the installer and observe a different 
behaviour? What system are you using?


My intention is to have this bahaviour: if the .pto extension is already 
assigned (like, to hugin), and lux is installed afterwards, the first 
doubleclick on a .pto after the installation of lux should result in a 
dialog which offers the user to keep this association or change it to 
another candidate. After the choice is made, the next time someone 
doubleclicks on a .pto, it's opened with the application the user has 
selected. I think this is perfectly reasonable. Other Windows users, 
please comment.


Thomas, you're good with windows. Why don't you help lux along? It would 
be easy for you the help make the installer do precisely the right 
thing, you know about stuff like the registry, which is alien to me as a 
linux person. I've published the .iss script on bitbucket, and if you 
find fault with it, why don't you change it? You can send in a patch, 
and I'll consider it - and so can everyone else. The file is in the 
scripts section:


https://bitbucket.org/kfj/pv/src/master/scripts/lux_setup.iss

If you have a better idea for an installer, you're also very welcome. I 
did consider nullsoft, because I could use cpack's NSIS module, it's 
only that Frederico came up with the inno setup idea, and it's an 
independent project, I liked the script-driven approach, so I went along 
with the suggestion. I do in fact prefer my own 'bundles' which are 
stickware and require no installation, but you know how windows users are...


Try lux - it's really a very nice program! You don't have to use it for 
stitching or exposure fusion or focus stacking or deghosting - all the 
synoptic work is optional. Primarily it's an image and panorama 
*viewer*. It makes an ideal companion for hugin, but it's new technology 
makes it hard to give stuff back to hugin and panotools. I'm not trying 
to take anything away from the hugin project - it's just that I don't 
get much help or feedback from the hugin project, so I go ahead best as 
I can. I tried to get the people on hugin-ptx interested in my program, 
even when it was in it's early stages of development. My postings were 
usually quickly shot down with something someone did not like about it, 
then the threads died down and my effort was ignored for another year or 
two until I tried again. What was I supposed to do but carry on 
developing as I saw fit? I'd much rather have someone else doing the 
windows builds and installers, but even though Frederico started the 
.iss for inno setup, it's ended up with me again to make it run okay. I 
bet you know how it is if one has to do just about everything.


Here's the code for the .pto association in the .iss script:

Root: HKA; Subkey: "Software\Classes\.pto\OpenWithProgids"; ValueType: 
string; ValueName: "{#MyAppName}.pto"; ValueData: ""; Flags: 
uninsdeletevalue


Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto"; ValueType: 
string; ValueName: ""; ValueData: "Lux Panorama Viewer"; Flags: 
uninsdeletekey


Root: HKA; Subkey: "Software\Classes\{#MyAppName}.pto\DefaultIcon"; 
ValueType: string; ValueName: ""; ValueData: "{app}\{#MyAppIconName},0"


Root: HKA; Subkey: 
"Software\Classes\{#MyAppName}.pto\shell\open\command"; ValueType: 
string; ValueName: ""; ValueData: """{app}\{#MyAppExeName}"" ""%1"""


Root: HKA; Subkey: 
"Software\Classes\Applications\{#MyAppExeName}\SupportedTypes"; 
ValueType: string; ValueName: ".pto"; ValueData: ""


Note the OpenWithProgids registry entry: if I understand this correctly, 
it has a list of several applications which can handle the extension. 
This is different from the old code, where one could simply overwrite 
the relevant registry key(s) to force a new association. I think the new 
mode is a compromise: it allows programs to register 

Re: [hugin-ptx] Re: lux - FOSS multiplatform image and panorama viewer

['Kay F. Jahnke' via hugin and other free panoramic software]

Building on Frederic da Vitoria's initial version, I've put together a 
script file for inno setup (see https://jrsoftware.org/isinfo.php) which 
can create a windows-10-compatible installer for lux. The .iss file can 
be found in the 'scripts' section. If my information is correct, 
extension associations can't be changed in W10 by checking the relevant 
boxes in the installer, instead the extension associations are presented 
as an offer when a file with the associated extension is first 
doubleclicked - so I removed these entries from the installer's dialog box.


The installer will install an association to the .lux extension which 
I'm moving to (from .ini which is still valid) and lux will be offered 
as standard app for several image types (jpg, tif, .png, .bmp, .exr) and 
for .pto files. It's likely that a windows system doesn't have 
associations for some of these extensions (especially .pto, .lux and 
.exr), in which case the doubleclick should even work without the dialog.


Lux may be installed user-only or all-users (which requires admin 
privileges) and optionally a desktop icon can be installed. That's about 
it for functionality. I built an installer for lux 1.0.9, which you can 
find here:


https://bitbucket.org/kfj/pv/downloads/lux_1.0.9_setup.exe

To uninstall, use the system settings 'Apps' subsection and look for 
'lux', which will also remove all extension associations.


Thanks, Frederic, for doing the initial work and starting the process of 
building the installer with inno setup - apart from the bother with the 
changed extension associations under W10, which I finally found 
explained in the FAQ, I pretty much took over your initial work, with 
added header for licensing and copyright and a few adaptations to the 
folder structure o my system. Would you like to be put in as author as 
well? If so, please indicate how I should mention you.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/42fbf890-4669-2e1b-9d88-bd585078547a%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 07.06.21 um 10:38 schrieb 'Kay F. Jahnke' via hugin and other free 
panoramic software:

Am 07.06.21 um 10:25 schrieb Frederic Da Vitoria:

Le sam. 5 juin 2021 à 11:24, 'Kay F. Jahnke' via hugin and other free 
    I tried yesterday to download the inno setup software with edge,

    which informed me that it was blocked and probably malicious,...

I just tested it with Edge too and got the same message, but clicking 
on the 3-dots menu on the download's row I had an option which allowed 
me to keep it nonetheless.


Of course one can ignore the warning, but I'll go the 'roundabout' way 
anyway, just to be on the safe side. It'll just take a little longer. 
And I'll have to adapt your script to the folder structure on my 
machine. Please bear with me!


Okay, so I've checked the inno setup installer with virustotal, and it 
came out clean. I installed the software, adapted the .iss script to my 
folder structure and successfully built an installer from it. The 
installer installs Lux both single-user and all-user, but I've failed so 
far to get the mime type associations working, and I'd like to have that 
included. The options to associate the mime types are displayed, but 
they have no effect on my system. So I'll need more tweaking time!


I'll post again when I get round to do more work on the installer.

Can inno setup also create an uninstaller? When testing, I used the 
system's own uninstall process (worked fine), because I couldn't figure 
out how else to do it.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/fc2aa0f4-fa0c-e4ad-0a94-540932082206%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 07.06.21 um 10:25 schrieb Frederic Da Vitoria:

Le sam. 5 juin 2021 à 11:24, 'Kay F. Jahnke' via hugin and other free 
I tried yesterday to download the inno setup software with edge,

which informed me that it was blocked and probably malicious,...

I just tested it with Edge too and got the same message, but clicking on 
the 3-dots menu on the download's row I had an option which allowed me 
to keep it nonetheless.


Of course one can ignore the warning, but I'll go the 'roundabout' way 
anyway, just to be on the safe side. It'll just take a little longer. 
And I'll have to adapt your script to the folder structure on my 
machine. Please bear with me!


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/878112fb-aae5-446b-1e9a-151d6d47facd%40yahoo.com.

Re: [hugin-ptx] Re: lux - FOSS multiplatform image and panorama viewer

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 07.06.21 um 09:28 schrieb David W. Jones:

I think the last time I had a working PV (before name change to lux) on 
my system, I had to compile it myself.


You did, indeed, because at that time there were no readymade binary 
packages for linux. Building is now easier, due to the build process 
with cmake. If you've managed the 'old' build, the new one is going to 
be easy. Please refer to the documentation. And then you can build a 
.deb which works for you and for debian11 in general, and you can share it.


Sorry, I don't do flatpack or appimage. I've tried both with a couple of 
different apps, with complete lack of success, and no interest in 
figuring out why they didn't work.


Harry's comment about using flatpack or appimage was not directed at 
you, but simply stating the fact that these two methods of installation 
avoid issues with incompatible or inaccessible libraries, because they 
provide an environment where the necessary shared library infrastructure 
is provided bundled with the installation medium.


We're trying to provide installable debian packages for users who don't 
want to experiment with these 'novel' methods, but since you use a 
flavour of Linux which isn't so common among end-users, it's slightly 
more difficult to help you get going. Did Harry's hint not work for you?


Doesn't compiling something to use static libs also include everything 
inside the app?


It, does, but it produces enormous bloat. And if anything relevant in 
one of the libraries changes, you have to recompile, redistribute, and 
make all users reinstall. Linux has decided against this, and for good 
reasons.


Kay


On 6/4/21 11:24 PM, Harry van der Wolf wrote:

This happens more often with manually installing debian packages.

So you do a "sudo dpkg -i lux-.dpkg" and get this error.
What you now should do is a:
"sudo dpkg --configure -a"
followed by:
"sudo apt-get -f install"

That should fix it.
And if you had done a simple DuckDuckGo/Google search, you would have 
found that as well as it is as old as the world (well, almost as old).


This could be solved by creating a flatpack or appimage which has 
everything "inside".


Harry

Op za 5 jun. 2021 om 10:37 schreef 'Kay F. Jahnke' via hugin and other 
free panoramic software <mailto:hugin-ptx@googlegroups.com>>:


    Am 05.06.21 um 05:31 schrieb David W. Jones:
 > Well, here's what happened when I tried to install it here on
    Debian 11:
 >
 > Preparing to unpack lux-1.0.9-0git-Linux.deb ...
 > Unpacking lux (1.0.9-0git) ...
 > dpkg: dependency problems prevent configuration of lux:
 >   lux depends on libc6 (>= 2.29); however:
 >    Version of libc6:amd64 on system is 2.28-10.
 >   lux depends on libexiv2-27 (>= 0.25); however:
 >    Package libexiv2-27 is not installed.
 >   lux depends on libgcc-s1 (>= 4.0); however:
 >    Package libgcc-s1 is not installed.
 >   lux depends on libstdc++6 (>= 9); however:
 >    Version of libstdc++6:amd64 on system is 8.3.0-6.
 >   lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
 >    Package libvigraimpex11 is not installed.
 >
 > dpkg: error processing package lux (--install):
 >   dependency problems - leaving unconfigured
 > Errors were encountered while processing:
 >   lux

    Thanks for reporting back!

    The dependencies are the same as they have been throughout lux 1.0.8;
    this issue is not new with 1.0.9:

    I've probably misled you by simply stating that I made a 'debian
    package': I develop lux on ubuntu, here I use ubuntu ubuntu 20.04.2
    LTS,
    which should differ quite a bit in the set of packages and their
    versions to your debian 11, which is also quite brand-new and has not
    been released yet. What surprises me is that dpkg can't get hold of
    common packages like libexiv2, libgcc and libstdc++, but these may be
    naming problems, where the ubuntu naming scheme differs from 
debian's.

    In general, you can't rely on ubuntu-built packages to run on debian.

    I'll change the name of the packages I offer for download to make 
clear

    what the target distro is, to help other users avoid this pitfall. As
    far as ubuntu goes, basing on 20.04 LTS is quite conservative, and 
the

    dependencies should work on newer non-LTS distros as well - ubuntu
    users, please report back! For now, there are two debian packages 
I can

    offer:

    https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0-debian10-i32.deb
    <https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0-debian10-i32.deb>

https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb 


<https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb> 



    As you can see, the debian 10 package is 32 bits - I currently don't
    have a 64bit 

Re: [hugin-ptx] Re: lux - FOSS multiplatform image and panorama viewer

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 05.06.21 um 13:10 schrieb Harry van der Wolf:


I created a Lux 1.0.9 app bundle for MacOS and a Lux 1.0.9 distributable 
binary version for MacOS.

The first one for the GUI lovers, the 2nd for the command line lovers.


Thanks, Harry! I copied the files to the download page:

https://bitbucket.org/kfj/pv/downloads/LUX-1.0.9-MacOS.dmg
https://bitbucket.org/kfj/pv/downloads/LUX-1.0.9-distributable-MacOS.zip

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f4196062-506b-9abd-239d-a89474161ea1%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 01.06.21 um 10:48 schrieb 'Kay F. Jahnke' via hugin and other free 
panoramic software:

Am 31.05.21 um 12:47 schrieb smib:

Sorry about missing file, here is another link (hope its both files 
this time)

https://www.dropbox.com/sh/ggztv234kfqe437/AADhRXvrgSzcnKozUgoFGtQ-a?dl=0


Thanks, I downloaded the zip file and it contains both the .iss and the 
installer. I'll check it out when I use the windows machine again.


This will still take a little longer - I tried yesterday to download the 
inno setup software with edge, which informed me that it was blocked and 
probably malicious, so I'll have to go roundabout and download it on 
linux, send it to virustotal and then install it. I guess it's just a 
false alert, but I can't compromise my development system.


Anyway, I released 1.0.9 (see the announcement on the 'lux - FOSS 
multiplatform image and panorama viewer' thread on hugin-ptx), so maybe 
if you like you can build an installer for that from the windows bundle 
I put on bitbucket downloads.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4b060d94-ae22-9a83-d196-15dbda416db0%40yahoo.com.

Re: [hugin-ptx] Re: lux - FOSS multiplatform image and panorama viewer

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 05.06.21 um 05:31 schrieb David W. Jones:

Well, here's what happened when I tried to install it here on Debian 11:

Preparing to unpack lux-1.0.9-0git-Linux.deb ...
Unpacking lux (1.0.9-0git) ...
dpkg: dependency problems prevent configuration of lux:
  lux depends on libc6 (>= 2.29); however:
   Version of libc6:amd64 on system is 2.28-10.
  lux depends on libexiv2-27 (>= 0.25); however:
   Package libexiv2-27 is not installed.
  lux depends on libgcc-s1 (>= 4.0); however:
   Package libgcc-s1 is not installed.
  lux depends on libstdc++6 (>= 9); however:
   Version of libstdc++6:amd64 on system is 8.3.0-6.
  lux depends on libvigraimpex11 (>= 1.11.1+dfsg); however:
   Package libvigraimpex11 is not installed.

dpkg: error processing package lux (--install):
  dependency problems - leaving unconfigured
Errors were encountered while processing:
  lux


Thanks for reporting back!

The dependencies are the same as they have been throughout lux 1.0.8; 
this issue is not new with 1.0.9:


I've probably misled you by simply stating that I made a 'debian 
package': I develop lux on ubuntu, here I use ubuntu ubuntu 20.04.2 LTS, 
which should differ quite a bit in the set of packages and their 
versions to your debian 11, which is also quite brand-new and has not 
been released yet. What surprises me is that dpkg can't get hold of 
common packages like libexiv2, libgcc and libstdc++, but these may be 
naming problems, where the ubuntu naming scheme differs from debian's. 
In general, you can't rely on ubuntu-built packages to run on debian.


I'll change the name of the packages I offer for download to make clear 
what the target distro is, to help other users avoid this pitfall. As 
far as ubuntu goes, basing on 20.04 LTS is quite conservative, and the 
dependencies should work on newer non-LTS distros as well - ubuntu 
users, please report back! For now, there are two debian packages I can 
offer:


https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0-debian10-i32.deb
https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-ubuntu20.04-amd64.deb

As you can see, the debian 10 package is 32 bits - I currently don't 
have a 64bit install of debian 10 handy, but I just did the CMake build 
here on the debian10 32bit system to verify that it builds and installs 
without problems, so I thought I might as well put it up for download. 
The ubuntu20.04 amd64 package is the same as what I had offered before 
as the 1.0.9 'Linux' package, only with a clearer name. Sorry for the 
confusion.


How about you build a debian package on your machine? Then we can have a 
look at what your system puts into the .deb. Just follow the steps in 
'Building lux with cmake' given on the bitbucket page. Then I can put 
your package online if you like, to help other debian 11 users. To build 
a debian package, you have to invoke cmake with -DCPACK_BINARY_DEB=ON 
during cmake configuration, and to build the package you have to say 
'make package'.


Are you dd or involved with the debian project? How about you help 
bringing lux to debian? With an actively maintained lux package on 
debian, we might rely on it trickling down to ubuntu and other 
debian-based distros - I've done this successfully with the vspline 
debian package, but that's already quite a bit of work, and I've shunned 
going through the laborious process for yet another package - especially 
as I don't have dd status and have to bother my mentor whenever I have a 
new version.


@Kornel: Is there a way to provide 'linux bundles' which include all 
shared libraries, as I make them for the Windows stickware version? Can 
CMake output flatpak or a similar format which works on more distros?


The CMake package build produces a package named 
'lux-1.0.9-0git-Linux.deb', can we influence the naming of the package? 
It might be good to have 'ubuntu' or 'debian' in the package name rather 
than 'Linux', and also the version, like 20.04, and the architecture, 
like amd64 - I've done the naming of the two packages I just put up for 
download manually.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/86b8821a-479b-7b8b-1619-43df02b157c1%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 31.05.21 um 12:47 schrieb smib:

Sorry about missing file, here is another link (hope its both files this 
time)

https://www.dropbox.com/sh/ggztv234kfqe437/AADhRXvrgSzcnKozUgoFGtQ-a?dl=0


Thanks, I downloaded the zip file and it contains both the .iss and the 
installer. I'll check it out when I use the windows machine again.


Am 31.05.21 um 14:42 schrieb smib:

> Forgot to say that the icon file is included in the files copied to the
> Lux directory during installation. You  may have to copy this to
> somewhere else and modify the icon location in the script to point to
> this new location

Okay, I think I'll manage. I'll have to first install the innosoft 
software, which I'll do when I find the time. Please bear with me!


Thanks again,
Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/e4dd35b3-771b-d9a1-86b9-6f137c05e718%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 31.05.21 um 10:08 schrieb smib:

Never played with the Registry before - steep learning curve. My current 
installer (and INNO script) can be downloaded from:

https://www.dropbox.com/s/rp5py97hxh1j8gx/Lux%20setup.iss?dl=0


The download is just the .iss script. Thanks for your contribution!

If associated, Lux can be selected  by right clicking an appropriate 
file  --open with-> choose another app. I have not worked out yet how to 
add it to the basic open with list during installation.


I'm not sure if this is possible, I just thought it might be... sorry if 
I've sent you on a wild goose chase.


As the installer changes the registry I suggest that you create a 
restore point before you start.


Thanks for the warning.

As the program files are changing, I think that you should have the 
installer and distribute. I think that it is obvious what needs to 
change in the script to use access the main program files.


Am I understanding you correctly: you would like me to take it over from 
here and use the inno script myself to create the installer when I build 
new versions?


Also I think 
that 'ini'  is not a good file extension to use as so many other 
programs use it for various purposes


May be best to use the '.lux' extension for the ini files lux can 
process. I think this is not a common extension, and it could be 
associated with lux without messing things up for other programs. And if 
a user passes a file with .ini extension on the command line, lux can 
still open it.



PS Don't have privileges to contact you off line


Ooops.. I thought everyone could just reply to a specific person on the 
list. Here, I see your email address as the sender (using thunderbird), 
and I can reply just to you or to the group.


If you want to reply to me off-list, just use the gmail account which is 
given in all my source code. Alternatively, you can also create an issue 
at bitbucket (you don't have to be a member there), just go to


https://bitbucket.org/kfj/pv/issues

and start a new one.

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/00a9418b-5acc-882b-82f7-0b38b0bd0285%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 28.05.21 um 03:55 schrieb smib:


Sorted out icons.


Good.


What mimes (other than pto files) did you have in mind?


I'd let the installer offer to make lux the standard viewer for common 
image files (.jpg, .tif, .png) and also for .exr files. Here on my 
systems I have it as standard program to open PTO files as well - I tend 
to look at the PTOs more often than edit them with hugin - and also for 
the .ini extension, which is a bit debatable, but lux accepts ini files 
as image input, e.g. for cubemaps or to 'wrap' .exr files with metadata. 
But that would also offer other ini files used by the system to be 
opened by lux. I may have to change the extension, or add a shebang, 
what do you think?


All of this should be optional, and the user should have to explicitly 
make the choice for any of the mime options. I don't know if you can 
also make mime associations which only show up in the context menu 
('open with') without changing the default application - if so, I'd 
offer lux in the context menu for all the mime types given above.


BTW - can you offer different types of install? Like, 'regular' install 
to the system's binary folder vs. user-only install without admin 
privileges? That would be nice to have as well.


Looking forward to your installer! Lux 1.0.9 will come out soon, I only 
did a few bug fixes since 1.0.8e, and when we're both ready your 
installer can be distributed via bitbucket downloads - unless you want 
to distribute it yourself.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/a74f731d-533f-db9e-7b5d-600ebb9b85b3%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 27.05.21 um 09:55 schrieb Brian Ims:

Hi Kay,
I'll have a go but here is some of my ignorance showing - where do I 
find the scripts folder with the icons?. I have looked in bitbucket but 
cannot see anything that resembles an icon


Try this one:

https://bitbucket.org/kfj/pv/src/master/scripts/PV.icns

I'm not sure about the format - I managed to get windows to accept it as 
the source for an icon, even though I believe it's a mac format. If you 
can't get it to work, ask again and I'll try and find a different format!


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/27749d91-b9dd-1028-a1ce-61a153804d36%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 26.05.21 um 09:55 schrieb smib:

Link for the installer and the script file used (as generated by the 
wizard) is:

https://www.dropbox.com/sh/ggztv234kfqe437/AADhRXvrgSzcnKozUgoFGtQ-a?dl=0


Thank you for sharing! Since you've posted the link to the list, I 
assume you're sharing it with the group as well, so just now I won't 
upload it to bitbucket downloads. lux 1.0.9 is coming up soon anyway.


I tried your installer here on my windows 10 system, and it seemed to 
work as intended, installing and uninstalling correctly, but I only did 
a brief test. Windows users, check it out and echo back!


It's just what I have in mind as a windows installer, and would only 
need a bit of detail work, like adding icons (there are icons for the 
MacOS version in the scripts folder), and stuff like mime type 
assignments so users can pick if they want file types to be associated 
with the program.


Would you like to do a bit of tweaking yourself?

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/ccbb356d-20f5-562e-5a3c-bf7b0bfec22d%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 26.05.21 um 03:38 schrieb smib:

I am not a serious programmer but I thought I would try to create a 
Windows installer.


Nice one!

You got the idea - you needn't be a 'serious programmer' to help the 
project along. In the FOSS world it's 'scratch your own itch', and if 
you'd like to see a Windows installer and know how to make one, there 
you go. And if you like what you did you can share it.



I used Inno Setup (https://jrsoftware.org/)


I looked at their home page, and it looks good. Their license seems to 
be compatible, and I'd have no problem mentioning that their software is 
used to make a lux installer.


After 
about 5 mins work (including download and install time) I came up with a 
working install program. The creation wizard provides many options most 
of which I left as default. Could be the way to go!


My experience is that the most important step is to find a viable path 
in the first place. Fleshing things out later is nice-to-have. I'd like 
to have a look at the installer you made, can you share it? You could 
either upload it to some cloud place where I can pick it up, or attach 
it to an email and send it off-list.


I'd be happy to have some help with the windows installer, so if you 
feel like working on it a bit to make it nice for everyone to use, you'd 
be very welcome. If not, that's also fine, then I'll just keep your 
suggestion as an option to find a good way to build an installer.


I had the idea to use CMake's packaging capabilities to produce a 
windows installer, which would fit in well with the lux project, because 
it now uses CMake for building. CMake uses cpack, a component which 
builds installers for various platforms. lux' CMakeLists.txt already has 
some content to 'feed' package building, and it's already used to make 
linux packages, so starting afresh with a different package building 
system may be more work, and duplicate effort which was already put into 
the CMakeLists.txt for lux, but so far the effort put into packaging 
wasn't very large - I think it's about the minimum necessary to get a 
package together at all. Have a look at what cpack offers:


https://cmake.org/cmake/help/latest/manual/cpack.1.html

They provide several builders for windows, but there does not seem to be 
one to target inno setup, here's an example:


https://cmake.org/cmake/help/latest/cpack_gen/nsis.html

I haven't tried any of this, but it looks like another viable route to a 
windows installer. But it does also rely on external tools, so going via 
CMake/cpack would just be a matter of convenience.


So, thanks again for your interest and effort! And let me have a look at 
what you made!


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/29c0601a-f3d7-0a57-2b80-4b8a73d694af%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Dear all!

I've done some more work on the windows version, ironing out a few 
glitches and adding documentation. So I've added a new development 
snapshot to bitbucket downloads:


https://bitbucket.org/kfj/pv/downloads/lux_for_windows1.0.8e.zip

This version shows the lux startup banner without flickering. There may 
be short displays of a blank white screen while things are set up, but 
then the banner screen takes over while the data are loaded from disk, 
and with 'first light' from the rendering thread, the banner screen is 
replaced with the latest rendered frame. Metadata display in the status 
line seems to work as intended, so I hope this version can finally pass 
as the release candidate for 1.0.9, sorry for re-announcing it.


While working on Windows, I noticed that, with the 'Path' environment 
variable set correctly, I could use lux.exe like any other regular 
'App', so that I could:


- call lux from the command line (msys2, Powershell, etc.)
- use it as target for the context menu's 'open with'
- use Win+R, shell:send_to to make it a Send To target

I documented my modifications to the 'Path' environment variable in the 
README.


Is there really no-one in this group willing and capable to produce a 
windows installer? I think it's even possible to just tell CMake to 
produce one, it shouldn't be too hard. I'm not so good at windows stuff, 
but from the downloads I figure that there are some windows users who 
download lux bundles, so I'd like to make it easier for them to 
integrate lux into their systems.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/1745bbd5-f8e2-97d5-f211-3c01be2c2893%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

I made another addition to the feature set, which will go into 1.0.9: 
Display of metadata in the status line, now that lux has one. This is a 
two-step process: First you may introduce up to ten exif tags you'd like 
to be read from the current input with this syntax:


  --metadata_query=

Adds a metadata query key to the list of queried metadata for the status
line. This is a vector field, so you can pass this option several times,
but currently the number of queried metadata keys is limited to ten
(0-9). And it's optional.

An example: pass --metadata_query=Exif.Photo.DateTimeOriginal to obtain
the original date and time. If the specified key has no value assigned 
to it, it will be displayed as '---'.


For now, queries are for Exif tags only, and only for those understood 
by libexiv2, as listed in https://www.exiv2.org/tags.html
The conversion to the displayed string is left to libexiv2's toString() 
function and can't be influenced via lux.


  --metadata_format=

Format string for metadata display in the status line. This is new and
still experimental. Pass a format string where %n will be replaced by
the current filename, and %0 to %9 will be replaced by the value gleaned
from querying they corresponding metadata_query entry (see above).
%h yields the image's hfov, %p it's projection and %P the viewer's
target projection.

If you omit the format string, metadata specified with
'--metadata_query=...' will still be displayed: the value will be 
prefixed by the key and a colon, and all specified keys will be 
displayed in numerical order.


For now, this is only in master and you'll have to build yourself.

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b49014ee-0230-c655-f8ce-f65ba32c23b4%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Dear all!

I've uploaded new lux development snapshots to bitbucket downloads, both 
a debian package and a windows 'bundle':


https://bitbucket.org/kfj/pv/downloads/lux-1.0.8-38git-Linux.deb
https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.8c.zip

There are a few new features, most important are these:

- lux now has a status line
- snap-to-XXX aborts on user input for faster response
- unrecoverable errors now show a message box with details

The status line is something I had in mind for a long time, and it helps 
to show the user that 'something' is going on during startup and when 
proceeding to the next image (set) by displaying which image files are 
loaded from disk and also signalling when interpolator buildup is still 
in progress. The status line will also display while there are 
snapshots/stitches/exposure fusions in the make, to explain, e.g., why 
lux does not proceed immediately to the next image or terminate after 
the last one. If 'nothing' is happening in the background, the status 
line disappears.


I used to let snap-to-XXX activity run through even if the user tabbed 
on to the next image or terminated lux, but especially with many images 
visible at the same time (like, when displaying PTO files of panoramas) 
this made it seem that lux 'hangs'. So I made the snap-to-XXX code more 
granular, with several 'exit points' where it can 'bail out' when 
appropriate.


To help users who don't run lux from the command line, I added display 
of a message box when unrecoverable errors occur - which should be quite 
rare. The message box displays the source code filename and line plus an 
explanatory text. It's displayed with tinyfiledialogs, and takes a 
little while to show, especially when coming from full-screen mode, 
because then it has to switch to window mode first.


I'd appreciate feedback - and I'd like to hear feedback even if it 
*does* work as intended ;)


If all is well, I intend to release this feature level as lux 1.0.9.

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/ac817aa4-5eba-d682-c5e8-ab9ef0fe774e%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 23.04.21 um 16:29 schrieb 'Kay F. Jahnke' via hugin and other free 
panoramic software:


>> @Kornel: Can't we include find_package statements ...
>> to make cmake find the required libraries automatically?

Now the penny drops. It's not that find_package actually *fetches* the 
libraries, it only figures out where they have been put on the system. 
As a debian user, where getting a bunch of libraries is as simple as 
apt-get ..., I had asumed that CMake would do that for me. So what I had 
in mind was something like FetchContent, but that doesn't seem to be 
good for loading libraries. Any ideas?


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/8bc013c1-526a-e0c3-079a-d0f0371b9322%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 23.04.21 um 15:44 schrieb Kornel Benko:

Am Fri, 23 Apr 2021 14:49:49 +0200
schrieb Kornel Benko :


Am Fri, 23 Apr 2021 11:59:36 +0200
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
:


@Kornel: Can't we include find_package statements in the CMakeLists.txt
to make cmake find the required libraries automatically? I noticed there
is only a find_package for libexiv2 so far. Maybe you have the code for
the other libraries needed by lux in another project already?

Kay
   


Sure we can. And we do already (CmakeLists.txt:206) for
Vc vigraimpex sfml-window sfml-graphics sfml-system exiv2
Have I missed something?


... no, you haven't, I have ;)

I got the idea this wasn't done automatically, because K. Krieger 
reported that, when he tried building with CMake on macOS, with 
macports, he had to gather the dependencies manually, even though I'd 
told him CMake would now take care of it. So I'll check with him again 
and try to figure out why it doesn't work his end.



How about the attached?


Sucked it in with a typo fix. Thanks!

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/5ab916c4-4c27-2ec9-cce5-99f89fdad97b%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

@Kornel: Can't we include find_package statements in the CMakeLists.txt 
to make cmake find the required libraries automatically? I noticed there 
is only a find_package for libexiv2 so far. Maybe you have the code for 
the other libraries needed by lux in another project already?


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/085b7d27-5214-6768-b758-934d458672d7%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 23.04.21 um 06:44 schrieb David W. Jones:
On 4/22/21 12:34 AM, 'Kay F. Jahnke' via hugin and other free panoramic 
software wrote:
For those of you who'd like to try out the new code, I've uploaded a 
debian package and a windows bundle of a current development snapshot:


https://bitbucket.org/kfj/pv/downloads/lux-1.0.8-21git-Linux.deb


Thanks for the DEB.


My pleasure, and by courtesy of CMake magic, as instigated by Kornel. 
Making the .deb with CMake is much less hassle than making a 'proper' 
debian package, but the CMake-made lux package, which is stripped to the 
bare essentials, is certainly good enough for trying out the Software. 
Enjoy.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/a9d5ca08-e919-02d0-ae05-31cc8b986684%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

I modified the light balancing code. Light balancing is similar to 
photometric optimization in panotools, but so far it's looking at 
brightness only. Previously, the light balance was calculated for all 
partial images visible in the current view, now it always looks at all 
partial images, which is more intuitive and produces the same result 
every time. I also renamed the command line parameter 
'aeb_auto_brightness' to 'light_balance', to clarify that this in not 
only for exposure brackets, but for all synoptic work.


The new code is quite fast, I made the effort to code 'all the way 
through' to the vspline level, where I introduced code specific to 
reductions. With this groundworks, the light balancing is now fully 
multithreaded SIMD code, and there is no more need for intermediate 
images, everything is done at the pixel pipeline level.


For those of you who'd like to try out the new code, I've uploaded a 
debian package and a windows bundle of a current development snapshot:


https://bitbucket.org/kfj/pv/downloads/lux-1.0.8-21git-Linux.deb
https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.8b.zip

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/0158b3bb-8c07-51cb-1af5-24a5852c2edc%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Dear all!

There are now several command line arguments which combine several 
settings into one to make stitching/fusing to the specifications in a 
PTO file more convenient. the output is created in the shape and 
projection given by the PTO file's p-line, lux forwards to the next 
image after the output is ready (or terminates if there are no more images):


--stitch=yes  interpret PTO file as panorama and stitch it
--fuse=yesinterpret PTO file as exposure bracket and fuse it
--hdr_merge=yes   interpret PTO file as exposure bracket hdr-merge it
--focus_stack=yes interpret PTO file as focus stack and fuse it
--deghost=yes interpret PTO file as serial image and deghost it

For faux brackets, 'compress' produces a 'standard' faux bracket
with Ev values -2, 0 and 2; either from an HDR image or from a bracket.
For single image input, the output will have the source image's shape:

--compress=yes  produce a faux bracket image

So if you have, for example, several PTO files containing exposure 
brackets, issue


lux --fuse=yes *.pto

or if you have several EXR files and wish to make faux brackets from 
them, issue


lux --compress=yes *.exr

The new parameters are nice for quickly setting up batch jobs without 
much ado, and will use the settings which 'one would normally use'.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/93e6a299-e46d-a133-f51d-976e75188ff6%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 11.04.21 um 19:27 schrieb Kornel Benko:

Am Sun, 11 Apr 2021 18:41:57 +0200
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
:


@Kornel: I did quite a few changes in the CMakeLists.txt, introducing
one new feature and tweaking the compiler options. Can you have a look
and see if I made any obvious mistakes? You know my CMake isn't so good...


I would set 'USE_LEAK_SANITIZER' explicitly also if not using LEAK_SANITIZER
...
To make it 'LEAK_SANITIZER' obvious in the cmake-gui I would use command 
'option'
...


Thanks for your suggestions, I've added them to the CMakeLists.txt with 
the latest commit.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/58256c4a-6894-7592-4a27-c279dbc4c552%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

@Kornel: I did quite a few changes in the CMakeLists.txt, introducing 
one new feature and tweaking the compiler options. Can you have a look 
and see if I made any obvious mistakes? You know my CMake isn't so good...


@all: The new feature is my use of the clang 'leak sanitizer':

https://clang.llvm.org/docs/LeakSanitizer.html

You may have noticed that I have my own code to track memory allocations 
(the memlog stuff), but that only goes so far and only tracks 
allocations in lux' own code - and only if it's explicitly coded. The 
'leak sanitizer' works at a lower level (a bit like valgrind) and also 
checks activity in the linked-in libraries. It's also allegedly quite 
fast. I may eventually throw out my own allocation tracing code in it's 
favor. Use of the feature is activated by passing -DLEAK_SANIZER=ON to 
cmake, and my own allocation tracing by -DMEMLOG=ON.


Neither of the two is necessary, but I noticed a *strange effect*, maybe 
some of you have seen such behavior, please get in touch:


When I do specific stuff in lux repeatedly (like, show a slide show of 
exposure-fused brackets) - memory use slowly 'creeps up', but it does 
not seem to rise at a steady rate like a 'real' memory leak, instead the 
increase slowly lessens and seems to pretty much stop after some time. 
When I noticed this behavior, I feared for the worst and suspected I had 
a hard-to-detect leak somewhere, but my own tracking of new/delete 
showed no unmatched pairs. This doesn't necessarily mean all is well 
(there may be pointer type issues), so I threw in the leak sanitizer. 
And to my surprise *the problem disappeared*. Like altogether. There was 
no more creeping memory use buildup. The leak sanitizer finds no fault, 
either. Now it might be that the implementation of malloc/free which 
underlies C++ new/delete may be at fault, but I'm not really competent 
to figure out what's going on here, help would be welcome!


Be that as it may, the sanitizer is lightweight so I may just have it 
on/in all the time anyway and benefit twofold: the 'memory creep-up' is 
gone, and I'm instantly notified if there are leaks detected (it even 
found a 40-byte leak in libexiv2...)


Apart from that, the recent pushes to master after 1.0.8 should produce 
a noticeable increase in stitching/fusing speed (and hopefully no creepy 
errors) - on my system, I was able to stitch a small-ish regular 
panorama (6X16MP JPG image stripe to 60MP spherical) in 29 seconds, vs. 
50 seconds using hugin_stitch_project. This is very encouraging!


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b0689c87-a230-453e-e8c8-3818caaadd1b%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 11.04.21 um 09:08 schrieb Harry van der Wolf:


The functionality now works great.
I will create a 1.0.8 mac bundle.


Thanks! I'm quite happy with 1.0.8 myself - I've done a bit of tweaking 
in the meantime which will make stitching/fusing a bit faster, but 
that's just a performance issue, the functionality in 1.0.8 should be 
just fine.


Did you notice the 'snap-to-fuse' in 1.0.8? Like, if you open the 
bracket (br.pto) in lux interactively, after a little while the 'proper' 
exposure fusion is displayed on-screen. It's calculated in the 
background, that's why it isn't displayed immediately (the proper fusion 
takes some time to compute), and if you change the view the normal 
hdr-blended image is displayed briefly until the viewer is at rest 
again, but I think it's a great help:


- if the bracket doesn't look good, no point rendering it to full size
- if it looks good, you may want to only render a section with 'U'
- if you want the rendition to the PTO's p-line, just press 'Shift+U'

We discussed my folder-based workflow, which works great with the new 
feature: I just make separate folders for all brackets, then I call lux like


lux */*.pto

On my system, the 'snap-to-fuse' is even so fast that I don't bother 
producing fused output - I just look at the PTOs for the brackets, never 
mind the short delay.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/10582e27-a0d3-afb6-0718-faa6468ca791%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 10.04.21 um 13:38 schrieb Harry van der Wolf:

Hi,

I did not forget about lux.


I was already doubting you... ;)

8 days ago the graphics card of my laptop gave up. Yesterday finally my 
new laptop arrived after 4 days delay in the warehouse.

This morning I downloaded the latest lux from git and compiled it.
I got in general good results, but also ran it on a series of test 
images and got strange effects on the edges. Note that I took a lux 
version of 8~10 days old which had the same issue but also "dark areas" 
in the images. As that is now "solved" in this latest version, I did not 
include those images.


I tested 1.0.8 quite throroughly, so it's probably best if you pick that 
version, just use


  git checkout 1.0.8

to get precisely that version.


I first run align_image_stack on the images which delivers a pto.
Then I run lux with
lux -W \
              --blending=hdr \
              --snapshot_like_source=yes \
              --snapshot_facet=1 \
              --snapshot_prefix="${PREFIX}" \
              --snapshot_extension=$SUFFIX \
              --aeb_auto_brightness=yes \
              --next_after_fusion=yes \
              --build_pyramids=no \
              --build_raw_pyramids=no \
              --quality_interpolator_degree=1 \
              --snapshot_threads=4 \
              "${PTO}"

See attached my luxfuser.sh script, but renamed as luxfuser.txt

In my Google drive you will find 2 examples ...



The lux.jpg has strange "cadres" around the image.


The output is correct, even if that may be unexpected. I'll explain: you 
specify '--snapshot_facet=1'. This means 'create output which covers the 
same area as facet #1 (the second facet). Because the facets don't 
overlap perfectly, some of the output does not have input from all 
contributing images and looks different (namely the stripes along two of 
the edges).


The easiest way to deal with this issue is to rely on the PTO: I've 
recently coded p-line processing and changed the semantics of 
'snapshot_facet'. The default for 'snapshot_facet' is now -1 (note the 
minus) which tells lux: 'when doing snapshots/stitches/fusions with 
snapshot_like_source, produce output as specified by the pto file's 
p-line'. When I coded the p-line processing, I also added output 
cropping. To get a correctly cropped result, try this:


First, you need a PTO with proper cropping info (note the -C):

  align_image-stack -C -p br.pto *.JPG

Next, you call lux like this:

  lux --snapshot_like_source=yes --next_after_fusion=yes br.pto

... plus any other parameters you may need. Note that these parameters 
are only needed when you don't have enough memory, maybe your new 
computer has enough memory now:


   --next_after_fusion=yes \
   --build_pyramids=no \
   --build_raw_pyramids=no \
   --quality_interpolator_degree=1 \

And if you're batching the job anyway, you can omit the

   --snapshot_threads=4 \

lux will pick a 'good' value automatically.

p-line processing is quite a recent addition, but it's in 1.0.8 for 
sure. Please let me know if this solves your issue!


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/12b1c0a8-a552-c643-2a5e-e809ce4fba28%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 06.04.21 um 20:05 schrieb Kornel Benko:

patch to handle the case that we are just at the start of the searched tag


Thanks. pushed to master.

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/3e2af621-2ba5-3f7d-4f69-d0f7b58eee54%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Windows users, I've uploaded a windows bundle of lux 1.0.8. The build 
was done with cmake on msys2. You can download the bundle from here:


https://www.magentacloud.de/lnk/01CohqKn

Password: hugin-ptx

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4ccb54ec-cfab-250b-4f9a-edc7fb88f3a8%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 05.04.21 um 12:17 schrieb Kornel Benko:

Am Mon, 5 Apr 2021 11:54:59 +0200
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
:


lux version 1.0.8 released!



Missing tag for 1.08.

  $ git describe --match 1.0.7 --tags
1.0.7-69-g5a096a0

vs
  $ git describe --match 1.0.8 --tags
fatal: No names found, cannot describe anything.
Exit 128


My mistake - forgot the git push --tags.

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/bed24c28-f3e4-8fc6-fc03-b9b86d21f32a%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

lux version 1.0.8 released!

This release fixes several bugs and adds new features. The most notable 
new feature is 'snap-to-stitch', which detects when the viewer is at 
rest, and then launches a background job to do a 'proper' stitch - or 
exposure fusion, when in hdr blending mode - of the current view, which 
may take some time and replaces the current view once it's ready.


At the same time, there's now a heuristic looking at the images in a PTO 
and determining from their relative positions and Ev values what 
blending mode should best be used. This heuristic is on by default, you 
can still manually override by passing '--blending=...' on the command 
line. Three blending modes can be chosen automatically:


'ranked' for 'normal' panoramas
'hdr' for exposure brackets with varying Ev
'quorate' for serial shots with constant Ev

The last mode is for deghosting and removes outliers from serial images.

When doing 'source-like snapshots' of PTO-based views, the default is 
now to use the information in the PTO's p-line to set the size, 
projection, and cropping of the output. So if you're viewing, e.g., a 
panorama in lux, and press 'Shift+P', you should get output which is 
very similar to what hugin would have produced as blended output.


lux does some things differently - it does not do seam optimization, but 
it does tele inserts without the need for masking: if you have images 
with several different hfov values in the PTO, it will put images with 
smaller hfov in front of other images. This is really nice to 'patch in' 
tele shots.


All in all, using lux for PTO input should be simple now - normally, 
just opening the PTO with lux should find the right mode. Keep in mind, 
though, that lux only knows a subset of PTO (e.g. it does *not* know 
translation parameters) and it will just ignore what it doesn't know, 
rather than reject it. And don't be impatient when a view takes some 
time to 'snap to stitch' - especially when many images are visible at 
the same time. Finally, keep in mind that lux is memory-hungry with the 
default settings, and if your PTO has many - or large - images, you may 
be better off with --build_pyramids=no or even --squash=1.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/66bd770a-e34c-8351-4fad-d6de86368efa%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Windows users, I've uploaded a new windows bundle, this time the binary 
was built with cmake, and it's now called lux.exe. Please note that the 
documentation of the new features is still missing, and the docu still 
refers to 'pv'. This is another development snapshot (1.0.7c), hopefully 
the last before I release lux 1.0.8!


The bundle is here:

https://www.magentacloud.de/lnk/OcCIhsLZ

Password: hugin-ptx

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b574d80c-3771-15a1-0a1c-9bfe236ba8c8%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 30.03.21 um 20:12 schrieb Kornel Benko:

Short googling ... Citing a result:
You need to link ole32.dll ("-lole32"). In order to link to that, you 
need to
have the import library for it (ole32.lib) installed, and in your search paths. 
I
assume you might need to have the Windows SDK installed for that.


Okay, here on my msys2 installation linking ole32 works just fine but it 
wasn't enough to deal with all the errors. I had to do a few more things:


- Comdlg32 is also needed.

- throw out pthread from the 'general' list of checked-for libraries:

set(LibFound ON)
foreach(_l Vc vigraimpex sfml-window sfml-graphics sfml-system exiv2)
...

- finally, I had an old vigraimpex build in /usr/local/lib, which CMake 
picked in preference of the one from package management - I removed 
that. My mistake, but something to keep in mind - /usr/local/lib takes 
preference, as on Linux.



Or even better
if(WIN32)
target_link_libraries(${_pv} ole32)
endif()


WIN32 does not seem to be defined on msys2, so I changed the 
link-specific conditionals to


if (WIN32 OR MSYS)
  target_link_libraries(${_pv} Ole32 Comdlg32)
else()
  target_link_libraries(${_pv} pthread)
endif()

Which also fixes the redefined pthread symbol errors for the windows 
build. With these changes, the cmake build runs through on msys2, and it 
also works on linux. @Harry: can you try on the mac?


@Kornel: I checked the code looking at the desktop size, and I think I 
made a mistake processing it. I changed it so that it should now indeed 
take the desktop height as the relevant datum. Can you please check on 
your ultra-wide setup? The GUI stripe should now only cover half your 
desktop's width.


This push also adds 'snap-to-stitch' processing for faux brackets. You 
may wonder what that means, so I'll explain quickly:


Faux bracketing is a technique where a single image (preferably one with 
extended dynamic range) is made into several LDR images with different 
exposure, so you get an image set that is *like a bracket* - hence the 
'faux'. This 'false' bracket is then submitted to ordinary exposure 
fusion. The resulting image has the 'look' of an exposure fusion with 
the same compressed dynamic range, so faux bracketing can be considered 
a *tone-mapping operation*, and it produces consistently pleasant 
results, which can't be said of many of the 'standard' tone-mapping 
operators, which are often encumbered by strong sensitivity to 
parametrization, local effects, strange colours etc.


lux can use this technique for single HDR images (which is obvious), but 
it can also use it on image sets. Here the logic is a bit more involved: 
lux first internally creates a HDR blend of the image set, and then uses 
the faux-bracketing on this internally-generated HDR image.


Until this commit, lux could only produce faux brackets as snapshots, 
but now they can be viewed 'live'. faux brackets need to know the 
desired exposure values for the artificial bracket, which are passed 
with several '--faux_bracket_ev=...' parameters. So to look at a faux 
bracket of 'image.exr' done with Ev values -2, 0, and 2, you'd invoke 
lux like this:


lux --faux_bracket=yes \
--faux_bracket_ev=-2 \
--faux_bracket_ev=0 \
--faux_bracket_ev=2 \
image.exr

As with all 'snap-to-stitch' processing, it takes a little while until 
the result shows - the rendering of such jobs is only done if the viewer 
is at rest with no other tasks running. Expect rendering times in the 
order of magnitude of a second. To save the result to disk, use 'U' or 
'Shift+U', with the same semantics as 'normal' exposure fusions.


All changes were pushed just now, please check it out and enjoy! I think 
that the set of features I'd like to see in 1.0.8 are now all present, 
I'll do a bit more testing and tweaking and then I think it's time for 
the next level :D


It would be nice if you lot could also do a bit of testing on your end!

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/27fccd31-c399-44ad-f0bc-3eecb73e573f%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 30.03.21 um 13:03 schrieb Kornel Benko:


Could you please post
1.) The error messages you get if compiling with cmake configuration
2.) compile (and link) commands if compiling with make config


Yes, sorry I didn't get around to it yet, I was busy with other stuff. 
The problem is with linking - the compile runs through fine, but then 
the linking stage fails. I attach a complete session log, from setting 
up the build directory until the failure.


I'm not sure if I'm doing everything right, I just tried to do the same 
sequence I use on Linux, assuming that msys2 works in a similar fashion. 
It may well be that the msys2 build on w10 is not a well-trodden path, 
but I don't have MSVC here.


Please let me know if you need more information or want me to try out 
stuff on windows.


Kay


--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b4df26ab-0043-925a-e266-dace78d3c91e%40yahoo.com.
Kay F. Jahnke@DESKTOP-071N1FJ MSYS ~/src/pv
$ mkdir build

Kay F. Jahnke@DESKTOP-071N1FJ MSYS ~/src/pv
$ cd build

Kay F. Jahnke@DESKTOP-071N1FJ MSYS ~/src/pv/build
$ cmake ..
-- The C compiler identification is Clang 11.0.0
-- The CXX compiler identification is Clang 11.0.0
CMake Warning at /usr/share/cmake-3.20.0/Modules/Platform/MSYS.cmake:15 
(message):
  CMake no longer defines WIN32 on MSYS!

  (1) If you are just trying to build this project, ignore this warning or
  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
  the CMake cache.  If later configuration or build errors occur then this
  project may have been written under the assumption that MSYS is WIN32.  In
  that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.

  (2) If you are developing this project, add the line

set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is required

  at the top of your top-level CMakeLists.txt file or set the minimum
  required version of CMake to 2.8.4 or higher.  Then teach your project to
  build on Cygwin without WIN32.
Call Stack (most recent call first):
  /usr/share/cmake-3.20.0/Modules/CMakeSystemSpecificInformation.cmake:27 
(include)
  CMakeLists.txt:52 (project)


-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /mingw64/bin/clang.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /mingw64/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- /usr/bin/git.exe describe --match 1.0.7 --tags
-- WORKING_DIRECTORY = /home/Kay F. Jahnke/src/pv
-- LUX_PACKAGE_RELEASE = 176
-- CMAKE_INSTALL_PREFIX = /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/Kay F. Jahnke/src/pv/build

/usr/bin/cmake.exe -E cmake_progress_start "/home/Kay F. 
Jahnke/src/pv/build/CMakeFiles" "/home/Kay F. 
Jahnke/src/pv/build//CMakeFiles/progress.marks"
make  -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/home/Kay F. Jahnke/src/pv/build'
make  -f CMakeFiles/lux.dir/build.make CMakeFiles/lux.dir/depend
make[2]: Entering directory '/home/Kay F. Jahnke/src/pv/build'
cd "/home/Kay F. Jahnke/src/pv/build" && /usr/bin/cmake.exe -E cmake_depends 
"Unix Makefiles" "/home/Kay F. Jahnke/src/pv" "/home/Kay F. Jahnke/src/pv" 
"/home/Kay F. Jahnke/src/pv/build" "/home/Kay F. Jahnke/src/pv/build" 
"/home/Kay F. Jahnke/src/pv/build/CMakeFiles/lux.dir/DependInfo.cmake" --color=
Consolidate compiler generated dependencies of target lux
make[2]: Leaving directory '/home/Kay F. Jahnke/src/pv/build'
make  -f CMakeFiles/lux.dir/build.make CMakeFiles/lux.dir/build
make[2]: Entering directory '/home/Kay F. Jahnke/src/pv/build'
[  5%] Building CXX object CMakeFiles/lux.dir/pv_no_rendering.cc.o
/mingw64/bin/clang++.exe  -I"/home/Kay F. Jahnke/src/pv" -Ofast -D USE_VC -D 
VECTORIZE -fno-math-errno -Wno-unused-value  
-DPV_FONTDATADIR=\"/usr/local/share/lux//fonts\" -std=gnu++11 -Ofast 
-std=gnu++11 -MD -MT CMakeFiles/lux.dir/pv_no_rendering.cc.o -MF 
CMakeFiles/lux.dir/pv_no_rendering.cc.o.d -o 
CMakeFiles/lux.dir/pv_no_rendering.cc.o -c "/home/Kay F. 
Jahnke/src/pv/pv_no_rendering.cc"
[ 10%] Building CXX object CMakeFiles/lux.dir/pv_initialize.cc.o
/mingw64/bin/clang++.exe  -I"/home/Kay F. Jahnke/src/pv" -Ofast -D USE_VC -D 
VECTORIZE -fno-math-errno -Wno-unused-value  
-DPV_FONTDATADIR=\"/usr/local/sh

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 30.03.21 um 09:24 schrieb 'Kay F. Jahnke' via hugin and other free 
panoramic software:

Am 29.03.21 um 23:51 schrieb smib:

Hi Kay,
Are you planning to provide another windows build?  At the moment I am 
having problems building but this is due to my lack of knowledge


I merged master into msys2 and tried a build on w10. I did not manage 
with cmake, but the 'plain old makefile' worked for me. I made a bundle 
- this is a development snapshot, so don't be surprised if it's not 
stable or bits are missing, but the latest features are in it and I did 
a brief test. You can find it here:


https://www.magentacloud.de/lnk/5CiIh4ZO

Password: hugin-ptx

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/75a14068-2c7f-5b9f-c6e8-2545cb26c1d0%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 29.03.21 um 23:51 schrieb smib:

Hi Kay,
Are you planning to provide another windows build?  At the moment I am 
having problems building but this is due to my lack of knowledge

Brian


I'm still wrestling with my latest features, but when in release a new 
version - hopefully within a few days - I'll also make a new windows 
bundle. The windows branch may not be viable right now, please bear with me.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/ded4a116-2340-592c-aa0a-155e342108cc%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

There is new functionality in lux: I call it 'snap-to-stitch'.

After a few weeks of development, I have gained enough confidence in my 
implementation of the multilevel blending code to try and use it 
automatically when a PTO is displayed. Here is the logic:


Per default, lux switches to 'high quality rendering' if there is no 
activity: neither ongoing user input, nor any background jobs, and no 
jobs pending in any of the queues. Until recently, 'hq rendering' would 
display the 'live view' of a PTO file, just with better interpolation. 
Now what happens is that a stitch or exposure fusion of the current view 
is produced in the background and displayed once it's ready.


For 'ranked blending' - the default, used for panoramas - this may be 
hard to notice, but if the live view showed 'hard' borders between the 
images, with the switch to the blended result these borders should 
simply 'disappear' after a while. For 'hdr blending' the switch is much 
more noticeable, because due to the exposure fusion the intensity values 
change a good deal - blown-out highlights darken and become visible, and 
dark areas receive fill light.


The snapshot logic remains the same: 'E' produces a snapshot of the live 
view, 'U' an exposure fusion and 'P' a panorama. As I have explained in 
my last post, the default for the 'source-like' snapshots, done with 
'Shift+E', 'Shift+U' and 'Shift+P' is now to produce a rendition 
according to the p-line in the PTO.


So trying out the new functionality is simple, especially for panoramas: 
just load a PTO with a panorama and see the boundaries between the 
images disappear after some time. Play with it: zoom in and out, look at 
other places. Once the viewer is at rest, the 'snap-to-stitch' should 
happen after some time. If you don't like the new mode, you can easily 
switch it off by pressing F12 or clicking on 'IDLE HQ'. For exposure 
fusions, you have to invoke lux with --blending=hdr to see the effect.


Of course, all of this is CPU- and memory-intensive, so if you use it 
with large panoramas, the background task may take long, and - as ever - 
you may run into memory problems, so you may want to consider adding 
--build_pyramids=no and possibly even --facet_squash=1 to your command 
line to lower RAM consumption. The idea is not to use lux' PTO-viewing 
capabilities to actually *look at* PTOs for any length of time - if you 
want to do that, stitch/fuse to a single output file and view that 
instead. What's intended is to give you a tool to inspect what the 
blended/fused output will look like before you actually commit to 
stitch/fuse.


And, again, a word of warning: lux' understanding of PTO files is 
limited to source image projection, position, Ev, lens and vignetting 
correction - and now the projection, shape, fov and crop from the p-line
for source-like snapshots. Don't be disappointed or surprised if other 
stuff from the PTO file is simply ignored. And be aware of the fact that 
this is new code and not yet well-tested. Start with something simple 
and work your way up.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/956268d4-2436-0507-b13a-50a76ebc2537%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Still with me?

I changed the semantics of --snapshot_facet=...
If this value is not passed explicitly, it defaults to -1. This tells 
lux to render source-like snapshots, fusions and stitches not to the 
shape and projection of a given facet, but to the *projection and shape 
given in the PTO file's p-line*. I also added code to process the 
cropping information in the PTO file. In sum, producing images which are 
similar to the output other PTO-processing software renders is now quite 
easy: Load the PTO, and press Shift+P (to stitch) or Shift+U (to fuse) 
to the target specification given in the PTO. In batch mode the same 
mechanism can be used, so for stitches use --next_after_stitch=yes and 
--snapshot_like_source=yes, and for exposure fusions 
--next_after_fusion=yes and --snapshot_like_source=yes.


Because cropped images could only be provided with correct metadata if 
the target format was spherical (using GPano metadata, which are only 
good for spherical) I finally decided to provide lux-specific metadata 
which work for all projections lux can handle and describe image 
projection and cropping. lux produces images with these metadata set, 
And when it loads such images it will processed cropped images correctly.


Please not that lux still does not process all infomation in the PTO: it 
ignores masks, stacks, and 'image active' flags, and also all 
specifications of the type of output except for it's size, projection 
and cropping, so @Thomas: if you specified in hugin that you want an 
exposure fusion, you won't get it automatically in lux: in lux you have 
to press 'U' or 'Shift+U' for a fusion, which may explain your failure 
to do an exposure fusion.


Again @Thomas: concerning the long loading time of your panorama: lux is 
memory-hungry, but there are ways to make it work with less memory (and 
load faster). You can try this flag, which keeps lux from building a 
good amount of interpolation structures which are not strictly necessary:

--build_pyramids=no
If your images still don't fit into memory, try
--facet_squash=1
Which is an emergency measure only and reduces resolution to one half.

Third @Thomas: during the time lux sets up, there is really nothing in 
it which might respond or with which you could interact. If the blank 
screen bothers you, start in windowed mode (-W or --fullscreen=no), or 
just Alt-Tab to something else: it's not your computer which is 
unresponsive, only lux, while it builds it's interpolators. While it 
does that, it will use a lot of CPU, though, and the system may respond 
sluggishly.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/e140fb82-1cdd-7702-138d-cab099be8bf3%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 22.03.21 um 18:13 schrieb T. Modes:



kfj schrieb am Sonntag, 21. M??rz 2021 um 13:08:59 UTC+1:

The key feature is *viewing* PTO files without having to stitch them
first. The recent addition of optional 'proper' stitches of what you
see
in the live view is a nice-to-have extra.


I did a short test on Windows.
When opening a medium sized pto project, the (full) screen remains white 
for about a minute (without any feedback). During this time the viewer 
takes all available memory and blocks the computer.
Hugin opens the same file immediately and remains responsive. It tooks 
about 20 s until all full images are loaded. The memory usage is also 
significant lower.


A short test with the exposure fusion resulted in bright and dark areas 
instead of nicely fused result.


Thank you for your feedback. It's easier for me to fix bugs if you 
include the version of lux (bundle) you used, the PTO files involved, 
and possibly the images. Then describe your invocation of lux (command 
line parameters) and which UI action you performed to lead to the result 
which you're not happy with. I'll see if I can reproduce what happened. 
If you invoked lux from the command line, the console output can also be 
helpful.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/1a3a85a0-2c94-64d0-e81d-48816952d701%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 22.03.21 um 13:54 schrieb Harry van der Wolf:



Op ma 22 mrt. 2021 om 10:47 schreef 'Kay F. Jahnke' via hugin and other 
free panoramic software <mailto:hugin-ptx@googlegroups.com>>:



This is done with --snapshot_magnification=..., as described in my post.
If your screen is 1920X1080, you work fullscreen,  and you have
--snapshot_magnification=10, your output on pressing 'p' will be
19200X10800


Yes, I must admit I skipped too fast over that, but I was looking for a 
"screen command". Your command line option requires me to first check 
the approximate size of the image, then give the magnification on the 
command line, and then press the "p" once you are zoomed out.
How do I do that in the live view without specifying all kind of things 
on the command line (which you always need to remember)?


You can inject additional command-line arguments in the 'override line'. 
Open the GUI, click on the text field in it's lower right. There you can 
enter additional command line arguments which take effect as soon as you 
commit with 'Return' and cumulate until you open another image/pto/ini file.


Doing more of that with the (G)UI instead would require extending it, 
which is on my list, but will take some time. I think for the time being 
rendering to the size given in the PTO's p-line will be a reasonable 
option, so you won't have to pass too many CL arguments, I'll implement 
that soon.


Keep in mind that exposure fusion, faux brackets, image stitching and 
quorate blending are new features in lux. Testing them may be a bit 
awkward, because it may require using additional CL arguments. Once it's 
established that the functionality performs as expected, the GUI can follow.


And if you simply pass, for example, --snapshot_magnification=6 with the 
initial invocation of lux, the parameter will be used for every 
snapshot/stitch/fusion in the session. If your initial estimate turns 
out wrong for a specific image, use the override.


Let me point out once again that lux is designed as an image and 
panorama viewer. The new functionality may give it a new 'spin'. Don't 
think of it as a new stitching/fusing program which shows you some sort 
of preview until you hit the stitch button. It's the other way round: 
You look at images and if you want to share something you take a 
snapshot. If you look at a PTO and a snapshot of the live view isn't 
nice enough, you do a stitch or fusion with 'p' or 'u'. I added batch 
capability for extensive testing and to, for example, fuse many brackets 
without manual intervention, but this is quite new and not so 
well-integrated as one might wish for.


There is another feature I'd like to point out to you: it's the second 
function of ini files. You can just gather a specific set of parameters 
in an ini file, try '6Xstitching.ini':


blending=ranked
snapshot_magnification=6
snapshot_extension=exr
fullscreen=no
window_width=1600
window_height=600

Note how this ini file does not contain any images. Then you launch lux 
like this:


lux --ini_file=6Xstitching.ini

It has the same effect as if you had passed all the arguments on the 
command line. All images you subsequently open during this session will 
have these values set - only the window size and fullscreen will be 
changed if you interact with them.


So then assuming you have a bunch of panoramas to process, you can do

lux --ini_file=6Xstitching.ini *.pto

And all that's left to do is to get the fit right and hit 'p'.

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/be8fcd00-4ea7-7165-b44f-6b2b6d828eab%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 22.03.21 um 10:40 schrieb Harry van der Wolf:



Op ma 22 mrt. 2021 om 10:24 schreef 'Kay F. Jahnke' via hugin and other 
free panoramic software <mailto:hugin-ptx@googlegroups.com>>:


Am 22.03.21 um 09:56 schrieb Harry van der Wolf:
 >
 > Op zo 21 mrt. 2021 om 18:17 schreef 'Kay F. Jahnke' via hugin and
other
 > free panoramic software mailto:hugin-ptx@googlegroups.com>
 > <mailto:hugin-ptx@googlegroups.com
<mailto:hugin-ptx@googlegroups.com>>>:
 >
 >
 >     Found the 'black output' bug and fixed it. Please rebuild.
 >
 > The black image is fixed now

Thanks for reporting back!

 > but I find it confusing that when I have a
 > wide panorama, I have to zoom out to get the entire panorama in view
 > (without the distortions on the side) before I can press "p" to
stitch it.
 > And the panorama is for example 1800x355 (to fill the screen),
and that
 > is then also the resolution it is saved in.
 > I thought the stitching would take the pto parameters into account.

There are two things going on here. The first is the 'target
projection'. That is the projection used to display the data on-screen,
which is also used to produce snapshots, stitches, and fusions. A
panorama with 1800x355 looks like a stripe panorama, which you may want
to render in spherical or cylindric projection. Use
--target_projection=spherical or --target_projection=cylindric. The
default in lux is to display in rectilinear, as if the user was looking
at the scene with a 'normal' lens, but you can't use that for very
wide-angle images.


That is not what I mean.
The original pano when stitched is indeed a partial stripe like panorama 
in the resolution 11000x3600 pixels (just as example. I actually only 
make partial panoramas).
Lux creates the pano snapshot of what it is visible in the viewer. As my 
screen is 1920x1080, I need to zoom out in LUX to get the picture more 
or less "full in view".
If I now press "p", I get a panorama maximum the size of my screen 
width, instead of (approximately) the original size.


This is done with --snapshot_magnification=..., as described in my post.
If your screen is 1920X1080, you work fullscreen,  and you have 
--snapshot_magnification=10, your output on pressing 'p' will be 19200X10800


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/18bfbec6-8af9-5876-6180-ba7ce2e8daa5%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 22.03.21 um 10:13 schrieb Kornel Benko:

Am Mon, 22 Mar 2021 09:08:48 +0100
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
:


Am 21.03.21 um 22:08 schrieb Kornel Benko:


Still black result-picture BTW.


Can you be more specific? like what panorama (maybe send the PTO), what
parameters, alpha channel images or not? I don't get the 'black output'
anymore since 4de331e.

Kay



I was soo sure I had recompiled. (but forgot to install!).

Works.


Good. Happens to me as well. I run make -j8, then when it's ready I 
wonder why it still doesn't work.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/36b64409-047a-b893-7a93-125630eeb1ea%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 22.03.21 um 09:56 schrieb Harry van der Wolf:


Op zo 21 mrt. 2021 om 18:17 schreef 'Kay F. Jahnke' via hugin and other 
free panoramic software <mailto:hugin-ptx@googlegroups.com>>:



Found the 'black output' bug and fixed it. Please rebuild.

The black image is fixed now


Thanks for reporting back!

but I find it confusing that when I have a 
wide panorama, I have to zoom out to get the entire panorama in view 
(without the distortions on the side) before I can press "p" to stitch it.
And the panorama is for example 1800x355 (to fill the screen), and that 
is then also the resolution it is saved in.

I thought the stitching would take the pto parameters into account.


There are two things going on here. The first is the 'target 
projection'. That is the projection used to display the data on-screen, 
which is also used to produce snapshots, stitches, and fusions. A 
panorama with 1800x355 looks like a stripe panorama, which you may want 
to render in spherical or cylindric projection. Use 
--target_projection=spherical or --target_projection=cylindric. The 
default in lux is to display in rectilinear, as if the user was looking 
at the scene with a 'normal' lens, but you can't use that for very 
wide-angle images.


With spherical target projection, you still have to zoom out (unless you 
pass the desired view hfov on the command line, like --hfov_view=180) to 
get the whole panorama into view. If you want your output to have a 
specific aspect ratio (like 1800x355), remember that lux is 'wysiwig', 
so you have to work with a window of that size (--fullscreen=no 
--window_width=1800 --window_height=355), and if the output is too small 
for your taste, use --snapshot_magnification=..., for example 
--snapshot_magnification=4 to get 7200X1420 output when you finally 
press 'p' - or when you batch the job with --next_after_stitch=yes.


The second thing that bugs you is that lux does not look at p-lines in 
the PTO, but only the i-lines. I intend to add p-line processing, but 
for a viewer it made no sense initially. So what I'll add is an option 
to display a PTO as specified in the p-line, with that projection and 
fov. For panoramas, this can even become what happens if you press 
'Shift+p' because the current setting makes little sense. But to display 
the specification in the p-line correctly, I would also need to 
implement (live) cropping, which will take some time. Please bear with 
me, and until then you'll just have to pass the target projection on the 
command line. I'll add p-line processing without cropping soon to test it.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/63f29fa4-2a4f-a885-5614-4e463cec6448%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 21.03.21 um 22:08 schrieb Kornel Benko:


Still black result-picture BTW.


Can you be more specific? like what panorama (maybe send the PTO), what 
parameters, alpha channel images or not? I don't get the 'black output' 
anymore since 4de331e.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b384cdb6-9f0d-508e-c082-a80d63767b54%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 21.03.21 um 12:37 schrieb Bruno Postle:

On Sun 21-Mar-2021 at 10:26 +0100, Hugin ptx wrote:


Don't get two things mixed up: First, there's hugin, the software 
package. This is - quite deliberately - an effort separate from hugin, 
the program, and could just suck in lux as it is; it's just a matter 
of adding it to the set of binaries in the package/bundle. Packagers 
have not yet come forward, but I hope the recent move to CMake will help.


lux (and multiblend) _could_ be included in the Hugin Windows/OSX 
installers, as could the old panoglview viewer for that matter, if 
somebody wants to step up and do the work, but as long as they are 
separate codebases it will only ever be a separate package for Linux.


Fine, We'll try and make it as accessible and simple to pull in as we 
can, and the packagers can decide if they want it in the bundle.


There is a fedora lux RPM package here: 
https://copr.fedorainfracloud.org/coprs/bpostle/panorama/packages/


Nice one! Hopefully some fedora user will try it! When it comes to 
stitching, there was a stupid bug which I only fixed very recently. May 
be best to rebuild the package...


The CRLF bug you posted to the issue tracker is also fixed.

..also multiblend 2.0, plus a recent Hugin snapshot which has a nice 
builtin panorama viewer and zooming in the preview window.


A nice built-in panorama viewer! I'll check that out. The zooming in 
preview mode I already saw, and I found it felt a bit rough-and-ready - 
maybe it's improved since then. Will have to build from source, though, 
because I'm on ubuntu.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f2deb75e-b705-8ce1-4e69-0ee3fce9dda0%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 21.03.21 um 18:34 schrieb Harry van der Wolf:



Op zo 21 mrt. 2021 om 17:54 schreef 'Kay F. Jahnke' via hugin and other 
free panoramic software <mailto:hugin-ptx@googlegroups.com>>:



I downloaded the three-image alaska 'panorama'. It uses translation
parameters, which lux does not process, hence the failure. The image is
not a panorama: The three partials have been taken from different
positions, always facing the facades, probably several meters apart.
It's an attempt to create a 'street view-like' image mosaic from a 3D
scene (dodgy, mosaics are for 2D content), hence the translation
parameters to attempt a fit, which works okay-ish because the facades
are roughly in-plane.


The Alaska one is the only one I didn't try.


First on the list... ;)

But I never paid attention to the TrX, TrY and TrZ parameters. My 2 
image pano is a hand-shot pano which I initially used for parallax. And 
yes: it needs translation parameters as well.

It is just small and handy and a quick test.


Just try any 'real' panorama with no translation. And the black output 
was a different matter, and should be fixed if you pull and build again.



I will take one of my other panos, but lately I don't do much panos.
Only bracketing and noise reduction with ais and enfuse. (burst mode 
with a number of photos. I never had nor will buy a full-frame so I 
sometimes make burst-mode photos and ais/enfuse them to remove the 
noise. Works great)

I will test pv/lux as well with noise reduction.


If you do simple HDR blending or an exposure fusion with lux on a serial 
shot with constant Ev, you should get the noise reduction as well, 
because the images will simply be averaged where they fit.


Usually the noise is most problematic in dark areas, so an AEB with 
different exposures - including at least one bright one which shows the 
dark areas well - is even better for noise reduction. If you don't have 
bright content, just leave the dark shot(s) from the bracket out.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/d6f23672-94f5-4d21-8fdb-53692bf6cbdc%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

@Harry, @Kornel

Yuv has pointed out that I did not have the issue tracker active on the 
bitbucket repo. Again, my fault. If you like we can move technical 
discussions to the issue tracker, which is a more structured approach as 
well. I set it up so you don't need a bitbucket account for the issue 
tracker. Then we can stop cluttering hugin-ptx with lux technical details.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b015013a-ba71-8199-0727-f996bd107e5c%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 21.03.21 um 17:54 schrieb 'Kay F. Jahnke' via hugin and other free 
panoramic software:



Am 21.03.21 um 13:31 schrieb Harry van der Wolf:

So it only takes image 0 and 1, and then still delivers a black image.


I can confirm here that I get black JPG and TIF output, which seems to 
be a bug. I'll investigate...


Found the 'black output' bug and fixed it. Please rebuild. Sorry, it was 
a really stupid bug, and has nothing to do with the PTO, just with me 
committing to quickly. But bear in mind to not try lux with panoramas 
using translation parameters.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/aa4e52a0-98d6-e32c-f099-7061c3fe1e1d%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 21.03.21 um 13:31 schrieb Harry van der Wolf:



Op zo 21 mrt. 2021 om 13:05 schreef 'Kay F. Jahnke' via hugin and other 
free panoramic software <mailto:hugin-ptx@googlegroups.com>>:



Fine, so it didn't work. Why don't you just zip the PTO and images and
mail them to me? I'll have a look.


The 2 image PTO is from my living room with a lot of "small rubbish" in 
there to test on parallax on short distances. I am not going to share 
that one ;)


You can still share the PTO, I may be able to see from it what's amiss. 
And then there's pto_gen (I think that's what it was called) to replace 
a PTO's images with dummy images. When it comes to parallax, note what I 
wrote further down about which parameters lux does process. Your image 
set should be parallax-free.


Donald Johnson shared a number of downloadable pano sets for multiblend 
in this post 
<https://groups.google.com/g/hugin-ptx/c/pRFIe_77yvo/m/UIuYlJlrDwAJ>.

Or directly:
https://ln2.sync.com/dl/f27685a80/392a24qm-7uudw2mp-4vzsr5eg-qaj852qx 


I downloaded the three-image alaska 'panorama'. It uses translation 
parameters, which lux does not process, hence the failure. The image is 
not a panorama: The three partials have been taken from different 
positions, always facing the facades, probably several meters apart. 
It's an attempt to create a 'street view-like' image mosaic from a 3D 
scene (dodgy, mosaics are for 2D content), hence the translation 
parameters to attempt a fit, which works okay-ish because the facades 
are roughly in-plane.


lux follows the panorama paradigm: all images should be taken from the 
same spot. That's why you use panorama heads and parallax-free technique.


lux only processes source projection, fov, yaw, pich, roll, lens 
correction parameters a, b, c, d and e and vignetting correction 
parameters Va, Vb, Vc, Vd, Vx and Vy.


If the 'live stitch' in lux does not show the images as you'd expect, 
the B algorithm won't make it any better.



...
So it only takes image 0 and 1, and then still delivers a black image.


I can confirm here that I get black JPG and TIF output, which seems to 
be a bug. I'll investigate that and post again once I've found what's 
amiss. Strangely enough, with exr output, I get the expected result. 
Please bear with me.


It is already a great reassurance that loading an aligned, exposed pto 
or ini, and pressing "p" is the right thing to do.


It *should* be.


Unfortunately for me not with the desired results.


We'll get it sorted out, don't you worry. Sorry for the inconvenience. 
Try a 'true' panorama for a change, if you like I can send you one.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/2282f90a-9f2d-fa6a-bd2e-6d119df68636%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 21.03.21 um 12:28 schrieb Harry van der Wolf:

With regard to the panorama image stitching.
Do I really need a complete pto or ini?


Yes.

If I need to do all the steps in hugin or via the command line tools, 
and then open that in lux and stitch from lux, I currently do not see 
the benefit of lux for panorama stitching.

Only as exercise how good lux can do that.


The benefit is in the responsive, powerful live view: You can work in 
the live view until you see just what you want, and then even create a 
good-quality stitch with just pressing a key.


The key feature is *viewing* PTO files without having to stitch them 
first. The recent addition of optional 'proper' stitches of what you see 
in the live view is a nice-to-have extra.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4e061e1d-7d09-3232-2a7c-8c97860964b7%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 21.03.21 um 12:22 schrieb Harry van der Wolf:


I did have a look at stitching some time ago and this morning again, but 
it is not clear to me.

This morning using the latest lux on my linux box.

- I tried a simple, fully optimised and aligned 2 image pto: I could not 
make that work (while Hugin created a nice pano), and it does not show 
it as a pano, but as 2 badly completely overlying images.
   I then converted that pto into an ini using your pto2pv.py and loaded 
that one. I had to rotate that one as PV does not recognise the portrait 
like images. It simply shows a very high and small  image 
(Shift-hold-left-click-drag to rotate them 90 degrees 
counter-clockwise), and then pressed "p" to stich it. That gave me a 
black image the size of one image.


Fine, so it didn't work. Why don't you just zip the PTO and images and 
mail them to me? I'll have a look.


- Then I took a 4 image wide landscape based panorama from one of the 
multiblend test sets (for which I created the mac binary). The pto loads 
OK and shows OK. It does a nice live stitch indeed, although it doesn't 
blend well on the overlap, but you get a nice impression.  when pressing 
"p" it again creates a black image the size of one image.


Sound like you pressed Shift+P, which is not good for stitches.

- Using the snapshot "button" in the viewer or Shift-snapshot button 
didn't help either.


The snapshot button is for the live view and snapshots the live view.
To stitch, use the 'P' key (not Shift+P).

I also tried by simply loading a panorama images and "monkey like" press 
keys and screen buttons, but that doesn't make it work either. Then it 
only acts as an image viewer.


That's correct. To view images together, they have to be in a PTO or an 
ini file. There is currently no GUI button to trigger stitches or 
exposure fusions.


I re-read your readme a couple of times, but didn't find the right clue 
on how to do it.


I'll have to go through the docu. It's a large field, and under current 
development, so please bear with me.


Being busy on a lot of other things as well (with hugin doing a great 
job), I waited for others to report and learn from their experiences.

But indeed: nobody did. So that was "some time ago".
This morning I tried again, using the latest lux, but couldn't make it 
work either (via above steps). Maybe it is my ignorance, but the process 
is not clear


I'll try and make the docu better.


So that is my report ;)


Thanks for your feedback! Much better if you actually *tell* me than 
failing and accepting failure. This way I can try and *do* something 
about it ;)


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/bdf309a0-b028-9eca-0ed1-27887472d903%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 20.03.21 um 22:54 schrieb yuv:

On Sun, 2021-03-14 at 19:23 +0100, 'Kay F. Jahnke' via hugin and other
free panoramic software wrote:

I thought this thread was about distributing pv(lux?) with Hugin, which
many people including myself find a good idea?


This thread announces two new features in lux, namely stitching images 
and doing exposure fusion with the Burt and Adelson image splining 
algorithm. Harry has used lux' exposure fusion capabilities, but so far 
- and quite suprisingly - there are no reports of image stitching, even 
though all it takes is to press a single key on the keyboard. I had 
hoped for some sort of 'peer review' of my modified implementation of 
the B algorithm, and I posted early to give interested people the 
opportunity to take an interest in ongoing development.


The echo surprised me: it was not really about the new features, but 
about how they could be instrumentalized for hugin/enfuse/enblend. Then 
it turned to building lux on various platforms. Such wandering off-topic 
happens often - most of what you see in this thread would have fitted 
better into the original threads about pv which announced it some years 
ago, first:


https://groups.google.com/g/hugin-ptx/c/pTHYpJNML8s/m/IaSnyobEAQAJ

and then:

https://groups.google.com/g/hugin-ptx/c/bj1g86oe6Wk/m/Mvek-TuPBAAJ



I don't mean to go technical on you


I did not complain that you were going technical on me, and I actually
want to empower you to stay technical.  Your tech is inspiring.  What I
am respectfully suggesting is that you need to spend some time on
organization and infrastructure.  You may believe that co-ordination is
a waste of time.  I submit to you that it is an investment of time.
Setting up robust organization and tools that scale will support lux in
the next stage and accelerate its development, saving your time,
leveraging your tech.  Would you consider your options?


I'd like to point out here that I have already invested a great deal of 
time in organization and infrastructure:


The code *is* in git already
The code has been ported to various platforms already
It's hosted with a state-of-the-art git hosting service
It's quite well-documented
And very extensively commented

I did not simply write up a bit of software on my own computer which I 
want to flaunt now. This is serious work, and I put everything in I knew 
(well) to make it accessible to others as well. Ca. half of the software 
is actually even library-grade stuff (vspline).



Distribution with Hugin was proposed and briefly discussed.  Does not
seem a real option, despite widespread support of some contributors and
former leaders/maintainers.  Neither the current maintainer of Hugin,
nor you, seem willing to even talk a compromise, and the rest of us are
missing in action.


Don't get two things mixed up: First, there's hugin, the software 
package. This is - quite deliberately - an effort separate from hugin, 
the program, and could just suck in lux as it is; it's just a matter of 
adding it to the set of binaries in the package/bundle. Packagers have 
not yet come forward, but I hope the recent move to CMake will help.


When it comes to hugin, the program, that has - as of yet - nothing to 
do with lux, because the code base is totally different. I gave a few 
hints as to how lux might be used by hugin as a 'preview on steroids', 
which would not require much integration, and if deeper integration 
would be desired, let me add this hint:


All rendering in pv is done by a seperate thread (which in turn employs 
a thread pool for throughput). Rendering jobs are launched by filling 
out a form (a job-type object, see pv_common.h), and the frame is 
returned via a queue. It's not too hard to use that mechanism - just 
fill out the form, submit, and wait for your frame. The separation is 
deliberate, because I hope that my *rendering* technology will find a 
wider audience - the UI is just to have something to feed the rendering 
thread with a few interesting jobs, and to display the frames. It's not 
the 'hot' stuff, and could be replaced by any old GUI interfacing with 
the user and filling out rendering requests. It's like two programs in 
one. And one of them, the rendering part, can be exploited via a clearly 
specified interface, without sharing any variables or resources with the 
other part apart from the usual inter-thread communication 
infrastructure. It's deliberately *open* to being used by other software.



Lux' relationship with Hugin can be summarized as:  overlapping user
base, some overlapping contributors; a common channel of communication
(hugin-ptx) and a simple tech interface in the PTO file format.  For
more, it would take a conversation between you and the Hugin
maintainer.  Other than that, sadly, there are no synergies to be
harnessed and everything else will be duplicate, whether refactored
code; infrastructure; organization.  For you duplication means you need
to build that organization or get

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 19.03.21 um 19:11 schrieb Harry van der Wolf:


Although it is only a "git checkout mac", I also prefer one branch. The 
power of cmake is that you can combine it. This will allow users to make 
packages for the environment.


Okay, if you're both against the mac branch, I'm not too attached to it. 
I've merged it back into master, so now the 'scripts' folder from the 
mac branch is in master. I'll delete the mac branch eventually.


The latest push adds experimental code for 'quorate blending', see the 
comments in pv_rendering.cc for now.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/2424bc52-3f9d-67f5-29aa-25c838203b75%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 19.03.21 um 18:18 schrieb Kornel Benko:

Why still the need for mac-branch?



So the mac branch contains linux + mac already.
Is there -any- difference in the source (.cc, .h CMake) affecting linux?
If not, then I see no problem.


Look at the 'scripts' folder in the mac branch for mac-specific code.


The same is true for the other branches, and the windows branch, with
it's code to produce stickware bundles, is quite different from master,
and the mac branch also has specialized bundle-building code which is
needed nowhere else. All that's needed is being aware of the different
branches, and the fact that I don't automatically merge every commit
instantly.

Development, for the time being, is happening on linux: I haven't heard
from a single mac user


Harry is one ...


Harry happens to have 'an old mac he's not yet thrown away'. Maybe not 
quite enough to qualify him as a 'mac user'. The old mac is good enough 
to test bundling code, though.


@Harry: what do you think?

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/c635f7b6-0749-18b9-dcdd-03988bd71f7d%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 19.03.21 um 12:55 schrieb Kornel Benko:

Am Fri, 19 Mar 2021 12:41:32 +0100
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
:


Am 18.03.21 um 21:21 schrieb Harry van der Wolf:


On MacOS I also build with cmake (cmake .. -D
CMAKE_INSTALL_PREFIX=/opt/local).
But it still builds pv instead of lux.
   

...

@Harry: I just merged master to all other branches and pushed them to
the repo because I think the code is good. If you like you can try build
on the mac now with the updated CMakeLists.txt.

I'll still do some tweaking and tinkering and I just had an idea how I
can attempt to do automatic deghosting, which I want to investigate - if
that works out, it could already go into the next version as an
experimental new feature.

Kay



Why still the need for mac-branch?


I like having separate branches for the different platforms. I don't 
know much about the mac stuff, but to cover all mac packaging by 'ifdef 
apple' statements in the cmake code is, I think, not a good idea.


Merging to these branches is not a big deal - it is usually enough to 
issue two lines:


git checkout mac (optional if you're already on the mac branch)
git merge master

The same is true for the other branches, and the windows branch, with 
it's code to produce stickware bundles, is quite different from master, 
and the mac branch also has specialized bundle-building code which is 
needed nowhere else. All that's needed is being aware of the different 
branches, and the fact that I don't automatically merge every commit 
instantly.


Development, for the time being, is happening on linux: I haven't heard 
from a single mac user or windows user who would be interested, nor of 
any who have downloaded and tried the bundles we've produced. I think 
it's perfectly good enough to merge master and make bundles when there's 
a new release out, just in case there's a user somewhere.


So that's my opinion just now - doesn't mean it has to stay like that 
forever. But I prefer a clear focus on getting the code to run well on 
linux, and let it trickle down to other platforms as needed, without 
putting much work into it. With my windows branch, this has worked fine 
for quite some time now (ca. 40 releases).


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/841055d2-6d1c-c5af-a8bd-e8c1ef8296bb%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 18.03.21 um 21:21 schrieb Harry van der Wolf:


On MacOS I also build with cmake (cmake .. -D 
CMAKE_INSTALL_PREFIX=/opt/local).

But it still builds pv instead of lux.


...

@Harry: I just merged master to all other branches and pushed them to 
the repo because I think the code is good. If you like you can try build 
on the mac now with the updated CMakeLists.txt.


I'll still do some tweaking and tinkering and I just had an idea how I 
can attempt to do automatic deghosting, which I want to investigate - if 
that works out, it could already go into the next version as an 
experimental new feature.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/cebf83a4-cd5e-f110-6408-eb84838611a4%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 19.03.21 um 09:26 schrieb Harry van der Wolf:



Op vr 19 mrt. 2021 om 08:41 schreef 'Kay F. Jahnke' via hugin and other 
free panoramic software <mailto:hugin-ptx@googlegroups.com>>:


Am 18.03.21 um 21:21 schrieb Harry van der Wolf:
 > I can't find the question backs, but you asked me about the speed
after
 > your improvements.
 >
 > The current version is about 10-15% faster.

Ha, that's nice to hear, Did you look at memory consumption, too?
That's
where I had hoped to see about 30% improvement , because I switched to
single-float masks.

Yes, that too. The memory usage went from 3.2GB to 2.7GB for the image 
sets I used (sets of 5 brackets of 13.5MB).


Less than I hoped, but every little helps ;)


With regard to the "??--snapshot_threads=X".
That still doesn't work for me. I tested on linux on the master repo. I 
have a 4-core CPU. no matter whether I set X to 4, 3 or 2. Always all 4 
cores are used and it actually creates many more processes.


The command I use from my batch file is:
${LUX} -W \
 ?? ?? ?? ?? ?? ?? ??--blending=hdr \
 ?? ?? ?? ?? ?? ?? ??--snapshot_like_source=yes \
 ?? ?? ?? ?? ?? ?? ??--snapshot_facet=1 \
 ?? ?? ?? ?? ?? ?? ??--snapshot_prefix="${PREFIX}" \
 ?? ?? ?? ?? ?? ?? ??--snapshot_extension=$SUFFIX \
 ?? ?? ?? ?? ?? ?? ??--aeb_auto_brightness=yes \
 ?? ?? ?? ?? ?? ?? ??--next_after_fusion=yes \
 ?? ?? ?? ?? ?? ?? ??--build_pyramids=no \
 ?? ?? ?? ?? ?? ?? ??--build_raw_pyramids=no \
 ?? ?? ?? ?? ?? ?? ??--quality_interpolator_degree=1 \
 ?? ?? ?? ?? ?? ?? ??--snapshot_threads=3 \
 ?? ?? ?? ?? ?? ?? ??"${PTO}"

In this case you see " --snapshot_threads=3", but of course I did vary 
that number.


Good thing you're so meticulous. I managed to reproduce the behaviour 
you criticized, and it made me find a silly bug where, while lux waits 
for a snapshot, it simply burns cycles in an unchecked loop, wehre it 
should instead have slept brief naps and checked only every few 
milliseconds whether the snapshots were finally ready. No surprise your 
CPU was busy.


I pushed the bug fix to master.

lux will still create many threads - on a four-core there should be 18 
or so - but they should *not* be active together while the exposure 
fusion happens.


Please try again, and if it still doesn't work let me know.

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/d72267ea-7340-4c6c-d3db-8e1e594fd093%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 18.03.21 um 21:21 schrieb Harry van der Wolf:
I can't find the question backs, but you asked me about the speed after 
your improvements.


The current version is about 10-15% faster.


Ha, that's nice to hear, Did you look at memory consumption, too? That's 
where I had hoped to see about 30% improvement , because I switched to 
single-float masks.


I built with cmake on linux and get a binary lux. sudo make install 
installs the font and font readme in /usr/local/share/lux/fonts where 
lux can find it.


On MacOS I also build with cmake (cmake .. -D 
CMAKE_INSTALL_PREFIX=/opt/local).

But it still builds pv instead of lux.


Note that the master branch may be a few commits ahead of the other 
ones, I don't always merge master into them straight away - rather I 
leave them at a state which is reasonably stable. Once I have a good 
feeling with master and/or want to carve out a new release, I merge. If 
you don't want to wait for me to merge master, you can do so yourself, 
just say 'git merge master' while you have the mac branch checked out. 
You may have to deal with merge conflicts yourself, then - but mostly it 
should merge fine.


When I release a new version, I merge master to all branches before I do 
so, so then you can expect to find the latest modifications to be 
available everywhere.



sudo make install does install pv in /opt/local/bin
It installs the font in /opt/local/share/pv/fonts, but it does not 
install the font readme on mac.

pv can find the font on mac.
I will have to look what I need to specify as install prefix to make pv 
find the font in the bundle, or that the bundle requires an extra 
setting for bundle builds.


All of this is probably because the mac branch hasn't merged master yet.

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/8f4621d5-25f5-129f-12ec-f341b9152910%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 14.03.21 um 17:12 schrieb 'Kay F. Jahnke' via hugin and other free 
panoramic software:


Sometimes you have things in your images you don't want to see in the 
final output.

> ...


But pv does not process hugin's mask information (yet), so if 
you want parts masked out for processing with pv, you have to 'manually' 
make the unwanted bits transparent. You can do that e.g. with gimp: add 
an alpha channel to your image if it doesn't have one yet, then pick the 
'eraser' tool and select a *soft* brush to 'erase' the unwanted bits 
with a bit of 'feathering'.


@Harry and whoever else may be interested: I'd like to give a slightly 
modified procedure, because - when stitching - I noticed that doing it 
the 'obvious' way with the gimp will produce artifacts: slightly 
darkened halos around the erased areas. These halos occur because by 
default the gimp also messes with the RGB values and darkens them where 
the eraser takes effect. In my opinion this is wrong, but that's what 
happens. I found a workaround:


- once you have added the alpha channel, open the 'layers/channels' window

- select the 'channels' tab

- click on the fourth one, the alpha channel

- now use the eraser: this will really only affect the alpha channel.
  You want a slightly soft brush, like .95, to have slight feathering.

- once the unwanted bits are gone, export the image to a format that can 
handle transparency, like TIFF, PNG or exr.


- make sure when exporting to check 'save colour values from transparent 
 pixels'


Doing it this way, the RGB values are not touched, even if the alpha 
channel is removed totally in some places. With images edited like this, 
the stitch should come out with good blending, if the images fit well.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/62a433ac-ae2a-331d-e56a-ec876c2f52e9%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 18.03.21 um 18:15 schrieb Kornel Benko:

Am Thu, 18 Mar 2021 16:50:19 +0100
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
:


@Kornel: If I update pv_combine.cc in the root directory, then issue
'make' in the build directory, the update goes unnoticed. I can touch
the generated per-isa variants (pv_combine_avx.cc etc.) which triggers a
recompile, but I think this should happen automatically. Can you maybe
fix that? It should just be a matter of telling cmake about the
unexpected dependencies.

Kay



My fail.
use
foreach(_f pv_fallback pv_avx pv_avx2  pv_avx512f)
 add_custom_command(
 COMMAND $(CMAKE_COMMAND) -E copy_if_different
 ARGS ${CMAKE_CURRENT_SOURCE_DIR}/pv_rendering.cc
${CMAKE_BINARY_DIR}/${_f}.cc OUTPUT ${CMAKE_BINARY_DIR}/${_f}.cc
 DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/pv_rendering.cc
 )
endforeach()
...

(See 'DEPENDS', hope this is better)


commit 0949aa0fac38b069466381dc8be70a872e35e2b5 (HEAD -> master, 
origin/master, origin/HEAD)

Author: Kay F. Jahnke
Date:   Thu Mar 18 21:13:16 2021 +0100

fixes flaw in CMakeLists.txt which made edits to rendering code go 
unnoticed. cmake did not see the dependency between the sources 
pv_combine.cc and pv_rendering.cc and the isa-specific versions it 
created with a custom command. This commit fixes it.


Thanks, Kornel, now it works as expected!

Kay



--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/65e8b113-1260-e7c6-6927-1c575b0d18e6%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

@Kornel: If I update pv_combine.cc in the root directory, then issue 
'make' in the build directory, the update goes unnoticed. I can touch 
the generated per-isa variants (pv_combine_avx.cc etc.) which triggers a 
recompile, but I think this should happen automatically. Can you maybe 
fix that? It should just be a matter of telling cmake about the 
unexpected dependencies.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/b798c60f-afad-e9a1-5e99-9d57c5937729%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

Am 18.03.21 um 11:56 schrieb Kornel Benko:

Am Thu, 18 Mar 2021 11:46:22 +0100
schrieb "'Kay F. Jahnke' via hugin and other free panoramic software"
:


Am 18.03.21 um 11:34 schrieb Kornel Benko:

Am Thu, 18 Mar 2021 11:01:31 +0100
schrieb Kornel Benko :
   

Please explain. What do you mean by 'use'? Is PV_FONTDATADIR an
environment variable? Or something CMake will patch in the source?

Kay
  


Compilation is called as
clang++ ... -DPV_FONTDATADIR="/usr/local/share/lux/fonts" ...
so that in the source you can use
#if defined(PV_FONTDATADIR)
... do something
#endif


Got it. applied. We had crossed mails, please check if my edit suits you.


Kornel


An alternative is the following
Create a template pv_config.h.cmake (attached)
add to CMakeLists.txt the commands to create pv_config.h (in the build dir)
patch attached

use
#include "pv_config.h"


I opted against this for now and I'm going with the PV_FONTDATADIR read
directly.

Kay



OK. Mark that using defines in a config file may be preferred because the
compile-command-line is shorter.


Yes, if we get more of the sorts we can change to that mode.


BTW, it works.


Hooray! Thanks for checking. Off to lunch...

Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/607ad876-b653-5271-122e-c5c8200650f2%40yahoo.com.

Re: [hugin-ptx] Image Stitching and Exposure Fusion with pv

['Kay F. Jahnke' via hugin and other free panoramic software]

So to reiterate what I have coded concerning the GUI font gleaning 
process: lux now does the 'full circuit':


- if user passes a font on the CL, try use that

- failing that, if the font is found in pwd, use that

- failing that, if LUX_GUI_FONT is set in environment, use that

- failing that, load hard-coded font set by CMake during build

This gives users the option to supply their own favourite font, holds on 
to the previous behaviour, allows passing the font via an environment 
variable and finally picks the hard-coded value if all else fails.


Kay

--
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/f554-fcd7-70a5-f3af-895b1f6bd28d%40yahoo.com.