Fit the resulting image as in ACR/PS?

[Mihai Dobrescu]

Hello, how the stitched image could be fit as in Photoshop/Adobe Camera RAW?

Here is how the ACR image is morphed to fit: IMG_2682-2690_Pano.jpeg

Here is how I've managed to do it in Hugin: IMG_2682 - IMG_2690_blended_fused.jpeg

Note, ACR/PS produce a larger jpg. The ACR one is 17.1 MB, at a quality level of 98, but I had to  reduce its quality in order to attach it.

The idea is to get as much as possible from the resulting pixels.

For example, the left and the right sides are stretched vertically to cover all the rectangle area in the resulted image.

Also, it is taken more from the bush in the approximately middle-lower part. Here is why:

Thank you in advance!

Mike

[David W. Jones]

On August 1, 2019 6:08:26 PM HST, Mihai Dobrescu <msdob...@gmail.com> wrote:
>Hello, how the stitched image could be fit as in Photoshop/Adobe Camera
>RAW?
>

>Here is how the ACR image is morphed to fit: *IMG_2682-2690_Pano.jpeg*
>Here is how I've managed to do it in Hugin: *IMG_2682 -
>IMG_2690_blended_fused.jpeg*

>Note, ACR/PS produce a larger jpg. The ACR one is 17.1 MB, at a quality
>
>level of 98, but I had to reduce its quality in order to attach it.
>
>The idea is to get as much as possible from the resulting pixels.
>For example, the left and the right sides are stretched vertically to
>cover
>all the rectangle area in the resulted image.
>Also, it is taken more from the bush in the approximately middle-lower
>part. Here is why:
>
>

>Thank you in advance!
>
>Mike

Autocrop in Hugin?

By the way, I think Hugin's blended-fused version handled the exposure much better than Photoshop did.



--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

Sent from my Android device with F/LOSS K-9 Mail.

[Mihai Dobrescu]

Autocrop did not do enough, meaning, as explained before, it let the image not rectangular and omitted too much compared to what I need (ACR is for reference, but can morph the image to the desired rectangle, having a slider for the morphing adjustment).

The feature would be very useful if missing and should not be a big deal as long as it morphs the images for stretching to the control points.

As for the image treatment, I have created a profile in RawTherapee and served it to Hugin (for the colours, sharpness exposure and so on).

Any ideas?

[David W. Jones]

Hmm, autocrop would have cropped it to a rectangle, yes? Did you
autocrop, change the zoom on the image, then not autocrop again?

I would have output the image as 48-bit TIFF and processed it in
LuminanceHDR. But it still looks better than what Adobe seems to have
come out with.

Or did you do the processing, then feed the finished image into Hugin
for stretching or something? Sorry, it's Friday and I may be confused.

[Mihai Dobrescu]

Hello, here is Saturday already.

The image processing is one thing. I have made my own sidecar for that and this is subjective. I did it with the help of RawTherapee team member heckflosse, who corrected the 400D support in RawTherapee.

I did not spend time to make similar processing in ACR.

My idea is to fit the Hugin result better. This needs more bending, if you like. More morphing.

It's the opposite of cropping, but I think it's similar to the image slices morphing in the stitching process.

The goal is to take a bit more from the source images.

In this particular case, for instance, I'd like to be able to alter the result boundary in the left bottom part by stretching it from the curved border it is now to a straight line. And so with all the other corners.

I am aware this means a bit of deforming, but it's acceptable if some value could determine how much. Maybe to go partially, like half way, from the curve it is now to some less curvy shape, in order to take some more from the pixels left out at this point.

See?

[David W. Jones]

Hmm. You might able to use control points on vertical lines positioned on the sides of the images?

There are tutorials online on using control points and lines to correct architectural or perspective distortions due to camera POV and angles. Maybe they could be adapted for your purpose?

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

[Mihai Dobrescu]

I can't find some clear tutorial.

Do you have some examples, please?

[Mihai Dobrescu]

Found it, Move/Drag does what I need. Awesome!

[David W. Jones]

On August 2, 2019 10:02:08 PM HST, Mihai Dobrescu <msdob...@gmail.com> wrote:

Found it, Move/Drag does what I need. Awesome!

Hurrah!

[Mihai Dobrescu]

Not quite.

1. Can't skew, or I don't find the means

2. I have reset the flow, made a new project, it generates strange results from the same source images.

[Mihai Dobrescu]

I have nine images to make the panorama above.

I think there is no way to set the images z-order, so I serve them in my order, to get the best out of the central bush.

By comparison to the custom ordering, the natural order of images (meaning adding them in Hugin in their naming order, given by taking them from left to right) produces a similar result to the ACR's regarding the stitching, but cropped to the bottom and top, and not stretching the maximum content of the images as ACR does. See the top right corner branches, for reference.

The custom ordering produces anomalies - the most notorious being the little canyon in the image that has the bottom part of the V shifted.

I presume I should provide some masks in order to use the natural ordering and force having the bush taken from the desired image.

Still, it's a lot of work to do compared to what ACR does automatically, in therms of productivity...

[Mihai Dobrescu]

 How would you stitch these photos in order to get as much as ACR does?

[David W. Jones]

Here's what I did:

1. Selected images in folder, right-clicked, used Open with Hugin PTO
generator.

2. Opened the PTO file.

3. Under Feature Matching, ran CPFind with the CPFind + Celest option.
If found a lot of control points.

4. Also under Feature Matching, ran the Vertical Lines option. It found
nothing.

5. Under Optimized, Geometric, ran Positions (incremental starting from
anchor).

6. Right-clicked in the list of file names, used Control Points > Clean
control points.

7. Under Optimized, Geometric, ran Everything without translation.

8. Looked at panorama with Fast Preview Panorama:
Clicked Center. Top and bottom were quite curved. Panorama was also angled.
I dragged the right side of the image until it looked straight.
Under Projection, tried various Cylendrical projections. Panini seemed
to look like what it sounded like you wanted.

9. Did Center and Fit again, then autocropped.

10. Closed Fast Preview Window.

11. Saved panorama, went to Sttch and clicked on Calculate Optimal Size.

12. Saved again and stitched.

Got something that looks just fine to me! But maybe I'm not entirely
sure what you're looking for. Attaching the PTO, let me know if you want
the stitched image.

On 8/5/19 8:30 AM, Mihai Dobrescu wrote:
>  How would you stitch these photos in order to get as much as ACR does?
>

> IMG_2682.jpg
>
> IMG_2683.jpg
>
> IMG_2684.jpg
>
> IMG_2685.jpg
>
> IMG_2686.jpg
>
> IMG_2687.jpg
>
> IMG_2688.jpg
>
> IMG_2689.jpg
>
> IMG_2690.jpg

[David W. Jones]

On 8/4/19 9:34 AM, Mihai Dobrescu wrote:

[snip]

> I think there is no way to set the images z-order, so I serve them in my
> order, to get the best out of the central bush.
> By comparison to the custom ordering, the natural order of images
> (meaning adding them in Hugin in their naming order, given by taking
> them from left to right) produces a similar result to the ACR's
> regarding the stitching, but cropped to the bottom and top, and not
> stretching the maximum content of the images as ACR does. See the top
> right corner branches, for reference.

I don't worry about the order photos are in. The real order is
determined by the control points CPFind sets. See my other post about
what I did.

[Mihai Dobrescu]

Thanks, but I have done 2 projects, one with images in one order, one with two switched places and the results differ. The image order matters, the first images go on top of next images.

I'll study your approach now. Thank you.

[Mihai Dobrescu]

Thanks for the fast reply and for your time spent on it!

