Stitching dramatically worse on version 11.12 relative to 10.0.11?

[James Gentles]

I have been using PTGui since version 3 (2004!), and have an established workflow to take GoPro images and generate aerial equirectangular panoramas.

Comparing PTGui PRO Version 10.0.11 and 11.12 performance as installed using the same set of images:

    As installed load images and just click ALIGN IMAGES

        - V10 gets worst point around 15px

        - V11 gets worst point around 50px

    Workflow removes bad points, enables individual lens parameters, selective viewpoint correction, add verticals and horizontals etc...

        - V10 quickly gets to better than 3-4px

        - V11 difficult to get it below 20px

I cannot find a similar issue on the forum and wondered if anyone had any ideas, maybe something in the defaults has changed?

Images and projects can be provided to lllustrate the behaviour.

Some points I noted that may help:

    - I am not using the lens database, just the EXIF. In V10 GoPro cameras incorrectly identify as "fisheye" and need

          changed to "full frame fisheye", V11 seems to know about this already

    - To maximise usable pixels the cameras are set at defined angles, they are not portrait and not landscape

          In lens settings the horizontal FoV is calculated as 91 in V10 and 125 in V11
          91 is the input image FoV, 125 is the actual horiz'al FoV given the camera angle. i.e. the OUTPUT horiz'al FoV

    - In V11 enabling viewpoint correction causes the equirectangular horizon to drop in the frame, I dont understand,

          in V10 it improves stitching, although I understand it causes distortion if over-used.

    - Everything else appears to work as expected.

    - Multiple cameras are syncronised to better than 10mS, parallax is not a major concern. The cameras are offset

         by about 5cm from each other and therefore the nodal points BUT the nearest object in frame is 30m away!

I have rolled back to V10.0.11 but would rather understand what I've done wrong!

James

[PTGui Support]

Hi James,

Could you make a project available for download?

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.
> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ptgui/0af9cada-8f09-4c64-a846-44dce5efa8dc%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/0af9cada-8f09-4c64-a846-44dce5efa8dc%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[John Houghton]

On Wednesday, April 10, 2019 at 7:56:12 AM UTC+1, James Gentles wrote:

    - Multiple cameras are syncronised to better than 10mS, parallax is not a major concern. The cameras are offset

         by about 5cm from each other and therefore the nodal points BUT the nearest object in frame is 30m away!

 James, If using a multicamera rig with fixed camera positions, wouldn't it make sense to make use of a template rather than expecting PTGui to work everything out from scratch? It should result in far more reliable stitching.

John

[James Gentles]

Thanks for the quick response.

Forgive me if I am unfamililar with conventions but I have put a zip in dropbox

https://www.dropbox.com/s/od2kznyb1wb4aog/V10-V11.zip?dl=0

containing

    - 4 raw images our of cameras

    - 2 Project files one prepaired with V10.0.17 (sorry for earlier type), and one with V11

The projects are not complete, just enough work to show the stitching

These are test shots (not for a client), so privacy is not a big issue, I will delete them when we are finished.

If interested in how these images were obtained background reading here http://www.gentles.info/KAP/Gallery/Panotechnique/index.htm

camera cradle here http://www.gentles.info/KAP/Rigs/index.htm?item=16

I dont have anything to add above what my original post said but await your analysis or further questions

James

James

[James Gentles]

John,

A good question, I dont have a good answer. Points for consideration:

1. Each project only has 4 cameras, the processing time to generate the initial stitch is small compaired with the total workflow so I never bothered

2. With extreme weight constraints, the cameras are not as well "fixed" as with a standard nodal mount,

    I perhaps thought this would make the template not so useful, see rig here https://www.dropbox.com/s/od2kznyb1wb4aog/V10-V11.zip?dl=0

3. I thought (perhaps incorrectly) that the templates would not help with the "usual issues" experienced by this technique.

     a. The biasing of control points towards the center of the image works for 99% of users but for this work I need to

         manually add more points near the horizon

     b. Removal of many NADIR points that bias the average error, when the horizon errors are most noticable to users

Are you still advocating templates to improve my workflow?

Should I also consider using the camera database?

I guess up to V10 it seemed to work quickly and well without needing these tools?

Thanks for the input

James

[PTGui Support]

Hi James,

I think I was able to get a reasonable stitch in PTGui 11. The problems
seem to be caused by optimizing really every possible parameter, even
individual Shear parameters. Only flatbed scanners exhibit shear distortion.

I would use the same lens parameters for all images, and only optimize
individual shift parameters.

There's a slight bit of parallax, so for calibrating a template I would
avoid control points on nearby objects.

I have attached my project file for PTGui 11. You can improve alignment
further by enabling viewpoint correction for all except one image.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.
> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ptgui/b65d7cde-f3fd-4005-b5ef-e3f11878c1ad%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/b65d7cde-f3fd-4005-b5ef-e3f11878c1ad%40googlegroups.com?utm_medium=email&utm_source=footer>.

[John Houghton]

On Wednesday, April 10, 2019 at 8:59:47 AM UTC+1, James Gentles wrote:

John,

A good question, I dont have a good answer. Points for consideration:

1. Each project only has 4 cameras, the processing time to generate the initial stitch is small compaired with the total workflow so I never bothered

2. With extreme weight constraints, the cameras are not as well "fixed" as with a standard nodal mount,

    I perhaps thought this would make the template not so useful, see rig here https://www.dropbox.com/s/od2kznyb1wb4aog/V10-V11.zip?dl=0

3. I thought (perhaps incorrectly) that the templates would not help with the "usual issues" experienced by this technique.

     a. The biasing of control points towards the center of the image works for 99% of users but for this work I need to

         manually add more points near the horizon

     b. Removal of many NADIR points that bias the average error, when the horizon errors are most noticable to users

Are you still advocating templates to improve my workflow?

James, Yes, I would still recommend the use of a template, though you should always take care to mount each camera in the same place on the rig, even if it is not very precisely positioned. Anything you can do to help PTGui along is worth doing rather than just chucking the images in and letting it fend for itself. Control point generation seems to be somewhat more successful too.  I got a good stitch manually without vp correction, perhaps marginally better than Joost's at the nadir.  Most points were generated with the "generate control points here" function once the images were roughly aligned. Project file attached.

