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

['kfj' via hugin and other free panoramic software]

On Monday, June 10, 2024 at 10:09:23 AM UTC+2 kfj wrote:

I think maybe there's an issue. I get this message: 

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

 
My mistake - I tried to generate the video with 60 fps, and the default for 
the (single-image) input seems to be 25 fps. 
The ffmpeg invocation you gave is fine and produces no errors. The video 
stuttering a bit may be due to my old hardware, or due to running a 25 fps 
video on a 60 Hz screen.

-- 
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/059a5c45-b329-4337-8546-2a372501f177n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

On Saturday, June 8, 2024 at 8:56:53 AM UTC+2 kfj wrote:


I just uploaded a debian package 
<https://bitbucket.org/kfj/pv/downloads/envutil-0.1.1-Linux.deb> of version 
0.1.1 of 'envutil'.

 
... how embarrassing - there was a bug in the package, which I've fixed 
('early adopters', please download again if you want correct video output 
with --itp -2) .

So, just to what your appetite: let's suppose you have a full spherical 
'pano.jpg', try this:

for (( x=0 ; x<360 ; x=x+1 )) ; do echo 90 $x 0 0 ; done > xx.seq

This creates a 'sequence file' - in this case, the only thing that varies 
from line to line is the second number, the 'yaw' parameter - and it will 
take values from zero to360, so one full pan around. Then this:

envutil -v --input pano.jpg --seqfile xx.seq --output pan360.mp4 
--width 1920 --height 1080 --itp -2

This will create the video output 'pan360.mp4' - a fullHD H265-encoded 360 
degree pan of your panorama with rectilinear output set to 90 degrees hfov. 
The video won't play everywhere - my Linux box plays it, but VLC doesn't. 
I'm new to video output, maybe there's someone out there in the community 
who has programmed with ffmpeg and wants to help? Anyway, you can instead 
produce 360 separate images like this:

envutil -v --input Cauri*.jpg --seqfile xx.seq --output pan%03d.jpg 
--width 1920 --height 1080 --itp -2

(note the changed output parameter) - and then combine the images with 
ffmpeg on the command line, like this:

ffmpeg -f image2 -pattern_type glob -framerate 60 -i 'pan*.jpg' -s 
1920X1080 -c:v libx265 pan2.mp4

That video plays with VLC. Programming with ffmpeg is quite tricky - it's 
old C code and I grabbed an example file which was 20 years old and 'bent' 
it to C++ - going via the single images is the safer option, but of course 
it takes lots of disk space (you want an SSD for that). But I think this is 
a cool idea - it could be used to create very high quality artificial 
tracking shots (if that's the correct term) or zoom sequences from a 360 
degree panorama with little programming effort. Of course one would want a 
companion program to generate the sequence files...


-- 
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/f69299bc-4822-4e2b-87e2-4ac67770f48en%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Still with me?
I just uploaded a debian package 
<https://bitbucket.org/kfj/pv/downloads/envutil-0.1.1-Linux.deb> of version 
0.1.1 of 'envutil'. This is now the sole program for conversion between 
environments (like full spherical panoramas) and extraction of partial 
images (nadir caps and such) - the separate 'extract' program ended up 
being able to do the conversions as well, so I decided to lump it all 
together into a single utility. I have taken the extraction of partial 
images one step further: envutil now accepts 'sequence files' - simple text 
files with four numbers per line, coding for hfov, yaw, pitch and roll of a 
single image. If you feed such a sequence (--seqfile my.seq), envutil will 
output a video (specify output like --output xx.mp4) - or a set of separate 
images (specify output like --output img%03d.jpg) . This is good fun, but 
you'll want to create the sequence file with a script or so (try a simple 
loop in a shell script for starters). Detailed documentation is on the 
github page.

-- 
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/2145a8ba-d807-49e6-929e-f773818fc372n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

To make it easier for you to evaluate the two new programs, I've uploaded a 
debian 
package <https://bitbucket.org/kfj/pv/downloads/envutil-0.1.0-Linux.deb> to 
the lux Downloads page. I built and test-installed this package on debian12 
- your mileage on other debian-based distros will vary. Building from 
source is also quite simple, the build is done with cmake. Both envutil and 
extract are MIT-licensed, even if the package mangement doesn't comprehend 
that (mine tells me it's 'proprietary').

I've elaborated 'extract' with options to use different interpolation 
methods. On top of the default bilinear interpolation, there are now two 
more methods, each with variations. The base method is picked with the 
--itp parameter:

1 - use simple bilinear interpolation directly on the source image
this is the fastest option, and unless there is a significant scale
change involved, the output should be 'good enough' for most 
purposes.

-1 - use OpenImageIO's 'environment' or 'texture' function for lookup.
 without additional arguments, this will use a sophisticated 
interpolator
 with good antialiasing.

-2 - use 'twining' - this is a method which first super-samples and then
 combines several pixels to one output pixel ('binning'). This is my
 own invention. It's quite fast and produces good quality output.
 This method should see community review to compare it with other 
methods.

The second and third methods can be tweaked further - I made an effort to 
allow practically the entire range of options OIIO can take, and my own 
'twining' filter can also be configured further - for details, please look 
at my github page <https://github.com/kfjahnke/envutil>. If you just want 
to try it out quickly, try passing --itp -2 and --twine 3 for ninefold 
oversampling and a 3X3 box filter for pixel binning.

While using OIIO for lookup tends to be quite slow (especially with the 
default settings), twining is quite fast unless you pick an overly large 
box filter. I found that the output of twining is nice and crisp and the 
antialiasing is good - I think this lookup method has potential and I'd 
welcome feedback, especially comparisons with other methods.


-- 
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/71261f7f-1cbe-4533-910e-d986af92ce9cn%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Added 'extract.cc' which extracts an image from a lat/lon or cubemap 
environemnt. You can pass yaw, pitch and roll of the virtual camera, 
allowed target projections are "spherical", "cylindrical", "rectilinear", 
"stereographic", "fisheye" or "cubemap", and you can specify width, height, 
and hfov of the output. Currently, only bilinear interpolation is used and 
output is RGB only (no alpha). Also builds with cmake.

To be continued! this should make a nice utility for panorama photography.

On Sunday, May 12, 2024 at 10:34:23 AM UTC+2 kfj wrote:

..- so far, there is no parameterization with CL arguments

-- 
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/8e71900b-d9f4-4179-9697-b60bf4e9c705n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

For the past couple of weeks, I've been diving into some new code. It all 
started out when I started using OpenImageIO as image i/o library for lux. 
OpenImageIO provides some functionality which is relevant in a panorama 
programming context, namely it's 'environment' function, which samples a 
full spherical with proper antialiasing and interpolation. I found this 
function 'tasty' and started playing with it. This led me to try feeding 
'cubemaps' to it, which is another format used to cover an entire 360X180 
degree environment. Alas, no luck here, not supported. lux has it's own 
flavour of cubemap processing, but I'm not entirely happy with it's 
performance, so next I decided to investigate cubemaps to maybe come up 
with better code. To have some standard to adhere to, rather than my 
'ad-hoc' approach in lux, I turned to openEXR's 'flavour' of cubemap. I 
started out by using their utility to convert between cubemaps and full 
sphericals ('exrenvmap') but I wasn't happy with it - it didn't work as I 
expected. Correspondence with the openEXR people turned out that cubemaps 
are not used much and their code is twenty years old and probably not 
entirely correct - and slow. Time to start coding myself, and to use my 
library zimt to code it all in multithreaded SIMD code for speed!
I first coded a utility to convert between full spherical (a.k.a lat/lon) 
format and cubemap format. This led to more code dealing with cubemaps - 
the utility is now quite capable and offers a few - hopefully - interesting 
features. Then, to work towards transferring my new insights and code to 
lux, I wrote code to reproject environment images (both full sphericals and 
cubemaps) to common projections: rectilinear, spherical, cylindrical, 
fisheye, stereographic and cubemap. This latter code is what is probably 
most relevant in a panorama programming context, so I'd like to point you 
to it. It may also be of interest to the libpano project. The code is here 
. There's a demo program 'stepper.cc' 
which shows how the code base can be employed to code reprojections very 
tersely - giving a virtual camera orientation with Euler angles is 
built-in. I may elaborate the demo program - so far, there is no 
parameterization with CL arguments, it's just a simple pass-an-environment 
and get preprojected images demo, but I thought that now is a good time to 
point you to this new project. The code is extensively commented, and it's 
all MIT-licensed.

-- 
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/75677626-f6ac-4506-9b65-bac8d9764d47n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

 There are some options which may help you (copied from 
https://kfj.bitbucket.io/lux_options.html):

snapshot_prefix 

This option sets the prefix used for snapshots, stitches and fusions. 
The default is to use the source image's filename suffixed with .lux. If 
you pass --snapshot_prefix=xyz the images will be named xyz1.jpg, xyz2.jpg 
etc.

Note that the prefix will persist throughout the entire lux session, so 
you can go through a set of images and take snapshots where you like, and 
all snapshots from the session will share the prefix and be numbered 
sequentially.
snapshot_basename 

This option forces the snapshot (or stitch or fusion) base name, and 
the resulting image will be named by combining this base name with the 
snapshot extension, with no intervening infixes. ...

I'll have to edit the text for the second one, though - the statement that 
extant files are overwritten without warning is no longer true. If you want 
to use the latter option, you can't do it in a batch job - then you need a 
separate lux invocation for each rendition. But then, you have total 
control: delete the output file if it's there, call lux with 
--snapshot_basename and --snapshot_extension to your liking. That is 
probably what you want.

This is a bit awkward for batch processing - it might be cleaner to use 
some sort of format string. I'll make a mental note and think about 
reworking the snapshot naming.

-- 
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/ab401d9c-df8b-4e2c-b8ec-d5fca0ef3b02n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

On Friday, April 26, 2024 at 10:16:56 AM UTC+2 GnomeNomad wrote:

Thanks, but I think the on-screen view should show the output crop, the way 
Hugin does without having to load the stitched image manually.

Well, at times you just don't get what you want ;-)
If you look at what hugin shows you when you choose the cropping rectangle, 
you also see the parts of the image set which, later on, are cut off when 
the cropping happens. The only thing which lux does differently is that it 
does not mark these areas by making them a bit darker, and lux does not 
show the cropping rectangle as a white rectangle. lux also does not offer 
any interface to modify the cropping window. I feel that it's better for a 
program which is primarily an image *viewer* to show users all the 
available content and let them choose which part of the content they wish 
to look at and, potentially, save as a snapshot (pressing 'E'). Honouring 
the cropping rectangle in the p-line is to allow for stitching to the PTO 
file's specs (press Shift+E), so that lux can function as a drop-in 
replacement for stitching - nice to have, but more of a side product: I 
show the stitched view, so I might as well offer stitching services beyond 
capturing what's in the current display. That's how 'source-like snapshots' 
and the processing of the p-line came to be.
One might consider adding code to lux to show all kinds of additional 
information - the cropping rectangle in the PTO's p-line is one such thing, 
then masks, horizon guideline etc.. I have thought about adding an optional 
vector layer for such data, but I haven't implemented anything along those 
lines yet, even though I find the idea attractive. Please keep in mind that 
I'm not trying to provide some sort of hugin clone. lux is a separate 
program and uses it's own logic, even though it can do things like 
understand PTO format to an extent, which I think is no mean feat. I think 
there aren't many image viewers out there which can do that at all.

 

-- 
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/75919911-1152-46fa-a429-c7f0cdbf6218n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Maybe you misunderstand something here: output cropping is not applied to 
the view which lux shows on-screen. lux shows all content which the source 
images provide, except for the parts which are excluded by source image 
cropping. Output cropping is only applied when the output is written to an 
image file and the p-line in the PTO file is applied (press Shift+E). The 
p-line has no effect on the on-screen view at all. If you want to view 
readily-cropped output, re-load the stitched image.

-- 
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/52c5adaa-5253-4ecd-9542-10c99587ddc5n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

It shouldn't. But your report is not really enough to figure out what the 
problem might be. Are you talking about source image cropping or output 
cropping? So: please send the PTO!

On Thursday, April 25, 2024 at 12:29:30 AM UTC+2 GnomeNomad wrote:

> In my testing here, it completely ignores crop settings in the PTO file. 
> It seems to me that would severely restrict usefulness, particularly in 
> situations where you have a large panorama with a small crop area.
>
> Ideas?
>
> -- 
> David W. Jones
> gnome...@gmail.com
> wandering the landscape of god
> http://dancingtreefrog.com
> My password is the last 8 digits of π.
>
>

-- 
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/5b499214-8e4b-433a-a03a-5584d9fdedf5n%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.2 released

['kfj' via hugin and other free panoramic software]

'Messing' with a lux batch job is probably not such a good idea ;-)

Overwriting existing image files is only allowed with an okay from the 
user, and to give that, you have to have lux open, and see the little 
dialog. I admit this isn't a very good solution for batch jobs. batch jobs 
are kind of experimental - I use them when I have e.g. a set of brackets to 
fuse and I know that the batch can simply run it's course, but to make them 
suitable for the 'broader public' could do with a bit of tweaking. If you 
want to stop lux when it's running a batch job, better kill it from the 
task manager.

On Thursday, April 25, 2024 at 11:00:06 AM UTC+2 mpgve...@gmail.com wrote:

one other thing i found by accident. 
if you start a series, like with 
lux --stitch=yes *.pto 

and you interrupt (esc) and it restarts itself.

... 

-- 
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/1c78988f-1a50-4625-95b6-584fbdc12ce8n%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.2 released

['kfj' via hugin and other free panoramic software]

On Thursday, April 25, 2024 at 12:26:59 AM UTC+2 GnomeNomad wrote:

On 4/23/24 22:06, 'kfj' via hugin and other free panoramic software wrote:

The UI is made so that you can interact with the view with gestures and 
usually don't have to use the menu, unless you need to change settings or 
do 'something special'. Once you get the hang of it, 

Then it's not nearly intuitive. But it is different.

 
Yes. I take the liberty to do something new. But then it's no *that* new - 
the view control is inspired by QTVR mode in 360cities, which I prefer over 
their default mode. I just took it a step further, adding mouse gestures 
for brightness control and zoom and tinkering with the zoom mode. You see, 
lux is a bit like a computer game. In games, you also have to learn the 
controls to reach the next level, otherwise it's 'game over' before you 
even get to see anything interesting.

Zoom in and out using my mouse wheel works exactly as expected 

 
Did you notice that the mouse wheel scroll is a 'focused zoom' which keeps 
the mouse position in the same place when you zoom? Nice to quickly zoom 
onto something off-center. Though I often just secondary-click on the 
feature I'm interested in (centers the view there) then press '2' a couple 
of times to zoom quickly (and '3' to zoom out). On the other hand, zooming 
with a vertical secondary-button click-drag is a centered zoom, but once 
you're used to the gesture, it gives you very precise control over the 
speed of the zoom (the further you drag the faster). If you don't like the 
focus mode, try the --scvd_focused_zoom and --scw_focused_zoom options to 
change their behaviour. And then you can also zoom with the plus and minus 
keys on the keypad or with Z/Shift+Z. Did you try the magnifying glass? 
(press 'I' (the letter igh)). I also often use the '1' key to get a 100% 
view. And if you get 'lost' just press Return ;-)

-- 
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/ddb5ed90-4939-4519-9c46-f96df2700a83n%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.2 released

['kfj' via hugin and other free panoramic software]

On Wednesday, April 24, 2024 at 10:58:57 AM UTC+2 hvd...@gmail.com wrote:

The AppImage does not run on my Chromebook with beta linux, which is the 
reported debian bookworm by the way. It starts flashing and completely 
blocks everything. But that could be because it is linux running in a 
sandbox on ChromeOS.

 
Sorry I can't really help with that - I was hoping that the AppImage would 
run just about everywhere, but there seem to be limits... Sometimes lux 
starts flashing on start-up if the screen extent is unexpected, and my code 
just re-tries until it gets what it wants, which may not be the right 
approach in every case. I do that to circumvent buggy behaviour in gnome 
which occured after the switch to wayland - I reported the problem, but 
there was no echo, so I had to program around the bug...

Can you please try and start lux in a window to see if that maybe avoids 
the flashing? just try

lux -W

This is also easier to shut down if the controls don't work anymore.

My other laptop is an aarch64 laptop and the deb and App image do not run 
on it either as they are intel x86_64.


That's correct. On macOS, you can run the i86 build via rosetta, but on 
other OSs, there are no handy emulation layers which instantly kick in 
automatically. But it would be interesting to see ARM builds for other 
platforms! You know that the build is quite straightforward for Linux, so 
if your ARM boxes run linux, it might be as easy as clone the pv repo, cd 
pv, mkdir build, cd build, cmake .., make. I recommend installing highway 
as a build-time dependency. On ARM it should make a big difference. Usage 
of ARM-specific build toolchain should happen automatically - the cmake 
build detects the host CPU. Packaging as debian package is now quite 
straightforward; all you have to do is to tell cmake to pick the 
appropriate package generator. The variables for the generator are already 
in the CMakeLists.txt. you specify the generator like this:

cmake -DCPACK_GENERATOR=DEB

after that, just say

make package

and cmake should produce the debian package. That's how I made the debian 
package I just uploaded. Apart from not being signed, it seems to fit in 
well, and it's much smaller than the AppImages! It also saves me the 
headache of having to include third party copyright info for all the shared 
libraries which the AppImage generator I use does not find automatically... 
but, hey, I want to see users from other distros use lux as well, hence the 
AppImage approach.

If you can produce a viable debian package for Linux on ARM, I can upload 
it to my downloads page. I think we did that some time ago when you were 
building lux on your RasPis.

-- 
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/c76d6f07-5fbc-4302-901d-4c56442c40fcn%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.2 released

['kfj' via hugin and other free panoramic software]

Sorry, debian users, for uploading a package with unresolved dependencies. 
Here's the updated package which asks for libexiv2 v.27, which is the one 
currently distributed with bookworm:

https://bitbucket.org/kfj/pv/downloads/lux-1.2.2-x86_64.deb

Please download and install again - if there are any further issues, please 
let me know!

-- 
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/6e12fb3e-f957-4ab6-98a2-5e97a67d499fn%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.2 released

['kfj' via hugin and other free panoramic software]

On Tuesday, April 23, 2024 at 9:27:49 AM UTC+2 GnomeNomad wrote:

So I clicked right button expecting a menu to pop up. Don't know if it's my 
bad, but it still seems a thought. I noticed that right click does other 
things in Lux, so maybe ctrl-right-click to bring up the menu, starting 
wherever the mouse pointer is?

You can always simply look at the lux documentation, where all mouse 
gestures and key commands are explained in great detail - the section in 
the README is titled 'User Interface'. Find the documentation here 
<https://kfj.bitbucket.io/README.html>.

The UI is made so that you can interact with the view with gestures and 
usually don't have to use the menu, unless you need to change settings or 
do 'something special'. Once you get the hang of it, it allows you to view 
(and present) your images fluidly, doing most of the view control with the 
mouse, and the occasional keystroke. Admittedly, performance with touchpads 
is not optimal, so if you use lux on a laptop, it's a good idea to connect 
a physical mouse. I recommend you read the docu - some of the mouse 
gestures are quite specific and hard to figure out by trial-and-error, e.g. 
the brightness and zoom level gestures.

 
I uploaded a debian package 
<https://bitbucket.org/kfj/pv/downloads/lux-1.2.2-x86_64.deb> for debian 12 
stable. It might be usable for other debian-based distros.

Thanks, downloaded, tried it. It installed over the 1.1.6 that was there 
before. Trying to run lux in a terminal gave me this:

lux: error while loading shared libraries: libexiv2.so.28: cannot open 
shared object file: No such file or directory

Bookworm comes with libexiv2-27. I have that installed. I guess the 
libexiv2 version your package is looking for is -28?

Ah, thanks for pointing that out! I used a local build of libexiv2 v. 28, 
and the dependency slipped into the package. Using libexiv2 v.27 is okay, 
but there are some (annoying) API changes with v.28 and switching back to 
v.27 requires some finessing in the build. I'll see to it that the 
dependency is set to v.27 and rebuild and upload the package. Thanks for 
testing! 

