[Request]: Resolve confusion between "Distance" and "Correlation"

[ChameleonScales]

As this wiki page explains, after Fine-tuning all Points, the Distance column shows the correlation. I find this confusing. Distance and correlation are not the same thing. Would it be possible to instead add a Correlation column and leave the Distance column separate?

[T. Modes]

ChameleonScales schrieb am Samstag, 30. Januar 2021 um 20:54:39 UTC+1:

As this wiki page explains, after Fine-tuning all Points, the Distance column shows the correlation. I find this confusing. Distance and correlation are not the same thing.

When the correlation is displayed the column header changes to "correlation", when the distance is shown the column header reads "distance". I think this resolves the confusion - you have to read the header.

IMO with automatic cp detection with cpfind or other the function "fine-tune all" is not needed at all. It is an remnant from the times of manual setting control points.

[ChameleonScales]

Ok, a few things:

So I was using the Debian repository version (2018) and in this version the header did not change to "Correlation". I just tried on the latest appimage and indeed this has been solved, so that's my mistake.

However, on this same appimage (20210130), when you click on "Select by distance", the values change back to distance but the header is still "Correlation".

In any case, I think it would make things clearer and provide more information if the Correlation column was added next to the Distance column. Do you see a reason not to?

[ChameleonScales]

with cpfind or other the function "fine-tune all" is not needed at all

Ok, but seeing the correlation lets you know if, for example, the wind moves plants and the control point patterns are less alike than in other areas

[T. Modes]

ChameleonScales schrieb am Sonntag, 31. Januar 2021 um 16:54:09 UTC+1:

So I was using the Debian repository version (2018) and in this version the header did not change to "Correlation". I just tried on the latest appimage and indeed this has been solved, so that's my mistake.

So you are using an very old version…

However, on this same appimage (20210130), when you click on "Select by distance", the values change back to distance but the header is still "Correlation".

This is a bug, I will fix it.

In any case, I think it would make things clearer and provide more information if the Correlation column was added next to the Distance column. Do you see a

reason not to?

 Yes, calculation of the correlation is expensive. Calculate the correlation for showing in the GUI would take to much time and would slow down the GUI for most case.

> Ok, but seeing the correlation lets you know if, for example, the wind moves plants and the control point patterns are less alike than in other areas

No, that's wrong. Cpfind searches in different levels, correlation is only calculating in 100 % scale. So also a  good control point can also have a low correlation. The correlation alone is not a criterium for the quality of a cp.

[ChameleonScales]

This is a bug, I will fix it.

Cool, thank you!

calculation of the correlation is expensive

I assumed the correlation was also calculated when you detect CPs. That said I didn't necessarily mean to show it at all times. Just when you press Fine-tune all would be enough, but still in a separate column.

Cpfind searches in different levels, correlation is only calculating in 100 % scale.

Do you mean if you stitch photos with different resolutions, CPfind with find good CPs but the correlation calculation will give low values? Or does it also have implications on photos with the same resolution?

To explain why I imagine correlation next to distance being useful:
I assemble natural landscape panoramas which have to be stitched as precisely as possible.