I am at a Windows computer now, usually I use Linux, but I can't access Linux now.

I don't know why, despite I have tried, despite I use the latest Windows binary (labeled as 2019), I don't have or I can't find an "Everything without translation" option.

Also, can't handle this part of "I dragged the right side of the image until it looked straight.", it simply snaps to the center of the processing area.

It is nice, but my idea was a bit different because I try to do something I always do in ACR very easy: think however you like about it, either expand the middle part of the projection, either compress the top-left and top-right corners of the projection, in order to make a rectangular image having the most of the image. Look at the original ACR: IMG_2682-2690_Pano_low_quality.jpg

It takes a lot more, if you look at the top-right area, the branches are there entirely. And look pretty natural.

My idea is not necessarily to have the same pixels as in ACR, but to take more out of the image.

For me this is not a contest between ACR and Hugin. It's an attempt to get rid of the big annoyance the Adobe's OS'es of choice are that lead me to move to different tools.

BTW, why Hugin generates a smaller image than ACR? ACR makes a 8655x2645 image, Hugin a bit more than 6000x...

If I try different lens or projection,m I should be able to mold, to reshape the projection to a rectangle (maybe not completely, to some degree, as in ACR).

This is done by setting a value with a slider in ACR...

The architectural tutorials I've found seem not to be applicable, as long as are done on a single image, making here that in two steps is overkill and less flexible if I need to go back to stitching again if I need something to be fixed or reworked. It's not that I'm lazy, it's simply unproductive.

Also, I have some strange behavior of Hugin when aligning in the simple interface. It changes the lens type and the projection to equirectangular all the time. Is this expected?

Best Regards.

[Mihai Dobrescu]

Hi, to add a sample of what I say, look here: https://youtu.be/cjSXkeRX2pQ?t=120

It is an extreme example, it's not the wanted result for the city panorama case, but would be very helpful in cases similar to mine, where a small adjustment does the job.

Is there any possibility to do that in Hugin?

Thank you.

[David W. Jones]

Hi, Mike!

On 8/6/19 8:49 PM, Mihai Dobrescu wrote:
> Thanks, I've got some other feed-back on my e-mail (don't know why
> giving up posting on the thread), that uses GIMP's cage. I'll try this once.
> I know ACR is more than Hugin, but I compare it's panorama related
> features only.

I think it can do what you want it to do. I only poked around with it
for about 10 minutes. And that was the first time I've ever used GIMP's
cage transform tool!

> I am discussing the boundaries warp in ACR. I keep thinking that it
> would be a nice feature to add that to Hugin and, despite I did not
> check the source code, I think something is already there for morphing
> the images at the alignment step, but these are at individual images
> level. Could be applied to the resulting projection though, to some
> degree, probably not automatic, unless some threshold is set related to
> the remaining parts, but manual, using some numerical value or some
> slider. This would increase the productivity and let the people process
> it in GIMP if they consider to.

I think Hugin has a foundation that could be used to build a cage
transform tool. Something like the Mask tool but one that marks the
transform points and would be applied after the image has been stitched.

Would be an interesting feature request!

