Control Point dialog features

[johnfi...@gmail.com]

I want to make a bunch of changes to the control point dialog.

Maybe this is just for my own use.  But if those in control of the project think any of these are good ideas, I'd be happy to go to the extra effort to do these changes in a way that can go into the official version (I'll need a bit of guidance on that).

For any of these, I'm asking first for what I misunderstood about the existing UI that makes the change unnecessary (how could I otherwise have avoided the problems I want to fix), and second for suggestions on how/where to make the change, and third for suggestions of a different feature I might add that would solve the same problem in a way other users would prefer:

1) Max resolution.  200% really isn't enough for me to place control points easily.  I don't know what puts me or my photos or my large high res displays outside the usual range, but adding 400% and 800% choices is a trivial code change that will make the program easier for me to use.

2) Losing the magnifier.  It always goes away at 200%, even though it magnifies enough to be helpful at 200% and can be made to usefully magnify even more.  I found/understand the code that removes it for 200%.  It also sometimes gets a timer and goes away by timer.  I found but don't understand that code.  I don't understand the intent of it going away by timer, nor the actual behavior (as a user, I can't predict which actions do or don't make the magnifier go away on a timer).  I'm slow.  I never want a timer taking the magnifier away.  I do want to be able to actively get rid of the magnifier, see item 3.

3) More keyboard control.  I don't have the dexterity to do as much with the mouse in that dialog as I assume others do.  I have a lot of accidents, such as create a point when I intended to move one, then try to delete the new one, randomly deleting a distant one instead, then they renumber (see item 5) and I'm totally lost.  Using the keyboard to move a point, I can never predict nor control which of the two will move (see item 4).  I want keys to control which side is selected.  Code exists that given a user provided position for one side of a control point will try to find the other side.  I don't yet know where that code is, but I want to define a key to activate it (user places or moves a point then presses the key to switch sides, then the key to auto place the corresponding point).

4) Visible indicator of which side is selected.  No clue what it should look like nor how to code it.  Suggestions appreciated, but I'll figure it out myself if necessary.

5) Global stable numbering of points (as an option if this gets shared with others).  I'm sick of losing track as points renumber.  I want a gap left when I delete a point, that may be reused for a new point but won't be reassigned to a different point.  I want the ability to place a control point on more than two images in multi-way overlap.  So I should be able to switch the active list of points for a pair of images from their intersection to their union (and have some visible indicator of left vs. right vs. both) then select a point that is in just one of the two sides and right click selection and/or key to have the software guess where it goes in the other side.  (I have enhancement ideas elsewhere that depend on points identified this way, but even without those enhancements, this would be a convenience feature for me).  Advanced version of this would have the option to use the most recent optimize results to exclude point that are outside the geometry of the other side.

I don't yet have a correct build of hugin either on Windows (mingw64)  or on Linux.  I struggled with both and never got cmake to believe the given location of dependencies either for hugin itself or for dependencies of dependencies when building those.  I got past that in Linux with modest kludging and in Windows with massive kludging.  I'll start a different thread on any of that if help is available.  Current state on both systems:  Most of hugin works including the whole control point dialog and the ability to save the project.  But no way to make it stitch.  On both systems I also have a binary install of hugin in a different place that can stitch (from the project saved from the version I built).  So I can test/use control point changes without correcting build issues.  But I'd like to fix the build issues.

[Gunter Königsmann]

I'm just an user. But I seem to have the same problems with Control Points as you.

[johnfi...@gmail.com]

Thanks for the feedback (nice to know it is not entirely my personal unusual take on UIs).

More details on what problems you have (I assume not identical to mine) might help.  You may give me more ideas on how to make it better for my own use and/or if I manage to fix my build I would be glad to provide a link to a built copy if you want, or if those in charge accept my changes, everyone might have them.  If either of those ways can get a binary to you, I would probably fix anything easy to fix (in that area of the code) that you mention, even if it doesn't matter to me.

