Discussion:
[KPhotoAlbum] Zooming issue
Angel Lopez
2018-10-14 09:21:03 UTC
Permalink
Hello,

I'm experiencing an strange behavior in kphotoalbum.

When viewing photographs, either if I draw a rectangle for zooming a
region, or if I just press "+" key, The display goes to the upper left
corner and with higher zoom level.
I from there if press "-" then it increases the zoom level even more.

I'm using the "last" git version, but I've seen this on previous ones too.
For me, this should be a bug, but as nobody has talked about it, probably
this is just a problem with my configuration. I tried deleting:
~/.config/kphotoalbumrc
but after a new start of kphotoalbum, the problem persists.

Any idea?

Thanks.
Angel.

______________________________
----------- Angel ------------
Johannes Zarl-Zierl
2018-10-14 19:31:02 UTC
Permalink
Hello Angel,
Post by Angel Lopez
When viewing photographs, either if I draw a rectangle for zooming a
region, or if I just press "+" key, The display goes to the upper left
corner and with higher zoom level.
I from there if press "-" then it increases the zoom level even more.
That sounds strange, indeed. Unfortunately, I can not reproduce it here.

Is your setup "special" in any way (e.g. high DPI, custom screen setup etc.)?

Cheers,
Johannes
Johannes Zarl-Zierl
2018-10-16 20:42:41 UTC
Permalink
Hi Angel,
in function: void Viewer::ImageDisplay::zoom( QPoint p1, QPoint p2 )
if I comment out : potentialyLoadFullSize(), then it works as expected (not
exactly because the first time I draw a rectangle no zoom if performed).
It seems that a call to potentialyLoadFullSize() is already made in the
resizeEvent() function.
That is kind of surprising, because the potentiallyLoadFullsize() does not
(directly) manipulate the view position or zoom level. I'm suspecting that it
interacts with cropAndScale() and causes that function to misbehave…

Can you try and see what happens if you switch the position of the
potentialyLoadFullSize() call with the call to cropAndScale(), i.e. what
happens if cropAndScale is done *before* potentiallyLoadFullSize?


Cheers,
Johannes
Johannes Zarl-Zierl
2018-10-19 15:11:17 UTC
Permalink
Hello Angel,

Sorry for not getting back to you sooner!

I have some further questions for you:
You've written that you saw the problem for some time now. Do you know when it
started initially?

I assume that fullscreen vs. windowed viewer does not make a difference…

Do you have the same problem with all images, or is it dependent on the image
size? Do you see the same problem with the demo image set?

Cheers,
Johannes
I did the suggested modification but it makes no effect. Indeed, the
function "zoomPixelForPixel", had it already reversed. So commenting
"potentialyLoadFullSize" in the zoom() function, solves the problem for
mouse zoom and "+" and "-" keyboard zooming, but pressing "=" for zoom
pixel for pixel, still goes wrong (as potentialyLoadFullSize was not
commented inside it).
So, with a call to potentialyLoadFullSize commented inside zoom, behavior
is as expected and very fast zooming.
With that call not commented, but "m_reloadImageInProgress = false" inside
the function "potentialyLoadFullSize" (original value was true) Then after
zooming it goes back to original. But it takes some time (like one second
in my computer)
As additional information, I'm working on an old laptop with screen
resolution 1366x768.
If you want I can do all the test you want.
Thank you again !!
Regards,
Angel.
______________________________
----------- Angel ------------
El mar., 16 oct. 2018 a las 22:42, Johannes Zarl-Zierl (<
Post by Johannes Zarl-Zierl
Hi Angel,
in function: void Viewer::ImageDisplay::zoom( QPoint p1, QPoint p2 )
if I comment out : potentialyLoadFullSize(), then it works as expected
(not
exactly because the first time I draw a rectangle no zoom if performed).
It seems that a call to potentialyLoadFullSize() is already made in the
resizeEvent() function.
That is kind of surprising, because the potentiallyLoadFullsize() does not
(directly) manipulate the view position or zoom level. I'm suspecting that it
interacts with cropAndScale() and causes that function to misbehave…
Can you try and see what happens if you switch the position of the
potentialyLoadFullSize() call with the call to cropAndScale(), i.e. what
happens if cropAndScale is done *before* potentiallyLoadFullSize?
Cheers,
Johannes
Johannes Zarl-Zierl
2018-10-19 16:34:40 UTC
Permalink
Hello Angel,

I've added some debug code to ImageDisplay in git master. Could you please
build the newest version and then run the following in a console window?

export QT_LOGGING_RULES='kphotoalbum.Viewer=true'
kphotoalbum --demo

The result should look something like the attached example. Can you please do
some zooming that exhibits the bug and send me the output?

Thanks in advance,
Johannes
Post by Johannes Zarl-Zierl
Hello Angel,
Sorry for not getting back to you sooner!
You've written that you saw the problem for some time now. Do you know when
it started initially?
I assume that fullscreen vs. windowed viewer does not make a difference

Do you have the same problem with all images, or is it dependent on the
image size? Do you see the same problem with the demo image set?
Cheers,
Johannes
I did the suggested modification but it makes no effect. Indeed, the
function "zoomPixelForPixel", had it already reversed. So commenting
"potentialyLoadFullSize" in the zoom() function, solves the problem for
mouse zoom and "+" and "-" keyboard zooming, but pressing "=" for zoom
pixel for pixel, still goes wrong (as potentialyLoadFullSize was not
commented inside it).
So, with a call to potentialyLoadFullSize commented inside zoom, behavior
is as expected and very fast zooming.
With that call not commented, but "m_reloadImageInProgress = false" inside
the function "potentialyLoadFullSize" (original value was true) Then after
zooming it goes back to original. But it takes some time (like one second
in my computer)
As additional information, I'm working on an old laptop with screen
resolution 1366x768.
If you want I can do all the test you want.
Thank you again !!
Regards,
Angel.
______________________________
----------- Angel ------------
El mar., 16 oct. 2018 a las 22:42, Johannes Zarl-Zierl (<
Post by Johannes Zarl-Zierl
Hi Angel,
in function: void Viewer::ImageDisplay::zoom( QPoint p1, QPoint p2 )
if I comment out : potentialyLoadFullSize(), then it works as expected
(not
exactly because the first time I draw a rectangle no zoom if performed).
It seems that a call to potentialyLoadFullSize() is already made in the
resizeEvent() function.
That is kind of surprising, because the potentiallyLoadFullsize() does not
(directly) manipulate the view position or zoom level. I'm suspecting
that
it
interacts with cropAndScale() and causes that function to misbehave

Can you try and see what happens if you switch the position of the
potentialyLoadFullSize() call with the call to cropAndScale(), i.e. what
happens if cropAndScale is done *before* potentiallyLoadFullSize?
Cheers,
Johannes
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum
Johannes Zarl-Zierl
2018-10-20 18:12:04 UTC
Permalink
Hello Angel,
Finally I made a new folder and added only to files: One raw .CR2 file from
my camera and the extracted thumbnail (using exiv2 -ep3). Started
kphotoalbum in that folder and discovered that zoom works fine on the JPG
but not in the CR2.
Using the detailed information that you gave me I could finally reproduce the
bug myself and subsequently fix it. The latest version in git master should
now zoom correctly even for raw images.

Thanks for your help in fixing this bug!

Cheers,
Johannes

Loading...