malfunction in CPImageCtrl when the magnified image has over 2**27 pixels

[johnfi...@gmail.com]

In my experimentation for 400% and 800% magnification, I am experiencing a malfunction (entire image displays as black) when the magnified image is over 134217728 pixels.

I have a bad code change work around for the problem and will figure out a better code change.

Who do I ask for the mercurial write access, so I can put the relevant changes into a branch and try to get some testing by others?

I did a lot of stepping through the code looking for the actual failure point and haven't found it yet, but I expect to.

I think the whole failure might be dependent on the environment (such as, the bug may be in or below gtk, rather than in hugin or wxWidgets, and I expect some hugin environments don't use gtk).  I'm even more confident that the performance reduction (for the CP dialog) caused by my code change and the possible performance increase (relative to original, not just relative to a crude fix) likely from doing it right would be highly dependent on which tools (gtk etc. and maybe even display driver) are underneath.  I can't test enough to do that justice.

The crude fix is replacing the line:

dc.DrawBitmap(bitmap,0,0);

in CPImageCtrl::OnDraw with

if (bitmap.GetWidth() > 2*vSize.GetWidth() && bitmap.GetHeight() > 2*vSize.GetHeight() )
{
    int posX, posY;
    GetViewStart(&posX, &posY);
    wxBitmap const& subBit = bitmap.GetSubBitmap(wxRect(posX,posY,vSize.GetWidth(),vSize.GetHeight()));
    dc.DrawBitmap(subBit,posX,posY);
} else {
    dc.DrawBitmap(bitmap,0,0);
}

[David W. Jones]

Could it be related to display driver?

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

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

[johnfi...@gmail.com]

I don't actually know enough about the interface between the display driver and the level immediately above it to know whether it is even possible for this bug to be related to the display driver.

If it is related to the display driver, I'm using the closed source Nvidia 340 driver (the driver for VERY old Nvidia chips) so this could be an issue almost no one else would ever see.  But more likely it is not display driver related.

I don't have a correct build process on my Windows system (only on my Fedora 35 system), but I think I can get my changes into a Windows build that is valid enough for testing the CP dialog.  That is on my todo list for a first sample of how environment specific the bug is, before I ask anyone else to test.  My Windows system has a Radeon card that is a much newer and more common architecture than the ancient Nvidia card in my Fedora system.

Even if the bug doesn't matter to most users, a comment in the code indicated there is a desire to have this same type of code change there, because if done correctly it would be a performance boost (rather than my first try that reduces performance).

I also am doing this in conjunction with CP dialog feature improvements that others seem to be interested in.

[David W. Jones]

I don't have Windows here, I have Linux, with Nvidia's driver, v 460.91.03.

Which version of Hugin is this? I have v2021.0.0.52df0f76c700. Just
tried zooming in on some of my biggest panoramas, didn't encounter any
problems.

> *Who do I ask for the mercurial write access, so I can put the

> relevant changes into a branch and try to get some testing by

> others?*

wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.

[johnfi...@gmail.com]

On Sunday, January 30, 2022 at 12:24:42 AM UTC-5 GnomeNomad wrote:

Which version of Hugin is this? I have v2021.0.0.52df0f76c700. Just
tried zooming in on some of my biggest panoramas, didn't encounter any
problems.

It is my own build from a mercurial clone from Jan 16.  Also, I added choices for 400% and 800% zoom (because that was a feature I want, not because I wanted to test with very large zoomed images).

I found the problem only in the Control Points dialog (it might be elsewhere, I didn't test). There, it is the zoomed size of a single image that matters for this, not the size of the panorama, so likely you didn't test the bug I found.

At 400% zoom, a 3548x2365 original image failed.

At 200% it should take a 14190x9460 original image.  I ought to test that, but I haven't yet.

[johnfi...@gmail.com]

Oops.  I meant 800% for the 3548x2365

[johnfi...@gmail.com]

I guess I posted too early in the morning, while rushing out to shovel snow.

When I did the testing, I was careful about correctly computing the 2**27 zoomed image size.  In my above two posts, I wasn't:

7035x4730 is just over 2**25 so at 200% it should fail.

I was correct the first time that 3548x2365 fails at 400%.

[johnfi...@gmail.com]

It now appears to me that the limitation may be in the device driver (Nvidia).  There is quite a lot to this malfunction that seems to me to be almost impossible to fit into the theory that the malfunction is in the driver.  But I've stepped through the code down to the point that the image is passed to the driver (XShmPutImage) and it gets there with a valid looking image (and all related values) in the failure case, and it apparently passes the whole (giant) image to the driver along with clipping info, rather than clipping it before passing it.

I still think I can make the change in the way implied by the FIXME comment in CPImageCtrl::OnDraw so that for users who wouldn't see the problem, it would still be a performance boost.

I still don't know the right way to even request the mercurial rights needed to correctly share the changes I want to make.  Failing that, I have a fast enough CPU, if this is for my own use only, I don't care about the small performance cost of fixing this just enough to work vs. the performance increase of a better fix.

So for now, I'll go back to adding the features I want to that dialog, rather than further chase this problem.

Of course, if you think I misunderstood what I saw in stepping through the code (and the failure is actually elsewhere) I'm open to suggestions.

[Bruno Postle]

Hi John, I'm just catching up on my email, do you have access to the
Hugin repository yet?

If not, then send me your sourceforge username. Note that sourceforge
supports a fork/pull-request workflow (similar to github), so you can
work on a separate personal repository just as easily as the main
repository. If you do choose to work on the main repository, then
typically features get developed in temporary branches and merged into
'default' when ready for user testing. The default branch will become
the next release. The numbered branches are for specific releases, so
the 2021.0 branch is kept open in case a severe bug is found that
would require a hotfix release (never been needed so far).

--
Bruno

[johnfi...@gmail.com]

On Monday, January 31, 2022 at 5:35:33 PM UTC-5 bruno...@gmail.com wrote:

If not, then send me your sourceforge username. Note that sourceforge
supports a fork/pull-request workflow (similar to github), so you can
work on a separate personal repository just as easily as the main
repository. If you do choose to work on the main repository, then
typically features get developed in temporary branches

I sent the username via a direct email.

I think I should provide my first few enhancements, including the 400% and 800% zoom choices, initially without the work around for the problem with over 2**27 pixels in a zoomed  image.  If my changes then get tested, it should confirm or contradict my current guess that the 2**27 pixel limit is inside the obsolete and poorly supported closed-source Nvidia driver I'm using (Nvidia variant 340).

I'm still a bit far from understanding the performance tradeoffs of combining that work around for me with a more general performance improvement for large zoomed images.  So for a while, I'll use my crude work around, and share other changes for testing.