John

[James Gentles]

Thank-you both for quick and illuminating answers!

I am somewhat humbled by these, they are both subtly different, and I will spend some time later today exploring further and implementing a template solution

I will get back with a conclusion and closing post in a day or so.

The rig that took these is a compromise of weight as well as the normal panorama considerations, hence the images geerated are themselves a compromise, e.g. Parallax.

I deemed the ability to take pictures syncronously with a knows ~50mm offset was better than an automated scanning/motion camera (I did try that approach also)

FYI, The sky si completed using stock material.

One final question, to help me understand! What has changed between V10 and V11 that means that the "out-of-the-box" stitching performance has got worse (for this UNUSUAL stitck case)?

and if I had been using a template for V10, would I not have seen these issues when moving to v11?

Thanks

James

[John Houghton]

On Wednesday, April 10, 2019 at 11:54:55 AM UTC+1, James Gentles wrote:

One final question, to help me understand! What has changed between V10 and V11 that means that the "out-of-the-box" stitching performance has got worse (for this UNUSUAL stitck case)?

and if I had been using a template for V10, would I not have seen these issues when moving to v11?

James, Only Joost has the inside knowledge to answer the first point! As to the second, I think it likely that you would not have seen these issues when moving to V11.  Changes in the lens model mean that templates may well need adjusting for use in V1, and it's important to ensure that the template does exactly what you want it to do by visiting the Project Settings tab of the template project. Choose appropriate settings: particularly the Align Images behaviour - and not forgetting the optimizer settings.

John 

[PTGui Support]

First of all the automated results (just hitting Align Images) look very
similar, you shouldn't judge by the numbers only.

PTGui 11 finds control points over a slightly wider area (both distant
and nearby). This is a good thing but it will result in higher average
control point errors.

PTGui 10 had a tendency to overcompensate with weird lens parameters in
order to minimize control point distance. PTGui 11 limits to more
real-world lens distortion curves.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.
> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ptgui/232f25f6-c974-4ae7-9660-fed1b96c84a2%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/232f25f6-c974-4ae7-9660-fed1b96c84a2%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Roy Hughes]

Its Roy here. I have raised this before and I am not trying to irritate. I would really like PTGUI 10 to behave like 11 when stitching indoors. 10 seems more tolerant even now and switching to manual. Galleries and shops with lots of white walls that look alike and some fancier up market shops by stitching over wider areas actually introduce more real world stitching faults. That's just my experience. I'd like a software switch to go near field or far field rather than doubling my workflow time killing unwanted points. Suppose there is a vase that straddles most of near frame edge areas from each shot. I want the software to concentrate on that an not pickout two different defects in the white walls miles apart. 10 just seems better at it than 11. !! might be better with varied imagery although thats an impression. I know we debated this before you concentrated on auto versus manual but its not made much difference. Again next time I have this challenge, I have a shoot in May in such a location you can have all the outputs and compare 10 and 11 yourself if you have time. There really IS a difference.

> an email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.

[PTGui Support]

Hi Roy,

We had a discussion a while back about PTGui 10 apparently handling HDR
in Av mode better:

https://groups.google.com/d/msgid/ptgui/faf95420-3345-4b0f-ba6e-018f3769daad%40googlegroups.com?utm_medium=email&utm_source=footer

but you seem to be raising a different issue here? Could you post a set
of images to illustrate the problem? Just saying PTGui 10 is better than
11 doesn't help me to fix any problems.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> www.ptgui.com <http://www.ptgui.com>

> > an email to pt...@googlegroups.com <javascript:>
> > <mailto:pt...@googlegroups.com <javascript:>>.

> > To post to this group, send email to pt...@googlegroups.com

> <javascript:>
> > <mailto:pt...@googlegroups.com <javascript:>>.

> > Visit this group at https://groups.google.com/group/ptgui

> <https://groups.google.com/group/ptgui>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/ptgui/232f25f6-c974-4ae7-9660-fed1b96c84a2%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/232f25f6-c974-4ae7-9660-fed1b96c84a2%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/ptgui/232f25f6-c974-4ae7-9660-fed1b96c84a2%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/ptgui/232f25f6-c974-4ae7-9660-fed1b96c84a2%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.

> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com?utm_medium=email&utm_source=footer>.

[James Gentles]

I promised to post again after spending part of today "testing"

Thanks to John and Joost for templates that gave much better results with V11.

It looks like I have had a workflow that produced sub 5px stitching for several years. When you have something that works you are reluctant to change or learn. So I have let some "improvements" pass me by until V10 to V11 made me question this.

After some experimentation with my unusual camera ararngements I still feel V11 behaves differently to V10. Joost has justified the changes and provided a solution (n the templates supplied), so I am happy with the support received, ut still have concerns. As this is a subtle matter it will take several weeks to process enough material to start to get a definative answer..

However Ray has asked a  further question. Ray, I have not deleted the dropbox mentioned further up this post, if you had time your comment on whether these 4 mages exibit teh same problems as you talk about would be illuminating.

Thanks to everyone for excellent support.

James.

> an email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.

[Roy Hughes]

Hi

So I don't have oodles of time to spend on this but...

1. The james.pts file and the accompanying changes used with version 11 as suggested by Joost give a decent stitch on your original images which are challenging.
2. Running your pts file on 10 or 11 don't produce great results. I find it difficult to say 10 is worse than 11 or 11 is worse than 10, possibly just different to each other. I notice that 10 sometimes stitches them upside down.

Subjectively I agree I think 11 does work differently to 10 but without a numerical measure of errors its really not possible to say anything other than that. It's almost as if the errors on 10 are less visually jarring than on 10 but that then leads us to distrust our subjectivity relative to a true numerical precision.

