A few more thoughts:
---
multiblend is exceptionally fast compared to enblend (maybe 10x to 20x
faster, as I recall). I found in most situations it produces output just
as visually appealing as enblend. I can't remember the details now, but a
couple of years ago I noticed some seam issues in
free skys.
>
> As for the blue sky, I have a few thousand Drone 360 Panossome surely
> have clear sky. Here is an example from Yesterday that has mostly blue sky
> - https://maps.app.goo.gl/zAZVz8gpB5FEoMr5A
>
>
>
> On Fri, Oct 20, 2023 at 8:11 AM Jeff “weltyj” Welty
nd let ya know
> what/where I get stuck. My panos have a very sharp contrast. Like this -
> https://maps.app.goo.gl/6d2nJiieKm6tjV6c8?g_st=ic
>
> By chance, do you have a compiled win version of skyfill?
>
>
> Sent from my mobile
>
> On Oct 19, 2023, at 21:46, Jeff “we
d to add the new beta to my todo list also.
>
> Thank you for the example photo!
>
>
> On Mon, Oct 16, 2023 at 9:55 PM Jeff “weltyj” Welty
> wrote:
>
>> p.s. The sky wasn't complete so I used my skyfill application to fill it
>> out...
>>
>> O
p.s. The sky wasn't complete so I used my skyfill application to fill it
out...
On Monday, October 16, 2023 at 7:55:04 PM UTC-7 Jeff Welty wrote:
> https://postimg.cc/ygYShW3h
>
> All my panoramas are handheld. I rotate the camera to portrait mode and
> try best I can to
images, about a 208 degree
field of view.
For the curious on the left is Mount Rainier in Washington State, USA. A
little right of center is Mount Saint Helens, and if you know where to look
Mount Adams. It was, as we like to say, a three volcanoe day.
Cheers,
Jeff
--
A list of frequently
I have linux mint 21.1 (vera). It was released Dec 2022. It isn't *that*
old. There is a new version out -- 21.2 released last July, maybe it's got
a newer version of wxwidgets.
Jeff
On Monday, October 16, 2023 at 4:31:27 PM UTC-7 GnomeNomad wrote:
> Hmm, sounds like a really old &quo
rce when I have
time.
Thanks for this new release of hugin, it's looking good.
Thanks,
Jeff
On Monday, October 16, 2023 at 11:34:21 AM UTC-7 T. Modes wrote:
> Hi Jeff,
>
> eljef...@gmail.com schrieb am Sonntag, 15. Oktober 2023 um 18:16:11 UTC+2:
>
> I started hugin with an ex
I got a change to grab this release this morning. I am using Linux Mint
21.1 Vera, and did a full update/upgrade before installing the new
version. System details follow this description of a bug I found.
-- I installed libpano13-2.9.22_rc2 from source
-- For this beta version of hugin, I did
by file), I recommend you give it a try. It's magic:
http://meldmerge.org/
I have used it to compare projects as big as darktable.
Bruno & Thomas -- I think I'd just release rc2 as is. Looks good to me.
Cheers,
Jeff
On Thu, Sep 7, 2023 at 8:22 AM T. Modes wrote:
> I will look at the
ons of
code...
Hope this is helpful,
Jeff
On Wed, Aug 16, 2023 at 8:08 AM Jeff Welty wrote:
> I'll try the mercurial merge request on sourceforge (something new for me).
>
> I was in the tarball mode because I use meld on two separate folders to
> track changes on a small project like this.
&
I'll try the mercurial merge request on sourceforge (something new for me).
I was in the tarball mode because I use meld on two separate folders to
track changes on a small project like this.
Jeff
On Wed, Aug 16, 2023 at 5:56 AM Bruno Postle wrote:
> Thanks everyone for testing.
>
as a result. These bugs would probably be very rare to appear in
actual practice.
Interested in a tarball?
Jeff
On Sun, Aug 13, 2023 at 2:45 AM Andreas Metzler wrote:
> On 2023-08-11 Bruno Postle wrote:
> > libpano13 is the PanoTools library for panoramic imaging.
>
> > A li
FWIW, I downloaded rc1, reviewed the source code changes relative to
13-2.9.21, compiled/installed and tested it on a couple of panos with the
hugin interface.
rc1 looks good to me. I'll do the same for rc2 when it shows up.
Cheers,
Jeff
On Tue, Aug 1, 2023 at 8:23 AM Bruno Postle wrote
uld assume that vignetting and TCA are also consistent between hugin
and lensfun.
On Thursday, April 28, 2022 at 8:49:58 AM UTC-7 bruno...@gmail.com wrote:
> On Thu, 28 Apr 2022 at 15:57, Jeff Welty wrote:
> > On Thursday, April 28, 2022 at 2:33:53 AM UTC-7 Bruno Postle wrote:
> >&g
he optimiser, the d & e parameters resemble the TrX and TrY
> parameters at the small scale, so sometimes you can get strange
> results mixing them.
>
I hadn't even considered that, but I see the problem. Probably best not to
optimize d if TrX and TrY are being optimized.
Thanks B
Hi Thomas,
On Thursday, April 28, 2022 at 8:40:05 AM UTC-7 T. Modes wrote:
>
> One approach is take the average value of each coefficient from each of
>> the separate panoramas, and update the lensfun data with the average
>> value. I did a quick check and this appears mathematically
ndle up the changes I have in a zip
or tar file. As I recall 4 or 5 source code files were affected. I did
not attempt to get the LM starting step sizes for the parameters correctly
set, those are hardcoded, and the same for every parameter, it's still a
FIXME issue.
Jeff
> --
> Bruno
I have a new camera (Canon G1X mark iii).
The default lens distortion at the widest angle (15mm) in lensfun
definitely does not match my particular copy of this camera, so I can't
export output Darktable with lens correction.
I have a dozen or so mini-panoramas with 2 to 5 images each, of
ugin itself. A tab that would be enabled after stitching... I could
sure imagine a nice GUI to draw masks, vary parameters etc. But I'm
certainly not going to ask for that right now.
Cheers,
Jeff
On Tuesday, March 22, 2022 at 3:48:34 AM UTC-7 Tobias wrote:
> Hi,
>
> thanks for the n
knowledge of how it all
works. So, if you are using this and find any part confusing, or could be
improved -- *please* let me know.
Enjoy!
Jeff
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you
The Nokia 6.1 has a 3.57mm focal length lens. The sensor is 4.608mm wide
by 3.456 high, so the diagonal (lower left to upper right) is 5.76mm. On
a full frame camera (old 35mm film), the diagonal is 43.27 mm. The crop
factor for the Nokia is 43.27/5.76 = 7.51
So the entries in the GUI
I just looked at the code, and it confirms the behaviour you describe. I
too find it unexpected. If what I'm seeing in the code (ImagesPanel.cpp,
ImagesPanel::CPGenerate() function ) is correct, it seems a somewhat
trivial fix.
Here's what I'd like:
---
No images selected and there are
That'll work fine.In -fsr mode, it will compare that brown color to the
expected blue color, determine a zero probability that it is actual sky,
and thus leave the color as is.
In normal mode, blending starts 50% of the way between the green line and
the yellowish line at the top, so it
Hmm, give that link another try -- I haven't used google drive in that way,
and I think I needed to change the access so anyone with the link can get
it.
Answering your final question -- yes, full sky replacement will replace all
pixels that are likely to be sky. Internally, a very
ixels just to the left of that vertical edge because it is not perfectly
vertical, and is using a localized rgb model to extrapolate and create
pixels to make the edge perfectly vertical. Those dark pixels pollute the
localized estimate of sky color...
On Friday, March 4, 2022 at 4:41:32 PM UTC-8
I'll grab that, woah, yes that's large. As an afterthought -- if you have
darktable -- just use the retouch tool. It'll be quick, easy, and like
magic!
On Friday, March 4, 2022 at 4:25:22 PM UTC-8 johnfi...@gmail.com wrote:
> My existing examples are absurdly large. I don't mind putting one
...
On Friday, March 4, 2022 at 3:41:01 PM UTC-8 Jeff Welty wrote:
> Fillsky should work for those problems -- any area *above* the detected
> end of sky which is black (i.e. r,g,b all 0), or alpha < 1. will be filled
> with the modelled esimate of the sky color. But the trick will be to
&g
Fillsky should work for those problems -- any area *above* the detected
end of sky which is black (i.e. r,g,b all 0), or alpha < 1. will be filled
with the modelled esimate of the sky color. But the trick will be to
apply a test mask (-tm) to the area so the
end of sky detection
> On Sunday, February 13, 2022 at 1:59:42 AM UTC-6 T. Modes wrote:
>
>> Hi Jeff,
>>
>> eljef...@gmail.com schrieb am Sonntag, 13. Februar 2022 um 04:05:39
>> UTC+1:
>>
>>> Added 8 bit support on the 2022.02.11 branch... Only for TIFF images.
>>>
&g
, February 21, 2022 at 4:32:47 PM UTC-8 Jeff Welty wrote:
> John, yes indeed I did mean the output horizontal field of view. I did a
> diff on the two files -- and literally the only differences are in the
> output size (h w...) and v I am assuming the fov represented by v
, February 21, 2022 at 4:32:47 PM UTC-8 Jeff Welty wrote:
> John, yes indeed I did mean the output horizontal field of view. I did a
> diff on the two files -- and literally the only differences are in the
> output size (h w...) and v I am assuming the fov represented by v
John, yes indeed I did mean the output horizontal field of view. I did a
diff on the two files -- and literally the only differences are in the
output size (h w...) and v I am assuming the fov represented by v
should be the same regardless of final output resolution, so that seemed
In addition to the output size being different, the horizontal field of
view is different -- for a.pto it is 360. For b.pto, it is 71. That is
probably making a big difference in the final optimized minimum.
On Monday, February 21, 2022 at 9:08:07 AM UTC-8 johnfi...@gmail.com wrote:
> If I
bit of testing I have done it seems to help
avoid falling into a local minimum for the optimization.
Jeff
On Sunday, February 13, 2022 at 4:11:27 AM UTC-8 johnfi...@gmail.com wrote:
> I think that problem is important and ought to get some attention and can
> be solved.
>
> But
Added 8 bit support on the 2022.02.11 branch... Only for TIFF images.
On Saturday, February 12, 2022 at 1:28:29 AM UTC-8 T. Modes wrote:
> Hi Jeff,
> eljef...@gmail.com schrieb am Samstag, 12. Februar 2022 um 02:07:30 UTC+1:
>
>>
>> I would greatly appreciate reports on com
.
Exiftool is how I'm getting the ICC profile copied from the input tiff to
the output tiff.
Jeff
On Saturday, February 12, 2022 at 1:28:29 AM UTC-8 T. Modes wrote:
> Hi Jeff,
> eljef...@gmail.com schrieb am Samstag, 12. Februar 2022 um 02:07:30 UTC+1:
>
>>
>> I would great
Hi Tobias,
The CIE I was incompletely refering to was not the CIELAB colorspace, but a
CIE standards model for predicting the watts/m**2 at a given point in the
sky.
Thanks for the interest though -- I don't mind input at all!
Cheers,
Jeff
On Tuesday, January 4, 2022 at 1:53:30 AM UTC-8
and is at best "experimental". The results are far superior than the
previous method. Look in the examples subdirectory to see how it is
working -- along with a shell script that shows the exact command line
parameters I used.
On Friday, December 24, 2021 at 7:30:40 AM UTC-8 Jeff W
but with a much simpler model.
The results are now MUCH better. It has lost the feature to have a little
"sun glow" from the edge of the frame, and I intend to add that back in.
For now, it's Christmas Eve and time to be with my family. Happy Holidays!
Cheers,
Jeff
On Friday, D
errors occurred!See also
"/home/welty/images/src/skyfill/build/CMakeFiles/CMakeOutput.log".*
---
No rush to fix this. I'm using the original Makefile I had which is lets
me keep working with the code and trying it out.
Jeff
On Thursday, December 23, 2021 at 1:48:23 AM UTC-8 T. Mo
I'm shocked it worked that well (though I can see obvious issues in the sky
hue and saturation). I suspect the clouds may be incorrectly determined to
be part of the sky -- and are affecting the estimate of sky hue and
saturation.
To see where it estimates the start of sky and end of sky, run
Thomas,
I made the changes to address your compile errors. It compiles and runs
for me. Let me know how it goes. New code on github now.
Jeff
On Wednesday, December 22, 2021 at 6:23:38 AM UTC-8 T. Modes wrote:
> Hi Jeff,
>
> eljef... schrieb am Mittwoch, 22. Dezember 2021 um 15:01
dification with the -m
column. The next step on clouds would probably be something like
using Celeste to identify clouds and ignore them in processing.
Thanks!
Jeff
On Wednesday, December 22, 2021 at 4:48:53 AM UTC-8 T. Modes wrote:
> Hi,
>
> I tried to compile on Windows with MSVC.
is on the source file on github now.
On Tuesday, December 21, 2021 at 3:59:03 PM UTC-8 bruno...@gmail.com wrote:
> On Tue, 21 Dec 2021 at 23:23, Jeff Welty wrote:
> >
> > Any preference for sourceforge or github? I don't have a preference. I
> have a very, very old project on sourceforge (
width than the example code I found. I'll look at
tiffinfo for clues.
Thanks for being the first bug reporter!
Jeff
On Tuesday, December 21, 2021 at 2:44:31 PM UTC-8 bruno...@gmail.com wrote:
> Hi Jeff, thanks for sharing. This looks like a very useful tool.
>
> The best way to get
/uhoan6lma8yp3kk/AADl-Mf0iuBSxVHeUEOYAM-Ia?dl=0
Code has lots of global variables as a few years ago I thought it would be
simple. So, I need to work on cleaning that up!
Cheers and Happy Holidays,
Jeff Welty
--
A list of frequently asked questions is available at:
http://wiki.panotools.org
> On Sunday, June 18, 2017 at 3:45:59 AM UTC+2, Jeff wrote:
>>
>> Has anyone tried to build Hugin using Windows 10's Windows Subsystem for
>> Linux
>>
>
> There is no need to build. Hugin for Linux ought to run on WSL exactly as
> it is released for Linu
Has anyone tried to build Hugin using Windows 10's Windows Subsystem for
Linux (https://msdn.microsoft.com/en-us/commandline/wsl/about)? Just
curious to know if anyone has tried it before I embark on this experiment
this weekend (maybe next weekend). And yes, you can run X11/GTK programs
using
and
another of someone using a rope swing to jump in a river. I'd use hugin to
align the pictures, output as multiple layers, then use GIMP to selectively
erase from each layer the background (except the base layer), then flatten.
Works well!
-Jeff
On Tuesday, June 28, 2016 at 1:32:11 AM UTC-7
Pretty sure you need Python 3.4 with the latest (2015.0.0) version of
Hugin. See the 'Pre-compiled versions' section of:
http://hugin.sourceforge.net/download/
-Jeff
On Wednesday, December 2, 2015 at 10:49:05 AM UTC-8, Greg Castanon wrote:
>
> I'm an amateur programmer screwing
You might start with:
src/hugin1/hugin/GLPreviewFrame.cpp
-Jeff
On Friday, July 31, 2015 at 6:34:24 AM UTC-7, Luca Campobasso wrote:
Hello!
This is a question probably more addressed to the developers of the Hugin
software..
https://lh3.googleusercontent.com/-S1_WVJfGyQ0/Vbt3YjRiyzI
Henk / Boomslang -
Hear hear!
David -
On Thursday, May 15, 2014 3:39:52 AM UTC-4, GnomeNomad wrote:
You have lots of knowledge in a narrow specialty.
And yet my grandmother, to the day she died, swore I was going to
electrocute myself when changing a lightbulb if the switch was still
:
Jeff,
On Thursday, May 15, 2014 2:12:34 PM UTC+2, Jeff W wrote:
The only reason I've entered this discussion at all is that following
Hugues' admittedly not-terribly-helpful post, the universal response from
the community was what we might call the Apple playbook: blame the user.
You
powerful, and more consistent alternatives.
Best
Jeff
On Wednesday, May 14, 2014 4:04:23 PM UTC-4, GnomeNomad wrote:
I think in some cases the Windows bug issues appear to be coming from
Windows components or libraries that aren't part of Hugin?
Also, MS is methodically stripping OpenGL
Unfortunately, I have to agree with Joergen here.
Hugues comment wasn't terribly constructive, but that doesn't change the
reality that Hugin has some significant issues compared to its competitors.
CPFind and Nona are both painfully slow, and both Enblend and Enfuse
frequently crash for me on
and then change back to the projection I want. That's a hack, but a
temporary workaround until we figure out what's really going on.
-Jeff
On Monday, May 5, 2014 11:06:19 PM UTC-7, Emaad wrote:
Hi,
I am facing this very strange image behaviour in Hugin. Some part of my
images is stretched
written this, it sounds like an entire tutorial could be devoted to
projections alone.
-Jeff
On Saturday, February 1, 2014 10:16:51 PM UTC-7, Tduell wrote:
Hello All,
I am preparing a tutorial on hugin-2014.0.0 for a magazine, which may be
published around May, if it all goes ahead.
My aim
This has been a known bug for a while, but the 64-bit Windows version gives
empty outputs on EXRs, likely due to a problem with the (old) OpenEXR
libraries not being supported under amd64 on Windows.
Since ILM has released OpenEXR 2.0, has anyone tried building the 64-bit
Windows version with
Mick,
See this post by Bruno:
https://groups.google.com/d/msg/hugin-ptx/aghpJeyIvQo/k6iOJVImjskJ and the
thread it belongs to for suggestions from other people on a similar problem.
-Jeff
On Monday, January 28, 2013 7:51:53 AM UTC-7, photohounds wrote:
Hi folks ...
First let me say 2
Yes, thank you Yuv, for all that you've contributed to Hugin and for all
help and advise you've shared with me. Good luck with your next endeavors
and ... come back soon!
-Jeff
--
You received this message because you are subscribed to the Google Groups
Hugin and other free panoramic
and Hugin
compiles. The Batcher seems to work still, but I haven't done extensive
testing. I don't know how commenting this one line affects Hugin on Linux or
Mac OS X.
Wish I had more time to devote to this project and hunting down bugs
-Jeff
--
You received this message because you
on
Windows, let me know if you get this same error. Thanks.
-Jeff
--
You received this message because you are subscribed to the Google Groups
Hugin and other free panoramic software group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group
Since the wired.com article mention the rare copies of Musée Français, I
found them in your pano and couldn't help noticing that someone put them in
the wrong order. Please correct me if I'm wrong, but it looks like someone
put Tome IV before Tome III. Shouldn't it go the other way around?
--
While working on fixing bug #712802
(https://bugs.launchpad.net/hugin/+bug/712802) I came across what I think is
another one and want to confirm it with others before reporting it on
launchpad.
If you have a mask on an image beyond the boundaries of the image, the
panosphere doesn't appear
65 matches
Mail list logo
