The most important use case for this idea would also depend on support for
low priority control points, which IIUC is in a fork of Hugin that I
haven't had time to look at yet.
Assume that control points are very accurately placed, but still don't
optimize very well. So the remapped images
It now appears to me that the limitation may be in the device driver
(Nvidia). There is quite a lot to this malfunction that seems to me to be
almost impossible to fit into the theory that the malfunction is in the
driver. But I've stepped through the code down to the point that the image
is
that 3548x2365 fails at 400%.
On Sunday, January 30, 2022 at 7:40:25 AM UTC-5 johnfi...@gmail.com wrote:
> Oops. I meant 800% for the 3548x2365
>
>
> On Sunday, January 30, 2022 at 7:34:35 AM UTC-5 johnfi...@gmail.com wrote:
>
>>
>>
>> At 400% zoom, a 3548x2365
Oops. I meant 800% for the 3548x2365
On Sunday, January 30, 2022 at 7:34:35 AM UTC-5 johnfi...@gmail.com wrote:
>
>
> At 400% zoom, a 3548x2365 original image failed.
> At 200% it should take a 14190x9460 original image. I ought to test that,
> but I haven't yet.
&g
On Sunday, January 30, 2022 at 12:24:42 AM UTC-5 GnomeNomad wrote:
> Which version of Hugin is this? I have v2021.0.0.52df0f76c700. Just
> tried zooming in on some of my biggest panoramas, didn't encounter any
> problems.
>
It is my own build from a mercurial clone from Jan 16. Also, I
dialog feature improvements
that others seem to be interested in.
On Friday, January 28, 2022 at 10:05:55 PM UTC-5 GnomeNomad wrote:
> Could it be related to display driver?
>
>
> On January 28, 2022 2:10:46 PM HST, "johnfi...@gmail.com" <
> johnfi...@gmail.com> wro
I'm pretty sure your main problem is that by default Hugin aligns images
based on the assumption that they were taken from a fixed point of view
(not hand held) so only yaw, pitch and roll vary between images.
I find the expert interface much simpler than the "Simple" interface (once
you know
In my experimentation for 400% and 800% magnification, I am experiencing a
malfunction (entire image displays as black) when the magnified image is
over 134217728 pixels.
I have a bad code change work around for the problem and will figure out a
better code change.
*Who do I ask for the
Since I mentioned my problems with trying to start debugging a debug build
of hugin, I'll describe the partial answer I've found so far. Maybe anyone
else who would try to debug hugin would already know this stuff. But in
case that is not true:
I think CodeBlocks was failing because the
On Saturday, January 22, 2022 at 10:39:36 AM UTC-5 johnfi...@gmail.com
wrote:
I ran make -j16
Meanwhile I ran system monitor to see that about half my cpu capacity was
in use
Then my system crashed. Seemed to be a display driver crash. Maybe there
is some problem in building hugin with j16
I had misunderstood some memory use info, to conclude the images there were
using 16 bytes per pixel. Actually it is only 3 bytes.
The actual measure of the limit past which it fails is 2**27 pixels in the
magnified image. I was incorrect thinking that was 2GB.
So it makes even less sense than
wxImage.
On Saturday, January 22, 2022 at 7:49:37 PM UTC-5 johnfi...@gmail.com wrote:
> On Saturday, January 22, 2022 at 3:57:29 AM UTC-5 T. Modes wrote:
>
>>
>> This is not so trivial. The current implementation keeps the full scaled
>> image in memory. So a 800 % zoom
On Saturday, January 22, 2022 at 3:57:29 AM UTC-5 T. Modes wrote:
>
> This is not so trivial. The current implementation keeps the full scaled
> image in memory. So a 800 % zoom will require several GB of RAM only for
> the cp tab.
>
In my initial testing of the feature, something fails
Don't know if this absolutely needs a new thread. Similar issues in the
mask dialog:
1) the scroll bars go away when not in use (generally nice) but can be hard
to get back. Middle drag would be much simpler for the user.
2) I believe (from behavior, haven't checked code yet) that proximity
On Saturday, January 22, 2022 at 1:34:37 PM UTC-5 bruno...@gmail.com wrote:
>
> The photos should align seamlessly, if they look to have different
> distortions then something is wrong.
>
> I apparently stated things unclearly. I was discussing the target overlap
of the three original
On Saturday, January 22, 2022 at 1:27:25 PM UTC-5 bruno...@gmail.com wrote:
> The
> standard nouveau driver might not have all the top features, but in my
> experience it is very stable.
>
My experience has been very different. Years ago at work, I was using
several Centos systems with
On Friday, January 21, 2022 at 6:33:52 PM UTC-5 bruno...@gmail.com wrote:
>
> Most of the Hugin output projections are designed for very wide angle
> of view scenes. You can try a fisheye projection like Stereographic,
> these are symmetrical and treat horizontal the same as vertical. But
>
driver that weren't on mode changes.
So maybe something else is going on. But likely not a hugin issue.
On Saturday, January 22, 2022 at 11:25:07 AM UTC-5 johnfi...@gmail.com
wrote:
> I ran the hugin I built. I did not do the LD_LIBRARY_PATH thing Bruno
> suggested in the other
I ran the hugin I built. I did not do the LD_LIBRARY_PATH thing Bruno
suggested in the other thread, because my system does have the lib64 setup
(lib is 64 bit) and because ldd indicated hugin had access to all the .so
files it needed without that. I'll investigate whether something else
I wanted to start this thread, even though I don't have a lot to ask/report
yet, because I'll otherwise forget things, and because someone might have
some useful feedback on what I have so far.
uname -a reports
Linux linux 5.15.15-200.fc35.x86_64 #1 SMP Sun Jan 16 17:37:06 UTC 2022
x86_64
On Saturday, January 22, 2022 at 2:55:12 AM UTC-5 Florian Königstein wrote:
>
> If someone likes to change the code for the control point TAB window, I
> have another wish: If there are very many images and control points, e.g.
> hundrets or even 1000 images, it is annoyingly slow if one
I started this in a different thread that I don't want to pollute with
these details, so I'm trying to move that here. I'm not currently prepared
to provide most of the info about what fails (didn't take good notes and
currently working on too many other things). But helpful suggestions would
On Saturday, January 22, 2022 at 4:40:11 AM UTC-5 bruno...@gmail.com wrote:
>
> Basically, the fix is to only centre the current control point in the
> viewports on mouseup, currently it centres on mousedown.
>
When you described the problem, I wondered whether the fix might be as easy
as
On Saturday, January 22, 2022 at 3:57:29 AM UTC-5 T. Modes wrote:
>
> This is not so trivial. The current implementation keeps the full scaled
> image in memory. So a 800 % zoom will require several GB of RAM only for
> the cp tab. Furthermore I would expect speed issue when drawing such big
On Friday, January 21, 2022 at 7:20:51 PM UTC-5 bruno...@gmail.com wrote:
>
> I never quite understood what made the magnifier come and go, so
> anything you can do to make this more predictable.
>
Without a clear statement of the original intent, there is no way I would
try to fix the
On Friday, January 21, 2022 at 6:33:52 PM UTC-5 bruno...@gmail.com wrote:
>
> Hugin will by default map the exposure of the photos to the scene,
> meaning that it will brighten your sky image and darken your ground
> image so that they match the exposure of the middle image - the end
>
I'm trying to assemble a specific vertical panorama, but also trying to
learn methods for assembling a vertical panorama.
One major issue (that I'm furthest from figuring out on my own) is the
exposure issue:
Taken on a cell phone (fixed F 1.9, Focal length 2.91, aperture 1.85, not
sure those
to Ubuntu
for hugin experiments, but generally prefer to use Windows for hugin.
On Friday, January 21, 2022 at 3:18:27 PM UTC-5 gunter.ko...@gmail.com
wrote:
> I'm just an user. But I seem to have the same problems with Control Points
> as you.
>
>
> Am 21. Januar 2022 19:34:06 MEZ sch
I want to make a bunch of changes to the control point dialog.
Maybe this is just for my own use. But if those in control of the project
think any of these are good ideas, I'd be happy to go to the extra effort
to do these changes in a way that can go into the official version (I'll
need a bit
Two posts ago, I forgot to explain I was being more concise by using v
instead of vfov/2 and using h instead of hfov/2
I was trying to show the pattern of sin vs cos interacting with + vs - and
wanted to reduce other confusion, but forgetting to define the abbreviation
increased confusion.
--
0 and the pitch depends on the hfov
>
> Am Donnerstag, 20. Januar 2022, 21:26:20 CET schrieb johnfi...@gmail.com:
> > I think the corner y values should be y {+ or -} sin(r)*vfov/2 {+ or -}
> > cos(r)*hfov/2
> > where the four corners are found by the four combinations of + or
four y,p pairs are:
1: y + cos(r)*h - sin(r)*v, p + cos(r)*v + sin(r)*h
2: y - cos(r)*h - sin(r)*v, p + cos(r)*v - sin(r)*h
3: y - cos(r)*h + sin(r)*v, p - cos(r)*v - sin(r)*h
4: y + cos(r)*h + sin(r)*v, p - cos(r)*v + sin(r)*h
On Thursday, January 20, 2022 at 3:26:20 PM UTC-5 johnfi
I think the corner y values should be y {+ or -} sin(r)*vfov/2 {+ or -}
cos(r)*hfov/2
where the four corners are found by the four combinations of + or -
then the corner p values are like that, but using p instead of y and
swapping vfov with hfov
On Thursday, January 20, 2022 at 3:14:14 PM
ad to a delta angle
> of
> 8 degrees.
>
> Am Donnerstag, 20. Januar 2022, 17:44:36 CET schrieb johnfi...@gmail.com:
> > My method does fail to cover the case that any image has y or p values
> > crossing 180 degrees (meaning directly behind the viewpoint of th
> tricky
> when implementing your version with quadrangles. I'm pretty sure there is
> some
> sort of transformation to avoid those problem...
>
> Am Donnerstag, 20. Januar 2022, 17:15:47 CET schrieb johnfi...@gmail.com:
> > The angles compared in your step 3 aren't actually
The angles compared in your step 3 aren't actually in comparable units. So
your method would miss overlaps near the origin (where two photos each have
small y and p values but opposite signs on their y and p values).
On Thursday, January 20, 2022 at 11:04:47 AM UTC-5 keith...@gmail.com wrote:
st intall those tools in a new system now ;)
>
>regards,
>
>Luís Henrique
>
>
> Em seg., 27 de dez. de 2021 às 20:38, johnfi...@gmail.com <
> johnfi...@gmail.com> escreveu:
>
>> Wow.
>> How do you work with a .pto file without images? Create
Wow.
How do you work with a .pto file without images? Create dummy images with
all the correct names? Or something simpler?
On Monday, December 27, 2021 at 6:03:18 PM UTC-5 bruno...@gmail.com wrote:
> On Mon, 27 Dec 2021 at 15:22, Jon Schewe wrote:
>
>>
>> With a small experiment I managed
I forgot to mention: In the optimizer tab, you can right click at the top
of any parameter column to select or deselect the whole column. That will
save you a lot of clicks when working with a large number of images.
On Monday, December 27, 2021 at 4:39:49 PM UTC-5 johnfi...@gmail.com wrote
project with a new name after all changes.
>
> On Mon, 2021-12-27 at 11:35 -0800, johnfi...@gmail.com wrote:
>
> Oops. I should have realized that would happen (Never before tried to
> work with a .pto without images).
>
> Did you add control points by hand or just le
The images are merged together in a stack. That is almost certainly
wrong. I don't know why that happened nor how to undo it.
I don't know how to learn more that the above from a .pto file without the
images (I'm not at all the expert that Bruno apparently is).
On Monday, December 27, 2021
On Monday, December 27, 2021 at 9:56:13 AM UTC-5 bruno...@gmail.com wrote:
> all the images are projected is at a Z distance of 1.
>
I'm taking that as the definition of the units X, Y and Z are all in. I
want to use some math to verify that I understand what that means.
I suddenly realize
" you will need to use all of these, but not all at once - this can confuse
the optimiser. "
I want to understand that detail. Photos tab: Optimize Geometric: the
calculate button:
Does it start from zero when you click it or does it start from wherever
any previous optimize finished? Your
I'm trying to learn a bit more myself, as well as hopefully help.
One thing that likely will help explain what is happening: In expert
interface, in the photos tab, in the radio buttons on the right, select
"positions". Some of the data displayed there should help explain what is
going
acters I've been removing.
>
> Using the 2020 version, the zoom with the mouse in the preview is working
> reasonably well. Although the preview still disappears on me regularly.
>
> On Sun, 2021-12-26 at 14:32 -0800, johnfi...@gmail.com wrote:
>
> I was really struggling to a
I was really struggling to accomplish anything with Hugin, before I
realized the "Simple" interface is harder to use than the "expert". Maybe
"Simple" is OK if you did a great job with your tripod making sure every
photo is from the same axis point. But I expect you did not.
In the photos
I will keep trying things. But from what I've tested so far, that idea
doesn't work (Align within stacks and combine each stack before combining
the results into a panorama.)
A "similar" layout isn't nearly good enough. The layout would need to be
near pixel perfect and I can't get close.
101 - 147 of 147 matches
Mail list logo