The problem you have is broadly NOT the same as mine. Mine began by noticing whereas 10 was tolerant to Aperture priority mode on fusion it is not on 11. It was suggested than 10 should not really have worked anyway. But as it always worked and now doesn't that suggests somethings different and I thought it would be easy to have a template around that difference. But no. Joost mentioned sampling differences between 10 and 11 in his reply to you and that got me interested. You said when you deleted points in certain areas you better results. I notice this in harmonic sequences in an image, so picture-white wall-picture, is a bit like a wave of white and then colour. This also got me curious because I think, in fact I know, my workflow time has gone up with 11 on large jobs and I am deleting points more on 11 than 10. There's something about sampling thats different. However this is going to be very difficult for Joost or anyone there to reproduce. Another example is switching from aperture priority to manual. It is more convenient on occasion to use aperture priority and quicker depending on location, (I was half way up an ice wall on one occasion(!), how busy the place is, type of trigger I can use with which camera etc. This increased length of workflow too in order to use fusion on some jobs I would shoot for longer. But so much depends on me and what I shoot, so I abandoned the discussions. Your issue just got me interested again in revisiting 11.

[PTGui Support]

Hi Roy,

Well show us some sample images which you think PTGui 11 handles worse
and I'll be happy to investigate. I fix bugs all the time.

But HDR panoramas for PTGui must be taken in M mode. If PTGui 10, 9 or 5
gives you good results with Av brackets, great for you. But if your goal
is to stitch them in PTGui then you are simply doing it wrong. I'm not
going to repeat that discussion.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

On 12/04/2019 10:06, 'Roy Hughes' via PTGui Support wrote:
> Hi
>
> So I don't have oodles of time to spend on this but...
>

> 1. The james.pts file and the accompanying changes used with version 11

> as suggested by Joost give a decent stitch on your original images
> which are challenging.

> 2. Running your pts file on 10 or 11 don't produce great results. I

> find it difficult to say 10 is worse than 11 or 11 is worse than 10,
> possibly just different to each other. I notice that 10 sometimes
> stitches them upside down.
>
> Subjectively I agree I think 11 does work differently to 10 but without
> a numerical measure of errors its really not possible to say anything
> other than that. It's almost as if the errors on 10 are less visually
> jarring than on 10 but that then leads us to distrust our subjectivity
> relative to a true numerical precision.
>
> The problem you have is broadly NOT the same as mine. Mine began by
> noticing whereas 10 was tolerant to Aperture priority mode on fusion it

> is not on 11. It was suggested than 10 should *not* really have worked

> www.ptgui.com <http://www.ptgui.com>

> > www.ptgui.com <http://www.ptgui.com> <http://www.ptgui.com>

> https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com>
>
> >
> <https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>

> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.

> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ptgui/bdecfab1-00fe-4c3c-9c60-37acf03f9e04%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/bdecfab1-00fe-4c3c-9c60-37acf03f9e04%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Roy Hughes]

Joost

Well you could knock me down with a feather! I decided to download the latest update before showing you the issue.

I was just preparing you a set of ver 10 with and without fusion (simple blend) and ver 11 without fusion and all the files and for the hell of it I thought I would try fusion again on 11 even though previously it hadn't worked. This is with the same set up that shouldn't really work. And it worked!

I don't know what to tell you. They are EXACTLY the same files that failed on a previous version in 2018 I assure you. I held them back as a record not really expecting to use them again.

I am very happy if this goes back to working consistently I will continue to use it until it fails, because its faster for me and gives really good results and I can sort a lot out in the camera at the time of shooting. Just quicker workflow. You can tell me off next time it fails! There is always one irritating customer, looks like its me this time!

Cheers

Roy

(BTW Joost, the last message was meant for James not yourself, he'd asked a question of me, I wasn't asking you the same thing again.)

[James Gentles]

Ray,

Thank-you for taking the time to look at this. If these are 2 differnet issues then "so be it". The lack of a connection is valuable information for Joost.

Everyone,

I was interested in Ray's comment that the images wre "challenging" so this adds fuel to my theory that I have developed a workflow to get round these challenges, rathr than maximise the use of PGui features as they evolve. For completeness or interest I will briefly outline what I consider to be non-standard and open myself up to comment.

The rig is a compromise (All are!).

Weight is critical. Cameras are attached by velcro strap and may vary slightly flight to flight

Parallax is compromised so 4 cameras can be triggred very accurately to remove motion-parallax.

To minimise the weight and cost cameras are mounted at an angle so 4 cover a hemisphere.

I have used this basic set-up over 7 years and 100s of panoramas.

When stitching the following non-standard workflows are adopted,

I assumed this was due to the non standard set-up, comments?

-   I always add extra control points at the 4 horizon seams. Control Point addition in PTGui is frame-center weighted (this has changed for the better over time) but because of camera orientation one part of the horizon is right in a frame corner

-   All 4 cameras csn see NADIR. If the 4 images are 1,2,3,4 I always remove control points 2+4 and 1+3 leaving 1+2, 2+3, 3+4, 4+1, this seemed to give a better stitch

-   In exceptional conditions (images are not taken at exactly the same time) I remove points that are furthest away from the annticipated stitch lines. This seems to give a better result

-   As there is nothing in the foreeground (typically 30m to infinity) I use Viewpoint correction sparingly to try to improve teh stitch. I understand this is NOT what viewpoint correction s there for!

Thanks for the support

James

[mark palmos]

On Wednesday, 10 April 2019 07:56:12 UTC+1, James Gentles wrote:

Comparing PTGui PRO Version 10.0.11 and 11.12 performance as installed using the same set of images:   

I agree, v11 has been a major step back for people like me who are not experienced/good at doing everything manually. v10 was way better at doing a decent job off the bat. 

It also does some weird things, like I import 8 photos, 6 around and two up (the to up  have been rotated 90° cw)

When I import them, they are all vertical in PTGUI, but as soon as I press to Align Images, and some of the images that were always vertical get auto rotated by PTGUI and the result is "very bad"...

I've just tried to add control points on v11 and the awful mess doesn't get better, but I just installed v10 too, and it immediately does a pretty good job without any manual work.

Something has taken a major step backwards with v11, and this has been from the very start of v11 unfortunately.

I can make a video if you like, but really I think it is pretty obvious there is a major difference.

I hope this can be fixed, or reverted to the way v10 did Image Alignment so well.

Tx Mark.

 

[PTGui Support]

Hi Mark,

Could you make the set of images available for download so I can
reproduce the problem?

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.

> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ptgui/7d856695-bae0-4afa-ab90-422537101b56%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/7d856695-bae0-4afa-ab90-422537101b56%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Roy Hughes]

That rotation occurs on 10 and 11 on Apple OS. If you quit the program and reload it sometimes goes away. Sometimes it doesn’t. Very difficult to reproduce. Personally I could not say 11 is worse than 10 though.

[mark palmos]

Hi Joost,

Thanks... here is a link to the images as an example, and also the two screen grabs showing the sharp difference in the results comparing v10 vs v11.

https://drive.google.com/open?id=1iUZosg60MFsu8uZcAAF7TKj_x-JnGN7L

By the way, only the two zenith images were rotated 90°CW - the others were not rotated at all when I converted them from raw to jpeg in Lightroom.

Thanks,

Mark.

> an email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.

[Erik Krause]

Am 13.04.2019 um 01:20 schrieb mark palmos:

> When I import them, they are all vertical in PTGUI, but as soon as I press
> to Align Images, and some of the images that were always vertical get auto
> rotated by PTGUI and the result is "very bad"...

Did you read https://www.ptgui.com/support.html#4_6 ?

This behavior didn't change since the very beginnings of PTGui.

If you get a "very bad" this is most likely a result of misplaced
control points. Placing more points doesn't help in this case. The only
solution is to identify the misplaced points and delete them. Sometimes
"Delete worst control points" works, sometimes you can spot them in the
Control Point Table (which you can sort by distance) or the Control
Point Assistant.

If you make the source images available we can easily identify the
source of the problem.


--
Erik Krause
http://www.erik-krause.de

[John Houghton]

On Saturday, April 13, 2019 at 10:01:18 AM UTC+1, mark palmos wrote:

Hi Joost,

Thanks... here is a link to the images as an example, and also the two screen grabs showing the sharp difference in the results comparing v10 vs v11.

https://drive.google.com/open?id=1iUZosg60MFsu8uZcAAF7TKj_x-JnGN7L

By the way, only the two zenith images were rotated 90°CW - the others were not rotated at all when I converted them from raw to jpeg in Lightroom.Hi Mark, 

Mark, I loaded the supplied images into PTGui V11, set the lens type to 15mm fullfame fisheye (not knowing what lens was used), ran Align Images and got a perfect stitch. I saw that the optimizer had ended up with the lens focal length = 13.02mm.  I repeated the stitch but set the focal length to 13mm and ran Align Images and got a good stitch once again. I used PTGui V12.13.

BTW, you should run Align Images only once.  Thereafter, make changes to control points etc and run the optimizer.

John

[Erik Krause]

Am 13.04.2019 um 11:01 schrieb mark palmos:

> https://drive.google.com/open?id=1iUZosg60MFsu8uZcAAF7TKj_x-JnGN7L

I threw the images on both versions of PTGui and choose Fullframe
Fisheye, since the images don't contain lens information. After Align
Images PTGui 11 produced a nice looking preview while PTGui 10 failed to
find control points for the two zenith images. I needed another
"Generate Control Points" and optimization (F5) run for that.

You should have set the lens type correctly in PTGui 11. If there is no
lens info in EXIF data PTGui has a hard time to guess the lens type. In
your PTGui 11 project it is 14.4mm rectilinear, which obviously can't
work. Set it to Fullframe Fisheye and press F5 to optimize again. This
should do the trick. Or start from scratch and answer the question about
the lens type correctly.

> By the way, only the two zenith images were rotated 90°CW - the others were
> not rotated at all when I converted them from raw to jpeg in Lightroom.

Auto rotation should be switched off in camera. Pointing the camera
straight up or down the sensor output is not defined and can give
arbitrary results. While PTGui 11 now can deal with arbitrary rotated
images it can't figure out whether the image was rotated clockwise or
counter-clockwise.

[PTGui Support]

I thought this problem was fixed some time ago, before the release of
PTGui 11.

If it still happens, please make the images available for download and
I'll be happy fix any bugs.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

[PTGui Support]

Hi James,

I think the stitching difficulties stem from parallax, although it's
more severe than I would expect.

In any case it's perfectly fine to use viewpoint correction for these
kind of images, as long as the control points are mostly placed on
ground surface. Control points on elevated objects should only be placed
if they are far away from the camera. Just remember to enable viewpoint
correction on all images except one (which will be used as an anchor).

And although VP correction may improve the alignment, it may cause
nearby buildings to appear slanted.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> 1. The james.pts file and the accompanying changes used with

> version 11 as suggested by Joost give a decent stitch on your
> original images which are challenging.

> 2. Running your pts file on 10 or 11 don't produce great results. I

> find it difficult to say 10 is worse than 11 or 11 is worse than
> 10, possibly just different to each other. I notice that 10
> sometimes stitches them upside down.
>
> Subjectively I agree I think 11 does work differently to 10 but
> without a numerical measure of errors its really not possible to say
> anything other than that. It's almost as if the errors on 10 are
> less visually jarring than on 10 but that then leads us to distrust
> our subjectivity relative to a true numerical precision.
>
> The problem you have is broadly NOT the same as mine. Mine began by
> noticing whereas 10 was tolerant to Aperture priority mode on fusion

> it is not on 11. It was suggested than 10 should *not* really have

> www.ptgui.com <http://www.ptgui.com>

> > www.ptgui.com <http://www.ptgui.com> <http://www.ptgui.com>

> https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com>
>
> >
> <https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/ptgui/c2971786-2157-4594-9d9d-c199a2412d50%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit

> https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.

> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ptgui/6e32cc2a-27a8-4964-bc43-6fc1eb20d451%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/6e32cc2a-27a8-4964-bc43-6fc1eb20d451%40googlegroups.com?utm_medium=email&utm_source=footer>.

[PTGui Support]

Hi Mark,

I think you're using the Samyang 12mm, right?

Actually PTGui 11 gives great results because it includes a lens preset
for this lens. After loading the images, the 'focal length' dialog box
pops up. Enter 12mm and select the Samyang 12mm fisheye from the list.
Then proceed to Align Images.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