So far I'm finding the source code unusually obvious and easy to fix (compared to other open source) while the build process has basically defeated me.  So if I'm fixing anything, fixing more shouldn't be significantly harder.

I would actually use what I can build now:  an improved UI for control points in one build of hugin, with the need to switch to an official build to stitch.  I only tried to build the hugin executable itself, not the other pieces.  I copied the other executables from the official build and the failure (due to whatever build error) is in the hugin executable after the user clicks "stitch" but before hugin tells the external executable to start.

I built in Windows with mingw64 (I hate the anti-optimization of the free version of Visual Studio and go to great lengths to avoid using it).  I built in Ubuntu and installed the official hugin build for ubuntu, both right before switching to Fedora/KDE (on a different drive) for most of my Linux use.  When I have the time, I'll likely redo in Fedora the hugin things I tried in Ubuntu.  So if I solve my build mistakes I might have builds for Windows, Ubuntu and Fedora.  Meanwhile I switch back to Ubuntu for hugin experiments, but generally prefer to use Windows for hugin.

[Bruno Postle]

On Fri, 21 Jan 2022 at 18:34, johnfine2017 wrote:
>
> I want to make a bunch of changes to the control point dialog.

> 1) Max resolution. 200% really isn't enough for me to place control points easily. I don't know what puts me or my photos or my large high res displays outside the usual range, but adding 400% and 800% choices is a trivial code change that will make the program easier for me to use.

This might be useful, though the arrow keys do shift the control
points a tenth of a pixel at a time which is usually accurate enough,
note also that the fine-tune function also moves control-points to
sub-pixel accuracy.

> 2) Losing the magnifier. It always goes away at 200%, even though it magnifies enough to be helpful at 200% and can be made to usefully magnify even more. I found/understand the code that removes it for 200%. It also sometimes gets a timer and goes away by timer. I found but don't understand that code. I don't understand the intent of it going away by timer, nor the actual behavior (as a user, I can't predict which actions do or don't make the magnifier go away on a timer). I'm slow. I never want a timer taking the magnifier away. I do want to be able to actively get rid of the magnifier, see item 3.

I never quite understood what made the magnifier come and go, so
anything you can do to make this more predictable.

Other annoyances with the Control Point tab:

When zoomed-in, if I go to drag a control point that is not in the
centre of the viewport then the view jumps to centre the viewport on
this location - but my mouse is still in the corner of the viewport -
placing the control point in a location nowhere near the original
location. The workaround is to first click on the control point to
centre it before trying to drag it, but this isn't obvious.

When the Hugin Control Points tab was created the most popular
panorama viewer was QuickTimeVR, this has a navigation system where
you click-dragged on the screen and the view panned in this direction
while you kept the mouse button down, so it made some kind of sense to
pan around the Control Points tab in the same way. But these days
every application uses middle-mouse drag to move the image as if you
had grabbed it and placed it in the new position - maybe it is time
Hugin did the same.

The Mask tab can show the location of include masks in other images as
an overlay on the current image. In the Control Points tab it would be
nice to do something similar and show the outline of the right image
on the left image and vice-versa, maybe by greying-out areas of the
images that don't overlap. This would be useful because ultimately the
stitcher places a seam down the middle of this overlap and control
points near the seam are more important for alignment than those at
the edge.

> 3) More keyboard control. I don't have the dexterity to do as much with the mouse in that dialog as I assume others do. I have a lot of accidents, such as create a point when I intended to move one, then try to delete the new one, randomly deleting a distant one instead, then they renumber (see item 5) and I'm totally lost. Using the keyboard to move a point, I can never predict nor control which of the two will move (see item 4). I want keys to control which side is selected. Code exists that given a user provided position for one side of a control point will try to find the other side. I don't yet know where that code is, but I want to define a key to activate it (user places or moves a point then presses the key to switch sides, then the key to auto place the corresponding point).
> 4) Visible indicator of which side is selected. No clue what it should look like nor how to code it. Suggestions appreciated, but I'll figure it out myself if necessary.