> Now, knowing Hugin better and using it for days just to check it's
> power, I'd say its interface is missing some minor concept change. I
> barely see the difference between advanced and expert mode (probably I
> didn't come that deep?) and I'd have two interfaces open at once, the
> expert and the simple one, because they complete each other and would
> help somebody adjust the panorama in certain condition.

Two interfaces open? Or are we mixing up the main Hugin window and the
Fast Panorama Preview window? I don't think we can have two different
interfaces (Interface > Simple, Advanced, Expert) open at the same time.

But the presence of the two windows confuses people regularly. There was
talk of merging them somehow, quite a while ago. My vote would be to
make the Fast Panorama Preview the only window, but that's just me. My
UI design experience was very light and many years ago!

I agree, the Advanced and Expert interfaces seem to have very little
difference between them. I don't think there are any 'automatic' actions
in the Expert interface like there are in the Simple interface, so I'd
just pick the Expert interface and use it. (If that's what you mean by
separate interfaces.)

> Now, after reading Hugin tutorials and about alternatives as much as
> I've found with google, I have a question: what is PTGui in relation
> with Hugin? Is PTGui based on Hugin? Is there a relation between the
> teams, similar to Wine and Crossover?

PTGUI is a different user interface to the Panotools library. I don't
think the teams are related in anyway. PTGUI is for Windows and MacOS
only, costs money and isn't open source. Hugin is free open-source software.

Others on the list would know about that much more than I do.

> Regards,
> Mike
>
>
> On Wed, Aug 7, 2019 at 8:35 AM David W. Jones <gnome...@gmail.com
> <mailto:gnome...@gmail.com>> wrote:

>
> On 8/5/19 8:25 PM, Mihai Dobrescu wrote:
> > Thanks for the fast reply and for your time spent on it!
> > I am at a Windows computer now, usually I use Linux, but I can't
> access
> > Linux now.
> > I don't know why, despite I have tried, despite I use the latest
> Windows
> > binary (labeled as 2019), I don't have or I can't find an
> "Everything
> > without translation" option.
>

> In the Expert interface: Photos tab > Optimize > Geometric > Everything
> without translation.
>
> Mine is v2019.0.0.a369cbe55179, according to Help > About. Everything
> without translation has been in Hugin for longer than I've been using
> it, so I don't think it's been removed or lost.

>
> > Also, can't handle this part of "I dragged the right side of the
> image
> > until it looked straight.", it simply snaps to the center of the
> > processing area.
>

> In the Fast Panorama Preview window, I left clicked on the gray area
> around the image, held down the button, and dragged the mouse down.
> That
> rotated the image.

>
> > It is nice, but my idea was a bit different because I try to do
> > something I always do in ACR very easy: think however you like
> about it,
> > either expand the middle part of the projection, either compress the
> > top-left and top-right corners of the projection, in order to make a
> > rectangular image having the most of the image. Look at the original

> > ACR: *IMG_2682-2690_Pano_low_quality.jpg*
>
> I see. I think ACR is doing a lot more to the image than just making a
> panorama of it. I fact, it looks like ACR is then running a cage (or
> some other) transformation on it afterwards.

>
> > It takes a lot more, if you look at the top-right area, the
> branches are
> > there entirely. And look pretty natural.
> >
> > My idea is not necessarily to have the same pixels as in ACR, but to
> > take more out of the image.
> >
> > For me this is not a contest between ACR and Hugin. It's an
> attempt to
> > get rid of the big annoyance the Adobe's OS'es of choice are that
> lead
> > me to move to different tools.
>

> You might try something intended to compete more against ACR: GIMP. I
> got the attached result by zooming out in Hugin's Fast Preview
> Window so
> the entire panorama was shown. I adjusted the crop to include the whole
> image, then generated the panorama. I opened the generated panorama in
> GIMP and did some adjusting using GIMP's Cage Transform. I didn't do
> any
> cropping in GIMP.

>
> > BTW, why Hugin generates a smaller image than ACR? ACR makes a
> 8655x2645
> > image, Hugin a bit more than 6000x...
>

> Don't know about that. Maybe the projection ACR is using is different
> because ACR knows it's going to run a transform on it afterwards, so it
> starts with a larger image that includes more empty areas to start with?
>
> > If I try different lens or projection, I should be able to mold, to

> > reshape the projection to a rectangle (maybe not completely, to some
> > degree, as in ACR).
> >
> > This is done by setting a value with a slider in ACR...
>

> ACR is more than just a panorama maker. See what I got using GIMP.

>
> > The architectural tutorials I've found seem not to be applicable, as
> > long as are done on a single image, making here that in two steps is
> > overkill and less flexible if I need to go back to stitching
> again if I
> > need something to be fixed or reworked. It's not that I'm lazy, it's
> > simply unproductive.
>

> Yes. I've used them to adjust vertical panoramas of buildings shot from
> street level. Might be something that could be done to your image, but
> might be pretty complex.

>
> > Also, I have some strange behavior of Hugin when aligning in the
> simple
> > interface. It changes the lens type and the projection to
> > equirectangular all the time. Is this expected?
>

> I don't know. I use the Expert interface. The simple interface seems to
> me to be little more than a wrapper around the Assistant process that
> can automatically make a panorama from a set of images.

> gnome...@gmail.com <mailto:gnome...@gmail.com>

> wandering the landscape of god
> http://dancingtreefrog.com
>
>
>

> --
> Mihai Sorin Dobrescu

[Mihai Dobrescu]

By separate interfaces, I mean there is "simple", meaning opens the "Fast Panorama preview" window. Then, choosing "advanced"  or "expert" opens a second window, "Hugin - Panorama Stitcher" and adds an overview mode peeker to the "Fast Panorama preview". But, next time Hugin is opened, will open one window only, depending on the mode selected in the previous session. This is misleading and is overkill to go selecting the mode each time just to have both. I need both.

I am curious if there is something more done in the back for "advanced" by comparison to "expert"...

Having two windows is very handy when having two monitors available. Think about GIMP, it has the option to go one windowed or split. It's good to have that.

[Bob Bright]

[Hi all, I accidentally sent this directly to Mihai yesterday, instead of hugin-ptx. My apologies for splintering the conversation. BBB]

--

On 2019-08-05 11:30 a.m., Mihai Dobrescu wrote:

 How would you stitch these photos in order to get as much as ACR does?

The closest you're going to get to duplicating your ACR results using Hugin alone is to choose the Panini General output on the Projection tab in the Fast Panorama preview window, and then move back and forth between the Projection tab, the Move/Drag tab, and the Crop tab, alternately tweaking the projection parameters, the position of the image, and the crop until you've got as much of the image in view as possible. Here's what I came up with using this technique (size is reduced to save bandwidth; the .pto is attached):



The result isn't horrible, but the process is quite finicky, and introduces fairly severe distortion at the edges.

The problem is that you're really asking Hugin to do something it's not designed for: i.e., apply arbitrary transformations to the corners of an image, in order to preserve as much information as possible in a full rectangular crop. This is a straightforward image editing function, but Hugin is not supposed to be a general purpose image editor.

Here's the result of spending a few minutes in the Gimp applying the cage transform tool to the cylindrical image you posted earlier in this discussion:






As you can see, the cage transform tool manages to preserve pretty much all of the information in the corners of the image, without introducing a lot of distortion elsewhere. Once you've played around with it for a bit and figured out how the tool works, the process is quite quick -- certainly quicker than trying to coerce Hugin into doing something it's not designed for. Try it, you'll like it!

Cheers,
BBB

--

Bob Bright Vancouver Island Digital Imaging +1 250 857 9887 BBBr...@VictoriaVR.ca

[Mihai Dobrescu]

[Hi all, I continue the discussion here. Mike]

Thank you! The discussion began when I've tried to get more out of that middle-bottom bush. In your first attempt, you've got the same crop as me and the bush was cropped too much too.

I find the process of that tuning exactly the same as you do.

Somehow, I've got a similar image.

As for the second attempt, indeed, I think Gimp might be the solution, but Hugin should be able to apply this process itself as it seems to be a necessary step in some cases and mght be useful in panoramas.

I think the code is there, because Hugin morphs individual images in order to synchronize the control points.

Best Regards.

[Bob Bright]

On 2019-08-07 11:38 a.m., Mihai Dobrescu wrote:

[Hi all, I continue the discussion here. Mike]

Thank you! The discussion began when I've tried to get more out of that middle-bottom bush. In your first attempt, you've got the same crop as me and the bush was cropped too much too.

I find the process of that tuning exactly the same as you do.

Somehow, I've got a similar image.

As for the second attempt, indeed, I think Gimp might be the solution, but Hugin should be able to apply this process itself as it seems to be a necessary step in some cases and mght be useful in panoramas.

I think the code is there, because Hugin morphs individual images in order to synchronize the control points.

Best Regards.

Sorry, but as I explained to you in email, the code is not there. Hugin is a dedicated panorama stitcher. It doesn't work by "morphing" individual images. What it does is apply certain global transformations to the input images, using a well established model, in order to match control points in the images as closely as possible. There's no code in there to perform arbitrary transformations of groups of pixels within the input images, or within the resulting panorama.

ACR works exactly the same way Hugin does when it comes to stitching: it matches features in the input images by applying global transformations to them. But unlike Hugin, ACR contains additional code which allows it to distort specific parts of the result. It looks to me like the additional code is basically a limited (and therefore fairly easy to automate) version of Gimp's cage transform tool, dedicated to this one task of filling in empty space around the edges of a stitched image.

Could the necessary code be added to Hugin? Of course it could! But that would be an enormous amount of work, and I can't see that it would be worth anyone's while to put the effort in. You're probably going to want to edit your panorama in the Gimp or some other general purpose editor, anyway, to fix minor stitching/blending errors, do some color correction, add a bit of sharpening, etc. So why not fix the corners of your panorama while you're at it?

My advice is to embrace the unix/linux philosophy of using collections of smaller, focused tools to accomplish what you're after. Hugin and the Gimp are both very good at what they do. You can think of them, if you like, as a single combined program: Hugin+Gimp. It's a very powerful combination. Sure, it's a bit less convenient to use than ACR in some respects. But that's a small price to pay for the freedom to be able to avoid the inflexible and invasive operating systems that companies like Adobe cater to.

[Mihai Dobrescu]

[I paste my answer here. Mike]

Hi, I am a software developer myself. I imagine it's not simple.

The code I was referring to is morph-to-fit script and related.

As a side note, ACR and PS use a script to stitch, I imagine the analysis and refinement to implement the whole process... They have managed to make a simple to use tool that fulfills a lot of people needs with a few clicks.

I am not saying it's perfect or to steel the idea from it, but it's a good example.

Too bad the discussion was split by writing directly to my inbox, as now I've got two opposite answers...

Of course, I wouldn't come to force anybody to do it or accept some code for it, nor having hard feelings for refusing that. Here might come some fork, that makes FOSS so flexible, but also a pain for the users, no wonder they blame it so much...

ACR would be my tool of choice, as I am not looking for something free, but, you know, I have embraced Linux, due to much pain induced by using Windows (privacy invasion and lack of support for certain VT-d implementations that renders it not bootable for years, and other inconsistencies and situations that broke my workflow). So I have found several gems like RawTherapee, Darktable, Inkscape, Krita, GIMP, Blender, along with their fine and responsive teams. And the DE's on Linux are stellar wonderful and well usable, that lead me to a true dilemma of what to chose, I'd peek at least two at once. The only thing left would have been a good panorama tool, which Hugin is.

Kind Regards,

Mike

PS: Often, the simpler the UI, the more complex the code is.

[Mihai Dobrescu]

Hi all, I have tried GIMP cage. Not successful.

First, I've tried 8 points, one per corner, one per side middle. Does not do as expected, somehow the image was twisted and swirled.

I've tried to add many, like following the irregular shape with a lasso tool. That was absolutely odd.

Took many minutes, on my old i7, about a quarted of an hour, just to calculate something after closing the cage.

Then each move took another painful time. An to be absolutely discouraging, out of the blue, the cage disappeared and the image got back to the original shape.

Don't get what happened, as long as I've used the mouse only. Weird.

I think this might do, eventually, but it does not have the advantage of working with some light preview, like ACR and Hugin.

A tool like this should be added for such processing.

Just my thoughts...

Regards,

Mike

[David W. Jones]

Hi, Mike!

Hmm, on my present i7 (2.4GHz laptop processor, 16GB memory), it was
fast. But you're working with the full-size image, I wasn't.

Twisted and swirled: You didn't have enough points.

You need more than 8 points. On the smaller one I did, I put a point on
every place where the curve of the image edge changed. I probably had
12-20 points each across the top and bottom. Plus one on each 'corner'
of actual image.

You'd probably need more points across on the full size image. The more
points you have, the more calculation it has to do for every pixel in
the image. I think using more points also reduces the distortion that
results from such transformations.

Maybe use the cage tool to change just the top part of the image. Save
it as a native GIMP image. Then use the tool to change just the bottom
part. I think doing each part separately will speed up the calculation
process.

It might also make it easier. With points on both top and bottom, I
noticed that tweaking a bottom point would also change things at the top.

I also somehow made the cage vanish the first time I tried it. I have no
idea why that happened. Also only using mouse.

> Sorry, but as I explained to you in email, the code is _not_

> Bob Bright
> Vancouver Island Digital Imaging
> +1 250 857 9887
> BBBr...@VictoriaVR.ca

[Mihai Dobrescu]

Probably the vanishing of the cage is a bug and after tuning and waiting it's so frustrating.

Working on a full image is truly difficult anyway. This is not the right thing to do.

I have 24GB of RAM, BTW, so I think is not the memory, but the calculations.

Probably GIMP should implement a preview mode for this.

[Mihai Dobrescu]

Oh, I've forgot to mention that once cage tool is released, you lose the cage...

[Bob Bright]

On 2019-08-07 10:38 p.m., Mihai Dobrescu wrote:

Hi all, I have tried GIMP cage. Not successful.

First, I've tried 8 points, one per corner, one per side middle. Does not do as expected, somehow the image was twisted and swirled.

I've tried to add many, like following the irregular shape with a lasso tool. That was absolutely odd.

Took many minutes, on my old i7, about a quarted of an hour, just to calculate something after closing the cage.

Then each move took another painful time. An to be absolutely discouraging, out of the blue, the cage disappeared and the image got back to the original shape.

Don't get what happened, as long as I've used the mouse only. Weird.

I think this might do, eventually, but it does not have the advantage of working with some light preview, like ACR and Hugin.

A tool like this should be added for such processing.

Just my thoughts...

Regards,

Mike

What you need to understand about the cage tool is that when you move one of the points in the cage, the other ones function as anchors to limit the amount of distortion in their neighbourhood. You don't have to set that many points, but if you don't set them in appropriate locations, you'll get bizarre and unacceptable distortions in the rest of your image.

In the case of the partial crop you posted earlier, if you want to preserve most of the image but expand the corners to fill the full rectangle, you need to set at least 9 points, one at each of the vertices in your original image, like so:

I've set a 10th point on the left side of the image, for reasons I'll explain in a moment. Placement of these points doesn't have to be super accurate, just try to get them close to the vertices.

Once you've set all your points and closed the cage, you can start dragging points around to fill in the corners. You'll want to drag point #9 down, e.g., to fill the bottom left corner. When you do this, points #8 and #10 will act as anchors to prevent the distortion from propagating too far. (There's still going to be some distortion in the rest of the image -- there has to be, because we don't want abrupt transitions -- but the anchors will keep it within acceptable limits.)

When you're satisfied with the bottom left corner, move on to the other corners in turn, dragging #1 up, #4 up, and #6 down and to the right. You'll also want to drag #10 in a bit, because moving #1 and #9 up and down respectively moves some of the detail on the left side of the image out of the frame. When you do this you'll have to go back and fine tune the placement of #1 and #9 again. Similarly for #5 and #4 & #6.

Here's what the result of your efforts should look like:

Once you catch on to it, the whole process shouldn't take more than about five minutes, even on a relatively slow machine. When you're satisfied with the result, press the <Enter> key to commit the transformation, and you're ready to move on to color correction, sharpening, etc.

[Frederic Da Vitoria]

2019-08-08 10:33 UTC+02:00, Bob Bright <bbbr...@gmail.com>:

Excellent tutorial on the cage tool! Thank you.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org

[Mihai Dobrescu]

This is exactly what I did in the second take, as I have already explained.

That took too much to process just to calculate the initial cage, that cage vanished unexpectedly, and was a pain to adjust, probably due to the big image.

Also, not being possible to persist the cage info makes it a bigger pain.

Hence, I'd like to have some cage tool in Hugin, to have it saved in the project, especially that it was said here that are already altered versions of the GIMP cage used to morph or, as you prefer to name it, reshape the source images.

[Bob Bright]

On 2019-08-08 1:58 a.m., Mihai Dobrescu wrote:

This is exactly what I did in the second take, as I have already explained.

That took too much to process just to calculate the initial cage, that cage vanished unexpectedly, and was a pain to adjust, probably due to the big image.

Also, not being possible to persist the cage info makes it a bigger pain.

I just tried scaling up your original image from 10 megapixels (6110x1650) to 27 megapixels (10000x2700), and then repeating the cage transformation that I described in my last post. It's slower, but the whole process from beginning to end still only took 7 minutes. The time for Gimp to recalculate the transform each time I moved a point was between 12 and 15 seconds. Note that this was on a vintage AMD A8-7600 machine, with no separate graphics card and 8 GB of ram. I'm pretty sure your "old i7" is at least as fast. (How big is your image, anyway?)

As for being able to "persist" the cage, I agree this would be a useful feature. Why don't you suggest to the Gimp developers that they add the ability to save a cage as a path, along with the corresponding path-to-cage function?

If you simply can't stand using the cage tool because it's too slow or unintuitive or whatever, you can also use Gimp's warp tool to fill in the corners of your image. Under the warp tool options, change the mode to "Shrink area", and make the size of the brush as large as it will go. Then with some judicious clicking outside the edges of your image, you can shrink the empty parts and achieve a nice result which only distorts the corners and leaves the middle of the image untouched. I personally think the cage tool produces a nicer result because the distortion is better distributed across the image. But it's your image, after all -- use whichever tool suits you, from the point of view of convenience as well as your artistic goals. (Note that if you prefer non-destructive editing, Darktable has a Liquify module which will essentially do the same thing as Gimp's warp tool.)

Hence, I'd like to have some cage tool in Hugin, to have it saved in the project, especially that it was said here that are already altered versions of the GIMP cage used to morph or, as you prefer to name it, reshape the source images.

Who said there are "already altered versions of the GIMP cage used to morph or ... reshape the source images"? That's not at all how Hugin works.

I repeat: to the best of my knowledge, there is NO code presently in Hugin which is capable of doing anything like what the cage tool does in Gimp. There is the alignment code which applies very specific global transformations to the source images, using the lens model developed by Helmut Dersch over 20 years ago; and there is the code which remaps one projection to another. That's basically it, so far as the guts of the program are concerned.

If you have the time and inclination to add the functionality you're looking for to Hugin, I'm sure nobody will object. What you're essentially after is some way for the user to specify arbitrary departures from an output projection. I.e., "I've stitched my input images, and now I want my output to be cylindrical, except that I want the bottom left X% of the image to be displaced by a certain amount in a certain direction, and I want the bottom right Y% to be displaced by some other amount in another direction, and ..., and I want those displaced areas to be smoothly blended in with the rest of the panorama."

(Hmmm, that sounds suspiciously like what you would get if you took the ordinary cylindrical output from Hugin and used some of the tools in Gimp or Darktable or whatever to displace the areas in question.)

Good luck!

[Mihai Dobrescu]

My attempt was with a TIFF image of about 8600 x 2600 px, having around 148 MB.

One day, my computer burned. I've asked for a new one to my favorite store and they've said there is a new generation coming, not many having it, and waited for import to be done for a few weeks.

Then I've got my i7 920, among the first ones in my country. So, yes, it is old, but still kicking.

I am sorry I don't have a reference, but I've read about several things I've discussed about, i.e. the Gimp cage altered version in Hugin, the morphing algorithm used to align the images, etc.. Don't remember where, if I find them, I'll post them.

Now, I've started some requests here:

https://gitlab.gnome.org/GNOME/gimp/issues/3778

https://gitlab.gnome.org/GNOME/gimp/issues/3779

https://bugs.launchpad.net/hugin/+bug/1839479

But I don't expect anybody start implement them anytime soon. They are rough ideas.

As for Darktable, I can't use it at the moment because it is broken on my distro and nobody seems o care about.

I have provided the debug data, which is poor in info, I have built it myself and still crashes.

[Michal Novotny]

On 8/9/19 8:06 AM, Mihai Dobrescu wrote:
> I am sorry I don't have a reference, but I've read about several things
> I've discussed about, i.e. the Gimp cage altered version in Hugin, the
> morphing algorithm used to align the images, etc.. Don't remember where,
> if I find them, I'll post them.

Don't you mean
https://metacpan.org/pod/distribution/Panotools-Script/bin/ptomorph? If
so, it has nothing to do with Hugin.

Michal

[Mihai Dobrescu]

I might have been mislead by some posts or discussions.

But I don't know what is that. What is that tool in the link on that page?

[Mihai Dobrescu]

... and to be clear for me...

Doesn't Hugin, through Panotools, detect control points to align the images, but those control points are not in the same positions in relation one to another in those source images, hence distorting them in order to create a meaningful panorama image/projection?

How is this called? Distorsion, morphing, reshaping...?

[Frederic Da Vitoria]

Hello Mihai,

There is a huge difference between what Hugin does and what the cage tool does.

As you can see, the cage tool affects only a part of the image, and it
does so by stretching/compressing, but not the whole image.
Furthermore, the cage tool does this just according to the
instructions you gave him. You can ask for a stretch vettically and a
compression horizontally. In other words, this is true morphing,
something which could be used for example to give the illusion that
someone sad is smiling. The assumption here is that the scene is not
perfect and should be artificially improved.

Hugin does something completely different. As far as I know, it always
works on whole images. It applies complex formulas which work
radially, that is all the points at a certain distance of the center
of the image will be affected the same way. In a way, Hugin works like
an optical lens.

Furthermore, Hugin applies the same transformation to all images (this
is not always true, but generally it is so). And all tranformations
are done to the images before merging them into a panorama. A
consequence of this is that if you move a point, this will affect the
transformation of all images: Hugin will try to find the
transformation which once applied to all images will give the best
results. Often improving the matching on one point will make other
points worse (especially when shooting without a panoramic head)

Hugin does not morph the images, it does not distort them in the way
of a morphing tool does. Hugin supposes the images are perfect and
just need some kind of geometric adjustment in order to make them fit
together.

This explains why Hugin gives much worse results if you dont use a
panoramic head: your pictures have parallax errors, which could maybe
be corrected through image-specific morphing, but Hugin does not do
morphing.

BTW, but very important: I don't know the correct word for what Hugin
does. But it definitely is not morphing.

2019-08-09 12:51 UTC+02:00, Mihai Dobrescu <msdob...@gmail.com>:

> ... and to be clear for me...
> Doesn't Hugin, through Panotools, detect control points to align the
> images, but those control points are not in the same positions in relation
> one to another in those source images, hence distorting them in order to
> create a meaningful panorama image/projection?
> How is this called? Distorsion, morphing, reshaping...?

[Mihai Dobrescu]

Hi, thank you everybody for not giving up on me and for the detailed descriptions.

My idea is GIMP cage is not the thing I need, generally speaking your description suits better my needs, because moving some point should have impact along all the image.

I've wrote several times that I have used a word, but colloquially speaking rather than accurate, still a morph need, probably.

If you don't know the word, let find one...

Still, it is impossible to have a panorama stitching without distorting the images to align the control points...

I don't see ACR altering only one image of the composed panorama either.

It is done on the whole result, my feeling being it does similar to a lens too.

Why not Hugin do some similar process...? At least in theory.

Anyway, I see the same developer contributing to Hugin and to Panotools as was indicated before.

Why not integrate that in Hugin? Doesn't Hugin use Panotools?

Regards,

Mike

[Frederic Da Vitoria]

My guess is that the final step done by ACR uses a completely
different code to do this. In other words. I think that ACR first
assembles a panorama using the same methods as Hugin does, and when it
has finished it checks if there are holes in the panorama and it uses
a morphing algorithm to fill those holes. This is a good idea, but it
is something completely different from what is already implemented in
Hugin. This is a nice finishing touch, and maybe Hugin could try to do
the same, but definitely the code to do this would be completely
separate from the code Hugin currently uses to create a panorama. So
adding this would be a major enhancement, not just a tweaking of some
instructions in Hugin. In order to do this, someone who knows about
morphing algorithms would have to create the code.

2019-08-09 13:59 UTC+02:00, Mihai Dobrescu <msdob...@gmail.com>:

>> <javascript:>>:

>> > ... and to be clear for me...
>> > Doesn't Hugin, through Panotools, detect control points to align the
>> > images, but those control points are not in the same positions in
>> relation
>> > one to another in those source images, hence distorting them in order to
>> >
>> > create a meaningful panorama image/projection?
>> > How is this called? Distorsion, morphing, reshaping...?
>>
>> --
>> Frederic Da Vitoria
>> (davitof)
>>
>> Membre de l'April - « promouvoir et défendre le logiciel libre » -
>> http://www.april.org
>>
>

> --
> 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/2269da4a-dbd4-4fd4-83df-3e98e024f829%40googlegroups.com.

[Mihai Dobrescu]

ACR is an automation of PS process.

In PS, the images can be loaded in layers, the they are aligned and masks are added.

The alignment distorts the images in a way that overlaps the control points (which is trnsparent to the user).

It is done with a script that can be read, being delivered with PS and looks improved by the users too.

Eventually, the user crops and distorts and flattens the image.

> email to hugi...@googlegroups.com.

[Vegard Brenna]

Hi Group

(my first posting)

Platform: macOS Mojave Version 10.14.6 (Build 18G87)

Version: 2019.0.0.a369cbe55179 built by Niklas Mischkulnig

nona: using graphics card: ATI Technologies Inc. AMD Radeon RX 580 OpenGL Engine

I have a steadily growing collection of 2 rows by 3 columns architecture pano shots which I'm finally able to start assembling. I run into a plethora of problems.

The shots I've been testing with are taken by a MFT camera with a 16mm lens (32mm eq), portrait orientation. Nodal Ninja 4 pano head.

I am testing with the same 6 full size (5182x3887) images every time.

My «workflow» (= attempt at getting this done)

1. Import 6 images
2. Reassign #1 as AC Anchor instead of #0
3. Reassign Lens 0 to all images. Hugin insists that I'm using two different lenses, 0 and 1.
4. Create one Vertical line (I am beginning to think this may be superfluous)
5. Create CPs using cpfind + celeste (I still find CPs that seem totally random, in the middle of nowhere)
6. Menu>Edit>Fine-tune all Points
7. View>Control Points (PF3)
8. Delete all CPs < 0.80
9. Open Fast Panorama Window
10. Click 2. Align...
11. Choose Projection, usually Panini General
12. Straighten pano, make vertical lines vertical, using Move/Drag
13. Go back to main window
14. Select Stitcher
15. Calculate field of view
16. Calculate optimal size
17. Fit crop to images
18. Stitch!
19. Run PTBatcherGUI

This may work or it may not, and I'm unable to solve the puzzles. There are too many variables.

Referring to the numbered list above, I am seeing issues.

3. My source images are HDR, produced by a different app. The sizes may vary by a pixel or two. Each time the size is different, Hugin assigns a new lens. Hugin computes HFOV, which varies between 42° and 44°. Really? That's more than 4%. 1/3887 = 0.025%

5. I'm unable to find an explanation anywhere of what Distance means. What is Optimal? I settle with the fine-tuned results, which are not distances, but correlations. But I have no idea what it is the correlation between.

6. What does fine-tune do? Run through all the CPs and assign them to a common, consistent mapping universe?

10. After Align, I may or may not get a well assembled picture. Sometimes it's beautifully seamless, sometimes it's gross, with partial images not matching.

18. Stitch! does not pass any arguments to PTBatcherGUI...

19. ... so I open the PTO file manually from within PTBatcherGUI and click Play. No big deal, compared to the rest.

PTBatcherGUI then randomly crashes with

enblend: failed to open "image0000.tif": No such file or directory

which is the same message as this one https://bugs.launchpad.net/hugin/+bug/1478174

However, this time the message is true. Despite the log saying

saving image0000.tif

it is not saving anything at all.

I watch the folder in Finder while PTBatcherGUI is working, and if it is indeed saving I can see the file popping up.

I have no web page, and attaching files to posts is frowned upon, so where do I go from here?

In my previous life, before I retired, I worked in (mainframe) software development.

Vegard Brenna
veg...@online.no

[Bruno Postle]

On 19 August 2019 08:27:29 CEST, Vegard Brenna wrote:
>
>3. My source images are HDR, produced by a different app. The sizes may
>vary by a pixel or two. Each time the size is different, Hugin assigns
>a new lens. Hugin computes HFOV, which varies between 42° and 44°.
>Really? That's more than 4%. 1/3887 = 0.025%

Hugin makes an initial FoV calculation based on EXIF data in the photos (if any). This is not very accurate, so it will recalculate FoV as part of the optimisation/fitting process.

Note that these optimised FoV numbers are those that give the 'best fit' in the panorama, so unless you are careful to only pick control points on objects very far away, the calculated FoV will vary every time.

>5. I'm unable to find an explanation anywhere of what Distance means.
>What is Optimal? I settle with the fine-tuned results, which are not
>distances, but correlations. But I have no idea what it is the
>correlation between.

The error distances are measured in pixels in the output panorama (so they will change if you resize the canvas area). For example, a large distance of 10 pixels corresponds to a 10 pixel dislocation in the panorama, which may be very visible.

The exception is immediately after you run 'fine tune all points', here the list of distances is temporarily overwritten by the correlation between the local image around each half of the control point. In this case small numbers are a _bad_ thing, as zero represents no correlation and one represents perfect correlation - this is not the best bit of UX in Hugin, but it does the job if you know to expect it.

>6. What does fine-tune do? Run through all the CPs and assign them to a
>common, consistent mapping universe?

Cpfind identifies lots of features in the scene (using corner detection) and describes them, it is these descriptions that are compared to create the initial set of control points. Often these features are not readily visible to the human eye, and the provided point coordinates may be one or two pixels off where a human might place them.

The fine-tune function does something else altogether. Here Hugin is directly comparing the image around each half of the control point - you can visualise this as subtracting one image fragment from the other and seeing if any features remain. This is much more like what you do when manually adjusting a control point, and the process gets very different results to cpfind.

>10. After Align, I may or may not get a well assembled picture.
>Sometimes it's beautifully seamless, sometimes it's gross, with partial
>images not matching.

Yes, this indicates that the automated process isn't working and you need to manually inspect and fix the set of control points before reoptimising.

>18. Stitch! does not pass any arguments to PTBatcherGUI...

This is supposed to work...

>19. ... so I open the PTO file manually from within PTBatcherGUI and
>click Play. No big deal, compared to the rest.
>PTBatcherGUI then randomly crashes with
> enblend: failed to open "image0000.tif": No such file or directory

This could be a problem with file permissions, does Hugin have permission to write in the output folder? In the past Hugin has had many problems with special control characters or untested language characters in filenames and foldernames, so it could be something like this.

>I have no web page, and attaching files to posts is frowned upon, so
>where do I go from here?

Please reply and attach a PTO project that demonstrates the problem, there is no need to attach photos at this stage.

Hope this helps.

--
Bruno

[Vegard Brenna]

Thanks Bruno, this gets me back on track again.

On 19 Aug 2019, at 14:02, Bruno Postle <br...@postle.net> wrote:

Hugin makes an initial FoV calculation based on EXIF data in the photos (if any).

There is full lens data in the EXIF, including the name of the lens. I can list it in the main window.

The exception is immediately after you run 'fine tune all points', here the list of distances is temporarily overwritten by the correlation between the local image around each half of the control point. In this case small numbers are a _bad_ thing, as zero represents no correlation and one represents perfect correlation - this is not the best bit of UX in Hugin, but it does the job if you know to expect it.

Since I was able to find this particular infomation on my own, I was aware of it. But I agree that the fact that it still mixes distances and correlations in the same column – even at the same time – is not really very elegant.

10. After Align, I may or may not get a well assembled picture.
Sometimes it's beautifully seamless, sometimes it's gross, with partial
images not matching.

Yes, this indicates that the automated process isn't working and you need to manually inspect and fix the set of control points before reoptimising.

Aaaarrrggghhh.

I will start by cheating, increasing my correlation limit to for instance 0.9 and see what happens. There should still be enough CPs I think.

18. Stitch! does not pass any arguments to PTBatcherGUI...

This is supposed to work...

Worked in 2017 version.

enblend: failed to open "image0000.tif": No such file or directory

This could be a problem with file permissions, does Hugin have permission to write in the output folder?

Since this varies by the time of day, the weather and whether Jupiter aligns with Mars, I don't think this is the problem. It is random. But yes, I've seen this exact problem with another app.

Please reply and attach a PTO project that demonstrates the problem, there is no need to attach photos at this stage.

I will create an isolated folder where I have full control (famous last words...) over what I'm doing.

Hope this helps.

At least I'm not totally stuck anymore.

Vegard Brenna
veg...@online.no

[AKS-Gmail-IMAP]

> On Aug 19, 2019, at 8:21 AM, Vegard Brenna <veg...@online.no> wrote:
>
>
>>> enblend: failed to open "image0000.tif": No such file or directory
>>
>> This could be a problem with file permissions, does Hugin have permission to write in the output folder?
>
> Since this varies by the time of day, the weather and whether Jupiter aligns with Mars, I don't think this is the problem. It is random. But yes, I've seen this exact problem with another app.
>

It could be related to one or both of the image dimensions being an odd number. Check the image dimensions and then shave it down by cropping it to slightly smaller but different dimensions. Try to get even numbers.

[Vegard Brenna]

Absolutely ridiculous, but cool! :D

I'll try when I've finished with Bruno's suggestions.

Vegard Brenna
veg...@online.no

[T. Modes]

Hi,

Am Montag, 19. August 2019 08:46:48 UTC+2 schrieb Vegard Brenna:

Import 6 images

1. Reassign #1 as AC Anchor instead of #0
2. Reassign Lens 0 to all images. Hugin insists that I'm using two different lenses, 0 and 1.

Hugin assigns different lenses, if the images are shoot at different focal length (as indicated by EXIF data) or have different image dimension.

In both cases, forcing the the same lens introduce additional errors. So better fix your input instead.

1. Create CPs using cpfind + celeste (I still find CPs that seem totally random, in the middle of nowhere)
2. Menu>Edit>Fine-tune all Points

 Cpfind finds control points by using a multi-scale approach. So the detected cps can include information from different scales. If you simply fine-tune all cp you destroy this (valuable) information. (Fine-tune works always on the same (1:1) scale). So no need to stubborn fine-tune all points.

But I agree that the fact that it still mixes distances and correlations in the same column – even at the same time – is not really very elegant.

You must be using a different version. The current version displays for me only distance or correlation, but not both at the same time (except for line cp, this is now fixed in the repository). Depending on the information displayed the header changes. So if the error is shown, the header reads error. And the same for correlation.

 

[Vegard Brenna]

On 19 Aug 2019, at 17:44, T. Modes <Thomas...@gmx.de> wrote:

HHugin assigns different lenses, if the images are shoot at different focal length (as indicated by EXIF data)

They are not.

or have different image dimension.

They may have. If at all, usually +/-1 pixels

In both cases, forcing the the same lens introduce additional errors. So better fix your input instead.

Good information. Since I will have to do that anyway, I can at the same time ensure that the pixel dimensions are even numbers, as "AKS-Gmail-IMAP" suggested. Oooohhh, I need a script!

1. Create CPs using cpfind + celeste (I still find CPs that seem totally random, in the middle of nowhere)
2. Menu>Edit>Fine-tune all Points

 Cpfind finds control points by using a multi-scale approach. So the detected cps can include information from different scales. If you simply fine-tune all cp you destroy this (valuable) information. (Fine-tune works always on the same (1:1) scale). So no need to stubborn fine-tune all points.

OK, let's skip that one as well. But I rely on the correlation coefficient to weed out less successful CP pairs.

I will have to find an alternative approach to that one.

But I agree that the fact that it still mixes distances and correlations in the same column – even at the same time – is not really very elegant.

You must be using a different version.

Latest Mac build. The latest Mac build is perhaps not based on the latest Linux build?

When displaying all CPs, I get one – 1 –  Normal CP (not a line) which is a number > 1.0

Vegard Brenna
veg...@online.no

[Rogier Wolff]

On Mon, Aug 19, 2019 at 02:02:57PM +0200, Bruno Postle wrote:
> The fine-tune function does something else altogether. Here Hugin is
> directly comparing the image around each half of the control point -
> you can visualise this as subtracting one image fragment from the
> other and seeing if any features remain. This is much more like what
> you do when manually adjusting a control point, and the process gets
> very different results to cpfind.

This started me thinking about a good UI for a person to adjust a
control point.

Would it be easier for a human to fine-tune a control point if you
show the two images, overlapped across eachother, but with a
checkerboard pattern (say 3, 4 or 5 pixels to a square) determining
whether to show the left or the right image?

Roger.

--
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
- Datarecovery Services Nederland B.V. Delft. KVK: 30160549 -
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!

[AKS-Gmail-IMAP]

I reported a bug like this a while back. Some images would work and some would not. It was an Aquarius moment for me also. The difference between the working and not working images were the image canvas sizes that I assumed were the same because these images were created by another application in what I thought were identical image boundary conditions. That application is silverFast 8. I found I could reliably predict a non working image by examining the dimension numbers. 

I noticed you mentioned your images are created from another application. Perhaps it is capable of producing strange image dimensions like silverFast 8 does.

Years ago the application NoiseNinja would exhibit a crash behavior related to some image dimension situations. The developer acknowledged the issue in the application notes.

In my case the error message seen in Hugin is true because the process step right before enblend fails to produce the intermediate image that enblend is to work on. For some arcane reason the cause was the dimension number, perhaps related to a division rounding. That process failure condition is not checked prior to assembling the commands sent to enblend, hence the enblend error message. 

It might seem ridiculous at first but surely the process before enblend is certainly not creating the file enblend is to be working on. Keep in mind "the computer is always right” when troubleshooting a computer situation. That “image0000.tif” did not get created. Hugin assumed it had without explicitly checking for the file.

--
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/73411420-A1B0-4117-AE6B-16EC79384E61%40online.no.

[Vegard Brenna]

Update.

So far, I'm only concerned by getting something that looks decent in the Fast Preview window.

• cpfind and cpfind + celeste produce identical, unusable results. I thought perhaps celeste could remove uncertainty caused by uniformly painted walls, but no.
• Accepting Pic #0 as Anchor or moving the Anchor to #1 produce identical results.
• Performing Edit>Fine-tune all Points (discouraged by T Modes) has a significant effect:
• Deleting Correlation < 0.80 transforms the Preview from "a stack of cards" to something that resembles what I'm after. But still useless.
• Deleting Correlaton < 0.90, 0.95 results in a steadily decreasing quality of the Preview, with larger and larger mismatch.

And finally...

• Selecting instead "Hugin's CPFind (prealigned)" immediately produces an almost correct Preview! Still some small glitches. None of the images are yet a perfect match, but I need to zoom in to see that. Both the Fast Preview and the Preview show the same mismatch.

It is perhaps time to move on to the curious enblend bug (which isn't enblend's fault) to see if the glitches go away with proper stitching.

I have so far wilfully tried to avoid Bruno Postle's suggestion – to check the CPs. Shudder.

The documentation at https://wiki.panotools.org/Hugin_Parameters_for_Control_Point_Detectors_dialog#Prealigned_panorama

(if it indeed is about this setting?) states

Prealigned panorama

This setting works only if the rough positions of the images are defined in the project. It tries to link all overlapping images.

If the advanced option Work only on image pairs without control points is selected (default), it skips all image pairs which are already connected by Control points. Otherwise it creates also control points for already connected images. 

My guess is that since I always give my image files a prefix Px_ so that they correspond to the rows in the matrix like this ...

P3 P4 P5

P0 P1 P2

... then Hugin "gets it" and processes them in the correct order.

Vegard Brenna
veg...@online.no

[Vegard Brenna]

Update.

Nona/Enblend bug found!

Remapping LDR images...

===> nona: using graphics card: ATI Technologies Inc. AMD Radeon RX 580 OpenGL Engine <===

Multiple images output

loading Pic0_.tif

remapping Pic0_.tif

saving PTO_Pic0_0000.tif <=== not true! (Fake News?)

. . .

Blending images...

===> enblend: failed to open "PTO_Pic0_0000.tif": No such file or directory <===

Nona is apparently incompatible with the graphics card, fails in some way, does not write any output file and does not return any useful error.

Enblend is innocent, its error msg is correct.

Switch GPU support OFF in Hugin Preferences, and all is well.

My setup may be useful

Mac mini 2018 with eGPU Razer Core X with above AMD graphics card, runnning dual LG 4k monitors.

I have also at last been able to produce a nice rendering of my pano, but the «solution» seems too silly (it's a workaround), and I don't understand it. Give me some more time.

Vegard Brenna
veg...@online.no

[Bruno Postle]

On 20 August 2019 09:53:54 BST, Vegard Brenna wrote:
>
>So far, I'm only concerned by getting something that looks decent in
>the Fast Preview window.
>cpfind and cpfind + celeste produce identical, unusable results. I
>thought perhaps celeste could remove uncertainty caused by uniformly
>painted walls, but no.

Celeste only removes control points from things that look like fluffy clouds, it was trained on a collection of sky photos.

>Accepting Pic #0 as Anchor or moving the Anchor to #1 produce identical
>results.

This is expected, the 'anchor' image is the photo that doesn't move around the canvas during optimisation, it is not involved in control point generation.

>Performing Edit>Fine-tune all Points (discouraged by T Modes) has a
>significant effect:
>Deleting Correlation < 0.80 transforms the Preview from "a stack of
>cards" to something that resembles what I'm after. But still useless.
>Deleting Correlaton < 0.90, 0.95 results in a steadily decreasing
>quality of the Preview, with larger and larger mismatch.

This sounds like you have ended up with too few control points to control the optimisation properly.

Manually fixing control points is not so hard: display the Control Points table, sort by 'distance', and click on the points with the largest error distance one at a time, you can easily see which points need to be deleted or repositioned.

I suspect that you have multiple problems caused by the pre-processing you are applying to these photos:

The processed photos have different pixel sizes, this is preventing Hugin from linking lens parameters during optimisation.

Tone mapped images are radically changed at a local scale, it is possible that they are no longer similar enough for cpfind. Hugin likes photos as they come from the camera.

Hugin is capable of stacking bracketed photos and generating HDR or exposure-fused output during the normal panorama stitching process. This might give better results than pre-processing the stacks.

In any case you should test stitching photos from just one exposure level of your bracketed suits to establish that this is or isn't the problem.

>My guess is that since I always give my image files a prefix Px_ so
>that they correspond to the rows in the matrix like this ...
>P3 P4 P5
>P0 P1 P2
>... then Hugin "gets it" and processes them in the correct order.

The filenames will affect the order that the photos initially appear in the project, but are otherwise ignored by the control point generation process.

--
Bruno

[Vegard Brenna]

On 21 Aug 2019, at 01:09, Bruno Postle <br...@postle.net> wrote:

Celeste only removes control points from things that look like fluffy clouds, it was trained on a collection of sky photos.

Thanks. In other words, an absolute waste indoors.

This is expected, the 'anchor' image is the photo that doesn't move around the canvas during optimisation,

That is what I wanted and thought it was. I'll put that step back in.

it is not involved in control point generation.

Right. I should have been able to figure that one out by myself. Obvious.

This sounds like you have ended up with too few control points to control the optimisation properly.

Yes. Somewhere along the road there is an optimal collection of CPs. At least I've found out where that point is not, or better, I've discovered one non functioning  procedure for how to find that optimum.

Manually fixing control points is not so hard: display the Control Points table, sort by 'distance', and click on the points with the largest error distance one at a time, you can easily see which points need to be deleted or repositioned.

Heehee, this is why I wrote "shudder" earlier. But you are right, doesn't look too bad now.

I suspect that you have multiple problems caused by the pre-processing you are applying to these photos:

The processed photos have different pixel sizes, this is preventing Hugin from linking lens parameters during optimisation.

Back to resizing. Or rather cropping.

Tone mapped images are radically changed at a local scale,

Ahhh, you're right! That's the whole point of tone mapping. D'oh!

it is possible that they are no longer similar enough for cpfind.

That was a new consideration to me. Local contrast also depends on global contrast, and these are not identical from image to image – different subjects.

I will test this.

In any case you should test stitching photos from just one exposure level of your bracketed suits to establish that this is or isn't the problem.

I already do that, but without knowing that it was useful in this scenario!

When shooting the originals, I am always on vacation, and always go back to the forest cabin and stitch the 0EV frames to see that I didn't mess up at the shooting session. But I can ensure everyone that a MacBook Air is not a Hugin powerhouse :(

I will have to tell the wife that Bruno Postle himself told me I need a MacBook Pro! :P

Thanks again for all the help, always enabling me to take yet some stumbling steps forwards.

I should be able to shut up for several days now :P

I wonder how all you guys on this list who are not retired – how do you have time for this? :D:D:D

Vegard Brenna
veg...@online.no

[T. Modes]

@aks

Am Montag, 19. August 2019 22:18:51 UTC+2 schrieb aks:

I reported a bug like this a while back.

I'm not aware of such a bug report. Can you give a link?

[AKS-Gmail-IMAP]

I was thinking it is related to:

 [Question #678756]: Read & Seek error at scanline 0, mod. “TIFFReadEncodedStrip"

but I am beginning to doubt myself. Please ignore it.

[Vegard Brenna]

Found it at last.

My 2 rows 3 columns pano is organised like this

P3 P4 P5

P0 P1 P2

In the layout window they show up like this. The camera has been tilted 45° up to catch the ceiling

We can readily see from the layout window that the closest corners of P3 and P5 overlap. The result ends up like below.

If I remove the P3-P5 CP pairs (there are 4 of them) and align again, the problem is solved.

Vegard Brenna
veg...@online.no

[Mihai Dobrescu]

Hello, I am revisiting this and my problem of understanding how to work with Hugin persists.

What I need is warping (boundary warping as is it called in Photoshop and possibly MS ICE). Here is some reference: http://kaiminghe.com/sig13/index.html.

I've read about warping related to Hugin, so I wonder if there's some technique of control points or other to achieve my goal.

What can I do? What is warping in Hugin?

Regards.

[Sean Greenslade]

On Sun, Sep 20, 2020 at 10:48:38AM -0700, Mihai Dobrescu wrote:
> Hello, I am revisiting this and my problem of understanding how to work
> with Hugin persists.
>
> What I need is warping (boundary warping as is it called in Photoshop and
> possibly MS ICE). Here is some reference:
> http://kaiminghe.com/sig13/index.html.
> I've read about warping related to Hugin, so I wonder if there's some
> technique of control points or other to achieve my goal.
> What can I do? What is warping in Hugin?

Hi, Mihai. As mentioned by Frederic in earlier messages, Hugin performs
only uniform geometric transformations to images:

> >> > On Friday, August 9, 2019 at 2:39:53 PM UTC+3, Frederic Da Vitoria

> >> >> Hugin does something completely different. As far as I know, it always
> >> >> works on whole images. It applies complex formulas which work
> >> >> radially, that is all the points at a certain distance of the center
> >> >> of the image will be affected the same way. In a way, Hugin works like
> >> >> an optical lens.

The techniques described in that siggraph paper are non-uniform
transformations. Hugin does not currently have the ability to do such
content-aware non-uniform transforms.

--Sean

[Mihai Dobrescu]

Hi, thanks, is there enough information to try implement such feature?

--
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/20200920210924.GA810%40bailey.

--

Mihai Sorin Dobrescu

[Sean Greenslade]

On Mon, Sep 21, 2020 at 06:40:47AM +0300, Mihai Dobrescu wrote:
> Hi, thanks, is there enough information to try implement such feature?

In theory. But since they did not release any code with the paper, that
would involve a large re-implementation project.

Also, given that it seems to be almost entirely a non-interactive
post-processing step, I would say it would be a better fit as a
standalone application, or perhaps a GIMP plugin.

--Sean

[Mihai Dobrescu]

Hi, there are some code implementations around:

- http://kaiminghe.com/sig13/index.html
- https://github.com/duanzhibin/Rectangling-Panoramic-Images-via-Warpin

- https://github.com/Jamie725/Rectangling-Panoramic-Images-Via-Warping/tree/master/final%20code

Maybe this one too:

- http://www.runmycode.org/companion/view/224

Regards.

--
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/20200921045627.GA18331%40bailey.

--

Mihai Sorin Dobrescu