On 13/04/2019 11:01, mark palmos wrote:
> Hi Joost,
> Thanks... here is a link to the images as an example, and also the two
> screen grabs showing the sharp difference in the results comparing v10
> vs v11.
>
> https://drive.google.com/open?id=1iUZosg60MFsu8uZcAAF7TKj_x-JnGN7L
>
> By the way, only the two zenith images were rotated 90°CW - the others
> were not rotated at all when I converted them from raw to jpeg in Lightroom.
> Thanks,
> Mark.
>
>
> On Saturday, 13 April 2019 07:18:20 UTC+1, PTGui Support wrote:
>
> Hi Mark,
>
> Could you make the set of images available for download so I can
> reproduce the problem?
>
> Kind regards,
>
> Joost Nieuwenhuijse

> www.ptgui.com <http://www.ptgui.com>

> > an email to pt...@googlegroups.com <javascript:>
> > <mailto:pt...@googlegroups.com <javascript:>>.

> > To post to this group, send email to pt...@googlegroups.com

> <javascript:>
> > <mailto:pt...@googlegroups.com <javascript:>>.

> > Visit this group at https://groups.google.com/group/ptgui

> <https://groups.google.com/group/ptgui>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/ptgui/7d856695-bae0-4afa-ab90-422537101b56%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/7d856695-bae0-4afa-ab90-422537101b56%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/ptgui/7d856695-bae0-4afa-ab90-422537101b56%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/ptgui/7d856695-bae0-4afa-ab90-422537101b56%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.

> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ptgui/14fc5ca1-23e2-40a5-9ab8-c6eca9689912%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/14fc5ca1-23e2-40a5-9ab8-c6eca9689912%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark palmos]

Hi John, Erik, Joost