This would be useful.

> 5) Global stable numbering of points (as an option if this gets shared with others). I'm sick of losing track as points renumber. I want a gap left when I delete a point, that may be reused for a new point but won't be reassigned to a different point.

This might be difficult given the underlying data structure, but I
don't know for sure.

> I want the ability to place a control point on more than two images in multi-way overlap. So I should be able to switch the active list of points for a pair of images from their intersection to their union (and have some visible indicator of left vs. right vs. both) then select a point that is in just one of the two sides and right click selection and/or key to have the software guess where it goes in the other side. (I have enhancement ideas elsewhere that depend on points identified this way, but even without those enhancements, this would be a convenience feature for me). Advanced version of this would have the option to use the most recent optimize results to exclude point that are outside the geometry of the other side.

I can see how this might be useful, and it could work with the current
control point system. Note that the pano13 library doesn't support
control points that match more than two images (at the moment).

> I don't yet have a correct build of hugin either on Windows (mingw64) or on Linux. I struggled with both and never got cmake to believe the given location of dependencies either for hugin itself or for dependencies of dependencies when building those. I got past that in Linux with modest kludging and in Windows with massive kludging. I'll start a different thread on any of that if help is available. Current state on both systems: Most of hugin works including the whole control point dialog and the ability to save the project. But no way to make it stitch. On both systems I also have a binary install of hugin in a different place that can stitch (from the project saved from the version I built). So I can test/use control point changes without correcting build issues. But I'd like to fix the build issues.

Hugin builds on most Linux systems using standard libraries that are
provided by the distribution, i.e. if you download the right -dev
packages using apt or dnf or whatever, building Hugin is incredibly
simple. What problems are you having (maybe start a new thread)?

--
Bruno

[johnfi...@gmail.com]

On Friday, January 21, 2022 at 7:20:51 PM UTC-5 bruno...@gmail.com wrote:

I never quite understood what made the magnifier come and go, so
anything you can do to make this more predictable.

 

Without a clear statement of the original intent, there is no way I would try to fix the code for removing the magnifier to behave as intended and predictably.

For my own use (and based on what you said, maybe  for others), I would entirely eliminate the existing code for removing the magnifier other than because that control point is no longer selected:  never remove based on a timer, never remove based on the main zoom level.  Then I would select some key and make that hide the magnifiers.

When zoomed-in, if I go to drag a control point that is not in the
centre of the viewport then the view jumps to centre the viewport on
this location - but my mouse is still in the corner of the viewport -
placing the control point in a location nowhere near the original
location.

Thanks for explaining several of my problems.  I should have realized that was what was happening.  But somehow I failed to understand and just thought that sometimes a really random glitch occurred.

That sounds like something harder to fix than I was expecting to tackle soon.  But also it sounds like the most important defect to fix.  I'll take a look at the code.  I assume it will be obvious where/why that happens and entirely not obvious what can be done instead.  But I'll look and think about it.

 

The Mask tab can show the location of include masks in other images as
an overlay on the current image.

 

Sounds like code I'll be interested to look at.

In the Control Points tab it would be
nice to do something similar

 

But likely more than I want to attack.

> 5) Global stable numbering of points (as an option if this gets shared with others). I'm sick of losing track as points renumber. I want a gap left when I delete a point, that may be reused for a new point but won't be reassigned to a different point.

This might be difficult given the underlying data structure, but I
don't know for sure.

Maybe I'll be surprised.  But from what I've seen, it shouldn't be too hard.  I really want that feature, so even if it is difficult.

Note that the pano13 library doesn't support
control points that match more than two images (at the moment).

Thanks for the warning.

That will be a big annoyance.  But would not really defeat my initial intent for this.