-- 
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/5fe9337c-fdf7-4c43-b659-c4597e76389en%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.2 released

['kfj' via hugin and other free panoramic software]

It still has difficulty displaying the old PTO, but I created a new one 

using current Hugin, using the original images, and Lux has the same 
problem with it. I checked in Hugin, the images from my friend's 
camera-that-he's-so-proud-of come in with a 5.75deg field of view. I 
think I'll stick with my Sony. 

 
5.75 degrees fov sounds like a very long tele indeed.


Looks like the Lux GUI consists solely of a file selector?


What makes you think that? Maybe you haven't tried to access the menu? Just 
move the mouse to the top margin of the window (or full screen). The menu 
is usually hidden to show you nothing but your image - both the old and new 
GUI only show when you move to near the top of the screen. 
 
I uploaded a debian package 
<https://bitbucket.org/kfj/pv/downloads/lux-1.2.2-x86_64.deb> for debian 12 
stable. It might be usable for other debian-based distros.

-- 
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/b1969a27-1a99-41ae-a51f-e92feba413fcn%40googlegroups.com.

[hugin-ptx] lux 1.2.2 released

['kfj' via hugin and other free panoramic software]

Sorry everybody who downloaded 1.2.0. There was a bug in it which prevented 
it from displaying PTO files with images with alpha channel correctly - 
just viewing images is fine. So I decided to do a bug fix release. Please 
download 1.2.2 from https://bitbucket.org/kfj/pv/downloads/
@GnomeNomad, this also fixes the error message when lux terminates.

-- 
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/f2615043-84eb-4b6b-bc57-2137aa3433c7n%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.0 released

['kfj' via hugin and other free panoramic software]

On Monday, April 22, 2024 at 10:29:55 AM UTC+2 mpgve...@gmail.com wrote:

thanks kfj, a better GUI is always great. 

You're welcome! 

what david wrote about pto not working is only with specific image 
formats? I'm guessing with JPG the template.pto file still works? 

We've figured it out, the images were outside the viewing area. 

the CMD file is simple, it checks if the images exists and with 
nona/enblend it stitches them together with use of the pto file, ups the 
file number with one and tries again.

batch stitching with lux is quite simple. All lux needs to stitch a PTO is 
a command line like this:
lux --stitch=yes my.pto 
and to stitch several, just pass them all on the command line:
lux --stitch=yes *.pto
The resulting files are named automatically and no metadata are 
transferred, if you want that, you'll have to employ exiftool.

The real great part of the cmd files is that i can run up to 3 
simultaneous cmd scripts within my processors 8 core capacity, making it 
almost 3 times as speedy that one gui running one folder set.

With lux, you don't have to do this, because lux multithreads internally, 
so when it does a stitch, it uses all available CPU cores anyway. You can't 
gain speed from running several instances. 

so for me, after setting up i only need to double click once per cmd 
instance and leave my pc alone. 

Should be the same with lux batch stitching, but you should rather set up a 
script which does the batch stitch in one folder, then moves to the next 
and does it there, etc - running them in parallel won't speed it up and use 
much more memory. Try it out and tell me how it worked for you. Of course 
the results lux produces are not identical to what nona+enblend produce and 
you may not be happy with the result. And lux needs lots of memory - if the 
panoramas are large, it may not be a good idea to stitch them with lux.


-- 
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/a1fb7b69-4cf8-4009-bb05-38f9829d24een%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.0 released

['kfj' via hugin and other free panoramic software]

On Monday, April 22, 2024 at 10:21:07 AM UTC+2 GnomeNomad wrote:

Ah, thanks. I tried dragging around in the blank window but couldn't 
remember how to zoom in/out. Centering the viewing area sounds like a good 
idea.

It  might be a bug in whatever version of Hugin I was using in 2013. I have 
another PTO that I had made with the same version, and got panoramas with 
mismatched items (like velvet ropes that crossed multiple images), produced 
using the Auto Alignment feature. Later versions of Hugin with the same 
function had no such disjoints.

Cool. Lux is fast. I'd still prefer a Debian Linux native version to the 
AppImage, and movement within the image that isn't counterintuitive for me, 
but it's getting better.

 
I'll make a debian package on my debian11 install when I get round to it - 
I'm developing on debian testing, and I'll first hunt down the bug I found 
with panoramas with images with an alpha channel.

If the only thing which confuses you is the direction in which the view 
moves when you drag the mouse, you can change that in the 'General 
Settings': quite near the top there are checkboxes to reverse the 
primary-button-click-drag direction and the secondary-button-click-drag 
direction - then commit at the bottom of the panel. If you prefer it that 
way and want to change the direction permanently, put lines like 
"reverse_drag=yes" or "reverse_secondary_drag=yes" in your .lux.ini file 
(in your home folder).

-- 
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/9bad71a5-eaa0-42f0-b4f0-7541e2008e47n%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.0 released

['kfj' via hugin and other free panoramic software]

Thanks for posting the PTO. I also got a black screen from it. The problem 
is that the visible content is outside of the viewing area. If you zoom out 
a good bit or start lux with --hfov_view=90, you'll see the images (which 
have quite small hfov of 14 degrees) near the top of the view. The pitch 
values in your PTO are larger than the hfov (17.4024521555217), and so the 
visible content is placed in an area which is not inside the viewing area.
I can see how this is confusing - maybe I should add code to center the 
view to a point somewhere inside the collection of images to avoid showing 
a blank screen.
Thanks for reporting back!

On Monday, April 22, 2024 at 8:33:39 AM UTC+2 GnomeNomad wrote:

> On 4/21/24 19:29, 'kfj' via hugin and other free panoramic software wrote:
>
>
>
> On Sunday, April 21, 2024 at 9:26:56 PM UTC+2 GnomeNomad wrote:
>
> Thanks, always good to have an improved GUI.
>
> I ran the appimage from the command line, it gave me a window to open 
> files. I went to open a PTO file, and got a blank black screen. Nothing 
> happened. Nothing displayed. When I pressed Escape, the window blank 
> display went away and I saw this in the command line window:
>
> OpenImageIO exited with a pending error message that was never
> retrieved via OIIO::geterror(). This was the error message:
> OpenImageIO could not find a format reader for 
> "/home/david/data/MyPhotos/Rabbit Island Vertical 
> Pano/RabbitIslandVerticalPano-2013092220130922.pto". Is it a file format 
> that OpenImageIO doesn't know about?
>
> So the new Lux can't open PTO files anymore?
>
> It should. The error message you get is nothing to worry about - I pass 
> every file to OIIO first to see if it can open it, and when it fails it 
> saves this error message which is never retrieved and displayed at program 
> exit. Maybe I should clean up better before terminating lux - this is 
> misleading behaviour. Thanks for pointing it out!
>
> Thanks.
>
> Considering the failure to open your PTO, I wonder: do the images have an 
> alpha channel? 
>
> No, the source images are JPGs and don't support transparency/alpha 
> channel.
>
> I checked the PTO display, and I saw there is an issue with panoramas with 
> images with alpha channel. Most embarrassing - looks like I have a bug to 
> fix. Did you try other PTOs? 
>
> I checked a version of the PTO that uses the same images. That rendered 
> fine. It was created in 2021 using Hugin.
>
> The problematic PTO file was created in 2013 using Hugin. Hugin doesn't 
> complain about either of them.
>
> Maybe you can post the PTO file, then I can see if I can reproduce your 
> problem. This would help me fix the bug. 
>
> Attaching the old problematic one 
> (RabbitIslandVerticalPano-2013092220130922.pto) and the newer 
> non-problematic one (P1000364-P1000361.pto).
>
> I don't know if the list will let them through.
>

-- 
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/a024055c-93f5-4c82-b949-f58f3e6789fen%40googlegroups.com.

Re: [hugin-ptx] lux 1.2.0 released

['kfj' via hugin and other free panoramic software]

On Sunday, April 21, 2024 at 9:26:56 PM UTC+2 GnomeNomad wrote:

Thanks, always good to have an improved GUI.

I ran the appimage from the command line, it gave me a window to open 
files. I went to open a PTO file, and got a blank black screen. Nothing 
happened. Nothing displayed. When I pressed Escape, the window blank 
display went away and I saw this in the command line window:

OpenImageIO exited with a pending error message that was never
retrieved via OIIO::geterror(). This was the error message:
OpenImageIO could not find a format reader for 
"/home/david/data/MyPhotos/Rabbit Island Vertical 
Pano/RabbitIslandVerticalPano-2013092220130922.pto". Is it a file format 
that OpenImageIO doesn't know about?

So the new Lux can't open PTO files anymore?

It should. The error message you get is nothing to worry about - I pass 
every file to OIIO first to see if it can open it, and when it fails it 
saves this error message which is never retrieved and displayed at program 
exit. Maybe I should clean up better before terminating lux - this is 
misleading behaviour. Thanks for pointing it out!

Considering the failure to open your PTO, I wonder: do the images have an 
alpha channel? I checked the PTO display, and I saw there is an issue with 
panoramas with images with alpha channel. Most embarrassing - looks like I 
have a bug to fix. Did you try other PTOs? Maybe you can post the PTO file, 
then I can see if I can reproduce your problem. This would help me fix the 
bug.

-- 
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/b9d2991e-c58f-49d2-9ec5-ed433e664219n%40googlegroups.com.

[hugin-ptx] lux 1.2.0 released

['kfj' via hugin and other free panoramic software]

Dear all!

I've finally released a new lux version, after a lot of work on the 
program. Linux users already had 'tasters' of what's now in version 1.2.0, 
there are two big changes:

- I wrote a new GUI using Dear ImGui

- I am now using OpenImageIO for image input

The new GUI should make it much easier to handle the large amount of 
options and settings, and pretty much everything can now be done 
graphically, rather than having to resort to command line options. The new 
GUI also has plenty of tool tips, so one can approach the functionality 
without having to switch between the program and the documentation all the 
time. I hope this helps to make the program more attractive. The mouse and 
keyboard commands are unchanged.

Using OpenImageIO for image input pulls in a lot of other libraries via 
plugins and linkage, so the number of dependencies has grown dramatically, 
but I think it's worth it. lux can now open a large variety of image files, 
including camera RAWs (using libraw, which is similar to dcraw) and videos 
as sequences of single images (using ffmpeg). Some of the image formats 
which can now be visualized are quite new (e.g. HEIF/HEIC ), and they were 
one of the reasons why I switched to OIIO - the newer formats weren't 
supported by libvigraimpex.

Under the hood there's the same fast rendering engine using multithreaded 
SIMD code, the only change is that automatic rendering quality for 
animations is now on by default. And, needless to say, there were many 
small bug fixes and tweaks, hopefully all for the better!

There are binaries available <https://bitbucket.org/kfj/pv/downloads> for 
Linux (in AppImage format) Windows (portable and installable version) and 
for intel-based macs - a version for mac silicon will hopefully materialize 
soon, until then, mac silicon users can run the intel code with Rosetta, 
which works quite well. 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/9e7eb818-5e7e-41bf-8d31-dd25ccd36f74n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

Bruno, I added signatures which are compatible with vigraimpex. Have a 
look, would that work as a replacement? There may be further need for 
adapters, because some of the code using vigraimpex is old and not using 
MultiArrayViews (stuff like vigra::DImage instead) - to patch cpfind, I had 
to brutalize the result of data() which is const for the image container 
used there. I know it's just the same, but of course that's not so nice. 
Works, though.

On Friday, February 23, 2024 at 10:54:38 AM UTC+1 bruno...@gmail.com wrote:

> On Fri, 23 Feb 2024, 08:30 'kfj' via hugin and other free panoramic 
> software wrote:
>
>> Okay, here goes: the code is online 
>> <https://bitbucket.org/kfj/oiio_fileio>
>> hugin developers, I can offer a patch against hugin master if you're 
>> interested in trying it out.
>
>
> This looks like something that could be #ifdef'd so it can be a Hugin 
> build option. Though the UI would need some changes to allow heic files in 
> the file picker etc..
>
> -- 
> Bruno
>

-- 
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/62bee646-7aba-4562-a3a9-439ab988ec71n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

On Friday, February 23, 2024 at 5:56:43 PM UTC+1 T. Modes wrote:

you are ignoring Hugin photometric optimizer and the photometric 
corrections done at stitching totally.

 
In lux, I only use part of them. I don't use the EMOR and work from linear 
RGB always. I do use  vignetting information and individual image 
brightness (Ev) from the PTO - the latter is kind of redundant because lux 
has it's own 'ligh-balancing' code as well (press Shift+L). I skipped the 
photometric optimization from my sample workflow with the modified cpfind 
and pto_gen because it caused an issue here, and I wanted to keep my POC 
simple.

 

They are already all there, and you simply pass the parameters you want. 
Again, here's the link to OIIO's libRAW plugin 

 
, you'll see it's pretty much all there. And in lux you can simply pass 
these args on e.g. on the command line, like --oiio_arg=raw:user_flip=0


Sorry, but this something for programmers or nerds. This is nothing a 
regular user does.

 
Look at the way the parameters are passed to the RAW converters in hugin as 
it is. That's not so different. Quite nerdy, if you ask me ;-) 

-- 
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/26937607-cc6f-4074-a99b-8c0eb8b688b2n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

On Friday, February 23, 2024 at 5:01:45 PM UTC+1 T. Modes wrote:

when taking the full Hugin workflow into account and take all advantage of 
the raw format it becomes fast more complicated.

...
These are only the first issues came me into consideration - these are 
simply ignored by your proposal. 

 
I am offering a proof of concept to demonstrate what's possible. But of 
course your concerns are valid. As I already pointed out  to Gnome Nomad, 
OIIO's raw plugin is highly configurable. It offers roughly the same 
functionality as libRAW upon which it is based, which in turn offers 
roughly the same functionality as dcraw. OIIO is quite good at taking in 
parameters from outside. In lux, I simply pass parameters to OIIO and it's 
plugins through as strings, and OIIO parses them and passes the 
plugin-specific ones on to the plugin.

Look at it in a different way: OIIO opens TIFFs just fine. There's noone 
stopping you from using the same workflow as ever, but you *could* also try 
and work from RAW directly. It's a new possibility to play with, to see if 
it opens up avenues which weren't possible before. It's an experiment. 
You're sure not killing the joy, and if you insist on keeping hugin the way 
it has always been - go ahead. My proposal - using a toolchain with 
modified pto_gen and cpfind, then autoopitimser and finally lux to stitch - 
doesn't even use hugin - it was dud...@gmail.com who proposed changing all 
of hugin.

Modifying cpfind was the missing link for me to get a toolchain together 
which works in RAW entirely. A lot of my photography is in RAW, and I throw 
away the TIFFs after stitching because they take up a lot of space. With 
the oiio branch of lux I can now simply replace .tiff with .CR2 in the PTOs 
and stitch from RAW, because I used dcraw in the first place. And for my 
Samyang fisheye, I can even pass through chromatic aberration parameters... 
I find that a remarkable achievement.

So it's not done with simply replacing the load image call with another 
library. 
The whole ecosystems needs to be adopted and you have to implement a lot of 
functions of a raw converter.

 
No, you don't. They are already all there, and you simply pass the 
parameters you want. Again, here's the link to OIIO's libRAW plugin 

 
, you'll see it's pretty much all there. And in lux you can simply pass 
these args on e.g. on the command line, like --oiio_arg=raw:user_flip=0

IMHO there are dedicated raw converter better suited for these task. Hugin 
can already take care of some of them. This I consider a better solution, 
than to open Pandoras box and implement a lot of RAW converter features 
into Hugin.

 
What the better solution is will show in time. I find a quick and easy 
option to work directly from RAW is a bonus, even if it takes some extra 
time to decode the images. If any of this turns out to be a good solution 
to adopt throughout the hugin codebase can't be decided now, but I wanted 
to show a path forward. Or will you go ahead and implement vigraimpex 
import plugins for e.g. HEIF and WEBP, to name but a few? Lux uses a fair 
bit of vigra, but I feel stuck now that nothing is happening with vigra 
anymore. My proposal is also about opening up an avenue to a large number 
of modern image file formats which vigra can't handle because noone there 
kept abreast of new developments.

-- 
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/837730dc-542c-4405-b8a4-5ad9eb171825n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

On Friday, February 23, 2024 at 11:54:20 AM UTC+1 dud...@gmail.com wrote:

Very nice. Did a git pull. I will dig into this probably tonight. Work over 
here soon. 
Exciting!


 :D

And if you want to stitch the panorama conatining e.g. RAW files, try a lux 
build from the oiio branch. I tried that here and it works fine, I just 
haven't published .dmg on the lux download page because of some licensing 
issues I want to resolve first.

-- 
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/59f86497-2dc3-4916-89d4-d475c07ebce9n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

On Friday, February 23, 2024 at 11:40:09 AM UTC+1 dud...@gmail.com wrote:

Yes, I have compiler working for both apple Silicon arm64 and Intel mac