The lens is a 12mm samyang, sorry, I should have said. It is on a Sony A7Rii which does not have an auto rotate OFF option :((

I had set it to 12mm, but 15mm worked really well with v11 and that pano. I will be stitching more later this weekend and will report back with it set to 15mm. Odd since the lens says 12mm... but if it works, I don't care how odd it may seem!

Thanks for the quick and good input fellas, I will let you know how things proceed.

EDIT. I have just spend an amazing 45 minutes doing what took me hours yesterday... setting v11 on the samyang preset (no idea why I did not see it before) got me near perfect, or "good enough to use" without further tweaking. Very fast and accurate. I still wonder why that worked so well, and why I got such horrendous results using 12mm full frame! Anyhow, I will do more tomorrow. thanks again.

Cheers,

Mark.

[John Houghton]

On Saturday, April 13, 2019 at 4:16:41 PM UTC+1, mark palmos wrote:

EDIT. I have just spend an amazing 45 minutes doing what took me hours yesterday... setting v11 on the samyang preset (no idea why I did not see it before) got me near perfect, or "good enough to use" without further tweaking. Very fast and accurate. I still wonder why that worked so well, and why I got such horrendous results using 12mm full frame!

Mark, Erik already pointed out that your screenshot showed that you had the lens type as rectilinear rather than fullframe, which accounts for the horrible results. 

John

[Roy Hughes]

Joost

I find it completely random. It seems if I’ve been using the code for several hours it will throw the bug up sometime during that period. But then when I try to repeat it I can’t. I have never raised it before because I am totally unable to reproduce it. It’s not a big problem it just goes away by itself. I wouldn’t sweat it.

Roy

[Roy Hughes]

James
I have some experience of aerial photography, not drones or kites but the in the air stuff. Some experience of 360 and I kinda understand some of the practical difficulties. I looked at what you do on your site and it’s great. My wife has done a bit of kiting (I can’t tell you what, delta wing ones and butterfly looking stunt ones and we used to attend the Bristol kite festival often). We’ve shot video and aerial footage too, had stuff tv, a lot of hot air ballooning. Never shot from a kite though.

I reckon if you could improve your rig you might get better or easier results. My rule of thumb is get as much done in the camera and on a shoot as you can. You want the software to be tunable, a tool and then forget about it. That’s my logic anyhow. So as Joist says if it’s parallax then work to avoid that. Perhaps a titanium rig or stiffening to your Velcro arrangement. Perhaps a kite with better low wind lifting power? Not my field but maybe hardware mods could be a fun challenge and refresh your passion. Then of course you have the camera change. I have no experience of the Ricoh but maybe?

Have fun with it all

Roy

[James Gentles]

Erik,

You say help with arbitrary rotation of images was added in V11. As my images are offset from portrait could this be why workflow for V10 is sub-optimal in V11?

Joost,

I understand the parallax issue, but I to am interested that you think ti is significant. I managed to tune my nodal mount to get just ~5px error between infinity and 10cm, But with this rig the cameras are 50-60mm apart. The 4 Gopro HERO3+ are mounted in an inverted pyramid, the corner of the cameras are ~20mm apart, see image here http://www.gentles.info/KAP/Rigs/index.htm?item=16 I cant get them closer. However nothing is ever in the foreground, so in the test example the closest object is the ground, at least 20m, thats my extreme, normally it's >30m. Using this tool www.tawbaware.com/maxlyons/calc.htm I calculate the parallax error as 6px at 20m and 4px at 30m? So excluding the area immediately around NADIR, and for shots at a more normal height this error is not significant?

All,

I wnet back and tried 4 versions of PTGui, with the same images (see above) and I intended to do the same workflow on all 4.

The test proved more difficult than I anticipated because I think my workflow is probably a combination of what worked rather than whats logical. With V11 being different I need a differnet workflow as already discussed. However I have 2 points to make about this.

Here are the worse case results for the stitch using 4 revisions "as-installed".

10.0.17 25px

10.9.19 24px

11.3      62px

11.12    33px

Is there a clue that something changed between 11.3 and 11.12?

a. You mentioned before that the worst case point isn't the key, its what it looks like and the average. If that is the case then the average only appears after an optimise, however the worst case can be sorted, and seen in the Control Point Table, Control Point editor etc etc.As you can always see the worst case its easy to make it the proirtiy? Is there any way an average value could be added to some of these control point lists and tables to help emphasise the average as well as the worst and best?

b.. From a sales perspective, prospective purchasers are just going to throw images at the program in DEMO mode.before making a purchase decision, very few will get to understand the advanced features before buying. This is why I htink its important to get "good" results "on download and install" for as many people/scenarios as possible.

Regards

James

On Saturday, 13 April 2019 12:40:42 UTC+1, PTGui Support wrote:

Hi James,

I think the stitching difficulties stem from parallax, although it's
more severe than I would expect.

In any case it's perfectly fine to use viewpoint correction for these
kind of images, as long as the control points are mostly placed on
ground surface. Control points on elevated objects should only be placed
if they are far away from the camera. Just remember to enable viewpoint
correction on all images except one (which will be used as an anchor).

And although VP correction may improve the alignment, it may cause
nearby buildings to appear slanted.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

.

.

.

[James Gentles]

Roy,

Thanks for the positive strokes.

Kites have been around for 1000s of years, photography using kites since 1880, and yes its green!

The first aerial 360 was taken in the1980s with a slit scan camera that was clockwork. It pulled the film past a slit as the whole camera rotated in sympathy, you got about 4x 360 rotations on one 36exposure film.

It was critical to tick the "DO NOT MOUNT" box when sending teh film for development. Happy Days!

As you can see from the rig http://www.gentles.info/KAP/Rigs/index.htm?item=16 the cameras are aligned with lens down and one corner pointing to NADIR to get them as close together as possible, In a previous posting I calculate the parallax error is 6px at 20m and 3px at 40m AGL. The flight to flight velcro error is about 2mm in camera position, stitching should manage that. You cant tell from the picture but the rig is not symetrical, its 5degrees off to take care of wind loading. I also just improved the firing software to improve it from 0.25seconds to <1/100 second. This also improves stitchng as it removes the time-domain parallax error.

I am open to new cameras, but so far the HERO3+ is light, reasonalbe quality, and cheap to replace if a hard landing...

Thanks for your interest.

To you and your wife, tight lines!

Regards

James.

[Erik Krause]

Am 13.04.2019 um 21:29 schrieb James Gentles:

> You say help with arbitrary rotation of images was added in V11. As my
> images are offset from portrait could this be why workflow for V10 is
> sub-optimal in V11?

In PTGui prior to v11 the horizontal field of view (hFoV) was the value
to be used as a basis for all calculations (for historical reasons
lengthy to explain). Obviously the hFoV is different for a landscape and
a portrait image shot with the same focal length.

v11 now uses the focal length as a basis and hence is independent from
the orientation. However, if you mix portrait and landscape in one
project PTGui still needs to know whether you rotated the camera
clockwise or anti-clockwise. This is because PTGui can compensate for
image center shift (caused by a decentered lens etc) and shift
parameters would be eventually applied in the wrong direction.

I don't know your particular workflow in detail hence it's hard to
imagine a case where it shouldn't work in v11. But I know that v11 is
much nearer to a fool proof solution than previous versions. All
panoramas I shot physically ok (with a tripod from the exact
no-parallax-point) PTGui produced flawless results by just using the
Project Assistant.

[PTGui Support]

On 13/04/2019 21:29, James Gentles wrote:
> Erik,
> You say help with arbitrary rotation of images was added in V11. As my
> images are offset from portrait could this be why workflow for V10 is
> sub-optimal in V11?

No this is unrelated. It's just that PTGui 10 didn't support a mix of
portrait and landscape images in 1 project. Your images all have the
same orientation.

> Joost,
> I understand the parallax issue, but I to am interested that you think
> ti is significant. I managed to tune my nodal mount to get just ~5px
> error between infinity and 10cm, But with this rig the cameras are
> 50-60mm apart. The 4 Gopro HERO3+ are mounted in an inverted pyramid,
> the corner of the cameras are ~20mm apart, see image here
> http://www.gentles.info/KAP/Rigs/index.htm?item=16
> <http://www.gentles.info/KAP/Rigs/index.htm?item=16> I cant get them
> closer. However nothing is ever in the foreground, so in the test
> example the closest object is the ground, at least 20m, thats my
> extreme, normally it's >30m. Using this tool
> www.tawbaware.com/maxlyons/calc.htm

> <https://www.tawbaware.com/maxlyons/calc.htm> I calculate the parallax

> error as 6px at 20m and 4px at 30m? So excluding the area immediately
> around NADIR, and for shots at a more normal height this error is not
> significant?

Yes as I said it's a larger error than I expected. Could rolling shutter
be an issue? I can imagine the position is quite steady but KAP rigs can
rotate a bit. I have seen problems in the past which turned out to be
caused by rolling shutter, this was using a robotic panohead which
didn't come to a stop between shots, and a A7RII using the electronic
shutter mode.

You might try a panorama with the rig on a high building. Or use a
longer exposure time: any movement would cause blur at long shutter
times, the same movement could cause rolling shutter issues at short
exposure times.

> All,
> I wnet back and tried 4 versions of PTGui, with the same images (see
> above) and I intended to do the same workflow on all 4.
> The test proved more difficult than I anticipated because I think my
> workflow is probably a combination of what worked rather than whats
> logical. With V11 being different I need a differnet workflow as already
> discussed. However I have 2 points to make about this.
> Here are the worse case results for the stitch using 4 revisions
> "as-installed".
>
> 10.0.17 25px
> 10.9.19 24px
> 11.3      62px
> 11.12    33px
> Is there a clue that something changed between 11.3 and 11.12?

Yes, 11.7 had improved rejection of bad control points. The remaining
difference could be explained by having control points more spread out
over the image, where v10 would find control points more clustered in a
smaller area.

>
> a. You mentioned before that the worst case point isn't the key, its
> what it looks like and the average. If that is the case then the average
> only appears after an optimise, however the worst case can be sorted,
> and seen in the Control Point Table, Control Point editor etc etc.As you
> can always see the worst case its easy to make it the proirtiy? Is there
> any way an average value could be added to some of these control point
> lists and tables to help emphasise the average as well as the worst and
> best?

Perhaps that could be useful. But Delete Worst Control Points takes in
account those averages already.

> b.. From a sales perspective, prospective purchasers are just going to
> throw images at the program in DEMO mode.before making a purchase
> decision, very few will get to understand the advanced features before
> buying. This is why I htink its important to get "good" results "on
> download and install" for as many people/scenarios as possible.

Well of course, I'd like to have PTGui produce a perfect panorama
whatever you throw at it and sell millions of copies! And I think it
does work nearly perfectly in 99% of the cases if you feed it with
proper parallax-free (and rolling shutter free) images. You'll get
control point errors of 2 or less straight away. So there is some
problem which makes your images difficult to stitch.

Joost

[PTGui Support]

Actually James is one of the pioneers of kite 360 panoramas! I remember
seeing your images in the early 2000s.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.
> To post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ptgui/3a03f0a5-129e-4751-ab91-5a7a67ae9abb%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/3a03f0a5-129e-4751-ab91-5a7a67ae9abb%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Roy Hughes]

James, Joost

Yeah I love this sort of stuff. As a commercial photographer I very much focus on getting a job done so it’s wonderful to remember what it was like to play with stuff. Which brings me to a point. PTGUI is pretty good (despite my moans and you’ll notice for me it’s all about doing as little as possible, time = money it’s just a fact of life).

Looking at James’s problem I am wondering about the rig. (I followed the rolling shutter argument I have met that in another context) Could there be more than 2mm variation in position? It gets buffeted by the wind, there are temperature changes I presume through the breeze, and I wondered if Velcro, bolts and wood might give more than that over all four cameras?

So is there a way of building this into a software compensation, you know set up say a few templates and quickly pick and choose between them. If one doesn’t give a close stitch drop it, an open option two and try again and so forth etc. A fast track manual optimisation before using the software in earnest. I am guessing the shift would be a difference in the mutual orthogonality of each cameras sensor plane and the angular displacement of the plane off the tangent. Can that be translated into a family of templates? Just a thought.

Roy

[Jim Watters]

James,

I remember your work from way  back.

I have optimized my share of multi camera rigs in my time. I gave your set of images a go.

I agree with John and I recommend using templates too. Having as many lens parameters locked in helps.

Label the camera and the position so they are always in the same order.

Letting the parameters all be optimized may bring down your errors but often at the expense of introducing weird distortion.

For your images I only got really good results by having individual lens settings for each of the lenses. I ended up adding about 140 control points between images to .

For my own GoPro multicamera rig, I created a little holder for GoPo to center the NPP over the tripod center and rotate the camera around to create a single row pano to optimize the parameters precisely. I used the settings from each camera as the lens settings in my final template. For you I just added a ton of control points to get best results I could.

https://www.tinkercad.com/things/c0meFRWrZ5d

For the template I put in average YPR values so when you open any new set of images, even this project they are only roughly aligned.

When I open the 4 images, apply my template and align images I get an average less than 3 and max less than 9

I am only optimizing YPR. My Settings is set to add 25 CP between pairs. After deleting worst I have between 20 and 25 CP between pairs, hardly any CP on the horizon.

I did find Optimizing viewpoint correction helped to further align the original project but I would only do that when using the template if you have added extra control points on the horizon first.

Please try the template on other set of images taken with the cameras in the same order.

Jim

On 2019-04-12 2:45 PM, James Gentles wrote:

-   I always add extra control points at the 4 horizon seams. Control Point addition in PTGui is frame-center weighted (this has changed for the better over time) but because of camera orientation one part of the horizon is right in a frame corner

This is easily done by drawing a selection in the area and right click to generate control points here.

-   All 4 cameras csn see NADIR. If the 4 images are 1,2,3,4 I always remove control points 2+4 and 1+3 leaving 1+2, 2+3, 3+4, 4+1, this seemed to give a better stitch

I actually found leaving these in helped with my results. Normally I would say you would want to remove these.

-   In exceptional conditions (images are not taken at exactly the same time) I remove points that are furthest away from the annticipated stitch lines. This seems to give a better result

This is definitely a good idea, alignment at the seem is all that matters.

-   As there is nothing in the foreeground (typically 30m to infinity) I use Viewpoint correction sparingly to try to improve teh stitch. I understand this is NOT what viewpoint correction s there for!

I will often enable it for every other image. Then switch those to keep and optimize the others. I find this help constrain the results from getting out of hand.

Thanks for the support

James

Jim Watters

[Jim Watters]

On 2019-04-14 5:52 PM, 'Roy Hughes' via PTGui Support wrote:
> Looking at James’s problem I am wondering about the rig. (I followed the rolling shutter argument I have met that in another context) Could there be more than 2mm variation in position? It gets buffeted by the wind, there are temperature changes I presume through the breeze, and I wondered if Velcro, bolts and wood might give more than that over all four cameras?

I think the problem is not having good starting values for the
individual lenses. When I got a very good alignment and was swapping
between the images I could see very little errors except in the nadir of
the images. The subject is too far away to be much of a problem.

Jim Watters

[mark palmos]

Thanks John,

The rest of the project went very quickly and easily. Thanks for the support, people!

Mark.

--
You received this message because you are subscribed to a topic in the Google Groups "PTGui Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ptgui/l8K4Tf__Wn4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ptgui+un...@googlegroups.com.
To post to this group, send email to pt...@googlegroups.com.

Visit this group at https://groups.google.com/group/ptgui.

To view this discussion on the web visit https://groups.google.com/d/msgid/ptgui/959622f1-6306-4054-a432-88d4eaaa3977%40googlegroups.com.

[James Gentles]

Jim,
This is great, many thanks. Your template gives the best results based on the understanding we now have about the specifics of the images and their challenges. I wont go through your comments one by one but it seems that I have been sticking over the last few years with a process that works, rather than one that is correct, hence the fall from grace with V11. I think given the challenges people see why I was reluctant to change a "working" process.

Eric,
Thanks for the V10-V11 information. I wont describe the workflow in detail (this is already getting very complex), suffice to say it is complicated by the physical and environmental conditions getting the thing to fly. I have accepted that my workflow was optimised for the problems I have, and that V10-V11 has resulted n requiring to look at this a-new

Joost,
Rolling shutter! Very interesting. In all the years I have been doing that I never considered GoPro's achilles-heel, the rolling shutter. Becasue the cameras are externally syncronised, I know that the image data is collected over 30mS, so the image capture is less than 30mS. I also estimate the worst case travel is 60cm/second. That gives a parallax of absolute maximum 18mm,normally I would say its far better so this adds noise to the results, useful to know, but not the killer imparement.

Roy,
There are many compormises, and I see where you are coming from, but the saving grace is that "normally" there is no foreground, so the camera parallax error is cancleled out by the lack of anyhting within 30m of the camera.

For interest, I attach an analysis of the camera angles which minimises the number of cameras required  and also tries to keep out of the corners! Older HEROs have soft corners, which only get worse when "stretched" by the projection, rubbish in rubbish out! By tilting the cameras the horizon increases from 90 to 100degreees allowing 4 cameras to have enough stiching overlap. The small purple box is the area of the image that when re-projected becomes unusable.

Enhancement?

1. I still think it's worth considering ptutting a "guide" average control point error up as a measure of best stitching. Its to easy to get side-tracked with the worst point.

2. Roy suggests some templates, and I guess there is the danger that you encourage people to not bother fixing the problem rather than adding software workarounds, I know you feel that the AUTO-ALIGN is 99% good to go, and I now have "my" solution, but maybe there is a need to lead people through the AUTO-ALIGN. Right now if the results are "bad" suggestins are given as to what to do next. I dont think there are suggestions if the results are "not so good" Are there opportunites here for the software to give nuanced feedback for some of these more subtle errors, like parallax, in its many forms?

Regards

James

[PTGui Support]

On 4/15/2019 12:23, James Gentles wrote:
> Joost,
> Rolling shutter! Very interesting. In all the years I have been doing
> that I never considered GoPro's achilles-heel, the rolling shutter.
> Becasue the cameras are externally syncronised, I know that the image
> data is collected over 30mS, so the image capture is less than 30mS. I
> also estimate the worst case travel is 60cm/second. That gives a
> parallax of absolute maximum 18mm,normally I would say its far better so
> this adds noise to the results, useful to know, but not the killer
> imparement.

Hi James,

Actually I'm not entirely convinced that the rolling shutter can be
neglected. But the issue would be rotation of your rig, not translation.
Rotation around the vertical axis.

Suppose the rig is rotating at a speed of 45 degrees per second, readout
time is 30ms, width of the image is 3000 pixels and hfov is 90 degrees
then this results in a shift of 3000*45/90/30
= 50 pixels during the sensor readout.

I have no idea if the 45 degrees/s is anywhere near realistic or not,
but there must have been some wind otherwise you couldn't fly.

Rolling shutter is somewhat similar to shear distortion, so I tried
enabling shear optimization and got these results:

without shear opt: 2.16 avg, 6.66 max
with shear opt: 1.29 avg, 3.75 max

Both are with viewpoint correction enabled. Lots of control points both
in foreground and background. You can check the attached project files.

Joost

[James Gentles]

Joost,

Thanks for continuing to think about this. You are correct, I had not considered rotational (rather than planar) errors caused by the rolling shutter.

Some time ago I did some deep dive analysis of all types of movement induced by the kite, in order to best design the passive damping system used, called a "picavet suspension". This work actually "re-invented" some techniqus that were originally discovreed 100years ago. Drones also have similar but different issues (that are "actively" compensated for these days).

The best images (with a level horizon) are normally taken as the kite and rig "rest", this happens about every 10-15seconds when the wind just backs off a tiny bit and everything "settles", a sweet-spot for best stitching!

So I would place the worst case twist much less than 45degrees, but this would still leave an up-to 10pixel error whch is one of the most significant discussed so far..

Feel like there are many imperfections, but we are considering worst case all the time, so on a bad day its going to be bad, the qustion is on a "average" day how bad is it. Given I will take 100s of images, and only use 1 set, maybe if it wont stitch I should be quicker to give-up and try the next set of images taken 4 seconds later?

By taking the best of the offered solutions (templates) I think I'm now back to the errors I used to get, BUT with a much better understanding of their origens. I will try and summerise the findings in a post in the next week. Although the specifics are related to the vagaries of kites, maybe the thinking will be of use to others with "instabillity".

James

[Claude Lada]

please remove

--
You received this message because you are subscribed to the Google Groups "PTGui Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ptgui+un...@googlegroups.com.

To post to this group, send email to pt...@googlegroups.com.
Visit this group at https://groups.google.com/group/ptgui.

To view this discussion on the web visit https://groups.google.com/d/msgid/ptgui/2c720f38-7693-45a2-83a0-86f2352cd11f%40googlegroups.com.

[Jim Watters]

James,

I took the template I provided. Added Optimizing Horizontal Shear and reduced the average from 3.6 to 2.8

Toggling through the individual images in Panorama Editor the nadir looks much better aligned.

Adding Viewpoint correction I got it down to average 1.5 and max of 5

I recommend calibrating each of the cameras. You can do this individually or by putting the rig on a stationary tall pole take a set of images. Just ensure the cameras go back to same spots each time.

When optimizing images. First pass without shear nor Viewpoint correction. Remove worst control points. then if error too high, then enable them.

Jim

[James Gentles]

Jim (et al),

Many thanks for posting the template. A short note to say I have been on vacation for a week (collecting more raw material!), so my silence is not apathy, nor was I taking the great help received here for granted!

I still plan to post a sort of conclusion of what was found, as it may be useful "diagnostic workflow" for others.

[Jim Watters]

James,

Curious what progress you have made?

Jim

[Panowork.com魔鬼哥哥]

I bought an upgraded PTGUI 12 pro a couple of days ago, then find out the photos that were created had much more noise than the 11 one, so I switch back to 11. what a wasted money

[John Houghton]

On Sunday, February 12, 2023 at 10:22:49 PM UTC Panowork.com魔鬼哥哥 wrote:

I bought an upgraded PTGUI 12 pro a couple of days ago, then find out the photos that were created had much more noise than the 11 one, so I switch back to 11. what a wasted money

I'm sorry to hear you are not happy with the results from V12.  I did a comparative test with PTGui Pro V11.31 and V12.19  using tiff image files and found no difference in the generated panorama image quality.   Noise was identical.  But the suspected fault described in your post is not connected with the problems in this old topic, so I think it best if you start a new conversation and provide some sample camera images together with your project files with which the fault can be readily reproduced for investigation.  Be sure to provide version numbers of the software used.

John