Some of my follow-on ideas for control points in 3+ images would need pano13 library support.  I'll worry about that when/if I get closer to it.

Hugin builds on most Linux systems using standard libraries that are
provided by the distribution, i.e. if you download the right -dev
packages using apt or dnf or whatever, building Hugin is incredibly
simple. What problems are you having (maybe start a new thread)?

I didn't take notes as I kludged past issues.  I'd rather be in Fedora than in Ubuntu for this anyway.  So I think my best path on that is to do it over from scratch on Fedora and capture details each time I need to kludge something.  Then I'll put all that in a new thread here.

Some of the Ubuntu issues seemed to imply the dependency packages in Ubuntu were too new for hugin.  That took some minor kludges.  It did not take downgrading any packages (as more serious such issues would).

My son's suggestion (which I might be forced to follow) is to create a VM in order to install whatever package version is easiest for hugin build even when that is too old for other things in the real system.  My Fedora install is several versions more up to date than Ubuntu on several things, so I expect such issues to be bigger.  But I still expect to kludge past any rev-too-new issues rather than downgrade dependencies.

Despite lots of varied software engineering experience, I never used cmake before trying to build hugin.  Likely I'm just using cmake wrong.  But I usually couldn't get it to believe it had found dependencies even when it not only had found them but reported the correct location right before aborting because the result variable of looking was set to "not found".  On Linux I got past that with lots of manual edits to CMakeCache.txt.  On Windows, I never got past that and build hugin.exe from source files without cmake.

Anyway, that is too much build issue sidetrack for this thread.

[Florian Königstein]

The effect of control points for 3+ images can also be simulated by placing several CPs for two images, e.g. one CP that connects image 1 and 2, one that connects image 2 and 3 and possibly one connecting image 1 and 3. Doing so, the optimizer is forced to align the images in the same way as if one CP would connect all three images.

If someone likes to change the code for the control point TAB window, I have another wish: If there are very many images and control points, e.g. hundrets or even 1000 images, it is annoyingly slow if one inserts or deletes just one control point. After such an operation Hugin does some updates. Probably some calculations concerning all images and CPs are done. Some time ago I tried to locate this in the code myself, but I didn't finish it for time reasons.

Maybe this is not what you want, but in my Hugin-clone (Hugin++) I built in a feature so that you can sort the images in the control point list so that the images with a pitch inside an interval and a yaw inside another inverval are listed in a connected block at the beginning of the control points list. So you can click on these images and see the CPs in the CP TAB window.

[T. Modes]

bruno...@gmail.com schrieb am Samstag, 22. Januar 2022 um 01:20:51 UTC+1:

On Fri, 21 Jan 2022 at 18:34, johnfine2017 wrote:
>
> I want to make a bunch of changes to the control point dialog.

> 1) Max resolution. 200% really isn't enough for me to place control points easily. I don't know what puts me or my photos or my large high res displays outside the usual range, but adding 400% and 800% choices is a trivial code change that will make the program easier for me to use.

This might be useful, though the arrow keys do shift the control
points a tenth of a pixel at a time which is usually accurate enough,
note also that the fine-tune function also moves control-points to
sub-pixel accuracy.

This is not so trivial. The current implementation keeps the full scaled image in memory. So a 800 % zoom will require several GB of RAM only for the cp tab. Furthermore I would expect speed issue when drawing such big bitmap.

So this would require a major overhaul to only keep a portion of the zoomed image in memory.

Other annoyances with the Control Point tab:

When zoomed-in, if I go to drag a control point that is not in the
centre of the viewport then the view jumps to centre the viewport on
this location - but my mouse is still in the corner of the viewport -
placing the control point in a location nowhere near the original
location. The workaround is to first click on the control point to
centre it before trying to drag it, but this isn't obvious.

Can you explain it better? How do you select the cp? When selecting the cp in the list the mouse is over the list and not in the corner. Or do I understand something wrong?

