On Thursday, October 6, 2022 at 7:38:43 AM UTC-4 kornel wrote:
> why don't you use 'make package'? That way. you should get a file like
> hugin-2021.1.0.8500-Linux.deb, which may be installed with
> # sudo dpkg -i hugin-2021.1.0.8500-Linux.deb
>
> I have no guess why the OP chose not to do
How is what finally worked different from what earlier didn't work?
For example, the instructions had /PATH/TO/HUGIN/SOURCES where your final
working version had ..
I assume .. is the path to hugin sources (from the place where you had your
build directory).
It is starting to sound like there
On Sunday, September 18, 2022 at 3:16:14 PM UTC-4 alexande...@gmail.com
wrote:
> So I shot the image sequences with the camera attached to a handcart in a
> rigidly fixed position so there should be hardly any plane pitch or yaw.
> And for optimising, my process was the following:
>
> -
There is a correct fov for each image (assuming it was taken with a camera,
rather than a scanner).
Giving it an incorrect low fov for each image can solve some problems. But
it does create other problems, so I don't think you should leap to that
choice so quickly.
The fov of each image
On Thursday, September 8, 2022 at 11:41:00 PM UTC-4 alexande...@gmail.com
wrote:
> . Relative depth may be the main issue I run into here because there are
> parts of a house as well as trees visible behind the wall at various
> distances.
In that case, your idea of working from a
It has been asked before and I see no answer
https://groups.google.com/g/hugin-ptx/c/qWe1L4QhlDk/m/QgV5TTeWAwAJ
If (unlike those who asked before) you have the problem on Windows or
Linux, I could probably diagnose it with more information.
If it is mac, were you using the version posted in
On Tuesday, August 16, 2022 at 3:25:26 PM UTC-4 Florian Königstein wrote:
>
>> But I took parts of the old code and built a command line utility named
>> Hugin2PTOptimizer that converts a Hugin .pto file to a .pto file readable
>> by PTOptimizer.
>> I have messed a bit around in the code and
I wish my panoramas came together as well or as easily as that one.
After I emailed back the .pto with several garbage CPs removed, I tried
stitching and the result is better than I've ever gotten without major
effort.
The automatic CP detection sometimes creates a few garbage ones. If I
I'm not seeing at all what I expected. So I may have been entirely wrong
about all that lens stuff. So ignore most of what I said.
Instead you have some very very wrong control points that must be deleted
and that might be the only important problem.
For example the two CPs connecting image 0
On Friday, August 12, 2022 at 12:37:53 PM UTC-4 Florian Königstein wrote:
> Probably it's best here to first optimize only raw, pitch and roll and
> then only translations.
I gave that a lot of thought, and I have not yet coded/tested what I
decided to do instead. But I think there is a
Your last two posts seem to be about one image. I assume you have more
than one to combine via hugin.
So when I asked about the different exposures across the multiple original
images, I think that was important. I don't see any answer.
I'm still guessing that hugin is adjusting the
On Wednesday, August 10, 2022 at 5:15:33 PM UTC-4 bruno...@gmail.com wrote:
> On Wed, 10 Aug 2022, 22:07 johnfi...@gmail.com, <> wrote:
>
>>
>> I still hope this question gets a reply from someone who does know what
>> those parameters are intended for and what o
Can you clarify some points. (I'm partially asking in case this helps
someone else give you a better answer, but also because I also want to do
some dynamic range things better in hugin than I currently know how to, so
I think your clearer question might draw out a better answer for me).
Your
On Wednesday, August 10, 2022 at 3:24:57 PM UTC-4 Florian Königstein wrote:
> I searched all source code files of Hugin++ for the string "tilt" (e.g.
> there could be variables tilt_x, tilt_y, tilt_z like in libpano13). But
> there wasn't found anything.
> So Hugin probably does not use tilt.
Do the Pano13 tilt parameters TiX, TiY, TiZ and TiS exist in some form in
Hugin or only in libpano13?
What are they tilting?
Looking at the code, I can't backtrack from implementation to intent.
They are effectively lens parameters, right?
I am thinking in terms of a division between lens
On Tuesday, August 9, 2022 at 1:38:07 PM UTC-4 Florian Königstein wrote:
> Some time ago I tried whether analytical calculation of the partial
> derivatives is better (faster convergence). I wrote code for analytical
> calculation (via automatic differentiation), but it seemed that there was
I worried this sidetrack of the discussion may be stopping someone who
knows more about the answers I'm looking for from replying in this thread.
I really want a better understanding of why results differ so much in the
same optimization problem among version and builds of pano13 (and maybe of
On Monday, August 8, 2022 at 3:29:44 PM UTC-4 Florian Königstein wrote:
> Before I answer to your post more detailed, could you please send me the
> images per Mail so that I can load the pano without the need for dummy
> images. Maybe the optimization was faster for me since some CPs were
>
On Monday, August 8, 2022 at 11:32:07 AM UTC-4 Florian Königstein wrote:
> Hi John,
>
> Optimization ran fast for me,
>
What is "fast" and which hugin did you use?
It runs "fast" (17 to 36 seconds) using any build of pano13 with sparse
lev-mar. But I still want it to be faster and I want
Despite trying to be careful in testing and organizing the above, I seem to
have made a big mistake on the Z axis.
My testing actually shows Hugin's TiX, TiY and TiZ are not a right handed
coordinate system. Then I missed that fact in reporting those results.
Maybe my test was wrong.
The
Is there a place in the hugin documentation that explains the axes and
directions hugin uses?
Both as a user and as a developer, this is a topic I have repeatedly
needed, looked for, failed to find, experimented and learned, and then
forgotten. Until I recently finally took notes.
I
On Monday, August 1, 2022 at 5:44:47 PM UTC-4 GnomeNomad wrote:
>
>
> I have panoramas that were about 2GB as 16-bit TIFFs that became about
> 600-700MB as 100% quality JPGs. So what quality setting are your JPGs at
> to give you a 15x difference?
>
My results are somewhere between those.
On Monday, July 4, 2022 at 2:51:54 PM UTC-4 mpgve...@gmail.com wrote:
> i do not understand where i can enter those command, i did not see a
teminal field in the gui and windows command prompt says it does not know
nona.
You use some form of windows command prompt and you do something to fix
On Monday, August 1, 2022 at 6:54:46 AM UTC-4 davi...@gmail.com wrote:
>
>
> Where the camera has an advantage is that it knows precisely how the
> sensor behaves, when and where it will create the most noise and what kind
> of noise, maybe even detect different kinds of surfaces and apply
On Sunday, July 31, 2022 at 2:49:59 PM UTC-4 irthoma...@gmail.com wrote:
> I see, thank you for the detailed reply. Does that mean that you are
> working with jpg files? I haven't dug into the code. Why not just use some
> temporary folder for the tiffs, and erase them when finished?
>
> I
On Monday, July 25, 2022 at 2:29:46 AM UTC-4 koga...@gmail.com wrote:
> I have been wanting to stitch aerial images for a long time but never
> succeeded. But I guess it's not possible to stitch them because of parallax
> mistakes in the pictures.
I would expect aerial images of mountains
In case this wasn't obvious and implied by your post, the error in the code
is exactly where the seg fault occurs:
hugin/src/hugin-2021.0.0/src/hugin_base/hugin_utils/utils.cpp:475
475 if (strlen(xdgDataDir) == 0)
Seg faults often indicate a bug in a distant place, that may be hard to
I added an experimental Equalize option to a branch of Hugin++
I would appreciate any feedback from those trying it and/or looking at the
source code and/or knowing more on the theory side than I do (which
wouldn't take much).
The idea is to modify the individual brightness levels monotonically
I made a fork of vigra, plus a tiny change to hugin++ so that hugin++ can
directly use ARW files rather than first converting them to TIFF. Very
little extra would be needed to support other formats supported by libraw.
I strongly dislike the directory clutter of the current hugin method of
On Wednesday, May 25, 2022 at 9:17:01 AM UTC-4 raywood wrote:
> > Please enter the horizontal field of view (HFOV) or the focal length and
> crop factor.
>
> I'm not sure what those values would be.
>
> What's the best way to use Hugin with screenshots?
>
A Panorama in the real world
Control points coordinates allow fractions of a pixel (1/3 pixel at a time
when moving via arrow keys. Even finer detail for "fine tuning" results).
What is the precise meaning of the coordinate relative to the pixel?
Imagine each pixel as a square in a very magnified image. I would expect
On Friday, May 13, 2022 at 2:37:51 AM UTC-4 kevin@gmail.com wrote:
> I couldn't figure out where libpano13's authoritative source repository
> is, or how to submit a pull request or equivalent, so I've attached the
> patch against libpano13 v2.9.21 here.
>
The project is here:
I received an email with more info on this failure. I thought I had the
right tools to translate the addresses for the official hugin build. But
it appears I don't.
I expect someone with a proper windows build environment for hugin can.
The important part of the XML file seems to be:
When building hugin++ you need to use FastPTOptimizer instead of libpano13.
https://sourceforge.net/projects/fastptoptimizer/
Your error message doesn't match the error I got when I used the original
libpano13 for hugin++, but your error is the kind of error I would expect
for that, so I think
On Sunday, April 17, 2022 at 1:03:09 PM UTC-4 Florian Königstein wrote:
>
> When you will have merged it, I can create new Windows binaries.
>
In case you (or anyone else) wants to try them, I have Windows binaries.
My build method (MINGW64) is different in the layer (not sure what it is
On Sunday, April 17, 2022 at 10:32:12 AM UTC-4 Florian Königstein wrote:
>
> At the moment I cannot see when the "jump around" in the old version
> occurs. What I see (in both versions) is that when scrolling via scrollbar
> so that a CP gets out of view and then scrolling back FAST,
On Thursday, April 14, 2022 at 6:25:53 AM UTC-4 Noveguy wrote:
> Thank Bruno for the tip. Unfortunately, I am using Windows now. But I
> think I could write some C# code to do that.
There are many different sources for linux tools (with or without including
and depending on a copy of bash)
You might want to jump down to the "TESTING" section below before reading
all this concept level content:
In a branch of the Hugin++ fork of Hugin, I fixed a bunch of minor bugs
that Hugin has display of CP labels and magnifier. After I do some other
related enhancements and corrections, all
On Monday, March 14, 2022 at 9:17:34 PM UTC-4 johnfi...@gmail.com wrote:
>
> Reviewing it, I now understand
>
> Actually, I was even more wrong that time.
I'm gradually understanding more about this problem, but still don't know
the basic cause.
When wxUSE_TASKBARBUTTON is defin
src/hugin1/hugin/huginApp.cpp:382:5: error: 'wxTaskBarJumpList' was not
declared in this scope
src/hugin1/ptbatcher/BatchFrame.cpp:1291:9: error: 'wxTaskBarButton' was
not declared in this scope
I seriously misunderstood the situation when I kludged past the above
problem earlier.
Reviewing
On Friday, March 11, 2022 at 3:46:32 PM UTC-5 johnfi...@gmail.com wrote:
>
> Are the functions float2rgbe and rgbe2float supposed to be exposed to
> clients of libpano13? Or are they purely internal? Currently in Linux (at
> least the Fedora package and my own buil
Due to the way inline works in c in gcc, I got errors building a debug
build of libpano13 in fedora.
I know several different ways to fix the problem. But I don't know enough
about all the ways libpano13 might be built and/or used to have a safe
opinion on which way is best.
Despite reading
On Wednesday, March 9, 2022 at 11:17:29 AM UTC-5 comp...@gmail.com wrote:
>
> Here is my guess as to, “What does calibration offer?”
> I think calibration identifies the corrective factors needed to remove or
> minimize pincushion/barrel and perspective distortion.
> I’m guessing that Hugin
On Wednesday, March 9, 2022 at 7:02:07 AM UTC-5 gunter.ko...@gmail.com
wrote:
> You can remove exzessive overlap by adding a mask that removes part of an
> image.
> But I wonder if too much overlap should be a warning, not a "error out and
> delete all the evidence" case...
>
I'm pretty
On Monday, March 7, 2022 at 1:13:45 PM UTC-5 gunter.ko...@gmail.com wrote:
> If two classes have nothing in common from the implementation side
> deriving them from the same base class still might have a big advantage:
> You can make a pointer to an object of that base class and access all
I don't understand your question and/or your intent.
You have a panorama that has been formed into a reasonable single image by
some projection. You want to add an image to fill the hole on top, which I
expect means that same projection would no longer be reasonable. I think
no projection
As a user, I'm bothered by a few behaviors of the Create control points
button in the Photos tab. Before fixing those in my own copy and/or in the
fork of hugin that I am working on, I'd like to get some opinions on:
Why it does what it currently does.
Why that might be the way other users
On Friday, February 11, 2022 at 8:07:30 PM UTC-5 eljef...@gmail.com wrote:
>
>
> I would greatly appreciate reports on compilation problems. I have NOT
> worked with the CMake files, I've only updated my local Makefile.
>
It compiled fine for me (using the CMake changes Thomas gave you) on
I just finished building a fork of hugin and a fork of libpano13 and
unmodified enblend on Windows using MSYS2 / mingw64
I tested barely more than opening an existing project, so there is a good
chance some operations won't work because of errors I made in building.
I ran into a massive string
I would appreciate some suggestions on what operations in Hugin are slow *and
*likely to be significantly affected by the quality of code generated by
the compiler.
Most slow operations in image processing are dominated by cache misses, so
the compilation quality makes no actual difference.
Thankyou.
On Saturday, March 5, 2022 at 11:01:24 AM UTC-5 eljef...@gmail.com wrote:
>
> https://drive.google.com/drive/folders/1ds5QHI4qNYqXOLNexS0Ov6Ll14HnhkSV?usp=sharing
>
> Hopefully you can see those files.
>
Not yet. I clicked on the "request access" button.
>I retract my advice
I have many small isolated gaps in the sky of my photos from my recent
vacation. That is a bit different from the example use of FillSky.
Given how many different things I'm trying to learn to use at once now, I'd
appreciate knowing whether FillSky is the right tool before I take time to
On Thursday, March 3, 2022 at 3:11:34 PM UTC-5 bruno...@gmail.com wrote:
>
> The libpano13-devel rpm package only exists for you to compile and link to
> the libpano13 rpm package in /usr. Just uninstall it and your Hugin build
> will pick up your forked libpano13 headers in
On Thursday, March 3, 2022 at 1:42:25 PM UTC-5 Florian Königstein wrote:
> I have limited knowledge in Linux, so I cannot say much about that.
>
> Did you take fastPTOptimizer from
>
> https://sourceforge.net/projects/fastptoptimizer/files/libpano13-2021-06-07.zip/download
>
No.
> or from the
I am building a fork of hugin
https://sourceforge.net/projects/huginplusplus/
That requires a fork of libpano13
https://sourceforge.net/projects/fastptoptimizer/
I don't think my issues are specific to those forks. Likely this is just
my ignorance regarding CMake.
Are there options I should
Thomas, is there any way that I could code/commit creation of a common base
class for CPImageCtrl and MaskImageCtrl that you would consider acceptable
to be merged to the default branch?
I think it would improve the maintainability of that code. I think it
would also give me a clearer way to
Is there a file format that is better than ordinary formats for the result
of combining photos with different resolutions?
I want to combine two photos, where one is a higher resolution image of the
most interesting feature in another. When viewing on a computer, I want to
be able to zoom in
How do I stop enblend from removing the result?
The message in the log is:
enblend: warning: some images are redundant and will not be blended
enblend: note: usually this means that at least one of the images
enblend: note: does not belong to the set
enblend: encountered degenerate image/mask
On Tuesday, February 22, 2022 at 11:13:34 AM UTC-5 T. Modes wrote:
>
> For the synchronized scrolling the images need some overlap. If the
> overlap is too small it does not work so good, but for a normal overlap it
> works here.
>
> I tested with about 30% full image overlap on Windows and
On Monday, February 21, 2022 at 7:50:20 PM UTC-5 eljef...@gmail.com wrote:
> Okay, I just did that test. I have a different explanation -- the output
> results from the optimization report errors relative to the output
> horizontal field of view. I took a pto file, ran the optimization
On Monday, February 21, 2022 at 6:26:54 PM UTC-5 eljef...@gmail.com wrote:
> 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.
>
I should have repeated my earlier statement that my committed code should
only be tested with non-float images. It has a serious performance flaw
for float images. That should be easy to correct, but I expected you to
have a strong opinion on where/how that should be corrected, and I thought
If I missed something in the documentation related to this, I'd appreciate
being told where that is.
How do the Stitcher parameter values modify the action of the Optimizer?
In experimenting with how well certain actions made a project fit, I was
confused over what seemed to be wildly
On Monday, February 21, 2022 at 5:52:13 AM UTC-5 bruno...@gmail.com wrote:
>
> The XYZ Translation parameters are initially hidden as they are not needed
> for normal usage, they are made available by selecting Menu -> Interface ->
> Expert.
>
> That is one of the reasons I think only the
On Sunday, February 20, 2022 at 4:52:32 PM UTC-5 scott092707 wrote:
>
> New problem:
>
> I have a two-photo vertical panorama of a building (with a neat bunch of
> sculptures at the top), and despite indicating the entire sides of the
> buildings in each photo of the same lines - bottom to
On Sunday, February 20, 2022 at 10:55:26 AM UTC-5 T. Modes wrote:
>
> I asked you several times not to mix up several things in one commit. You
> still mixed up several unrelated code changes in one changeset. (Yes, they
> have both the same target. But the code changes are totally unrelated.
I pushed the change discussed here to my branch.
Hopefully someone else will try building and testing it.
With this change, higher zoom level no longer affects memory use: All
levels other than 100% and "fit" have the same memory use as each other,
and that memory use is lower than any of
Other than field of view, what parameters are able to produce wrong results
that have lower total error than any correct result?
If I understand correctly, that is the major reason for wanting limits.
But in case I've misunderstood:
In many other optimization problems hard limits are used to
On Thursday, February 17, 2022 at 1:23:54 PM UTC-5 gunter.ko...@gmail.com
wrote:
> I don't know if that is the case here. But if the GUI feels sluggish one
> typical reason is that you try to update the display for every single mouse
> event you get sent (which means that if you draw
I recently rewrote my local change for saving memory in the CP editor, to
make it more suitable for committing on the branch with my other changes.
I ran into a bunch of performance side issues (yes, it saves memory, but
the savings vs. cost in cpu time are a much trickier topic).
I have only
I think that problem is important and ought to get some attention and can
be solved.
But I think your suggested solution would not be effective. Either the
user would need to know enough in setting the limits that they might as
well just set the value and not optimize the variable, or
On Friday, February 11, 2022 at 3:24:32 PM UTC-5 dkloi wrote:
> If provide the raw files, maybe we could give it a shot. Are you able to
> show what you are getting?
Thanks for the offer. But this time I'd rather not share the photos (and
they were not raw, they were from my cell phone,
In case someone chooses to test this (push several points of a mask close
to each other, then try to select one to move or delete, etc.), I should
point out that
I did not yet post the related correction to the code used when you CTRL
click on a line to create a new point. That is the same
I finally went back to that set of 3 photos and got a good result. I'm not
happy with the methods required. There is probably a better way. I'm open
to advice on what to try next time. There should be a better way, so in
any case I'll look through the relevant parts of the source code to
On Thursday, February 10, 2022 at 7:00:05 PM UTC-5 johnfi...@gmail.com
wrote:
> A slight rearrangement of conditions inside my code would directly fix
> the problem you described.
>
> Since you have seen symptoms of the basic issue I described, does that
> mean you would li
On Thursday, February 10, 2022 at 6:41:27 PM UTC-5 bruno...@gmail.com wrote:
>
> I experience this as trying to drag one node, but Hugin insists on
> dragging the previous (highlighted) nodes instead, which would make
> sense, but somehow the highlighted nodes seem to be more likely to get
>
After playing with it a bit, I understand how it might have been the way it
was due to not caring about the behavior of points close together (rather
than explicitly wanting them to act that way) while wanting an interface
that supported the explicit method of supporting multiple points
When points are very close together in a mask, you can't select just one to
move.
I understand having the points so close is not typical. But the code seems
to have been written anticipating points being that close together and
intending that a single click should select all the nearby
On Sunday, February 6, 2022 at 6:55:26 PM UTC-5 bruno...@gmail.com wrote:
>
>
> I thought this startup crash had been resolved by automatically
> disabling the Fast Preview window in this situation (it has been a
> long time since it was last reported). If the Ctrl trick is definitely
>
I eventually found out the method (hold ctrl while starting hugin) and then
found the place that is documented for re enabling fast preview window (it
brings up a dialog that lets you choose). But I didn't find any
documentation of using that to avoid the crash on hugin statup that might
On Saturday, February 5, 2022 at 8:35:00 AM UTC-5 gunter.ko...@gmail.com
wrote:
> Could wxImage::GetSubImage and then scaling the resulting portion of the
> original image in CpImgCtl::OnDraw do the trick?
>
Yes. That does work. I was intending to do something that works much
better than
On the branch with my previous CP Editor change, I pushed code to provide
400% and 800% zoom choices.
*slow and ugly:*
Currently, 400% and 800% are slow and ugly. I have plans for changing both
those things.
But I have been using them this way for a while, and for my use having
those choices
On Friday, February 4, 2022 at 10:55:04 AM UTC-5 T. Modes wrote:
>
> Hugin is bad in upscaling. When doing high upscales you will often see
> interpolation artefacts, which is not what the user wants and what is
> helpful. So I don't see the point of make this configurable.
>
It already was
On Friday, February 4, 2022 at 10:40:38 AM UTC-5 T. Modes wrote:
> do a clean rebuild.
>
> Thanks. It was fixed by *make clean*
I should have tried that earlier. I was trusting the build system to know
what needed to be rebuilt.
--
A list of frequently asked questions is available at:
So far as I can tell, two members of the PanoramaOptions object share the
same address.
I don't yet understand the relationship between Hugin and panotools.
This kind of error usually implies using a .h file connected with a .so
file when the two are out of sync with each other.
So does this
I got the backtrace from gdb (easier than I expected):
--
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
Sorry, I didn't realize before posting, that even my screenshot failed.
I really hate how aggressively kdbg stops you from copying information
out. But it is the only debugger I managed to get working with hugin in
Fedora. I'll try again with gdb and provide a better traceback.
--
A list of
If I did this right:
I created a branch JohnsWork
I pushed one commit containing phase 1 of changes to add preferences for
the behavior of the magnifier in the CP dialog.
In the preferences for the CP dialog, there are three new entries, all in a
section named magnifier. The first two were
On Wednesday, February 2, 2022 at 2:36:28 PM UTC-5 Luís Henrique Camargo
Quiroz wrote:
>
>John just told us about another annoyance that I, while adding manually
> my control points, see all the time. I put the text in bold, in his first
> paragraph below.
>I even tried, in vain, to
On Wednesday, February 2, 2022 at 11:38:37 AM UTC-5 T. Modes wrote:
> bruno...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 23:20:14 UTC+1:
>
>> On investigation, it looks like the magnifier doesn't appear when you
>> click down on a control point, it only appears once you have dragged it
I wasn't giving proper attention to where the mouse was hovering when I was
trying to understand the magnifier behavior. I was instead thinking about
where the last mouse click had been, which doesn't seem to matter as much.
In testing now, it seems that the magnifier appears when the hovering
On Tuesday, February 1, 2022 at 12:34:49 PM UTC-5 T. Modes wrote:
>
> Just to recapitulate how the magnifier work:
> a) When a cp is selected (via the list or by clicking on it) the magnifier
> is shown. As soon as the mouse moves over one image it is hidden. -> So no
> need for an additional
On Tuesday, February 1, 2022 at 11:48:46 AM UTC-5 T. Modes wrote:
>
> The disabling of the magnifier for the 200 % view was added as a feature
> request. So there are uses which prefer this.
>
I really hate that feature and I don't even get why someone else might like
it (unlike the timer
On Tuesday, February 1, 2022 at 11:48:46 AM UTC-5 T. Modes wrote:
> It is difficult to comment because you are often mixing things. Or as an
> example you contradict yourself
>
> johnfi...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 15:41:14
> UTC+1:
>
>> Hiding
On Tuesday, February 1, 2022 at 11:31:43 AM UTC-5 Luís Henrique Camargo
Quiroz wrote:
>
> What about keeping the views at 200% and just the magnifier (or a
> bigger one) at the intended 400 and 800%? So the left and right views would
> show a bigger field of view.
>
I think what I plan
If there are no objections (in time before I actually do it) I will make a
branch and make the small change described here as my first (of I expect
many) commits on that branch.
If there is any disagreement on details (rather than overall objection to
the change), please tell me that as well.
On Sunday, January 23, 2022 at 8:36:58 AM UTC-5 gunter.ko...@gmail.com
wrote:
> Do we really have to magnify all of the image if afterwards only a small
> portion of the magnified image fits on the screen? For me that feels like
> an use of something similar to wxScrolled: wxScrolled tells
On Tuesday, February 1, 2022 at 6:56:17 AM UTC-5 bruno...@gmail.com wrote:
>
> The remapping and stitching is performed as usual by the Hugin toolchain,
> ptomorph just manipulates the input images a bit to make them stitch better.
>
By "input" do you mean original? I can't imagine how that
On Monday, January 31, 2022 at 5:35:33 PM UTC-5 bruno...@gmail.com wrote:
>
> If not, then send me your sourceforge username. Note that sourceforge
> supports a fork/pull-request workflow (similar to github), so you can
> work on a separate personal repository just as easily as the main
>
On Monday, January 31, 2022 at 5:06:20 PM UTC-5 bruno...@gmail.com wrote:
> See the ptomorph proof of concept from ten(!) years ago here:
> https://groups.google.com/g/hugin-ptx/c/UripOuuYXCQ?pli=1
>
> This works incredibly well, with no need for low-priority control
> points, but I never
1 - 100 of 147 matches
Mail list logo
