Thank you so much for your time, I'll try to follow the steps and learn!
I may come back to ask about some stuff.
For instance, I'd prefer image 2886 to prevail, but in my tests that makes
everything go wrong, the image you have picked seems to provide the best
alignment.
I'd like to be able
Hi, Mihai!
How I got this
Note: I use Linux and don't have Photoshop, so I viewed the panorama you
provided in GIMP.
I use the Expert interface in Hugin.
I shoot handheld panoramas all the time, so I used my usual process.
Steps
1. Converted CR2 to 16-bit TIF images using RawTherapee.
2.
On 1/31/22 11:41, johnfi...@gmail.com wrote:
> 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
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 Tue, 1 Feb 2022, 17:53 johnfine wrote:
>
> I hope Bruno and others will answer your question, because I'm pretty sure
> Bruno disliked the current magnifier hiding and would be more competent to
> explain why and/or have more mainstream reasons.
>
I never really considered the possibility
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
johnfi...@gmail.com schrieb am Dienstag, 1. Februar 2022 um 18:15:24 UTC+1:
> 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
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 would only be
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
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 would only be temporary: other actions make the magnifier appear
> and "hiding" would not suppress
That might be a point: If you want to hit exactly the right pixel on a retina
display you'll have to resort to a powerful magnifier. If you find the right
part of a scene on my 1280x800 screen a 8xmagnifier might instead be a way to
get completely lost while a 1x magnifier will introduce
Hi John!
I have never really used 200% magnification, and the lack of the
magnifier in it was the culprit. Even if the magnification were low, an
important feature is the "high contrast" the magnifier provides.
What about keeping the views at 200% and just the magnifier (or a
On Tue, 1 Feb 2022 at 12:53, johnfine2017 wrote:
> 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
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.
I recently explore using the Capture One (22) HDR pano merge/stitch. I was very
disappointed in the resulting image; there were weird chroma and luminance
noise problems. I was able to isolate the problem to the HDR merge, the pano
stitch was ok, but not as good as Hugin. Merging in Photomatix
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 Mon, 31 Jan 2022 at 22:42, johnfi...@gmail.com
wrote:
> 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,
19 matches
Mail list logo