When the Hugin Control Points tab was created the most popular
panorama viewer was QuickTimeVR, this has a navigation system where
you click-dragged on the screen and the view panned in this direction
while you kept the mouse button down, so it made some kind of sense to
pan around the Control Points tab in the same way. But these days
every application uses middle-mouse drag to move the image as if you
had grabbed it and placed it in the new position - maybe it is time
Hugin did the same.

Middle-mouse drag work in current version… Or do you mean to invert the direction of the middle-mouse drag?

On Fri, 21 Jan 2022 at 18:34, johnfine2017 wrote:

Likely I'm just using cmake wrong.  But I usually couldn't get it to believe it had found dependencies even when it not only had found them but reported the correct location right before aborting because the result variable of looking was set to "not found".  On Linux I got past that with lots of manual edits to CMakeCache.txt. 

Normally the lines before the error should indicate what was not found and give a hint.

Manually editing the CMakeCache.txt is the worst of all ideas. If you need to fiddle with some setting I would recommend using the CMake GUI and do the edits there.

[Bruno Postle]

On Sat, 22 Jan 2022 at 08:57, T. Modes wrote:
> bruno...@gmail.com schrieb am Samstag, 22. Januar 2022 um 01:20:51 UTC+1:
>>
>> When zoomed-in, if I go to drag a control point that is not in the
>> centre of the viewport then the view jumps to centre the viewport on
>> this location - but my mouse is still in the corner of the viewport -
>> placing the control point in a location nowhere near the original
>> location. The workaround is to first click on the control point to
>> centre it before trying to drag it, but this isn't obvious.
>
> Can you explain it better? How do you select the cp? When selecting the cp in the list the mouse is over the list and not in the corner. Or do I understand something wrong?

You can select a control point by clicking on it in the control point
lists, or by clicking on it directly in a viewport. Selecting a
control point centres it in the viewports.

However if see a control point and want to move it, the obvious way to
do this is to just click and drag it in one go - this only works
properly if the control point I want to drag is *exactly* in the
centre of the viewport, otherwise the viewport jumps to where the
control point was originally, but the mouse position is still
somewhere else.

Basically, the fix is to only centre the current control point in the
viewports on mouseup, currently it centres on mousedown.

>> When the Hugin Control Points tab was created the most popular
>> panorama viewer was QuickTimeVR, this has a navigation system where
>> you click-dragged on the screen and the view panned in this direction
>> while you kept the mouse button down, so it made some kind of sense to
>> pan around the Control Points tab in the same way. But these days
>> every application uses middle-mouse drag to move the image as if you
>> had grabbed it and placed it in the new position - maybe it is time
>> Hugin did the same.
>
> Middle-mouse drag work in current version… Or do you mean to invert the direction of the middle-mouse drag?

Yes, invert it so it works like a touchscreen. If you want to pan
around quickly there are scrollbars.

--
Bruno

[Bruno Postle]

On Sat, 22 Jan 2022 at 01:17, johnfine wrote:
> On Friday, January 21, 2022 at 7:20:51 PM UTC-5 bruno...@gmail.com wrote:
>
> Without a clear statement of the original intent, there is no way I would try to fix the code for removing the magnifier to behave as intended and predictably.

I'm not sure anyone can remember what the original intent of the
magnifier was, all I know is that it disappears just when I want it.

> I didn't take notes as I kludged past issues. I'd rather be in Fedora than in Ubuntu for this anyway. So I think my best path on that is to do it over from scratch on Fedora and capture details each time I need to kludge something. Then I'll put all that in a new thread here.

Hugin builds out of the box on all versions of fedora. First fetch the
build dependencies:

sudo dnf install gcc-c++ libpano13-devel zlib-devel libtiff-devel
libjpeg-devel libpng-devel gettext-devel wxGTK3-devel boost-devel
freeglut-devel cmake desktop-file-utils OpenEXR-devel exiv2-devel
glew-devel python3-devel swig flann-devel perl-Image-ExifTool
mesa-libGLU-devel libXmu-devel sqlite-devel vigra-devel perl-podlators
fftw-devel lcms2-devel