Excellent. I just pushed the patch to the oiio_fileio repo. On top of 
applying the patch, you need to put fileio.cc and fileio.h alongside the 
source code for cpfind (that's in src/hugin_cpfind/cpfind) where the 
patched code expects it. As I said, this is just a quick shot, and it may 
not even work on the mac. And for now, it's only for pto_gen and cpfind, 
not the wole of hugin. Don't forget to get OpenImageIO from macports. If 
you run into problems, I'll try and help as best as I can. 

-- 
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/d6d26223-813e-4ab5-8e50-617f8f90a27en%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

On Friday, February 23, 2024 at 11:31:40 AM UTC+1 dud...@gmail.com wrote:

I am all in for porting to whole Hugin program.

 
Do you have a working build setup on your mac? then I can send you the 
patch to try it out. I just tried to see if I could quickly get hugin to 
build on my mac and I failed right at the beginning, where it failed to 
find my wxwidgets install from macports. I don't really want to spend much 
time on getting the hugin build going on my mac, I'd much rather see 
someone else doing it who already has a working build setup on their mac. 

-- 
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/9885f833-49c9-4785-a12f-2467a362fd87n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

On Friday, February 23, 2024 at 10:54:38 AM UTC+1 bruno...@gmail.com wrote:

This looks like something that could be #ifdef'd so it can be a Hugin build 
option.


This is roughly what I am aiming at. My call signatures are more complex, 
because the OIIO code does not interface with vigra data containers 
directly but takes explicit separate stride arguments. But this could be 
hidden with more go-between-code - as stated, I wanted a quick 
proof-of-concept, mainly to see if I could get the entire toolchain set up 
to work from a bunch of RAW files all the way to a stitched panorama. If 
there is interest on the hugin side to take this further, I'm willing to 
code some more and make it easy for hugin to try this out for the hugin 
code base by supplying import functions with adapted signature.

Though the UI would need some changes to allow heic files in the file 
picker etc


I also had the UI issue when switching to use OIIO in lux. My old code 
offered a file-select with common image file extensions, but this became 
impractical with the large number of image file formats OIIO supports, so I 
now simply offer all files for opening and silently ignore those files in 
the selection which don't check out as OIIO-compatible. OIIO works like 
vigraimpex: it looks into the files and opens them with the appropriate 
plugin, no matter what the extension is. I wrote a replacement for vígra's 
isImage as well which helps with figuring out whether a file can be used as 
image input or not, and I could add that to the oiio_fileio repo.

If we could get it to the point where all it would take is to replace the 
type of the info structure and the name of the import routines, making it a 
compile option should work out, and the new functionality would become 
available throughout the hugin tool chain. hugin does try and open, e.g., 
panoramas with .CR2 files, but fails miserably because libvigraimpex 
doesn't understand them properly - I think libvigraimpex interprets them as 
TIFFs and it all comes out wrong.

-- 
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/bed876ff-daaa-4ab6-bd6c-b2a2b2456894n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

Okay, here goes: the code is online <https://bitbucket.org/kfj/oiio_fileio>
hugin developers, I can offer a patch against hugin master if you're 
interested in trying it out.

-- 
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/2d44ac58-76ca-4236-b19f-ca7bde3c1259n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

On Friday, February 23, 2024 at 8:47:07 AM UTC+1 dud...@gmail.com wrote:

That sounds very interesting. Mac user here. I probably won't be able to 
implement this myself. Would it be possible for you to have some code to be 
able and compile for Mac?

I'm just brushing up the glue code, then I'll publish it. All you need is 
to ad a .cc file to your source files, include a header into the files 
which you want to transform and replace the info structure and the calls to 
vigra::importImage read the data. You also have to up the C++ standard to 
C++14 for OIIO and link to OIIO. If you have a working build environment, 
these changes are not hard to do. When I find the time I can see if I can 
get it to work on my mac - Routinely I only build lux on that mac, but 
maybe building hugin and friends is not too hard - after all macOS is 
unixoid. No promise, though.

-- 
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/7c0139e1-d572-4827-9e0e-45b058a57a3dn%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

> It seems you came far into this libraw implementation. Would be of big 
interest to have this working with enfuse or align_image_stack. How would 
it handle tonemapping code though?
My proposal is simply about reading image files into the program. it's to 
replace use of libvigraimpex for image import, that's all. Everything else 
remains just the same. This is why it was so easy to 'slot it in' to cpfind 
and pto_gen: I just looked for vigra::ImageImportInfo and replaced it with 
a struct which uses OIIO data internally, then I looked for 
vigra::importImage and replaced it with calls to an equivalent routine 
using OIIO. Apart from a bit of glue code to mimick the 
vigra::ImageImportInfo structure and to map parameters originally passed to 
vigra::importImage to the code using OIIO there were no changes. I already 
had the glue code, because I use it in lux.
Tonemapping etc. is not in the scope of this proposal. That's the beauty of 
it: all code can remain as it is, only image import is re-routed to a 
powerful, modern library with lots of interesting features. The glue code 
resides in a small pair of .cc and .h files, and inside the code being 
transformed, all it takes is an include statement and the replacement of 
vigra::ImageImportInfo and vigra::importImage with calls into the glue 
code. It's minimally invasive. The down side is that OIIO is a large 
library. But it's very available - I found it on all platforms lux supports 
- various linux distros, macports, mingw and freeBSD.


-- 
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/c4909668-09ce-4f8e-8846-a64ff81b3702n%40googlegroups.com.

Re: [hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

> And how does it handle the need for noise reduction and sharpening in RAW 
files? 

Processing the RAW file is done with configuration parameters, please refer 
to the OIIO docu 

 
for available options - among them noise reduction which is best done early 
in processing. Sharpening is best done on the finished panorama.


-- 
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/8a6dade3-1633-4d34-9d84-c1368c9e95adn%40googlegroups.com.

[hugin-ptx] creating panoramas directly from RAW images

['kfj' via hugin and other free panoramic software]

Dear all!

In my last post I have already hinted at new possibilities arising from the 
use of OpenImageIO (OIIO for short). I found that it's quite feasible to 
use OIIO's image importing code as a stand-in for vigra's importImage. Now 
I've gone one step further and refitted some hugin tools with OIIO code: 
pto_gen and cpfind. For pto_gen, I have just changed the retrieval of image 
metrics to use OIIO, but in cpfind I have also changed the image import 
code. With the modified tools, I could run a tool chain from a set of RAW 
images to a readily-optimized PTO file by using first the modified pto_gen, 
then the modified cpfind and finally autooptimiser. The resulting PTO could 
be loaded into my recent build of lux (the build from the oiio branch, for 
which I offered an AppImage in my last post) which also employs OIIO and 
can process RAW images as input. lux stitched this PTO into a seamless 
panorama.
All of this was possible without any intermediate TIFF files on disk - OIIO 
handles the loading and processing of RAW images in-library using libRAW 
and presents the readily-converted data. I think with this little 
experiment I have established that OIIO would make a good candidate to 
replace vigra's ageing impex library - OIIO can also handle newer formats 
like HEIF and webp, among many others. Since the swapping-in of OIIO code 
for vigra code is quite painless, one might assume that the entire hugin 
software collection could be refitted like this, bringing hugin up-to-date 
with newer file formats and adding RAW support. 

-- 
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/cf611e0c-978f-4516-b3ad-8c0396036f3dn%40googlegroups.com.

[hugin-ptx] lux with OpenImageIO - experimental AppImage available

['kfj' via hugin and other free panoramic software]

Dear all!

Until recently, I've been using libvigraimpex to open image files for lux. 
lux is using strided nD arrays for image data storage (namely, 
vigra::MultiArrays) , and libvigraimpex can directly read into these data 
structures. I wasn't too happy with the supported range of image types 
which libvigraimpex offers - e.g. newer formats are missing. So I was 
looking for a replacement, but I found no library reading the data into 
strided nD arrays - until I found OpenImageIO 
<https://openimageio.readthedocs.io> (OIIO for short). This library is 
extremely comprehensive, and since it accepts strides, I could just 'slot 
it in' where I used libvigraimpex before - with a few hundred lines of glue 
code.

I have built an experimental lux AppImage (so, this is for Linux only) to 
demonstrate just how versatile this library is. Just to whet your appetite, 
here are three really cool things you can do:

   - open videos, viewing single images
   - open RAW files
   - open HEIF and HEIC files
   
Because OIIO can open such a wide range of image formats, the lux build I 
offer shows all possible files and does not pre-select images - the filter 
list would be too large. When opening videos, note that you can navigate 
through the single images with the 'subimage' control, at the bottom of the 
View Control Panel.

If you'd like to give the AppImage a spin, here's the link:

https://bitbucket.org/kfj/pv/downloads/lux-with-oiio-experimental-x86_64.AppImage

Because OIIO plays so well with vigra data structures, it might be an 
interesting option for hugin and relatives. It's RAW support, for example, 
uses libraw, which is a wrapper around the code for dcraw, which, in turn, 
is one of the raw converters hugin can employ as helper programs. lux can 
process many PTO files, among them PTOs which refer to raw source images. 
While the hugin process calls dcraw (when so configured) to convert the raw 
files to TIFF and then takes it from there, lux can now directly open PTOs 
with raw source images and stitch them with a single keystroke (Shift+E)! 
Check it out. Just keep in mind lux is doing it all in-memory and you need 
huge amounts of memory to stitch large panoramas - and for PTOs with raw 
files, you must have been using dcraw - otherwise the geometry won't quite 
fit, because most raw converters cut off o bit of margin.

The versatility comes at a price: you'll notice that the new AppImage is 
*much* larger than the ones before. This is because it packs all the helper 
libraries as 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/3163e7b4-cff4-46d1-8c01-02886b99bab0n%40googlegroups.com.

[hugin-ptx] Re: new GUI for lux

['kfj' via hugin and other free panoramic software]

Dear lux users on Linux! I uploaded a new version of the experimental 
lux-with-imgui AppImage which has all the changes and additions to the new 
GUI in I did in the past few weeks. It's slowly coming together! All the 
important functionality is now available - many settings which would have 
needed command line arguments before can now be manipulated graphically 
through 'panels' - both for the current image or for the entire lux 
session. Other panels give access to functionality like snapshots and slide 
shows, and also to per-image settings like projections. Check it out - the 
URL is the same:

https://bitbucket.org/kfj/pv/downloads/lux-with-imgui-experimental-x86_64.AppImage

Windows and macOS users will have to wait for some time until I publish 
binaries for these platforms, but I have successfully built and run the 
code on Windows (using MinGW) and also on macOS, both on intel and M1 macs 
- only packaging on the ARM mac didn't yet work out...
On Sunday, December 3, 2023 at 9:57:18 AM UTC+1 kfj wrote:

> I've been working on the new GUI for some time now, and I think it's time 
> for a first demo! This is for Linux only, for the time being. I've built 
> what's currently in the imgui branch into an AppImage and uploaded the 
> AppImage to the lux download page. If you want to try it, here it is:
>
>
> https://bitbucket.org/kfj/pv/downloads/lux-with-imgui-experimental-x86_64.AppImage
>
> This is an AppImage, so for those of you who aren't familiar with the 
> format, after downloading the file, you need to set execute permission, 
> then you can execute it like any other binary. AppImages should run on a 
> wide range of Linux distros. If you find it runs on your Linux, let me know 
> about it, and also let me know if there are any problems.
>
> The first thing you get to see is a file select dialog, where you can 
> select images and/or PTO files. After you've okayed the selection, lux 
> starts in full-screen mode, displaying the first image. If you don't like 
> full-screen, press F11, TAB takes you to the next image. If you want to 
> interact with the view, all the keyboard and mouse commands from 'legacy' 
> lux are there, but there is one big difference: if you move the mouse 
> pointer close to the image's top margin, you get a quite ordinary-looking 
> drop-down menu. This is how you access the new GUI functionality. The 
> 'File' menu has a few entries, among which the 'Imgui Demo' is probably the 
> most interesting: it provides a panel to show all widgets and functionality 
> Dear ImGui offers. The second menu has lux-specific panels. You can now 
> make all kinds of settings with the GUI which did require command line 
> parameters in 'legacy' lux. Check it out - the widgets in the panels are 
> usually named like the CL parameters, and the little '?' signs next to the 
> widgets yield tool tips when hovered. The new GUI focuses (for now) on 
> parameterization, which I felt was awkward in 'legacy' lux. I'll eventually 
> extend it to the operation of the virtual camera, slide-show control, 
> snapshots, stitching etc. - please bear in mind that this is a first demo, 
> not the final new GUI, so there are plenty of things still missing. If you 
> want to use the 'legacy' GUI, you can simply switch between the old and new 
> GUI with the 'C' key - the demo is 'hybrid'.
>
> The panels, once you've opened them, remain visible and display the 
> currently active parameters. If you change anything, there is no immediate 
> effect, you have to use the 'Apply' or 'Okay' buttons at the bottom of the 
> panels. Note that you can Apply changes to either the current view or to 
> the entire session. I think you'll get the hang of it quickly. Please note 
> that Dear ImGui may produce small .ini files saving the layout and position 
> of the panels, this enables it to start up as it was closed.
>
> So much for now, and maybe there's an echo this time? This would also be a 
> good moment to make propositions or get involved.
> On Friday, November 3, 2023 at 10:01:45 AM UTC+1 kfj wrote:
>
>> Dear all!
>> Over time, lux has become very complex. To do more than 'ordinary' image 
>> and panorama viewing, it's often necessary to pass arguments on the command 
>> line. Many users find that difficult, and the 'legacy' GUI is not up to the 
>> task to handle the complexity. So I decided to start on a new GUI for lux. 
>> lux is using openGL via SFML, and a common way of writing GUIs for SFML 
>> projects seems to be using Dear ImGui <https://github.com/ocornut/imgui>, 
>> an immediate-mode GUI lib

[hugin-ptx] Re: new GUI for lux

['kfj' via hugin and other free panoramic software]

I've been working on the new GUI for some time now, and I think it's time 
for a first demo! This is for Linux only, for the time being. I've built 
what's currently in the imgui branch into an AppImage and uploaded the 
AppImage to the lux download page. If you want to try it, here it is:

https://bitbucket.org/kfj/pv/downloads/lux-with-imgui-experimental-x86_64.AppImage

This is an AppImage, so for those of you who aren't familiar with the 
format, after downloading the file, you need to set execute permission, 
then you can execute it like any other binary. AppImages should run on a 
wide range of Linux distros. If you find it runs on your Linux, let me know 
about it, and also let me know if there are any problems.

The first thing you get to see is a file select dialog, where you can 
select images and/or PTO files. After you've okayed the selection, lux 
starts in full-screen mode, displaying the first image. If you don't like 
full-screen, press F11, TAB takes you to the next image. If you want to 
interact with the view, all the keyboard and mouse commands from 'legacy' 
lux are there, but there is one big difference: if you move the mouse 
pointer close to the image's top margin, you get a quite ordinary-looking 
drop-down menu. This is how you access the new GUI functionality. The 
'File' menu has a few entries, among which the 'Imgui Demo' is probably the 
most interesting: it provides a panel to show all widgets and functionality 
Dear ImGui offers. The second menu has lux-specific panels. You can now 
make all kinds of settings with the GUI which did require command line 
parameters in 'legacy' lux. Check it out - the widgets in the panels are 
usually named like the CL parameters, and the little '?' signs next to the 
widgets yield tool tips when hovered. The new GUI focuses (for now) on 
parameterization, which I felt was awkward in 'legacy' lux. I'll eventually 
extend it to the operation of the virtual camera, slide-show control, 
snapshots, stitching etc. - please bear in mind that this is a first demo, 
not the final new GUI, so there are plenty of things still missing. If you 
want to use the 'legacy' GUI, you can simply switch between the old and new 
GUI with the 'C' key - the demo is 'hybrid'.

The panels, once you've opened them, remain visible and display the 
currently active parameters. If you change anything, there is no immediate 
effect, you have to use the 'Apply' or 'Okay' buttons at the bottom of the 
panels. Note that you can Apply changes to either the current view or to 
the entire session. I think you'll get the hang of it quickly. Please note 
that Dear ImGui may produce small .ini files saving the layout and position 
of the panels, this enables it to start up as it was closed.

So much for now, and maybe there's an echo this time? This would also be a 
good moment to make propositions or get involved.
On Friday, November 3, 2023 at 10:01:45 AM UTC+1 kfj wrote:

> Dear all!
> Over time, lux has become very complex. To do more than 'ordinary' image 
> and panorama viewing, it's often necessary to pass arguments on the command 
> line. Many users find that difficult, and the 'legacy' GUI is not up to the 
> task to handle the complexity. So I decided to start on a new GUI for lux. 
> lux is using openGL via SFML, and a common way of writing GUIs for SFML 
> projects seems to be using Dear ImGui <https://github.com/ocornut/imgui>, 
> an immediate-mode GUI library which only requires the capability to render 
> textured triangles on the host system. There's a 'glue' layer for SFML, 
> which makes employing Dear ImGui quite straightforward, and Dear ImGui's 
> logic blends well with SFML's. So that's what I use as well.
> I have set up a new 'imgui' branch in the lux repo 
> <https://bitbucket.org/kfj/pv> and I've tentatively added a few GUI 
> elements to lux to see what I can do. I've also established that the code 
> will build on all platforms I support myself (Linux, MacOS and Windows) - 
> with the exception of building the MacOS version on Apple silicon (I only 
> have intel Macs). To build the imgui branch, you may need to provide openGL 
> libraries on your system (e.g. freeglut from MacPorts on MacOS), cmake 
> should take care of the rest.
> What's in the imgui branch is little more than a proof of concept, please 
> don't expect too much. The menu will appear if you approach the upper 
> window margin. There is, as of yet, no documentation for the new GUI, but 
> many options have tool tips (hover over the little question marks). Have a 
> look, try it out, and - as ever - comments are welcome!
>

-- 
A list of freq

[hugin-ptx] new GUI for lux

['kfj' via hugin and other free panoramic software]

Dear all!
Over time, lux has become very complex. To do more than 'ordinary' image 
and panorama viewing, it's often necessary to pass arguments on the command 
line. Many users find that difficult, and the 'legacy' GUI is not up to the 
task to handle the complexity. So I decided to start on a new GUI for lux. 
lux is using openGL via SFML, and a common way of writing GUIs for SFML 
projects seems to be using Dear ImGui <https://github.com/ocornut/imgui>, 
an immediate-mode GUI library which only requires the capability to render 
textured triangles on the host system. There's a 'glue' layer for SFML, 
which makes employing Dear ImGui quite straightforward, and Dear ImGui's 
logic blends well with SFML's. So that's what I use as well.
I have set up a new 'imgui' branch in the lux repo 
<https://bitbucket.org/kfj/pv> and I've tentatively added a few GUI 
elements to lux to see what I can do. I've also established that the code 
will build on all platforms I support myself (Linux, MacOS and Windows) - 
with the exception of building the MacOS version on Apple silicon (I only 
have intel Macs). To build the imgui branch, you may need to provide openGL 
libraries on your system (e.g. freeglut from MacPorts on MacOS), cmake 
should take care of the rest.
What's in the imgui branch is little more than a proof of concept, please 
don't expect too much. The menu will appear if you approach the upper 
window margin. There is, as of yet, no documentation for the new GUI, but 
many options have tool tips (hover over the little question marks). Have a 
look, try it out, and - as ever - comments are welcome!

-- 
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/9b9296d4-68b5-41b7-b8ed-e2279a2c27c3n%40googlegroups.com.

[hugin-ptx] Re: Experimental HUGIN AppImage package

['kfj' via hugin and other free panoramic software]

Hi!

I recently switched to distributing the Linux version of my image and 
panorama viewer, lux <https://bitbucket.org/kfj/pv>, in AppImage format. 
When browsing for other AppImages in the catalog 
<https://appimage.github.io/>, I noticed there is an entry for hugin, which 
you,  @aferrero2707, provided. Following the link I did find AppImages, but 
the series ends 2019. What happened? I had a good long look at the AppImage 
format and it's ecosystem, and I think it's a good idea, but of course it's 
only as good as the AppImages on offer.

Kay

On Monday, November 5, 2018 at 5:13:38 PM UTC+1 aferrero2707 wrote:

> Hi!
>
>
> On Sunday, November 4, 2018 at 7:40:27 PM UTC+1, T. Modes wrote:
>>
>>
>> I think I implemented such logic in changeset a71803394853. First step: 
>> testing if file can be found beside the calling executable. Only if it is 
>> not found there (=in the AppImage) check the PATH variable.
>>
>> I found one more place related to calling the control point detectors 
>> which needed a patch. Please use changeset be85ff35e9444 (or later) for 
>> testing.
>>
>
> I prepared a new package that is compiled against the development branch 
> without patches (
> https://github.com/aferrero2707/hugin-appimage/releases/download/continuous/Hugin_Panorama_Creator-git-20181105-x86_64.AppImage
> ).
> As far as I could check, it works properly... good job, and thanks!
>
> Andrea
>

-- 
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/f5c15944-792d-444b-9532-ae7cf8af46dbn%40googlegroups.com.

[hugin-ptx] A better path to exposure fusions

['kfj' via hugin and other free panoramic software]

Exposure fusion is based on the Burt&Adelson image splining algorithm. This 
is the algorithm used by enfuse to produce exposure fusions for hugin, and 
it's also used by lux, with roughly the same effect.
I've been looking at some of my landscape brackets recently, fused with 
this method, and some of them weren't quite how I thought they should be: 
if there were 'islands of bright content' in darker surroundings, 
highlights in these 'islands' would show near-white (overexposed) even 
though the bracket contained valid pixels for the area in question in the 
darkest exposure.
How can this be? The Burt&Adelson algorithm is pyramid-based. To form an 
image pyramid, the image is scaled down repeatedly, producing a series of 
ever-smaller images - the 'pyramid'. The scaling-down combines several 
pixels from a larger image into one pixel in the next-smaller pyramid 
level. If some of the contributing pixels are overexposed (white), their 
combination will be partly informed by the white contribution, which is not 
a correct value to calculate with. With ever smaller pyramid levels, the 
problem gets worse. When the pyramids are combined in the fusion, these 
wrong pixels eventually produce the artifacts I noticed.
Is there a remedy? I think I have figured it out: the trick is to first 
hdr-merge the bracket, and then to create a faux bracket from the HDR 
rendition. I'll describe the process using lux:

   1. create a PTO named 'stack.pto' from your bracket with 
   align_image_stack
   2. hdr-merge with lux: lux --hdr_merge=yes stack.pto
   3. create a faux bracket from the result: lux --compress=yes 
   stack.pto.lux.1.exr.lux

This simple three-step process is already pretty good, but I found a way to 
improve it further, by using a different method for HDR merging, which I 
call HDR fusion. The modified process goes like this:

   1. create a PTO named 'stack.pto' from your bracket with 
   align_image_stack
   2. hdr-fuse with lux: lux --fuse=yes --hdr_spread=1 
   --snapshot_extension=exr stack.pto
   3. faux bracket from the result: lux --compress=yes 
   stack.pto.lux.1.fused.exr.lux

Give it a try, I think the result is a fair bit better than using plain 
exposure fusion! Comments welcome.

-- 
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/7d1651df-93c9-443a-b725-7613c441a077n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

I've released lux 1.1.8 which has the bug fix mentioned in the last post, 
and better support for making AppImages. 
The new version can be downloaded here:

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

This version was built on ubuntu 20.04, because 18.04 is no longer 
supported. I hope this does not break use on older systems.

On Thursday, July 27, 2023 at 11:34:16 AM UTC+2 kfj wrote:

> 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/95763568-b045-4c21-a6ae-69e3b7c1a2c0n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear all!
I've released lux 1.1.7. You can download ready-made binaries here 
<https://bitbucket.org/kfj/pv/downloads/> - if you have 1.1.6 already, 
nothing much has changed, there aren't any major new features.
For Linux, I have switched to using AppImage 
<https://github.com/AppImage/AppImageKit>. This looks like a promising way 
to serve more distributions, and also older systems: the 1.1.7 AppImage 
build was created on a VM running Ubuntu 18.04, the oldest still-supported 
LTS ubuntu in circulation. But that does not mean that this lux build is 
using old libraries - quite the contrary: the libraries are the same one 
would use in a rolling release, e.g. libexiv2 v.0.28 and highway 1.0.5. The 
AppImage bundles the new libraries with the binary, resulting in an 
up-to-date package which runs well on older and newer distros - at least 
that is the idea. I'd appreciate if you Linux users out there could help 
finding out whether that's actually true: just download the AppImage, make 
it executable, and run it - then let me know whether it worked or not! I've 
made an effort to tweak the binary as much as I could, doing stuff like 
building clang from scratch to get the best rendering code, and on my 
system, the AppImage sometimes even outperforms the natively built binary.
In case you're curious: the AppImage is like a self-extracting compressed 
file, which decompresses itself into a temporary folder, sets up an 
environment where the binary uses the shared libraries in the temporary 
folder, and once it's finished, discards the temporary folder. It's a neat 
mechanism, it's fully FOSS, it's been around for a while and seems to work 
just fine. There's no need for run-times, no App store attached - it's 
quite different to snap or Flatpak, which spring to mind as other ways of 
serving several distros. I wonder why I didn't start using it earlier.
For Windows users, there are the usual two packages - one zipped folder to 
run lux as a portable application, one setup.exe to install it. I test-ran 
it on W10 and W11 - the W11 test took several attempts because Windows did 
not like that lux hadn't yet been downloaded frequently, and of course it's 
not signed and does not come from the Store...
For MacOS I offer a .dmg for intel-based macs - I have no Apple account and 
I am not registered as an Apple developer, so you'll have to go through the 
usual routine of your system trying to dissuade you from using my software. 
Your mileage with lux on Mac will vary, and finder integration is still 
missing, but apart from that it's running just fine on my iMac with Big 
Sur. The ARM build for 'Apple silicon' hasn't materialized yet, I'll upload 
it once I get it.
The freeBSD port will also take a little longer.
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/33d7627e-14ec-4dd0-b3dc-7127763fd8a3n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Ooops... misread the download counter - fourteen so far. So maybe you did 
try?

On Friday, July 14, 2023 at 8:41:36 AM UTC+2 kfj wrote:

> 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/1d48568d-30b7-410c-8c47-4f216f516351n%40googlegroups.com.

[hugin-ptx] lux for Linux as AppImage

['kfj' via hugin and other free panoramic software]

Dear all!

So far, I've been offering debian packages for lux, specifically built for 
several distros and versions. This took quite some time, so I was on the 
look-out for an alternative. For now, I've settled on AppImage 
<https://appimage.org/> - building the bundle was reasonably painless, and 
the resulting single-file artifact runs on the linux installations I have 
floating about, namely debian 11 and 12, and ubuntu 22.04 and 23.04. I 
built the artifact on the debian 11 system, because the recommendation is 
to build rather on an older system - I stopped myself from installing 
something even older just for the purpose.

The AppImage 'promise' is that an AppImage should run on a wide variety of 
distros, so I'd be curious to hear from users of other linux distros 
whether they can in fact run this one! Running an AppImage is simple:


   - Download it
   - set the execute permission
   - run it like any other executable


You can download my lux AppImage from here 
<https://bitbucket.org/kfj/pv/downloads/lux-1.1.6-x86_64.AppImage>. Please 
note that this is for AMD/intel 64 bit systems only! It's built from lux 
master, which is slightly ahead of 1.1.6 proper.

If you're interested in the build process, it's script-driven, and the 
relevant build script is in the scripts folder off the pv repo's root, 
requiring only two helper programs and one additional file (the AppRun 
script, needed here to provide the font file path at run-time).

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/9107b0dd-dbe2-440f-a168-1210c9e2935bn%40googlegroups.com.

[hugin-ptx] lux on zimt

['kfj' via hugin and other free panoramic software]

I'm currently doing some refactoring on lux' rendering back-end. I've 
extracted several components of vspline into a new library zimt 
<https://github.com/kfjahnke/zimt>, namely

   - multithreading/thread pool
   - SIMD data types and back-ends
   - processing of nD arrays

And now I've re-routed some of the vspline code lux uses to work with zimt. 
The main difference is with 'peeling': The original vspline code processes 
underfilled SIMD vectors with scalar code, whereas zimt 'stuffs' the unused 
lanes and then processes a full vector. This should not affect performance 
much, but it makes all the scalar 'eval' versions in the rendering code 
unnecessary, which should reduce the code's complexity.
Because this is a far-reaching change, I have created a new branch 
<https://bitbucket.org/kfj/pv/src/zimt/> 'zimt' in the repo and I've 
uploaded a debian package 
<https://bitbucket.org/kfj/pv/downloads/lux-on-zimt-experimental.deb> built 
from this branch. Apart from the back-end changes, the binary is pretty 
much like 1.1.6, but I've made a better debian package, now with 
dependencies. Comments welcome!

-- 
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/fe1a44b8-4711-4b28-9714-290f679e61abn%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear all!
I've just released lux 1.1.6. The main change is that lux now uses highway 
as it's default
SIMD back-end, which should result in better performance for machines with 
AVX512f,
which Vc does not support. All builds which I publish on the download page 
<https://bitbucket.org/kfj/pv/downloads/> will now be
done with highway. Apart from the change to highway, there were a few 
changes to the user interface.

 Here's a copy of the tag annotation I pushed with the 1.1.6 tag:

   with lux 1.1.6, highway is the default backend for SIMD operations.
For i86 builds, there is no more dedicated AVX support with this
back-end, only the (slow) 'fallback', SSE4.2, AVX2 and AVX512f.
If you need dedicated AVX support, configure the build to use
Vc and add the AVX flavour (-DUSE_HWY_LIBRARY=OFF -DUSE_VC_LIBRARY=ON
-DFLV_AVX=ON). Performance of the SSE4.2 code is quite similar to
dedicated AVX, and CPUs with AVX are getting increasingly rare,
so I suppose it's okay to make this change. Up to the AVX2 ISA,
Vc and highway produce quite similar performance, but for AVX512f,
highway seems to perform better. For ARM builds, highway is the
only option producing native ARM SIMD code anyway. Other architectures
should also rceive native SIMD code with highway, but I have no test
results confirming that.
Apart from that, there were some bug fixes, and some changes to the
user interface. lux can now do 'focused zoom', a zoom which is centered
on the current mouse position. For mouse-wheel-mediated zoom, this is 
now
the default, for vertical-secondary-button-click-drag it's optional.
The behaviour can be switched on/off with the CL arguments 
scw_focused_zoom,
and scvd_focused_zoom, respectively. Single click processing was also
changed: a single primary-button click will stop an active auto-pan,
but it won't start it (as it did previously). To start auto-pan with the
mouse, there's a new gesture: the 'slap' or 'spin' gesture. It's a
primary-button single-click executed while the mouse is in horizontal 
motion.
The depression and release of the mouse button have to be no more than
300msec apart for this gesture, otherwise it's taken as a click-drag.
A secondary-button single-click will now move the click position to view
center. There are two keys for quickly doubling/halving the zoom factor:
the 2 and 3 keys. This gives another route to quickly zoom to 
interesting
detail: secondary-click on the detail, then press 2 repeatedly.
The 'focused zoom' can 'act funny' near the zenith and nadir because the
viewer maintains the vertical. For work near zenith and nadir, it can be
preferable to 'release the vertical' (F2). To 'regain the vertical', you
can now use the 'J' key, which sets camera roll to zero, and pressing F2
again after that will re-lock the vertical.

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/258010c0-5272-4fd3-8603-7cc64f2bn%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear all!

I've released lux 1.1.4 - the version jump is due to silly old me who got 
the tagging wrong, it should really have been 1.1.1. Most changes are 
'behind the scenes', and the most notable one is that lux can now use 
google highway for SIMD operations. This should allow more performant 
builds on newer x86 and non-x86 CPUs.

The binaries I released on my project's download page 
<https://bitbucket.org/kfj/pv/downloads> are still using Vc. Please pick 
files with '1.1.4' in the name. macOS binaries should arrive soon. So 
what's new apart from that?

   - processing of panoramas with stacks
   - support of all PTO include and exclude masks
   - support of PTO lens/source image cropping

Stacked panoramas are now fully supported, but bear in mind that they use a 
lot of memory. You may have to use --build_pyramids=no and 
--build_raw_pyramids=no to squash memory use. The stacks are exposure-fused 
before they are stitched together, and each stack is processed as such and 
used for the final result, rather than using heuristics to make the stack 
assignments during the stitch and excluding redundant images from the 
result.

The full masking support refers to still images (when the viewer is at 
rest) and stitches to image file output, while the 'fast' view (while 
zooming, panning etc) will only show the 'stack parents' to save time.

Correct lens/source image cropping now makes it possible to properly 
display and render 'dual fisheye' images.

I'd like to point you to one interesting new feature, called 'hdr_spread'. 
With this parameter, you can select by how much the dynamic range of an 
exposure fusion is actually compressed. A 'classic' exposure fusion will 
compress the dynamic range to the same range as the input images, and this 
is what you get with the default, which sets hdr_spread to zero. Now with 
increasing hdr_spread, the dynamic range will be compressed ever less, 
until, finally, you arrive at the maximum value of one, which produces 
'proper' HDR output (you'll need openEXR output to capture that). The HDR 
output from this process is actually generated with lux' modified 
Burt&Adelson image splining algorithm, so it uses a multi-scale approach 
and produces pleasing results. So if you'd like to produce an HDR image 
from a PTO holding an exposure bracket, try the new feature, it's as easy as
lux --fuse=yes --snapshot_extension=exr --hdr_spread=1 bracket.pto

hdr_spread will also affect the fusion of stacks. 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/c3ae622f-92b1-400d-95c9-d1d5e6d58023n%40googlegroups.com.

[hugin-ptx] Re: What's the process to manually deghost bracketed photos ?

['kfj' via hugin and other free panoramic software]

You can try lux <https://bitbucket.org/kfj/pv>. If you have a bracket in a 
PTO, try and invoke lux like this:

lux --deghost=yes my.pto

This uses lux' 'quorate' blending mode, where pixels which are similar on 
several source images are favoured and outliers are suppressed. For now, 
lux does not offer an option to do this with all stacks in a stacked 
panorama, so you'd have to deghost the stacks individually, then stitch the 
results. It may not be good for tree branches, though, because you need 
several images to agree, and with moving branches they may all be 
different. It's more for removing true 'ghosts' like people walking through 
the set.

-- 
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/fa08f1cd-5178-47d7-8693-09180a27d323n%40googlegroups.com.

[hugin-ptx] Re: vignetting parameters in PTO file

['kfj' via hugin and other free panoramic software]

Thanks for the reply! So that file is faulty, with the Va = 0? Anyone from 
panotools listening to this? You could update it. What I do now in lux is 
to silently set Va to one when it's zero.

On Thursday, March 31, 2022 at 5:23:17 PM UTC+2 T. Modes wrote:

> kfj schrieb am Donnerstag, 31. März 2022 um 09:33:32 UTC+2:
>
>> Dear all!
>>
>> Someone pointed out that when trying to view 
>> tests/simpleStitch/simple.pto in the libpano package with lux, there was a 
>> strange result. 
>>
>
> This file was written by a very early Hugin version before finalizing the 
> photometric features. So it was written by an alpha (or beta) Hugin 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/df8ceaa5-115e-406b-9124-d743b2a445cbn%40googlegroups.com.

[hugin-ptx] vignetting parameters in PTO file

['kfj' via hugin and other free panoramic software]

Dear all!

Someone pointed out that when trying to view tests/simpleStitch/simple.pto 
in the libpano package with lux, there was a strange result. I found out 
that this is due to the vignetting parameters in that PTO. It gives this 
i-line:

i w750 h500 f0 K0a1 K0b0 K1a1 K1b0 K2a1 K2b0 Va0 Vb0 Vc0 Vd0 Vx0 Vy0 a0 b0 
c0 d0 e0 g0 p8.91614 r0.192433 t0 v25.3608 y-13.4262  u10 
n"051221_6054_750.jpg"

Note how Va is given as zero. The default for hugin-generated PTO files is 
to have Va==1, and the other V parameters zero. Is this a difference in 
dialect, or is the simple.pto file faulty?

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/c99522c3-6329-401c-91b3-ab158aa28f1en%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

... and I also added a package for debian11 just now.

-- 
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/2debb561-c9d4-43b7-a824-6d7ddb3e8954n%40googlegroups.com.

[hugin-ptx] lux FOSS panorama and image viewer: 1.1.0 released

['kfj' via hugin and other free panoramic software]

Dear all!
After two pre-releases and some bug-fixing I've now released lux 1.1.0!
You can find ready-made binaries for Ubuntu, Windows and MacOS on the 
project's download page:
https://bitbucket.org/kfj/pv/downloads/
All binaries are for intel/AMD 64 bit architecture.

-- 
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/fddab91a-f1f3-4396-9625-3de1c77359aen%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

I also uploaded updated binaries:
https://bitbucket.org/kfj/pv/downloads/lux-1.1.0-pre-2.deb
https://bitbucket.org/kfj/pv/downloads/lux-for-windows-portable-1.1.0-pre-2.zip
Kay
On Saturday, March 5, 2022 at 10:20:07 AM UTC+1 kfj wrote:

> 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/021a50d4-8d1c-42a7-b7ff-3028d5d35b27n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear all!
It's been a while since I have released new binaries! So today I'm offering 
binaries of a development snapshot which has - roughly - the feature level 
which I intend for lux 1.1.0.
Development has been intense - I rewrote a lot of code in the rendering 
engine, switching processing to associated alpha RGB pixel pipelines, which 
are better suited to deal with interpolation and masking. These code chages 
did mostly affect the processing of synoptic data (stitching, exposure 
fusions), but 'ordinary' image and panorama viewing should also benefit.
Probably the most important new features are processing of PTO files with 
source image cropping and masks (limited to exclude masks) - and processing 
of panoramas with stacks. My own panoramas make use of these features, and 
I found it frustrating that lux could not handle them, so I 'scratched my 
itch'.
I hope that this will make lux more useful for the community - give it a 
try, everything is set up to work with sensible defaults. To see masked and 
stacked panoramas on-screen will take a fair while. And lux is - as ever - 
memory-hungry in the default setting, so don't overdo the number/size of 
images in the panoramas. Snapshots are now done with the plain 'E' button 
for screen-sized snapshots and Shift+E for 'source-like' snapshots, and 
will automatically render panoramas/exposure fusions for data which are 
displayed as such, and there are more UI changes - I've tried to be 
conservative, but development goes on and the new features have to 'find 
room' somehow.
Find a debian package and a windows portable ZIP file here:
https://bitbucket.org/kfj/pv/downloads/lux-1.1.0-pre.deb
https://bitbucket.org/kfj/pv/downloads/lux-for-windows-portable-1.1.0-pre.zip

-- 
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/4b723106-07ed-4fe5-87be-f2b54420d5aan%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Before committing to 1.1.0, I have decided to release another lux binary in 
the 1.0.9 series, because I have put quite some work into lux since 1.0.9a 
and I'd like to have the software in use for some time to see if any bugs 
crop up. My 'grooming session' is now done, and I have documented all 
options in lux_options.html. Find new binaries on my bitbucket site's 
download page:

portable windows version: 
https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9b.zip
windows installer: 
https://bitbucket.org/kfj/pv/downloads/lux_1.0.9b_setup.exe
debian package: https://bitbucket.org/kfj/pv/downloads/lux-1.0.9b-amd64.deb

So, what's new? Casual users likely won't notice any changes - the focus is 
more on ironing out bugs and glitches. lux is complex software, and 
sometimes changes in one part affect other parts in unwanted ways - for 
example, the comic book mode went dysfunctional, because I changed the 
semantics of the initial_dx and initial_dy options (that's fixed now).

The truly new features are quite 'specialist': it's about creating image 
pyramids, which are central to both the viewer and the lux version of the 
Burt and Adelson image splining algorithm. What I added here are new 
low-pass filters which are used to create a pyramid level from the level 
'below' it. Until now, lux was using b-spline reconstruction kernels, 
'area' decimation and a small binomial (.25, .5, .25). Now I added the next 
odd binomial, an 'optimal' Burt filter, and FIR half-band filters based on 
a truncated sinc with a Hamming window, as explained here:

https://www.dsprelated.com/showarticle/1113.php

The filters are used in a 'convolving basis functor', a hybrid between 
b-spline evaluation and FIR filter which allows off-grid access. They 
require a spline pyramid to operate on, which makes the pyramid building 
code a bit slower. Especially these filters should provide near-optimal 
results - for more on the topic, please visit the documentation - or 
discuss it here! Visibly, the change is hard to detect, because lux' image 
pyramids were pretty good as they were. If you want to give it a try, 
invoke lux with --pyramid_smoothing_level=-7 for a 7-tap half-band or -11 
for an 11-tap half-band etc. (the half-band filters lux uses have tap 
counts of 4N-1). If you (optionally) combine that with --decimate_area=yes 
and zoom out (start with 1:1 magnification by pressing '1', then zoom out) 
the resulting animation should be practically free from pyramid level 
switching artifacts.

One more bit of good news: I finally managed to find someone who has a 
recent intel core-i processor which offers the AVX512 instruction set, and 
managed to talk him into running lux on it. And, lo and behold, the AVX512 
capability was detected and the AVX512-specific code used! So far I have no 
idea if there is a significant performance gain from using the new ISA. but 
I suspect that the doubled register size vs. AVX2 should make a fair 
difference, because a lot of lux code is running in the registers rather 
than accessing RAM. Any of you out there with AVX-512 capable processors, 
please check it out!

Kay
On Monday, July 5, 2021 at 10:35:35 AM UTC+2 kfj wrote:

> Dear all!
>
> I've made an intermediate release of lux with a few bug fixes and changes 
> to the docu which have accrued during the past few weeks, during my 
> 'grooming' session, which will continue until the release of lux 1.1.0. The 
> intermediate release has version lux_1.0.9a, downloadable binaries can be 
> found in the Downloads section of the bitbucket repo:
>
> https://bitbucket.org/kfj/pv/downloads/lux-1.0.9a-amd64.deb
> https://bitbucket.org/kfj/pv/downloads/lux_1.0.9a_setup.exe
> https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9a.zip
>
> And the README in HTML format was also updated:
>
> https://bitbucket.org/kfj/pv/downloads/README.html
>
> The windows installer has seen some work (thanks, Bernd!):
>
> - it's less obtrusive, per default, lux is not launched after installation
> - for several extensions, lux can now be chosen as target via the context 
> menu
> - SendTo can be used to invoke lux with a selection from the explorer
>
> Kay
> On Wednesday, June 23, 2021 at 11:14:22 AM UTC+2 kfj wrote:
>
>> 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 m

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

['kfj' via hugin and other free panoramic software]

Thanks, Bruno, that explains TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0, and it has much 
more information than the docu I was using!

I have another issue with the i-lines. In PTOptimizer.html 
, there is the 
option to use cropped source images with the 'C' field:

# C100,600,100,800 Crop(l,r,t,b), Only pixels inside the rectangle will be 
used for conversion.
#  Cropped image size is used for all image 
parameters
#  (e.g. field-of-view) refer to the 
cropped part of the image.

I tried to use a PTO file with such C fields with hugin, but the cropping 
information was silently changed to a selection field ('S' tag)
Is this field type not used by the hugin processing chain?

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/1a345e81-b88b-4cc9-a896-2e9d4f28f9f0n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear group!

I'm working on a script which modifies PTO scripts. For PTO format, I'm 
using this reference:

http://hugin.sourceforge.net/docs/manual/PTOptimizer.html

I noticed that there are quite a few fields which are not covered in this 
documentation. In a recent PTO script generated by hugin, the i-lines end 
with these fields:

TrX0 TrY0 TrZ0 Tpy0 Tpp0 j0

I assume that TrX, TrY and TrZ are translation parameters. Tpy, Tpp and j 
mean nothing to me. Is there maybe more documentation for PTO format 
somewhere? If not, how about we create 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/6a87102e-cbdf-4f78-baa3-dfd06b5d0c39n%40googlegroups.com.

[hugin-ptx] Re: is hugin_hdrmerge broken?

['kfj' via hugin and other free panoramic software]

Okay, now I understand, thanks for the clarification. Lux combines the 
remapping and HDR merging 'under the same roof', so the overexposedness can 
be detected in the pixel pipeline and does not need to be stored to an 
intermediate file. I had hoped to suggest hugin_hdrmerge as an alternative 
to lux users who found lux too 'automatic' for HDR merging, but I 
misunderstood what it does. So it's probably better to suggest software 
like align_image_stack to them, as an alternative to the use of "lux 
--hdr_merge=yes my.pto" which hdr-merges the images in a pto in one 
(automatic) go.
On Thursday, July 1, 2021 at 5:31:11 PM UTC+2 T. Modes wrote:

> kfj schrieb am Mittwoch, 30. Juni 2021 um 23:05:13 UTC+2:
>
>> I saw hugin produce such pgm files, and I could never figure out why they 
>> would be needed: the exr should have all the nececssary information, 
>> because it holds linear RGBA. What's the pgm good for?
>>
>
> In Hugins HDR workflow all input images are remapped to the output 
> projection. In the same time they are converted into the same linear 
> colorspace - it corrects the exposure, vignetting (and also white balance). 
> But then the information about under- and over exposed pixels is lost. This 
> information is transferred to hugin_hdrmerge with the _gray.pgm files and 
> helps to merge the individual images.
>
>

-- 
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/dce16931-f0cb-4265-a87d-6f24c58c9576n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear all!

I've made an intermediate release of lux with a few bug fixes and changes 
to the docu which have accrued during the past few weeks, during my 
'grooming' session, which will continue until the release of lux 1.1.0. The 
intermediate release has version lux_1.0.9a, downloadable binaries can be 
found in the Downloads section of the bitbucket repo:

https://bitbucket.org/kfj/pv/downloads/lux-1.0.9a-amd64.deb
https://bitbucket.org/kfj/pv/downloads/lux_1.0.9a_setup.exe
https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9a.zip

And the README in HTML format was also updated:

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

The windows installer has seen some work (thanks, Bernd!):

- it's less obtrusive, per default, lux is not launched after installation
- for several extensions, lux can now be chosen as target via the context 
menu
- SendTo can be used to invoke lux with a selection from the explorer

Kay
On Wednesday, June 23, 2021 at 11:14:22 AM UTC+2 kfj wrote:

> 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/24d84c5b-7f02-4212-a73b-280aee2c2880n%40googlegroups.com.

[hugin-ptx] Re: is hugin_hdrmerge broken?

['kfj' via hugin and other free panoramic software]

Thanks for the quick fix! I thought it would do the registration and 
photometric optimization of the input images (like align_image_stack), and 
then merge them to HDR (the man page is a bit thin). I converted my input 
to openEXR format, and now I found the next problem:

/usr/local/bin/hugin_hdrmerge -v -o hugin.exr ./IMG_308?.EXR

caught exception: Precondition violation!

File with original pixel weights (./IMG_3086_gray.pgm) is missing

(/home/kfj/src/hugin/src/hugin_base/vigra_ext/ReduceOpenEXR.h:72)

Abgebrochen (Speicherabzug geschrieben)

I saw hugin produce such pgm files, and I could never figure out why they 
would be needed: the exr should have all the nececssary information, 
because it holds linear RGBA. What's the pgm good for?

Kay

On Wednesday, June 30, 2021 at 5:36:36 PM UTC+2 T. Modes wrote:

> kfj schrieb am Mittwoch, 30. Juni 2021 um 11:39:05 UTC+2:
>
>> Am I doing something wrong or is hugin_hdrmerge broken? 
>>
>
> Hugin_hdrmerge is intended to merge linear exr files only - not for LDR 
> images. And for this use case it works.
> I added a better error message to make it clearly and prevent the crash.
>

-- 
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/45b22d6e-63d5-458b-b4b8-584d8894efean%40googlegroups.com.

[hugin-ptx] is hugin_hdrmerge broken?

['kfj' via hugin and other free panoramic software]

I'm trying to use hugin_hdrmerge on a bracket of three images, but I'm 
getting an error saying that the images are 'not an image file', and 
subsequently the program crashes:

hugin_hdrmerge -o hugin.exr IMG_308?.JPG  
   
caught exception: Cannot read image file "IMG_3086.JPG". File is not an 
image file. 

Abgebrochen (Speicherabzug geschrieben)

Am I doing something wrong or is hugin_hdrmerge broken? I tried an older 
build (some time last year) and one fresh from source as of today, with the 
same result - same for TIFF input.

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/7e70f108-b291-4577-8d41-ff3949873688n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear all!

I've just released lux 1.0.9. This version does not introduce much new 
functionality, the focus was more on usability and stability. I've uploaded 
a debian package and a windows bundle to the project's download page:

https://bitbucket.org/kfj/pv/downloads/lux-1.0.9-0git-Linux.deb
https://bitbucket.org/kfj/pv/downloads/lux_for_windows_1.0.9.zip

Hopefully, a mac bundle will be available soon.

Kay

On Tuesday, April 13, 2021 at 11:59:29 AM UTC+2 kfj wrote:

> Dear all!
>
> My viewer 'pv' has been renamed to 'lux', and it's seen a lot of 
> development recently. There are two important changes:
>
> - lux now builds with CMake, and readymade binaries are available for 
> download
>
> - lux can now do stitching and exposure fusion
>
> Special thanks go to Kornel for the work on the CMakeLists.txt, and to 
> Harry for providing code to make mac bundles and testing my exposure fusion 
> code, and I'd also like to thank all of you who have accompanied the 
> development process with helpful suggestions and bug reports.
>
> You can find bundles for mac OS and windows, and a simple debian package, 
> on the project's download page <https://bitbucket.org/kfj/pv/downloads/>. 
> There's also documentation 
> <https://bitbucket.org/kfj/pv/downloads/README.html> in HTML format, and 
> online on the project's bitbucket page <https://bitbucket.org/kfj/pv>.
>
> The binaries currently on offer are all version 1.0.8, which has seen a 
> good deal of testing and should be reasonably stable.
>
> 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/79f6491e-c2e3-464f-8603-e1a4691f5444n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear all!

My viewer 'pv' has been renamed to 'lux', and it's seen a lot of 
development recently. There are two important changes:

- lux now builds with CMake, and readymade binaries are available for 
download

- lux can now do stitching and exposure fusion

Special thanks go to Kornel for the work on the CMakeLists.txt, and to 
Harry for providing code to make mac bundles and testing my exposure fusion 
code, and I'd also like to thank all of you who have accompanied the 
development process with helpful suggestions and bug reports.

You can find bundles for mac OS and windows, and a simple debian package, 
on the project's download page <https://bitbucket.org/kfj/pv/downloads/>. 
There's also documentation 
<https://bitbucket.org/kfj/pv/downloads/README.html> in HTML format, and 
online on the project's bitbucket page <https://bitbucket.org/kfj/pv>.

The binaries currently on offer are all version 1.0.8, which has seen a 
good deal of testing and should be reasonably stable.

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/806b2699-e1bd-4df6-a67c-6fedf295627en%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear group!
I introduced HDR blending with pv some time back, and since that time I 
felt tempted to tackle both exposure fusion and image stitching as well. 
Hugin usually delegates these tasks to enfuse and enblend, and I have used 
both programs to good effect for a long time, so I was aiming at using 
similar techniques in pv. enfuse and enblend rely on multiresolution 
blending, as published by Peter J. Burt and Edward H. Adelson in their 
article 'A Multiresolution Spline With Application to Image Mosaics',  
which was used for exposure fusion by Tom Mertens, Jan Kautz and Frank Van 
Reeth, as described in their article 'Exposure Fusion'.
pv uses b-splines for interpolation, and it's use of image pyramids relies 
on a variant of image pyramids based on b-splines. This has proven 
effective for viewing images with pv for many years now, and it's also what 
I use for image pyramids in my implementation of the adapted 
multiresolution blending algorithm. This provides a fresh, modern 
implementation based on my library vspline, 
<https://bitbucket.org/kfj/vspline> which is fast because it is 
multithreaded and uses SIMD code.
I have pushed a prototype to the master branch of my pv repo 
<https://bitbucket.org/kfj/pv> which offers both exposure fusion and image 
stitching using this new code, so for now the code is Linux-only - if you 
feel adventurous, do your own merge to the msys2 or mac branches. To try it 
out, simply load a PTO containing a registered exposure bracket or a 
panorama into pv, select the ROI and press 'U' for an exposure fusion or 
'P' for a stitch. You may want to pass --snapshot_magnification=... on the 
command line to get larger output, other snapshot-related parameters should 
apply.
Consider this a 'sneak preview' - the code is, as of this writing, not yet 
highly optimized, but should be functional. The output is rendered in the 
background and may take some time to complete. Best work from the command 
line, where there is some feedback on the process. I'll tweak the code in 
the days to come, and I intend to provide a version with alpha channel 
processing as well. I'll post again once everything is 'production grade' 
and fully documented.
One large benefit of having these new capabilities in pv is that it does 
away with the need for intermediate images and external helper programs: 
the intermediates are produced and processed internally in RAM, so there is 
no disk traffic, and the internal intermediates have full single precision 
float resolution, which makes for good image quality. On the down side, due 
to the RAM-based intermediates, output size is limited.
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/b5684495-9bb9-4558-bc72-e3c4fb6d9b91n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear group!
I've decided to offer Windows binary packages of pv to interested users for 
evaluation. The software should work on all 64bit W10 systems, and may even 
run on older Windows versions. You should have at least a dual core system 
with AVX units, otherwise it won't be fun at all. Best is four cores and up 
with AVX2 or better SIMD units.
Just drop me a line off-list, and I'll send you a download link to a 'pv 
bundle' - a ZIP-compressed folder containing pv and all necessary DLLs and 
associated resources. This is 'stickware' and does not require 
installation, all you need to do is to unzip the folder, find 'pv.exe' (or 
plain 'pv' if you've opted to hide extensions in the explorer) and 
doubleclick on it - it will open a file select dialog and you can take it 
from there. Documentation is included (see README.html).
The download is via one of my private cloud accounts, that's why I don't 
want to publish a link here, which might be circulated widely and get me in 
bandwidth trouble with my service provider.
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/01920435-266a-426d-9f30-73aea4edf8c8n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

pv now supports 'standard long argument syntax'. So you can now pass long 
arguments like

  --option value

instead of pv's 'ini file style'

  --option=value

Cartola schrieb am Montag, 6. April 2020 um 15:56:47 UTC+2:

> Hi Kay, good job and one more option for us, thank you!
>
> My first impressions after building it on an Ubuntu 18.04: 
>
...
>
 
@cartola: sorry it took me so long to fix this. You seem to have lost 
interest in pv's development - after your initial reply I did not hear from 
you.

In fact this is the same for the very limited response I got on this 
mailing list so far. That's a bit sad: here I go spending years of 
development time to build a rock-solid feature-rich multiplatform panorama 
viewer, using cutting edge technology, and all I get from the 'vibrant' 
community is a measly few replies and no follow-up. Where is everybody? Is 
noone reading the mails on this ML anymore? 

Hope it helps to improve you very good job! Maybe Greg can port it to 
> FreeBSD! :)
>
 
Can Greg? I've managed to port pv to Windows and MacOS, so porting to BSD 
shouldn't be too hard. Again, where is everybody?

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/1952ae49-6e1e-410f-8522-00d4054d1827n%40googlegroups.com.

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

['kfj' via hugin and other free panoramic software]

Dear group!

A few weeks ago, a friend of mine managed a pv build on an intel mac using 
macports. He sent me a build log, and I have included the instructions in 
my bitbucket repo. So now pv can run on Linux, MS Windows and MacOS. The 
mac build is simple, it comes down to this:

   - sudo port install vigra -python38
   - sudo port install sfml
   - sudo port install exiv2
   - git clone https://bitbucket.org/kfj/pv
   - cd pv
   - git checkout mac
   - make

Mac users, please give it a shot, and report what you think!

Since pv has matured nicely and all major platforms are now supported, how 
about including it in the hugin or hugin-tools package? This would give 
hugin users immediate access to a panorama viewer which is the same across 
all platforms.

I'd also welcome packagers to produce standalone pv installers/installable 
packages. Where MS Windows is concerned, pv depends on MinGW/msys2, which 
is probably not very common, so I could provide an msys2-built binary and 
the necessary DLLs, if someone would want to build a windows installer but 
does not have an MinGW/msys2 environment.

Kay
kfj schrieb am Mittwoch, 8. April 2020 um 11:32:01 UTC+2:

> On 06.04.20 15:56, Carlos Eduardo G. Carvalho (Cartola) wrote:
> > 
> > -  Its performance is a little bit worse than Panini, which I usually 
> > use. The image flow is slower (my machine is an i7 from 2013 without an 
> > Nvidia)
>
> Three more things concerning performance:
>
> - per default, pv uses bilinear interpolation for moving images. If you 
> want to squash animation rendering times even further and do not mind 
> aliasing, you can use nearest neighbour interpolation for moving images 
> instead:
>
> --fast_interpolator_degree=0
>
> - per default, pv does it's internal calculations in linear RGB and 
> converts the result to sRGB before sending it to the GPU. This is 
> mathematically correct, but takes time. You can switch to processing in 
> sRGB, which is okay for simply viewing images, with this option:
>
> --process_linear=false
>
> - also per default, pv checks if the input image has an alpha channel. 
> If so, it tests if any pixels at all have transparency. If so, alpha 
> processing is switched on. Even if there is only a single pixel with an 
> alpha value of 254, this will trigger alpha processing, which also takes 
> time. You can force alpha processing off:
>
> --alpha=no
>
> I was surprised to find that some of my panoramas done with hugin had 
> pixels with transparency, even though I had used automatic cropping. 
> Seems the automatics don't exclude all pixels with a little transparency 
> (espacially in the corners). So keep this in mind.
>
> Performance comparisons are a dicey issue, a lot of stuff may go on 
> behind the scenes, and you may end up comparing apples and pears.
>
> I'd be surprised to see CPU-based rendering code which is significantly 
> faster than pv, as long as the mathematical operations are the same. 
> It's very highly optimized.
>
> 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/f2251959-7f8b-43e0-936d-a1182422e47fn%40googlegroups.com.

[hugin-ptx] viewing PTO files without stitching

['kfj' via hugin and other free panoramic software]

Hi group!

I've recently started this thread to point you to my image and panorama 
viewer:

https://groups.google.com/forum/#!topic/hugin-ptx/bj1g86oe6Wk

In my initial posting, I've already mentioned the topic of 'live stitching' 
- displaying a synoptic view of several registered source images *without 
stitching*. I've made good progress along these lines, and the latest 
version of pv can *directly read PTO files*. The file select dialog will 
show PTO files, and it's as simple as opening them like any other image 
file. On the command line, just pass a pto file like you'd pass an image 
file, like

pv pano.pto

pv will only process the source image information ('i-lines'). pv supports 
PTO geometry well: it will handle source images in rectilinear, cylindric, 
spherical, fisheye and stereographic format and honour the source images' 
orientation, horizontal field of view and all lens correction parameters. 
Photometric parameters are ignored except for Eev - pv expects sRGB or 
linear RGB images and does not handle colour profiles, nor does it do 
vignetting correction or camera response curve processing. Nevertheless, 
the display of a well-registered image set, especially with images taken 
with fixed aperture and exposure time, will be pretty close to the stitched 
result, especially with applied feathering.

'live stitches' have advantages and disadvantages, I'll start out with some 
advantages:


   - Access to the output is much more immediate, because the lengthy 
   stitching process is avoided. As long as your image set remains the same, 
   you can quickly reflect changes in the PTO file by simply pressing 'F1' in 
   pv, which will reload the PTO file and reuse the interpolators, which 
   otherwise take some time to set up. You can use pv as an 'external preview' 
   while working on the PTO in a stitcher like hugin, save work in the 
   stitcher and refresh pv to see the output straight away.
   - Interpolation is done directly on the source images. This preserves 
   the full source image quality and resolution - you can, e.g., zoom into the 
   view like into the source images, without being limited to the resolution 
   you chose for the output of stitching, and without the images having been 
   geometrically transformed and then stored before being read back in again, 
   losing some quality in the process. Same goes for exposure.
   - pv uses a geometric approach to select from which source image(s) a 
   target pixel should be taken. Without feathering or alpha processing, the 
   simple rule is: 'take from the source image whose center is closest to the 
   target pixel'. Seams are not explicitly defined but occur as an emergent 
   phenomenon. the 'closest-center' rule automatically chooses those parts of 
   the source images which are usually the best - technically speaking - 
   because they are least encumbered with lens flaws.
   - You can experiment easily with several target projections (use 
   --target_projection=...), again without having to stitch an output image. 
   If you set up pv's viewer window with the right aspect ratio and use a 
   snapshot magnification appropriate to your desired output size, making a 
   snapshot of what you see is equivalent to stitching with a stitcher. The 
   process is WYSIWYG, and output quality is defined by output size  and the 
   'quality interpolator' which is currently in use (per default, a cubic 
   b-spline). It's much faster than 'true' stitching. The rendition of a 
   snapshot is delegated to a separate thread 'on the back burner', so you can 
   keep on viewing while the snapshot(s) are completed in the background.
   

Now for some disadvantages:


   - 'live stitching' is memory-hungry. Every source image is read from 
   disk and converted to an internal representation (typically a set of two 
   float-based image pyramids). You can save on memory by passing 
   --build_pyramids=no, which will impose a few limits - for simply viewing 
   the PTO it's okay, though. But even then, more memory is needed than for 
   viewing a stitched panorama. 
   - There is - as of yet - no seam optimization. The seams occur where two 
   source images 'meet', and there is nothing you can do about it - 
   registration errors can be masked to a degree by using feathering, but 
   that's it.
   - Animation can be slow. When viewing single images/panoramas, pans, 
   zooms, etc. should not stutter on a reasonably powerful system. But with 
   'live stitching', frame rates drop. Especially when viewing views where 
   many source images contribute, and with target projections other than 
   rectilinear, frame rates may go down to a few per second.


This is a wide topic, so there are many more factors to consider, but I 
won't go on here. What I'd like to mention is a second 'blending mode' 
which pv offers. If you pass --blending=hdr, you can view registered 
exposure series as if they had already been blended into an HDR output. 
While

Re: [hugin-ptx] Python help needed

['kfj' via hugin and other free panoramic software]

On Tuesday, July 23, 2019 at 7:08:01 AM UTC+2, kfj wrote:
 

> I did the changes I mentioned above here and made a new patch - not sure 
> if the removal of the excutable flag shows in the diff, if not, just do 
> chmod a-x on offending files.
>

Sorry, one of my local changes leaked into the previous patch. here's the 
proper one. And yes, the mode changes did make it into the patch. 

>
> with regards
> 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/25ae73a0-6171-4fdb-a4a5-d2f8c3d35fb7%40googlegroups.com.
diff --git a/src/hugin_script_interface/plugins-dev/dual_use.py b/src/hugin_script_interface/plugins-dev/dual_use.py
--- a/src/hugin_script_interface/plugins-dev/dual_use.py
+++ b/src/hugin_script_interface/plugins-dev/dual_use.py
@@ -1,5 +1,3 @@
-#!/usr/bin/env python
-
 from __future__ import print_function
 
 gpl = r"""
@@ -23,8 +21,6 @@
 
 # @category Examples
 # @name Dual Use Plugin
-# @api-min  2011.1
-# @api-max  2012.0
 
 # dual_use will function as a hugin plugin and as a standalone
 # Python script.
diff --git a/src/hugin_script_interface/plugins-dev/plugin_skeleton.py b/src/hugin_script_interface/plugins-dev/plugin_skeleton.py
--- a/src/hugin_script_interface/plugins-dev/plugin_skeleton.py
+++ b/src/hugin_script_interface/plugins-dev/plugin_skeleton.py
@@ -1,5 +1,3 @@
-#!/usr/bin/env python
-
 # plugin_skeleton.py - a skeleton for a hugin plugin
 # Copyright (C) 2011  Kay F. Jahnke
 
@@ -18,8 +16,6 @@
 
 # @category Examples
 # @name Skeleton Plugin
-# @api-min  2011.1
-# @api-max  2012.0
 
 # we use modern type python print statements:
 
diff --git a/src/hugin_script_interface/plugins/crop_cp.py b/src/hugin_script_interface/plugins/crop_cp.py
deleted file mode 100755
--- a/src/hugin_script_interface/plugins/crop_cp.py
+++ /dev/null
@@ -1,337 +0,0 @@
-#!/usr/bin/env python
-
-from __future__ import print_function
-
-gpl = r"""
-crop_cp.py - remove CPs from parts of the panorama
-
-Copyright (C) 2011  Kay F. Jahnke
-
-This program is free software: you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation, either version 3 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program.  If not, see <http://www.gnu.org/licenses/>.
-"""
-
-# @category Control Points
-# @name Crop Control Points
-# @api-min  2011.1
-# @api-max  2015.1
-
-# crop_cps will function as a hugin plugin and as a standalone
-# Python script. It can also serve as a template for a slightly
-# more involved plugin than the ones in the Examples section.
-
-# Please note that this script tries to use wxPython. This should
-# work on Linux systems that have wxPython istalled, but as far as
-# I know currently it won't work on Windows, and certainly not on
-# Mac OS, where there is currently no hsi/hpi suport. If you want
-# to switch off the use of wxPython, set the default parameter in
-# the entry function to a value different from None, i.e. change
-# def entry ( pano , inside = None ) :
-# to
-# def entry ( pano , inside = False ) :
-
-import os
-import sys
-import hsi
-import math
-
-# we make an exception for run time errors in this script:
-
-class CropCpError ( Exception ) :
-
-def __init__ ( self , text ) :
-self.text = text
-
-def __str__ ( self ) :
-return self.text
-
-# some global variables to reduce overhead - we just reuse the same
-# FDiff2D objects every time we call the transforms
-
-transform_in = hsi.FDiff2D(0,0)
-transform_out = hsi.FDiff2D(0,0)
-
-# transform point coordinates using panotools transforms
-# and the global variables for source and target
-
-class to_pano :
-
-def __init__ ( self , pano , image ) :
-
-pano_options = pano.getOptions()
-img = pano.getImage ( image )
-w = img.getWidth()
-h = img.getHeight()
-self.wh = w / 2.0
-self.hh = h / 2.0
-
-# image to pano
-
-self.tf = hsi.Transform()
-self.tf.createInvTransform ( img , pano_options )
-
-def transform ( self , p ) :
-
-# pixel coordinates come in, but have 

Re: [hugin-ptx] Python help needed

['kfj' via hugin and other free panoramic software]

xamples
 # @name Skeleton Plugin
-# @api-min  2011.1
-# @api-max  2012.0
 
 # we use modern type python print statements:
 
diff --git a/src/hugin_script_interface/plugins/crop_cp.py b/src/hugin_script_interface/plugins/crop_cp.py
deleted file mode 100755
--- a/src/hugin_script_interface/plugins/crop_cp.py
+++ /dev/null
@@ -1,337 +0,0 @@
-#!/usr/bin/env python
-
-from __future__ import print_function
-
-gpl = r"""
-crop_cp.py - remove CPs from parts of the panorama
-
-Copyright (C) 2011  Kay F. Jahnke
-
-This program is free software: you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation, either version 3 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program.  If not, see <http://www.gnu.org/licenses/>.
-"""
-
-# @category Control Points
-# @name Crop Control Points
-# @api-min  2011.1
-# @api-max  2015.1
-
-# crop_cps will function as a hugin plugin and as a standalone
-# Python script. It can also serve as a template for a slightly
-# more involved plugin than the ones in the Examples section.
-
-# Please note that this script tries to use wxPython. This should
-# work on Linux systems that have wxPython istalled, but as far as
-# I know currently it won't work on Windows, and certainly not on
-# Mac OS, where there is currently no hsi/hpi suport. If you want
-# to switch off the use of wxPython, set the default parameter in
-# the entry function to a value different from None, i.e. change
-# def entry ( pano , inside = None ) :
-# to
-# def entry ( pano , inside = False ) :
-
-import os
-import sys
-import hsi
-import math
-
-# we make an exception for run time errors in this script:
-
-class CropCpError ( Exception ) :
-
-def __init__ ( self , text ) :
-self.text = text
-
-def __str__ ( self ) :
-return self.text
-
-# some global variables to reduce overhead - we just reuse the same
-# FDiff2D objects every time we call the transforms
-
-transform_in = hsi.FDiff2D(0,0)
-transform_out = hsi.FDiff2D(0,0)
-
-# transform point coordinates using panotools transforms
-# and the global variables for source and target
-
-class to_pano :
-
-def __init__ ( self , pano , image ) :
-
-pano_options = pano.getOptions()
-img = pano.getImage ( image )
-w = img.getWidth()
-h = img.getHeight()
-self.wh = w / 2.0
-self.hh = h / 2.0
-
-# image to pano
-
-self.tf = hsi.Transform()
-self.tf.createInvTransform ( img , pano_options )
-
-def transform ( self , p ) :
-
-# pixel coordinates come in, but have to use center-origin
-
-transform_in.x = p[0] - self.wh
-transform_in.y = p[1] - self.hh
-
-if self.tf.transform ( transform_out , transform_in ) :
-return ( transform_out.x , transform_out.y )
-
-# KFJ 2011-06-19 I've noticed the transform failing
-# with images that have X, Y or Z values different from 0.
-# I'm not sure if this is a bug in the transform.
-
-print ( 'transform failed for %s' % str ( p ) )
-return None
-
-# the crop_cps routine is the workhorse of this script. It does the
-# actual work of looking at the CPs and removing the unwanted ones.
-
-def crop_cps ( pano , inside ) :
-
-pano_options = pano.getOptions()
-
-size = pano_options.getSize()
-
-# we need these offsets because pano coordinates are center-origin
-
-wh = size.width() / 2.0
-hh = size.height() / 2.0
-
-# that's the ROI of the panorama, in corner-origin
-
-roi = pano_options.getROI()
-
-# out limits, now in center-origin
-
-left = roi.left() - wh
-right = roi.right() - wh
-top = roi.top() - hh
-bottom = roi.bottom() - hh
-
-ni = pano.getNrOfImages()
-tflist = []
-
-# we get a list of CPs in pano coordinates. Note that the pano
-# coordinates are taken from the coordinates in the left image only.
-
-for img in range ( ni ) :
-tflist.append ( to_pano ( pano , img ) )
-
-# we take the CPVector:
-
-cpv = pano.getCtrlPoints()
-print ( 'found %d CPs' % len ( cpv ) )
-
-# We want to put the remaining CPs into this CPVector:
-
-ncpv = hsi.CPVector()
-
-for cp in cpv :
-p = ( cp.x1 , cp.y1 )
-img = cp.image1Nr
-tfp = tflist[img].transform ( p )
-# KFJ 2011-06-17 If the transform fails, keep the CP
-# - best to be defensi

Re: [hugin-ptx] Python help needed

['kfj' via hugin and other free panoramic software]

On Saturday, July 20, 2019 at 1:13:09 AM UTC+2, Tduell wrote:
>
> On Fri, 19 Jul 2019 18:40:22 +1000, 'kfj' via hugin and other free   
> panoramic software > wrote: 
>
> [snip] 
>
> > When it comes to picking only python3, I'm not sure how to do that, but 
> > I'll try and look into the matter eventually (busy with other stuff 
> now). 
> > Can we postpone this to some later time, or can someone else do that 
> bit? 
>
> There is a bug report related to this issue, (   
> https://bugs.launchpad.net/bugs/1829309)  in which I have provided a   
> patch, which works here for me, but for some reason I was unable to push   
> to the repo. I had hoped another with admin privileges would push it but   
> that doesn't seem to have happened. 
> Have a look at that patch, and the source, and see if you think it is an   
> adequate fix. 
>

I checked some more, and came to the conclusion that the 'shebang line' ,' 
#! /usr/bin/env python' in the plugins is irrelevant when they are launched 
as plugins by hugin. Hugin, with the python interface linked in, *is* a 
python interpreter, and it's either python2 or python3, depending on what 
cmake figures out for it. The shebang, is only relevant when the plugin is 
executed as a stand-alone script: Some of the plugins (like woa.py) are 
programs in their own right, and the #! /usr/bin/env python tells the shell 
to launch 'python' to interpret the script. So no matter what the shebang 
is, when used as plugins from hugin, the shebang has no effect. There is no 
need to make any change to the plugin code.

I think forcing the linking-in of a python3 interpreter should be handled 
by cmake. On my system, for example (I mistyped, I'm on ubuntu 18.04 LTS), 
when I build hugin as per instructions in the wiki, it comes out a python2 
interpreter. There's docu I found here

https://cmake.org/cmake/help/git-stage/module/FindPython3.html

Does that help?

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/255d0a2a-8de5-4148-8509-16a7634d1a1b%40googlegroups.com.

Re: [hugin-ptx] Python help needed

['kfj' via hugin and other free panoramic software]

On Saturday, July 20, 2019 at 1:13:09 AM UTC+2, Tduell wrote:
>
> On Fri, 19 Jul 2019 18:40:22 +1000, 'kfj' via hugin and other free   
> panoramic software > wrote: 
>
> [snip] 
>
> > When it comes to picking only python3, I'm not sure how to do that, but 
> > I'll try and look into the matter eventually (busy with other stuff 
> now). 
> > Can we postpone this to some later time, or can someone else do that 
> bit? 
>
> There is a bug report related to this issue, (   
> https://bugs.launchpad.net/bugs/1829309)  in which I have provided a   
> patch, which works here for me, but for some reason I was unable to push   
> to the repo. I had hoped another with admin privileges would push it but   
> that doesn't seem to have happened. 
>

I don't have admin privileges either, and won't ever have because I won't 
do sourceforge.

Have a look at that patch, and the source, and see if you think it is an   
> adequate fix.
>

It seems to do what it's supposed to do - it builds and works okay on my 
system (ubuntu 16.04 LTS), but I have both python2 and python3 on this 
machine. How about older systems which only have python2? Wouldn't trying 
to force python3 on such machines fail, because they simply don't have 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/5e0051f6-bacf-4860-95fd-d89663ed1673%40googlegroups.com.

Re: [hugin-ptx] Python help needed

['kfj' via hugin and other free panoramic software]

On Thursday, July 18, 2019 at 9:57:35 PM UTC+2, Bruno Postle wrote:
>
> Great, can you do a patch to remove the api-max check, and force python3 
> throughout?
>

I don't know (yet) how to remove the api checking code. But that's not a 
problem: the api-check entries in the plugins are not mandatory. If they 
are simply removed from the plugins, the plugins will try to run with 
whatever API hugin offers, and simply fail to function if the API is not 
right. So the quickest way to disable the API check is simply to remove 
these two lines from all plugins:

# @api-min  2014.0
# @api-max  1029.0

If, on the hugin side, somone feels that the code to do the API check is in 
their way, they would be free to remove it. That's an area of the code I am 
not familiar with - I may look into it if I find the time. But then, if the 
plugin thing should ever become popular, maybe having the *option* to limit 
plugins to a certain API subset is nice to have. I'd say leave the code in, 
just remove the checks from the plugins.

I also propose to remove the plugin 
src/hugin_script_interface/plugins/crop_cp.py: the CP tool in the openGL 
viewer is better, and the plugin tries to use wxPython, which produces 
added complications. Best to get rid of it.

I think those changes are simple enough to do by someone who has repo write 
access, but if you'd like a patch I can probably put one together.

When it comes to picking only python3, I'm not sure how to do that, but 
I'll try and look into the matter eventually (busy with other stuff now). 
Can we postpone this to some later time, or can someone else do that bit?

Hope that helps
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/31ac5394-2fc9-4402-b1f0-7dcdbc434dca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Python help needed

['kfj' via hugin and other free panoramic software]

On Friday, May 17, 2019 at 11:49:01 PM UTC+2, Bruno Postle wrote:
>
>
>
> On 17 May 2019 22:14:09 BST, Harry van der Wolf wrote: 
> > 
> >But I agree with Bruno: Some volunteer should fix it, or it should be 
> >removed. 
>
> Thanks, I'm sure I could fix it too, but if nobody actually wants the 
> python interface, there is no point maintaining it. All we need is somebody 
> who values it to step up and demonstrate that it is valued. 
>

Sorry, I'm a bit late noticing this thread. 

Okay, here I am standing up for the python interface. I regularly use the 
woa script. But I got frustrated by the disappearance of the python 
interface with every new release because nobody thought of adapting the 
api-max values in the scripts. These api-min and api-max values were Yuv's 
idea, and have consistently led to making the python interface unusable 
with every new release; for some time I sent bug notifications but grew 
tired of it - instead I just adapted my local repo clone. Since the last 
update to the api-max values seems to have happened in 2017, I suppose 
noone apart from me misses the python interface, but there's no need to 
deliberately cripple it by wrong api-max values. The python interface 
adapts automatically to new hugin versions (because SWIG looks at hugin's 
source code), and the worst thing that can happen is that some old python 
script doesn't work anymore because it tries to use an old API - as far as 
I remember this has happened only once since I wrote the python interface, 
and ll other failures were due to wrong api-max values.

So I propose to remove the API check, I think it's useless.

Kay

>
> -- 
> Bruno 
>

-- 
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/d97ad209-f267-4558-affe-b09a62891cbf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] misleading field of view values in Exif.Photo.UserComment

['kfj' via hugin and other free panoramic software]

Hi group!

While fitting my panorama viewer with automatic metadata detection (using 
libexiv2) I noticed a problem: Hugin provides the UserComment Exif tag.This 
tag gives two field of view angles: the horizontal and the vertical. These 
are taken from the values which can be set in the openGL preview. The image 
which is written to disk in the final output is not this whole view, but 
the cropped section. The cropped section is often smaller than the whole 
screen shown by the openGL preview. In such cases, the values in the 
UserComment field are misleading. What's missing is the information about 
the cropping rectangle.

I noticed this when - naively - using the fov values in the UserComment 
field when displaying cropped stripe panoramas. This came out - at times 
grossly - wrong, and I finally figured out that the fov values in the 
UserComment are perfectly irrelevant for a panorama viewer if cropping is 
present but it's extent is unknown.

For spherical images, I can fall back on the GPano information, which 
supplies all the necessary information, but for other projections, where 
there is no GPano information, there is no way to figure out the image 
metrics to display such images correctly in a panorama viewer. To mend the 
situation, I'd recommend to extend the output to the UserComment Exif tag. 
Whats needed on top of the two field of view values are three 2D values, 
given in pixel coordinates:


   - size of the uncropped view (to which the field of view data pertain)
   - upper left and lower right corner of the cropped area


This is the same information that is displayed in the stitcher tab 
(panorama size and cropping information); it' also in the PTO file, like 
here:

p f2 w6000 h1682 v306  E10.8957 R0 S2520,3699,456,1249 n"TIFF_m c:LZW 
r:CROP"

where

w: width
h: height
v: hfov
S: crop

For sphericals, the values given by the GPano metadata are just that:

Cropped Area Image Height Pixels: 793
Cropped Area Image Width Pixels : 1179
Cropped Area Left Pixels: 3049
Cropped Area Top Pixels : 1379
Full Pano Height Pixels : 3529
Full Pano Width Pixels  : 7058

The equivalence isn't immediately obvious; for the the cropped area it's

1249 - 456 = 793
3699 - 2520 = 1179

The 'full size' in the GPano data refers to a full spherical, whereas in 
PTO, it refers to the chosen fov (306 degrees in this example), so we have

3000 * 360 / 306 = 3529
6000 * 360 / 306 = 7059

And the GPano crop area left and top values are relative to the full 
spherical as well (calculations omitted)

The GPano format isn't usable for some projections: a 'full' cylindrical 
(360X180), for example, has infinite vertical extent, so it would be 
impossible to give a 'Full Pano Height' value. The hugin way of using the 
uncropped view's hfov and vfov as a reference, and the crop on top, makes 
PTO format suitable to describe sections of cylindricals etc. correctly, so 
I think the PTO convention should be followed when extending the user 
comment. By appending the full extent and crop information after the Ev 
information, software looking merely at the fov data would not fail, but 
software relying on cropping information could pick up the data and reject 
input missing the crop information or request further user input. So for 
the example used above, I'd propose this UserComment:

charset="Ascii" 
Projection: Equirectangular (2)
FOV: 306 x 86
Ev: 10,90
Extent: 6000,1682
Crop: 2520,3699,456,1249

This has all the information that's needed and works for all projections 
(like PTO). It's merely copying the relevant values from the PTO, so the 
data are at hand already, it's just a matter of conveying them into the 
UserComment exif tag, and the extension of the exif tag would not break 
older software inspecting the tag's content. What do you say?

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/b315aa37-6f2c-4cfc-83af-71f2c2ec4897%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] pv, a new free linux panorama viewer

['kfj' via hugin and other free panoramic software]

Dear all!

Today I have published the source code for 'pv', a new, free panorama 
viewer. Currently this software is available for linux only. This is 
totally new software written from scratch, using interpolation code from 
'vspline', a uniform B-spline processing library which I have also 
published today. The software is beta stage and so far it's only been 
tested on my own systems, but I hope it will turn out usable on a wide 
range of machines. You will need to compile it yourselves if you want to 
try it out, it does have a few dependencies which are easily satisfied if 
you're using ubuntu 17.04 and otherwise may require building some libraries 
from source as well, namely vigra, SFML, and, optionally Vc.

The code is available from these two git repositories hosted with bitbucket:

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

In the repositories you'll find the source code and documentation 
describing the software, so just have a look and see what's on offer!

Let me just hint at a fewt interesting features:

- the code is fully multithreaded
- it optionally uses the CPU's vector units
- it supports spherical, cylindric, fisheye, stereographic and rectilinear 
panoramas
- Interpolation is done using arbitrary-degree uniform B-splines

I hope you won't mind me announcing this on hugin-ptx - after all this 
software does not use PanoTools at all and is only connected to hugin 
insofar as it processes panoramas made with hugin. Please let me know what 
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/ade59d52-94ce-4776-8c8e-a4f78479a450%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] banding in hugin_hdrmerge output

['kfj' via hugin and other free panoramic software]

Hi group!

When going through some old panoramas I had rendered as HDR in openEXR, I 
tried to recreate these images. But the output wasn't as before; I noticed 
ugly banding where there were smooth transitions in the sky before. So I 
went to investigate. Looking at the intermediate stages I noticed the 
single merged HDR stack images already had the flaw, so I concluded that 
hugin_hdrmerge might cause the problem. In the relevant bit of code which 
hugin_hdrmerge uses, namely

hugin/src/hugin_base/vigra_ext/HDRUtils.h, lines 70ff,

the function to HDR-merge pixels (ReduceToHDRFunctor) had the gaussian 
weight function commented out and instead, after a comment reading

'simple triangular function should also work ok'

there was other code instead. I activated the use of the gaussian weighting 
function and this removed the problem, now my output is corrrect again. I'd 
recommend using the gaussian weighting in favour of the other code.

Since it's just a matter of commenting out a line and uncommenting another, 
I refrain from filing a bug, sending a patch etc., but I wonder why noone 
has stumbled upon this before. Maybe openEXR output isn't used much... and 
of course there is the possibility that my system has peculiarities 
producing a bug where other environments don't, so I'd like to hear if 
anyone else has had problems with hugin_hdrmerge.

with regards

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/6fbfcf41-3745-43bc-a056-945e353dd987%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: improved philopod technique for handheld panorama shooting

['kfj' via hugin and other free panoramic software]

Am Samstag, 23. August 2014 15:43:43 UTC+2 schrieb Cartola:
>
> I totally agree with Kay.
>
> When I have first tested philopod some years ago I didn't like it and 
> abandoned it. A few time ago I have rediscovered it and maybe finally used 
> it correctly. I am using it all time now (many examples in my weekly 
> publishings <http://cartola.org/360/>). It's lighter, shooting is faster, 
> call less attention, mainly in "forbidden places" like museums and others 
> where they tend to complain about tripods, and stitching is also much 
> faster, with nadir already ok in the first step.
>
> This video shows a good technique to take advantage of the philopod 
> <https://www.youtube.com/watch?v=ouOEM4cKKGc>.
>
 
The video shows the 'classic' philopod technique. Notice how, in the first 
example, the camera is tilted slightly up/down. If the philopod were 
positioned precisely (weight over ground target), tilting the camera down 
means moving the NPP further forward than it should be, and tilting it up 
moves it further back. Using my loop-and-brace technique avoids the 
problem; the brace will keep the loop precisely in-plane with the NPP at 
all times. Florian's second example shows him doing zenith and nadir shots 
by 'rule of thumb'. This works all right, but with the loop and brace 
technique, you don't do zenith and nadir shots vertically up or down, but, 
still guided by the philopd, tilted very far up and very far down. Again 
the brace takes care of keeping the loop in-plane with the NPP, only the 
sky shot is a bit awkward since the camera body gets in the way of the loop 
if the brace isn't very big, but the zenith is usually less problematic 
than the nadir, since most of the content there is quite far away and 
parallax isn't a problem. For the nadir shot, I position the camera with 
the philopd and then gently swing it out of the way with one hand when I 
take the shot - that way I don't have the string and weight in the picture.

I am particularly pleased with the good performance around the nadir. I 
routinely use my GPS unit, oriented to magnetic north, as my ground target. 
When I stitch the panorama, all I need to do to orient it is to center on 
the nadir, drag the GPS unit's image to the center, and rotate until the 
GPS unit shows upright. With this simple operation I get a perfectly level 
horizon and I don't have to bother myself with orienting the panorama some 
other way - I can upload straight to 360cities.

>
> Zeiljko Soletic <http://www.360cities.net/profile/gospar2> inspired me to 
> retry the technique. Watching his panoramas (almost all with philopod) I 
> gave it another try. For example, in a trip to France he shot more than 500 
> panoramas with philopod (he mentioned that at facebook).
>

Almost all my recent ones are done with a philopod as well:

https://www.360cities.net/profile/kfj 

>
> Tripod or pole now only for specific situations, like when long 
> expositions are necessary or a higher point of view (pole). I have a drone 
> for even higher shooting :)
>

Cool! I thought about geting into drones myself. I suppose it's fun 
programming the thing to do it's little dance around the NPP ;)
I found that the philopod isn't precise enough to do man-made stuff, since 
in straight lines, you can see even single-pixel errors. But for 
landscapes, it's all I need. I make sure that the horizon +/- 30° stitches 
correctly and leave the covering up of the ground and sky errors to the 
blender - that's why you usually see the image of my GPS unit 'torn in 
half' when you look at the nadir of my images.

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/7878b779-e499-41b7-8239-3619f267ab4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: improved philopod technique for handheld panorama shooting

['kfj' via hugin and other free panoramic software]

Am Sonntag, 4. August 2013 13:14:52 UTC+2 schrieb John Eklund:

the philopod is only for the desperate.


I disagree. I've come to like the method very much, and I'm happy with my 
results. I only realized how good the technique is once I had learned it, 
and now I'm using itall the time.
 

> Like the Swiss army knife, its main feature is that you should always 
> carry it on you.


My improved (loop, weight and brace) philopod weighs 31.7g, including it's 
box. Considering my backpack weighs in at about 20kg, this isn't much. 
Beats my tripod, anyway. And I stopped taking my swiss army knife (75.1g) 
in favour of a small Opinel (36.5g). So for the weight of a swiss army 
knife, I now have a knife and a philopod :)

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/604479a1-5223-4eaf-9239-9a87e7aced96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: how I shot myself in the foot with panoramas from stacks

['kfj' via hugin and other free panoramic software]

On Friday, May 9, 2014 7:40:24 PM UTC+2, JohnPW wrote:
>
>
>
> Did you ever figure out how to unlink the stacks?
> This new,easier and more intuitive interface is nearly unusable for me.
>

If you use my script, standalone, it will unkink as well:

... The standalone version will accept
# an optional second parameter to set a bracket size other than 3.
# This is also useful for removing stacks from a project: call
# make_stacks with images_per_stack = 1 

from hugin, use:

in images tab, select images
right click on selection
stacks
stack size
1

I'm sure if you had learnt the new interface first and then been presented 
with the old one instead, you'd be twice as upset ;-)
It takes a little getting used to and I had the odd WTF?! moment, but once 
I got the hang of it it turned out quite well-thought-out and usable. I'm 
not sure, though, if I would find my way if I didn't have a very precise 
idea of what I can do in hugin and what I can't. And the assistant isn't 
getting good press at all - c't Magazin gave it a really bad note when it 
tested panorama stitchers in it's last edition...

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/e12fd545-6f1e-4fb9-9372-2e3af4cb2cdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] How to stitch a pano with very light windows and dark corners?

['kfj' via hugin and other free panoramic software]

On Wednesday, May 7, 2014 12:25:40 PM UTC+2, Brandan wrote:
>
> I have been playing around and the second one is my best so far, but far 
> from perfect.
> In the second one I had hugin output the blended layers of similar 
> exposure, I then made another project and took the different layers and 
> stitched them together. A person can now see out the front windows, the 
> floor looks great(though there is now an alignment problem, no idea why), 
> The side windows look a little worse, but is livable. The kitchen is a 
> little bit lighter.
>

In my experience, fusing the stacks first and blending the fused stacks 
after works best. You may want to fine-tune the enfuse options, 
specifically exposure-mu and exposure-sigma - I think in newer versions 
it's now called exposure-optimum and exposure-width.

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/73d60892-1baa-4dc2-aa6c-74084a701468%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] hugin: cmake writes build files to hg directory instead of build directory

[kfj]

On Thursday, April 24, 2014 7:09:12 PM UTC+2, kornel wrote:
>
> Am Donnerstag, 24. April 2014 um 10:00:57, schrieb kfj 
> <_k...@yahoo.com> 
>
> > Hi all! 
> > 
> > Just built the latest version (Pre-Release 2014.1.0.cb1ab46b18cd) to see 
> if 
> > it works fine with the new libpano release 2.9.19, and it does here 
> > (Kubuntu 14.04, Kernel 3.13.0-24-generic x86_64). I noticed something 
> > strange, though: As usual, I wanted to do an out-of-source build. When I 
> > had run cmake from my build directory, though, it told me it had written 
> > the build files to my hg directory instead. I could build there, but 
> it's 
> > not nice, I prefer an out-of-source build. Maybe there's a glitch in the 
> > cmake files? 
>
> I don't have such problems. 
> Maybe there are some leftover files from previous cmake call form the 
> source. 
>

Oops... must have been something like that. Did a fresh clone and now all 
went as expected. Sorry for the noise

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/753db3d2-bd22-4a2a-ae1a-9d583f423138%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] hugin: cmake writes build files to hg directory instead of build directory

[kfj]

Hi all!

Just built the latest version (Pre-Release 2014.1.0.cb1ab46b18cd) to see if 
it works fine with the new libpano release 2.9.19, and it does here 
(Kubuntu 14.04, Kernel 3.13.0-24-generic x86_64). I noticed something 
strange, though: As usual, I wanted to do an out-of-source build. When I 
had run cmake from my build directory, though, it told me it had written 
the build files to my hg directory instead. I could build there, but it's 
not nice, I prefer an out-of-source build. Maybe there's a glitch in the 
cmake files?

 ~/src/hugin/hugin.build$  cmake ../hugin.hg -DENABLE_LAPACK=YES 
-DCPACK_BINARY_DEB:BOOL=ON -DCPACK_BINARY_NSIS:BOOL=OFF
-DCPACK_BINARY_RPM:BOOL=OFF -DCPACK_BINARY_STGZ:BOOL=OFF 
-DCPACK_BINARY_TBZ2:BOOL=OFF-DCPACK_BINARY_TGZ:BOOL=OFF 
-DCPACK_BINARY_TZ:BOOL=OFF -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0
...
-- Current source dir = /home/kfj/src/hugin/hugin.hg
-- Configuring done
-- Generating done
-- Build files have been written to: /home/kfj/src/hugin/hugin.hg

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/de6edab3-44a6-4eef-8716-4097259127ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: cant' stitch exr images

[kfj]

On Tuesday, April 22, 2014 1:27:38 PM UTC+2, kfj wrote:
>
> ...
>
 

> enblend: an exception occured
> enblend: 
> Precondition violation!
> exportImage(): file format does not support requested number of bands 
> (color channels)
> (/usr/local/include/vigra/impex.hxx:547)
>
> has anyone seen this error and maybe found a fix?
>

I think it's definitely enblend. I rebuilt everything from scratch with a 
fresh checkout, which put me at

enblend 4.2-71d42086623e

and the problem remains, the final exr output can't be produced. I reverted 
to the enblend from the distro's package, and that works okay. That is:

enblend 4.1.2

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/adcb3ed2-ccf4-4f5b-813e-63f9070155c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] cant' stitch exr images

[kfj]

Hi all!

I've recently moved to Kubuntu 14.04 64bit. I'm not sure if that's the 
cause of my problem, but currently I can't stitch exr images. Everything 
runs just fine, but in the last step enblend fails to write the final 
output, here's an example log file:

nona  -r hdr -m EXR_m -o IMG_8800_IMG_8817_hdr_ -i 0 /tmp/huginpto_aiK4HX
nona  -r hdr -m EXR_m -o IMG_8800_IMG_8817_hdr_ -i 1 /tmp/huginpto_aiK4HX
nona  -r hdr -m EXR_m -o IMG_8800_IMG_8817_hdr_ -i 2 /tmp/huginpto_aiK4HX
hugin_hdrmerge  -o IMG_8800_IMG_8817_stack_hdr_.exr -- 
IMG_8800_IMG_8817_hdr_.exr IMG_8800_IMG_8817_hdr_0001.exr 
IMG_8800_IMG_8817_hdr_0002.exr
nona  -r hdr -m EXR_m -o IMG_8800_IMG_8817_hdr_ -i 3 /tmp/huginpto_aiK4HX
nona  -r hdr -m EXR_m -o IMG_8800_IMG_8817_hdr_ -i 4 /tmp/huginpto_aiK4HX
nona  -r hdr -m EXR_m -o IMG_8800_IMG_8817_hdr_ -i 5 /tmp/huginpto_aiK4HX
hugin_hdrmerge  -o IMG_8800_IMG_8817_stack_hdr_0001.exr -- 
IMG_8800_IMG_8817_hdr_0003.exr IMG_8800_IMG_8817_hdr_0004.exr 
IMG_8800_IMG_8817_hdr_0005.exr
enblend  -f844x756+40+168 -o IMG_8800_IMG_8817_hdr.exr -- 
IMG_8800_IMG_8817_stack_hdr_.exr IMG_8800_IMG_8817_stack_hdr_0001.exr 
enblend: warning: no usable resolution found in first image 
"IMG_8800_IMG_8817_stack_hdr_.exr";
enblend: warning:   will use 300 dpi
enblend: info: loading next image: IMG_8800_IMG_8817_stack_hdr_.exr 1/1
enblend: info: loading next image: IMG_8800_IMG_8817_stack_hdr_0001.exr 1/1
enblend: info: writing final output

enblend: an exception occured
enblend: 
Precondition violation!
exportImage(): file format does not support requested number of bands 
(color channels)
(/usr/local/include/vigra/impex.hxx:547)

enblend: info: remove invalid output image "IMG_8800_IMG_8817_hdr.exr"
enblend: warning: could not remove invalid output image 
"IMG_8800_IMG_8817_hdr.exr": No such file or directory
make: *** [IMG_8800_IMG_8817_hdr.exr] Fehler 1

has anyone seen this error and maybe found a fix? The intermediate exr 
files look just fine to me. Here's my system and hugin info:

enblend: enblend 4.2-7bcf8a1e6b3d
vigra freshly built from default branch 

Hugin Version: Pre-Release 2013.1.0.f5364a60c3b2

System information
===
Operating system: GNU/Linux
Release: 3.13.0-24-generic
Kernel version: #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014
Machine: x86_64
...


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/e0f21908-3bda-4bcd-966c-0aead261bdeb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: How to use "Crop Control Points"?

[kfj]

On Friday, March 28, 2014 2:11:02 PM UTC+1, Cartola wrote:
>
> Thanks Kay! I didn't know none of this two options and I will probably use 
> them both!
>
> I've tested removing from masks here. Does it remove from all existent 
> masks? At least it considers that inside an "include" mask it shouldn't 
> remove?
>
> I can test it later also, but as I'm at work now it was easier to ask :)
>
> I don't actually know - I always used my plugin. Maybe I should learn 
something new ;-)

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/3177cd8d-0e15-40cf-aa88-69602733f8c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: How to use "Crop Control Points"?

[kfj]

On Thursday, March 27, 2014 1:25:24 PM UTC+1, Cartola wrote:
>
> Hi,
>
> I've never used the "Crop Control Points" plugin under Actions menu. How 
> can it be used? I tried here but didn't discover how it works.
>
> This plugin is functional, but in order for it to function you have to 
have wxpython installed (otherwise it will forever return -11 and do 
nothing). On my system, wxpython is installed by selecting the packet 
'python-wxtools'. 

If you have wxpython installed, after invoking the plugin, it will present 
you with a dialog box asking whether you want to remove control points 
inside the ROI or outside (ROI = region of interest, the area of the pano 
you have set your crop window on). I use this plugin mainly to remove CPs 
outside the ROI. My typical use case is, in the openGL preview, to set a 
cropping rectangle from a bit below the horizon to just above the mountain 
tops and then remove all CPs outside this area - when I optimize 
afterwards, the fit is good in the areas which are most visible in a pano 
and errors are forced to boring areas like the floor or easy-to-blend areas 
like the sky.

The 'remove CPs from masks' menu point is kind of similar and can be used 
for the same effect; it's even better insofar as the mask can take any 
shape whereas the 'crop CPs' plugin only works with the (rectangular) ROI. 
But back when I wrote the plugin, I think this menu point wasn't there yet. 
I wrote this plugin originally to demonstrate two things:

- it might be nice to pass other stuff to a plugin than just the Panorama 
data structure
- wxpython calls can be used from a plugin to get additional user input

The first point was made but noone ever cared to consider passing 
additional parameters. The second point, if I remember rightly, turned out 
problematic since it did not work on all platforms. The plugin is still 
there, more as a demonstartion of what can be done than as a really 
productive item.

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/01195ffc-02b9-4f08-b4ab-35486333c594%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Can I automatically improve stitching?

[kfj]

On Wednesday, March 19, 2014 8:04:22 AM UTC+1, Pawel Rozenek wrote:
>
> Hi Panoramers :)
>
> Quite often stitching pictures in Hugin gives e a result like here:
> http://www.rozenek.com/images/forum/hugin-problem.jpg
>
> It is NOT a problem with my bracket, because I designed a special bracket 
> just for my camera:
>
> http://www.rozenek.com/a-new-version-of-the-panoramic-bracket-for-my-camera/
>
> so I have got a perfect nodal point.
>

Let me point out that the center of gravity shifts when the camera is 
tilted up or down, and with a pano head like the one you are using this 
can't be totally avoided - ideally you'd have to readjust the setup for 
each level of tilt to compensate for the minute differences due to tilting 
- no matter how hard you try, your pano head plus tripod will always be 
slightly elastic.

The comment about there being no true NPP with a fisheye lens is also true, 
and you can only try and avoid the issue as best as possible by using a 
shooting pattern where the overlap areas are at a similar distance from the 
image center - try a pattern of twelve, like looking at a a dodecahedron's 
faces from it's center.

When it comes to having lots of good control points to get a better result, 
have you tried woa?

Kay

  

>
> Of course I can add a few control points by hand but it is annoying :)
>
> Is any chance to change any Hugin settings to improve stitching even if it 
> takes more time?
>
> Thank you for answers :)
>

-- 
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/deb36bdf-4f47-4488-ab92-f5f6d0843627%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: Handling of overexposures

[kfj]

On Monday, March 24, 2014 10:06:44 PM UTC+1, nadv...@suse.cz wrote:
>
>
> I still wonder if I have to create the mask manually. I'd expect that at 
> least for HDR this is done automatically. But in my case the HDR 
> output looks the same as LDR. 


Masking in hugin is always done manually. HDR and exposure-fused output may 
work in your situation, but they are best suited for cases where you have 
material in all exposure levels for the whole output, and work best if you 
have a set of bracketed exposures for each individual shot. If you run into 
a situation where you are likely to be unable to fit the dynamic range into 
a single exposure, go for brackets and use them all the way, not just for 
the parts where you must. But if you work from raw and process in 16bit, 
you may be able to avoid bracketing and capture enough of the dynamic 
range; just avoid overexposing and pull the dark areas up later.

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/f544bbf3-89a9-4981-84f2-8d817e6fa0b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Hugin is purely and simply unusable for panorama stiching

[kfj]

On Monday, March 24, 2014 6:08:34 PM UTC+1, Hugues D wrote:
>
> Hi,
> I just downloaded and installed Hugin. I then loaded 15 pictures I have 
> stiched very easily with the free Microsoft ICE giving great results but 
> some stiching errors. I thought that Hugin would be a better tool. 
> Conclusion : Hugin is not even capable of finding two common points between 
> 2 pictures in my set of 15.
> This is ridiculous and unusable.
>

Thanks for sharing. You show your's, so I'll show mine

http://www.360cities.net/profile/kfj

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/5a194201-b75b-4723-8df5-be845aa6eeae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Microscopy set of images and stitching them by using Hugin without image deformation

[kfj]

On Thursday, March 20, 2014 7:30:17 PM UTC+1, Mario Modesto wrote:
>
> Hello everybody,
>
> As the title sais, I recently obtained several images from a simple sample 
> with a microscope. And I would like to stitch them without deforming them. 
> How can it be done using Hugin?
>

To put it simply, you want to stitch them in mosaic mode. For your input 
images, assume a rectilinear lens and assign an arbitrary horizontal field 
of view - just use a small value. The only parameters you should need to 
optimize are x and y, I don't think you should have much trouble with lens 
distortion but if you do you can try optimizing a, b and maybe c, but try 
without first. I would try using cpfind for the control points, possibly 
with a setting which will give you more control points than usual - try 
something like --fullscale --sieve2size 5 -o %o %s

Output would be rectilinear, it shouldn't be difficult to get it to work, 
since you have so few parameters to play with. I do assume you are using a 
mechanical stage, if not you need to optimize for r (roll) as well. And you 
shouldn't refocus from one image to the next, because that will confuse the 
control point generator, which needs identical bits of image to recognize, 
and with the very small depth of field of microscopic images a small change 
in focus may make it impossible for the cpg to do it's job - the problem 
will be more pronounced with higher magnifications.

One more thing: make sure your microscope is köhlered precisely - see 
http://en.wikipedia.org/wiki/K%C3%B6hler_illumination

Kay


> Thanks
> Mario
>

-- 
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/de89f6a0-2e06-4572-8a72-aadfa656559f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: Hugin 2014.rc1 and Python scripting, doesn't work

[kfj]

On Sunday, March 23, 2014 6:16:37 PM UTC+1, Robert Lesac wrote:
>
> Hi,
> There is no RC2 build for for Windows yet.
> At least I can stop muck around trying to fix it.
> Thanks!
>

Just go back a version or two. The python interface isn't precisely 'new' - 
I wrote it in 2010.

Kay
 

>
> On Sunday, March 23, 2014 5:43:16 PM UTC+1, Stefan Peter wrote:
>>
>> On 23.03.2014 15:41, Robert Lesac wrote: 
>> > Update: 
>> > Added PYTHONPATH (pointing to the hugin/bin) to my system variables, 
>> > didn't help with Hugin, but Python now imports HSI successfully. 
>>
>> Python scripting was broken with RC1, try RC2 (no idea if RC2 has been 
>> packaged for Mac though). 
>>
>>
>> > 
>> > On Sunday, March 23, 2014 2:35:14 PM UTC+1, Robert Lesac wrote: 
>> > 
>> > Hi, 
>> > I wanted to try out the new scripting interface, but for the life 
>> of 
>> > me can't get it to work. 
>> > Setup: HuginSetup_2014.0.0-rc1_64bit_Windows_Python + Python 3.3.5 
>> + 
>> > Win7 64x 
>> > From the Hugin interface all scripts return -1. 
>> > 
>> > Manually running a script complains about HSI not being available, 
>> > so I copied HSI.* to the scripts directory and the script will run 
>> > from the command line. 
>> > From Hugin I still get the same error. 
>> > 
>> > Trying 'import hsi' from the Python interpreter just gets me a 
>> > complaint 'ImportError: No module named 'hsi''. 
>> > Seems to me it might be a path mixup, any ideas how to fix it? 
>> > 
>> > 
>> > Thanks! 
>> > 
>> > -- 
>> > 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+...@googlegroups.com 
>> > . 
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/hugin-ptx/74fac189-a2bb-49a0-a150-a322bc0f8f6f%40googlegroups.com
>>  
>> > <
>> https://groups.google.com/d/msgid/hugin-ptx/74fac189-a2bb-49a0-a150-a322bc0f8f6f%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>  
>>
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>
>> -- 
>> "In summary, I think you are trying to solve a problem that may not 
>> need to be solved, using a tool that is not meant to solve it, without 
>> understanding what is causing your problems and without knowing how 
>> the tool actually works in the first place :)" 
>> Jeffrey J. Kosowsky on the backuppc mailing list 
>>
>>

-- 
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/017b1b0c-2626-4818-8e46-08e454c19d58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hugin-ptx] Re: Handling of overexposures

[kfj]

On Friday, March 21, 2014 1:34:08 AM UTC+1, nadv...@suse.cz wrote:
>
> Hi, 
>
> the recent discussion about exposure compensation reminded me that I 
> have related problem. 
>
> I have a panorama from 10 images taken with fixed exposure, EV 12. 
> A small part of the panorama is overexposed, so I added one extra 
> correctly exposed image with EV 14 that covers the overexposed area. 
>
> Now, when I process it as "Exposure fused from any arrangement", then 
> there are no burned out areas, but the extra image is still recognizable 
> as a darker rectangle, which does not look good.


I think in your situation you don't want exposure fusion. Try this:

- use an include mask on the EV 14 image covering the overexposed area plus 
some space around it
- do an LDR photometric optimization of your whole image set
- stitch as ordinary pano (with exposure correction, LDR)

This has the effect of forcing out the overexposed bit from the result, but 
the photometric optimization will have corrected the EV14 image to blend 
well with the other images. The 'space around' is to give the blender room 
to manouvre and produce an invisible transition. You could use an exclude 
mask on the overexposed image instead, but this may get you unwanted 
(underexposed) parts from the EV14 image into the stitch. You may have to 
shift the output EV closer to the EV14 image to get a good result; rather 
stitch too dark and pull up the dark areas later with the gradation curve 
when you do the retouching or do a 'false exposure fusion' from a brighter 
and a darker stitch. Consider working in 16bit TIFF.

Kay


>
> With "Exposure corrected" it does not consider overexposures at all 
> and part of the overexposed area are just grey in the result. 
>
> What is the recommended workflow for this situation? 
>
> Thanks, 
> Vladimir 
>
>

-- 
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/eebcef1b-af8c-49b9-a79f-c5d7c4f21aa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [hugin-ptx] Re: How to best shoot and stitch this?

[kfj]

On Wednesday, March 5, 2014 10:00:48 AM UTC+5:30, Tduell wrote:
>
> Hello Kay, 
>
> Sorry if I am a bit dense, but a couple of questions on detail, if I may. 
>
> On Tue, 04 Mar 2014 21:19:46 +1100, kfj <_k...@yahoo.com > 
> wrote: 
>
> > - 'pin' the four corners of each image to the corresponding points on   
> > your skeleton drawing (the ladder) 
>
> Where is this to be done, in Gimp or Hugin? 
> Can you be a bit more explicit as to what you mean by 'pin' an image to

another, it isn't a term I see used in Gimp or Hugin. 
>

Okay, sorry for the sloppy terminology. By 'pinning' I mean setting control 
points between a reference image with reference points and corresponding 
points in partial images which need placement. Imagine, for example, having 
a set of image tiles and a reference image showing a grid. Pinning would 
then mean that you set CPs from the four corners of each tile to the grid 
points where the image is to be placed. Another use of pinning was my 
method of fixing prominent features in landscape panoramas to an artificial 
panorama which is used as reference, resulting in what I labeled a 
'canonical' panorama with near-perfect horizon and orientation, see

https://groups.google.com/forum/#!topic/hugin-ptx/l32L3Iffv6w

> - use the ladder drawing as reference and optimize the other images for   
> > r, p, y, x, y and z. 
>
> What is the ladder drawing in this context...the bare drawing, or the   
> drawing with all the images 'pinned'? 
>

The ladder drawing, in this context, is the line drawing made in gimp which 
serves as the surface you 'pin' your individual images to.

By 'reference' do you mean (in hugin terminology) the 'anchor' for   
> position?


Yes, that's what I mean. You are right, anchor is the hugin term, or to be 
more precise, position anchor. And when you finally stitch the panorama, 
you simply deactivate this anchor image, resulting in a panorama from the 
individual photos, held by the invisible 'spine' of the hidden artificial 
anchor image.

The 'pinning' technique has quite a few interesting applications, but I 
think it isn't used much, since it doesn't occur to many people to mix in 
images which don't visibly contribute to the final product. Another example 
of pinning is using a reference showing an azimuthal grid, possibly with 
the sun's position marked which can be found by using the techniques 
discussed here:

https://groups.google.com/forum/#!topic/hugin-ptx/vWRO7SxdFxQ

If your set of photographs show both the nadir and the sun, you are just a 
few clicks away from a level horizon and a good orientation.

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/d89e7a12-826d-4872-9e6f-ffe151c94835%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] Re: How to best shoot and stitch this?

[kfj]

On Tuesday, March 4, 2014 6:51:13 AM UTC+5:30, Tduell wrote:
>
> Hello All, 
> The attachment shows the Vietnam Veterans Commemorative Walk, in Seymour, 
>   
> Victoria. 
> It is approx. 80-ish metres long, with about 52 glass panels on each side, 
>   
> each panel approx 2m high, 1.5m wide. 
> The panels are etched with images from the war, and the names of all the   
> Australian veterans. 
> Shooting and stitching a pano of each side looks like a tricky project. 
> The right side of the attached image is roughly north, so shooting the   
> south side is always going to present a bit of a problem with the light,   
> i.e. the sun is always to the north. 
> On the north side the panels have much better light, but there is   
> vegetation about 4 to 5m from the panels. 
> Standing on the edge of the vegetation, a 24mm lens (36mm equiv) shooting 
>   
> approx normal to the panels gives about 2.5 panel wide coverage. 
> Does anyone have any comments on whether a pano might be possible, and any 
>   
> ideas on how to tackle it? 
>

If you can live without the curve of the wall, I would do this:

- In a drawing program like gimp, create a line drawing of a stripe with 
sections having the same aspect ratio as the individual images on the wall 
- imagine a ladder put down horizontal with rungs upright

- Mask the individual normal shots so that there is some of the left and 
right neighbouring image visible; enough to let the blending software 
create an invisible blend.

- 'pin' the four corners of each image to the corresponding points on your 
skeleton drawing (the ladder)

- use the ladder drawing as reference and optimize the other images for r, 
p, y, x, y and z. If the otimization fails, you could try adding line 
control points along the ladder's lines; in my experience with stitching 
mosaics from handheld shots this has always helped getting the optimization 
to work and achieving a good result.

- leave the placement of the seams to enblend; the curvature might be 
slight enough not to create too much parallactic error

This process might be less work than processing each individual image to be 
perfectly normal and of the right size and then mosaicing them together. 
And making a trial with just a few images won't cost you too much time.

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/e9cf0262-8973-4f35-93d2-fe31b616f2b5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] What happened to the hsi?

[kfj]

On Thursday, February 20, 2014 5:28:04 AM UTC+5:30, Tduell wrote:
>
> On Sat, 08 Feb 2014 16:57:39 +1100, Terry Duell 
> > 
>   
> wrote: 
>
> > Hello Kornel, 
> > 
> > On Fri, 07 Feb 2014 22:01:43 +1100, Kornel Benko   
> > > wrote: 
> > 
> >> 
> >> Am I the only one missing the 'Actions' button in the main window? 
> >> 
> > 
> > No sign of it here either, current default branch local Fedora build. 
> > 
> >> I could not find any menu entry for WOA in recent created hugin. 
> >> Still, the plugins are installed. 
> > 
> > Likewise. 
> > 
> > 
>
> It has re-appeared in a recent build of the default branch   
> (6554:7ff646d5e247), and reported as back in the 2014.0.0 RC1. 
>

I reckon the patch I sent in and which Kornel applied was only against the 
default branch, and that's why it did not make it into earlier forks. Two 
thing happened there:

- the api changed, breaking woa. This was easily fixed by adding code to 
make up for the variant of SrcPanoImage's constructor taking a filename as 
it's argument; the changed code is now in the default branch.

- @api-max in all plugins was not updated to the current API version, 
resulting in the plugins not being accepted as valid for the latest 
version, and since no valid plugins could be found, the 'Actions' menu did 
not show up.

My patch fixed the problems in the default branch, but the changes may have 
to be applied to other branches as well. The update of the @api-max (and 
sometimes @api-min) values  has to happen with every new version; this is 
apparently documented as part of the release process but has been forgotten 
occasionally.

The code changes to woa.py as applied in the default branch should be 
introduced into earlier versions if they use the new API with the missing 
SrcPanoImage constructor variant, I don't know when the API change was 
introduced. If they use the old API, the old woa.py code should be used. 
@api-min and @api-max must always be set appropriately.

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/b998053a-16e5-4d83-8a1a-cc2620f6de8e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] Re: orienting a panorama by the sun

[kfj]

On Friday, August 3, 2012 12:34:15 AM UTC+5:30, kfj wrote:
>
> Hi group!
>
> I just came up with a neat trick to orient my panoramas (like, when I 
> publish them on 360cities). If I have the sun visible in the panorama, I 
> enter 'sun', the date/time and position into Wolfram Alpha, like this:
>
> sun July 9 2012 18:37 at 45.338 N 7.2524 E
>

After using this method for a while, I became annoyed with Wolfram alpha, 
because it was so very picky about what you have to enter, and I found no 
way to just get the azimuth and nothing else. So I opted to write a little 
python script which reads out the relevant EXIF tags from an image with the 
pyexiv2 module (GPS Date, GPS Time, GPS Longitude and GPS Latitude) and 
calculates the sun's position using the pysolar module. The script gives 
the azimuth in degrees clockwise off north, as required by the orientation 
dialog in 360cities, who host my full spherical panoramas. Interested? 
Download the script from here:

http://bazaar.launchpad.net/~kfj/+junk/script/download/head:/sun_position-20140120072527-vlz6gee23xhwlkrl-1/sun_position

and put it into /usr/local/bin or somewhere else in your path.

You'll obviously have to have the pyexiv2 module and pysolar installed; I 
got pyexiv2 via my package management (I'm on Kubuntu 12.04). pysolar can 
be had from http://pysolar.org/

usage is simple, just pass the image's filename to the scipt and it outputs 
the azimuth and altitude:

$ sun_position IMG_5458.CR2
azimuth (clockwise, N = 0 degrees): 204.558020 altitude 57.709008

I hope this works generally - I geotag my images from gpx tracks, using 
exiftool -geotag, so the images have these GPS-related tags (printed with 
exiftool):

GPS Version ID  : 2.3.0.0
GPS Latitude Ref: North
GPS Longitude Ref   : East
GPS Altitude Ref: Above Sea Level
GPS Time Stamp  : 12:25:07
GPS Date Stamp  : 2013:08:09
GPS Altitude: 1022.8 m Above Sea Level
GPS Date/Time   : 2013:08:09 12:25:07Z
GPS Latitude: 46 deg 1' 30.64" N
GPS Longitude   : 8 deg 25' 49.52" E
GPS Position: 46 deg 1' 30.64" N, 8 deg 25' 49.52" E

In 360cities, I put the sun into the center in the orientation window, then 
click on the button in the top right corner and drag the tip of the compass 
until the number shown is equal to the azimuth.

Again this made me wish there was something like an 'absolute' control 
point type in hugin, where you can just enter an azimuth and an altitude 
value (call it yaw and pitch if you like) to set the orientation of the 
panorama. Then it would be as easy as 'click on the sun and set an absolute 
control point'. Add the nadir in the same way, and the panorama is 
perfectly oriented and levelled.

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/b3639240-4c23-4083-aa2a-924edaa62628%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] Re: Warped Overlap Analysis not working

[kfj]

I posted a patch (in the other thread about SrcPanoImage's constructor) 
which fixes woa, and pulls up all plugins to API level 2014.1

Kay

On Friday, January 17, 2014 12:23:50 PM UTC+5:30, kfj wrote:
>
>
>
> On Thursday, January 16, 2014 6:23:30 PM UTC+5:30, kornel wrote:
>>
>>
>>  
>>
>> There is this macro in SrcPanoImage.h:
>>
>> #define image_variable( name, type, default_value ) \
>>
>> type get##name() const { return m_##name.getData(); }
>>
>> #include "image_variables.h"
>>
>> while in image_variables.h the call to it:
>>
>> image_variable( Filename, std::string, "" )
>>
>> should expand to:
>>
>> getFilename() const { return m_Filename.getData(); }
>>
>
> No, I think this macro is to find out the file name if you have a 
> SrcPanoImage already. What I am looking for is a way to create an 
> SrcPanoImage from a file. In the previous version, you could call 
> SrcPanoImage's constructor with a filename as it's sole argument. The file 
> was opened, read, analyzed and you had an SrcPanoImage to work with. Now 
> the constructor does not take any arguments any more. So you can contruct 
> an SrcPanoImage, but it can't have any content yet, since you can't tell 
> which file to contruct it from. So I suspect that there must me a mechanism 
> like:
>
> SrcPanoImage myImage ;
> ifstream f ( "image.tif" ) ;
> myImage.readData ( f ) ;
>
> Pano objects need this clumsy mechanism: You have to create the Pano 
> onject, then create an ifstream from the PTO file and finally call the Pano 
> object's readData method, passing it the stream object. So I suppose it 
> might be similar with SrcPanoImage now, but I'm only guessing.
>
> I'll start a new thread. Quite probably noone gives a damn if woa works or 
> not, and this thread will just go on without anyone in the know looking 
> into 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/5b6595c7-cafc-42b0-ab57-d2c4ee85824a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] Re: SrcPanoImage's constructor doesn't take arguments any more. How to use it now?

[kfj]

Grudingly, here's the patch. It also pulls all other plugins up to API 
level 2014.1, so that the Actions menu will show up. I've tested the 
plugins, they all run with this API version. In woa, I added code to 
reflect the loss of the SrcPanoImage coonstructor taking a filename.

https://www.dropbox.com/s/3jlhyyoosnis1g7/hsi.2014.diff

Kay

On Sunday, January 19, 2014 11:01:31 AM UTC+5:30, kfj wrote:
>
>
>
> On Saturday, January 18, 2014 2:23:40 PM UTC+5:30, T. Modes wrote:
>>
>>
>>
>> Am Freitag, 17. Januar 2014 08:06:16 UTC+1 schrieb kfj:
>>>
>>> SrcPanoImage's contructor doesn't take any arguments. There used to be a 
>>> version of the constructor taking a filename:
>>>
>>> SrcPanoImage(const std::string &filename) ...
>>>
>>> This is gone now, and only the default constructor remains. How is one 
>>> to make an SrcPanoImage from a file now? Probably some roundabout way like
>>>
>>> Anyway, is there a technical reason why the construction from a filename 
>>> was thrown out? It breaks woa, so I'd like to know, and I'd like to have it 
>>> back if possible ;)
>>>
>>> The old version was too inflexible. It resulted in too much read access 
>> to the files. This has been reduced as much as currently possible (and will 
>> therefore not restored).
>>
>
> I can't see the point. The version of the constructor without arguments 
> was there before. If using the other version 'results in too much read 
> access to the files', there is a simple solution to the problem: don't use 
> that version; use the parameterless one. In C++ you can have as many 
> constructors as you like, and having an extra one does no harm. Removing 
> one which has been there constitutes an API change which is imho 
> unnecessary.
>  
>
>> Depending on the exact use case there are now different ways:
>>
>>   HuginBase::SrcPanoImage srcImg;
>>   srcImg.setFilename(filename);
>>
>
> So I was right about the roundabout way... what makes it worse is that the 
> other functions have also changed (readEXIF() took several parameters) or 
> weren't there before (like checkImageSizeKnown()). So I'd have to write a 
> new version of woa using the modified API. What's wrong about keeping the 
> constructor-from-filename?
>
> Kay
>  
>
>>
>> and then
>>   srcImg.setSize(size);
>> or
>>   srcImg.checkImageSizeKnown();
>> or
>>   srcImg.readEXIF();
>>   srcImg.applyEXIFValues();
>> or …
>>
>> Thomas
>>
>

-- 
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/847a6c6a-b4ad-4772-a06c-9605a4d50a10%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] Re: SrcPanoImage's constructor doesn't take arguments any more. How to use it now?

[kfj]

On Saturday, January 18, 2014 2:23:40 PM UTC+5:30, T. Modes wrote:
>
>
>
> Am Freitag, 17. Januar 2014 08:06:16 UTC+1 schrieb kfj:
>>
>> SrcPanoImage's contructor doesn't take any arguments. There used to be a 
>> version of the constructor taking a filename:
>>
>> SrcPanoImage(const std::string &filename) ...
>>
>> This is gone now, and only the default constructor remains. How is one to 
>> make an SrcPanoImage from a file now? Probably some roundabout way like
>>
>> Anyway, is there a technical reason why the construction from a filename 
>> was thrown out? It breaks woa, so I'd like to know, and I'd like to have it 
>> back if possible ;)
>>
>> The old version was too inflexible. It resulted in too much read access 
> to the files. This has been reduced as much as currently possible (and will 
> therefore not restored).
>

I can't see the point. The version of the constructor without arguments was 
there before. If using the other version 'results in too much read access 
to the files', there is a simple solution to the problem: don't use that 
version; use the parameterless one. In C++ you can have as many 
constructors as you like, and having an extra one does no harm. Removing 
one which has been there constitutes an API change which is imho 
unnecessary.
 

> Depending on the exact use case there are now different ways:
>
>   HuginBase::SrcPanoImage srcImg;
>   srcImg.setFilename(filename);
>

So I was right about the roundabout way... what makes it worse is that the 
other functions have also changed (readEXIF() took several parameters) or 
weren't there before (like checkImageSizeKnown()). So I'd have to write a 
new version of woa using the modified API. What's wrong about keeping the 
constructor-from-filename?

Kay
 

>
> and then
>   srcImg.setSize(size);
> or
>   srcImg.checkImageSizeKnown();
> or
>   srcImg.readEXIF();
>   srcImg.applyEXIFValues();
> or …
>
> Thomas
>

-- 
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/58d91d01-6878-49a5-b437-8f9e12b64bdf%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.