Sometimes the wind moves leaves in a turbulent way and trees 200 meters from the camera may look slightly different between 2 photos.
On the other hand, if there's a stone 3 meters from the camera, the correlation and number of CPs is going to be higher on it because the wind doesn't affect it. Problem is: if the tripod is not properly calibrated to avoid parallax (I'm not always the one taking the photos), the far away trees may be more reliable even though they have low correlation, but Hugin may prefer the stone because there are more CPs on it. This means the optimizer will give a higher CP distance on the trees which will introduce a seam in the far away landscape.
"You should delete the CPs on the stone" I hear you say. The thing is I don't always know if there is parallax and sometimes, close elements take up such a large part of the photo that I'd prefer not to have CPs covering a small area, so I leave the ones on the stone in the hopes that there's no parallax.

And here's the point:

If I could see that the CPs with low correlation have a high distance, this would draw my attention and I may find that these CPs are in the far away trees and then I would know not to trust that stone and delete those CPs with more confidence.

Do you think there's a better approach?

[T. Modes]

ChameleonScales schrieb am Sonntag, 31. Januar 2021 um 19:15:50 UTC+1:

calculation of the correlation is expensive

I assumed the correlation was also calculated when you detect CPs. That said I didn't necessarily mean to show it at all times. Just when you press Fine-tune all would be enough, but still in a separate column.

But then the column would be the most time 0, then there will be other complains.

Cpfind searches in different levels, correlation is only calculating in 100 % scale.

Do you mean if you stitch photos with different resolutions, CPfind with find good CPs but the correlation calculation will give low values? Or does it also have implications on photos with the same resolution?

Cpfind is working internally on different levels, I did not meant images with different resolutions. So cpfind can also find good cp at a higher level - which can have low correlation values (which is only calculated at 100 % scale, but the cp is evaluated by cpfind at another level ).

To explain why I imagine correlation next to distance being useful:
I assemble natural landscape panoramas which have to be stitched as precisely as possible.

Sometimes the wind moves leaves in a turbulent way and trees 200 meters from the camera may look slightly different between 2 photos.
On the other hand, if there's a stone 3 meters from the camera, the correlation and number of CPs is going to be higher on it because the wind doesn't affect it. Problem is: if the tripod is not properly calibrated to avoid parallax (I'm not always the one taking the photos), the far away trees may be more reliable even though they have low correlation, but Hugin may prefer the stone because there are more CPs on it. This means the optimizer will give a higher CP distance on the trees which will introduce a seam in the far away landscape.
"You should delete the CPs on the stone" I hear you say. The thing is I don't always know if there is parallax and sometimes, close elements take up such a large part of the photo that I'd prefer not to have CPs covering a small area, so I leave the ones on the stone in the hopes that there's no parallax.

And here's the point:

If I could see that the CPs with low correlation have a high distance, this would draw my attention and I may find that these CPs are in the far away trees and then I would know not to trust that stone and delete those CPs with more confidence.

The correlation is only calculated at a small region (default 21x21 px). So if there is a parallax error this is not necessarily visible in the correlation value.

And cpfind is not using this correlation value - it uses another algorithm. So the correlation value say nothing about the quality of a cp. (The correlation is only used by the fine-tune algorithm, nothing else uses this value.)

And a single cp has (in most cases) no big effect on the whole pano. All cp work together. So if you have cp on the "stone" and the "tree" the optimiser will try to satisfy the alignment of both elements. But if you prefer the alignment in one of the elements leave the cp only on this element and remove the cp on the other. But this is a matter of the image content and of personal taste which element is more important, so there is no general algorithm how to solve this problem.

[ChameleonScales]

I'm afraid you misunderstood a few parts.

Yes, parallax doesn't affect correlation and yes a single CP has a low influence on the optimizer.

As I understand the optimizer, it prefers what satisfies the larger number of CPs. If it has to chose between satisfying a few CPs in the trees or many CPs on the rock, it will prefer the rock and therefore the tree CPs will be more distant (if there is parallax).

And yes you may want to focus on the rock. That doesn't change the issue. You could switch it and have mountains in the back and bushes 3 meters away.

The point is if you could see both distance and correlation at the same time you may more easily determine whether there is parallax in those windy cases.

But if you say that the calculated correlation is not reliable in the first place, I guess there's no point in using it at all, in which case I can drop this request.

[Klaus Foehl]

On 31.01.21 19:15, 'ChameleonScales' via hugin and other free panoramic

software wrote:

> I assemble natural landscape panoramas which have to be stitched as
> precisely as possible.

Maybe you are aware that hugin implements only a small number of
distortion parameters from the Brown-Conrady lens model. Higher order
physical lens distortions are unaccounted for.

Does hugin so far satisfy your precision requirements?

Best regards

Klaus

[ChameleonScales]

> Maybe you are aware that hugin implements only a small number of
distortion parameters from the Brown-Conrady lens model

Yes, I remember you told me here https://groups.google.com/g/hugin-ptx/c/ERSQCxkbxkw/m/hFZmxWOwAwAJ

> Does hugin so far satisfy your precision requirements?

At least if a panorama lacks precision it's due to either the wind or the camera not being properly calibrated so I don't think a more complete lens model would make much of a difference.

It's more a matter of manipulating control points efficiently.
Sometimes an iterative "optimize > select by distance > delete > optimize, etc..." converges towards the wrong objects and by the time I realize there is an issue I have to either restart by eliminating the right CPs from the beginning or just place some CPs manually.

I'm mostly looking for an efficient workflow to determine early on whether there is parallax or large moving/deforming objects.

Thinking of it, something that would be totally awesome is a vector map overlay, showing the distance between control points and the direction towards their corresponding one. This way you could immediately see from the first optimization if and which objects are moving relative to each other and decide what to do about that.

Does that seem like a good idea to you?

[ChameleonScales]

Or perhaps more simply vector arrows on each control point, with direction and magnitude.
I have a CGI brain so I thought "vector map" with colors but actually arrows would be much easier to program and work just fine.

[dgjohnston]

Before I use hugin I usually use DxO PhotoLab to correct for lens and camera body distortion. Does anyone know if DxO uses the Brown-Conrady lens model for their routines or anything similar?

In the wikipedia entry for “Distortion” there is one comment about this:

• DxO Labs' Optics Pro can correct complex distortion, and takes into account the focus distance.

Optics Pro was renamed to PhotoLab in a previous release.

Also look at DxOMark the company that does the lens and camera testing to create the correction modules for lens-camera pairs.

Don J.

--
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/e1c1e6cc-366d-cfe7-0cbb-1d53d712f848%40gmail.com.

[Greg 'groggy' Lehey]

On Monday, 8 February 2021 at 21:28:45 -0600, dgjohnston wrote:
> Before I use hugin I usually use DxO PhotoLab to correct for lens
> and camera body distortion.

Yes, I do that too.

> Does anyone know if DxO uses the Brown-Conrady lens model for their
> routines or anything similar?

The DxO developers will know. Why don't you ask a question of
support?

Greg
--
Sent from my desktop computer.
Finger groo...@gmail.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[Abrimaal]

"Fine tune all points" is usable. I often make two versions of the same panorama, with and without Fine tune.
It is often visible on the preview, that the panorama layout changes after fine tuning.
When adding control points manually, a human selects the most sharp edges and the highest contrasts.
The detector (I think) compares blocks X × Y pixels, this is why these points look misplaced.
The similarity is very low.

The image is an example, that points 5, 7, 8, 10, 11 are auto-detected, where a human would never place control points.
Points 9, 12, 13 are added manually and fine tuned.
After deletion of the misplaced points 5, 7, 8 the final result may be much better.
It would be much better if "Fine tune all points" automatically removed points with low correlation.
Correlation is similarity, and it is not related to distance (in pixels).

By the way, this is an analogue scan, the result may differ from digital photos.
The points could be placed on dust :)

[Klaus Foehl]

Hello,

On 09.02.21 04:28, dgjohnston wrote:
> Before I use hugin I usually use DxO PhotoLab to correct for lens and
> camera body distortion. Does anyone know if DxO uses the Brown-Conrady
> lens model for their routines or anything similar?

You probably know that hugin uses "abc" of which only b is a proper
parameter of the Brown-Conrady lens model.

Best regards,

Klaus

[Donald Johnston]

I did not know that. Thanks. I use DxO to make sure the images are as free from camera and lens distortion as possible. I think hugin can then do its magic a bit better.

Don