..then in the Hugin source:

mkdir BUILD
cd BUILD
cmake ..
make
sudo make install

This will install it into /usr/local, so (on fedora) you will need to
set LD_LIBRARY_PATH before you run Hugin:

LD_LIBRARY_PATH=/usr/local/lib64 hugin

--
Bruno

[Gunter Königsmann]

On MS Windows cmake only detects wxWidgets if wxWidgets *wasn't* built using cmake. The rest should work fine there, too, minus Windows having no standard paths to store all the libraries in and therefore needing to be told where to find them all.

[T. Modes]

Hi Bruno,

bruno...@gmail.com schrieb am Samstag, 22. Januar 2022 um 10:40:11 UTC+1:

However if see a control point and want to move it, the obvious way to
do this is to just click and drag it in one go - this only works
properly if the control point I want to drag is *exactly* in the
centre of the viewport, otherwise the viewport jumps to where the
control point was originally, but the mouse position is still
somewhere else.

Basically, the fix is to only centre the current control point in the
viewports on mouseup, currently it centres on mousedown.

Okay, now I see. I tested with zoom set to fit. There is was not obviously.

Tried to fix in repository. Hopefully the changes does not affect other things.

>> When the Hugin Control Points tab was created the most popular
>> panorama viewer was QuickTimeVR, this has a navigation system where
>> you click-dragged on the screen and the view panned in this direction
>> while you kept the mouse button down, so it made some kind of sense to
>> pan around the Control Points tab in the same way. But these days
>> every application uses middle-mouse drag to move the image as if you
>> had grabbed it and placed it in the new position - maybe it is time
>> Hugin did the same.
>
> Middle-mouse drag work in current version… Or do you mean to invert the direction of the middle-mouse drag?

Yes, invert it so it works like a touchscreen. If you want to pan
around quickly there are scrollbars.

Also done. Middle drag should now work as in the fast preview windows - like a touchscreen.

Thomas

@Gunther Königsmann: Hugin CMake detects here wxWidgets build with CMake on Windows fine. So it's not a general problem.

[johnfi...@gmail.com]

On Saturday, January 22, 2022 at 3:57:29 AM UTC-5 T. Modes wrote:

This is not so trivial. The current implementation keeps the full scaled image in memory. So a 800 % zoom will require several GB of RAM only for the cp tab. Furthermore I would expect speed issue when drawing such big bitmap.

 

Each of my two home computers (windows and Linux) has 32GB ram and a pretty good 8 core CPU.  So big and slow won't bother me much.

So this would require a major overhaul to only keep a portion of the zoomed image in memory.

I'll look at the code and think about doing that right for others.

 

[johnfi...@gmail.com]

On Saturday, January 22, 2022 at 4:40:11 AM UTC-5 bruno...@gmail.com wrote:

Basically, the fix is to only centre the current control point in the
viewports on mouseup, currently it centres on mousedown.

When you described the problem, I wondered whether the fix might be as easy as changing that action from mouse down to mouse up (I just wasn't confident that was the answer).

It sounds like Thomas is already doing that. 

[johnfi...@gmail.com]

On Saturday, January 22, 2022 at 2:55:12 AM UTC-5 Florian Königstein wrote:

If someone likes to change the code for the control point TAB window, I have another wish: If there are very many images and control points, e.g. hundrets or even 1000 images, it is annoyingly slow if one inserts or deletes just one control point. After such an operation Hugin does some updates. Probably some calculations concerning all images and CPs are done. Some time ago I tried to locate this in the code myself, but I didn't finish it for time reasons.

I'll keep that in mind as I'm looking through that code.  I don't want to over promise things (since I don't yet even know how to give my changes back to the project).  But I do appreciate getting told all the things others think are wrong with this dialog as I start to make changes.

Maybe this is not what you want, but in my Hugin-clone (Hugin++)

I was aware that existed and it did look like a better base for what I want to do.  But I assumed I'd get more answers to my questions if I started with the main line and decided later when/if to switch.

[Bruno Postle]

On Sat, 22 Jan 2022 at 11:46, T. Modes wrote:
>>
>> Basically, the fix is to only centre the current control point in the
>> viewports on mouseup, currently it centres on mousedown.
>
> Okay, now I see. I tested with zoom set to fit. There is was not obviously.
> Tried to fix in repository. Hopefully the changes does not affect other things.

> Also done. Middle drag should now work as in the fast preview windows - like a touchscreen.

Thanks! tested, both these fixes seem to work as expected here.

--
Bruno

[johnfi...@gmail.com]

Don't know if this absolutely needs a new thread.  Similar issues in the mask dialog:

1) the scroll bars go away when not in use (generally nice) but can be hard to get back.  Middle drag would be much simpler for the user.

2) I believe (from behavior, haven't checked code yet) that proximity for selecting a point to move is independent of zoom, so at high zoom you can't select a point without multi selecting other points around it and you can't move a point a short distance (without it snapping back) unless you first move it far away and then move it back.

[johnfi...@gmail.com]

On Saturday, January 22, 2022 at 3:57:29 AM UTC-5 T. Modes wrote:

This is not so trivial. The current implementation keeps the full scaled image in memory. So a 800 % zoom will require several GB of RAM only for the cp tab.

 

In my initial testing of the feature, something fails badly as soon as the rescaled image is larger than 2Gb.

I expect that means some code is using an int instead of correctly std::sizet to store the number of bytes in the image.  I would have been less surprised at misuse of an int for the number of pixels in an image.  But the number of pixels is much smaller.

I'll try tomorrow to find the exact spot in the code that goes wrong.

I'm a bit surprised no one has worked with an image that gets this large even at 200%.  My image needs well over 400% to get over 2Gb, but mine was taken with a cheap phone.

[johnfi...@gmail.com]

I did a bit more code review and testing.  I can't find anything in hugin itself that has that size in bytes in any form for any reason.  hugin just hands off all that work to wx.

I find it near impossible to believe wxImage would have such a bug.  But I can't see how it can be anyplace outside wxImage.

[johnfi...@gmail.com]

I had misunderstood some memory use info, to conclude the images there were using 16 bytes per pixel.  Actually it is only 3 bytes.

The actual measure of the limit past which it fails is 2**27 pixels in the magnified image.  I was incorrect thinking that was 2GB.

So it makes even less sense than when I first looked for it.  I can't see anything either in hugin or in wxImage that should be bothered by having over 2**27 pixels.  But as soon as the magnified image is larger than that, it doesn't get displayed at all (wxImage correctly creates the large image in memory, but it doesn't display).

[Gunter Königsmann]

Do we really have to magnify all of the image if afterwards only a small portion of the magnified image fits on the screen? For me that feels like an use of something similar to wxScrolled: wxScrolled tells you what part of the image to render, you render that part and the rest happens by some magic the operating system offers.

Unfortunately wxScroleld itself chokes on too big virtual areas to scroll in as GTK3 does do so when volunteering the magic that on scrolling moves all parts of the displayed area that can be re-used after scrolling, then requests the areas that aren't cached, currently (only the pixels that are visible on the screen are cached). Afterwards that magic copies the resulting bitmap to the screen; if the wxScrolled is only updated when wxWidgets issues an idle event that feels both speedy and allows real work to be done in the background.

[johnfi...@gmail.com]

On Sunday, January 23, 2022 at 8:36:58 AM UTC-5 gunter.ko...@gmail.com wrote:

Do we really have to magnify all of the image if afterwards only a small portion of the magnified image fits on the screen? For me that feels like an use of something similar to wxScrolled: wxScrolled tells you what part of the image to render, you render that part and the rest happens by some magic the operating system offers.

Unfortunately wxScroleld itself chokes on too big virtual areas to scroll in as GTK3 does do so when volunteering the magic that on scrolling moves all parts of the displayed area that can be re-used after scrolling, then requests the areas that aren't cached, currently (only the pixels that are visible on the screen are cached). Afterwards that magic copies the resulting bitmap to the screen; if the wxScrolled is only updated when wxWidgets issues an idle event that feels both speedy and allows real work to be done in the background.

If I were working on wxWidgets, rather than working on Hugin, I would certainly focus on the things you suggested.

Inside wxWidgets, there are lots of places where it would be easy to only record what needs to be done for magnifying and clipping, rather than actually do it, then the next time data from the magnified and subsequently clipped image gets copied (such as by GTK) produce that data on demand.

I tried to figure out ways to derive from wxImage (rather than simply use it) in order to add those features (that I think it should have had).  But so far as I understand, the interactions with GTK etc. aren't coded in a way that would permit that.

For the moment, I'm setting that whole issue aside and working on some easier things, (the things I originally intended to talk about in this thread).

[Greg 'groggy' Lehey]

I've been chasing up a mail configuration problem delivering mail to
Gmail (hint: make sure you have an SPF record or similar), and in the
process came across this message and about 30 more that were filed as
spam:

On Friday, 21 January 2022 at 10:34:06 -0800, johnfi...@gmail.com wrote:
> I want to make a bunch of changes to the control point dialog.

(end quote)

I don't understand why; there's nothing obviously wrong with the
message, and unlike the problems that Gmail caused for my third-party
domain, both sender and mailing list are under the control of Google.
There were two other threads, also sent by people with Gmail accounts,
so maybe this is part of the problem.

It seems that Google is going over the top in trying to control spam,
and in the process it is rejecting valid mail. I'm seriously
considering giving up my Gmail account. If you have a Gmail account,
you should at least check the spam folder daily to see what surprises
Gmail has in store for you.

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.php

[Robert Krawitz]

On 2/6/22 20:09, Greg 'groggy' Lehey wrote:
> It seems that Google is going over the top in trying to control spam,
> and in the process it is rejecting valid mail. I'm seriously
> considering giving up my Gmail account. If you have a Gmail account,
> you should at least check the spam folder daily to see what surprises
> Gmail has in store for you.

A lot of email services are doing this. My alma mater uses Outlook Online, and about half of my
spam folder was real email (and conversely, a lot of junk email made it through). I finally fixed
this by using fetchmail to inject mail into my own mail server.

A couple of important email messages I sent have also gotten lost. Junk email is a problem, but the
cure (server-side junk filters that cannot be turned off) is worse than the disease.

[Gunter Königsmann]

It is an endless battle: The ones that write spam try to evade the spam filters. The ones that write spam filters adapt their filters for that which causes the ones that write spam to adapt their spam to the filters...
...And there are many things that look like spam and aren't: Mailing lists, for example, send the same mail to many users. These mails might be sent from the same server as real spam (a spam Sender might want this to happen). They might send mails to mail accounts that no longer exist (which is another red flag for spam) and they might occasionally mention things like blue, pills and money.

In the end the best a mail provider can do is to try to find a spot in which the spam filter Filters out about as many legit mails as it lets through spam ones. Or to not Filter anything out that might be even remotely legit.

[Klaus Foehl]

Hi Greg, dear all,

with my gmail account I find 1) at first glance entire threads go into
Spam 2) I find one or two examples where a reply makes it into the Inbox
3) all this starts on 16.01.2022 with a posting of Noveguy.

Also between 09.01.2022 and 16.01.2022 I did not receive any hugin-ptx
email. To me 9 days of list quietness look weird.

Regards Klaus