I’m facing some weird behavior for TImage (ROOT 6.04.02, OpenSUSE 13.1 x64) after having zoomed the image for the first time. Whenever I left-click into the image after a zoom, it appears to be automatically zoomed to the 1x1 pixel area of the clicked pixel (judging by the displayed color). The behavior does not show after using the Zoom function with number entries from the drop-down menu, so I assume it’s got something to do with ExecuteEvent.
Can someone please try to reproduce this behavior?
[ul]
[li]Left-click - all is well[/li]
[li]Zoom some area by left-click/mouse move[/li]
[li]Left-click again into the image - it will be zoomed to and colored with the color of the clicked pixel[/li]
[li]Repeat by unzooming and left-clicking as often as you want[/li][/ul]
I tried on my mac with 6.05/01
I can zoom as much as I want.
Then if I click with the left button I see one pixel zoom…
Then can un-zoom to retrieve the full picture…
Bummer, then it appears I’ll have to overwrite it. I work with a lot of draw objects that will zoom along with the TImage so that I can place them precisely over areas of interest in the image. When you try to grab a draw object with a left-click and just miss it by one pixel, the 1x1 zoom makes the placement somewhat tedious, because you have to unzoom the whole image, then zoom to the area of interest again, then try grabbing the draw object again hoping you don’t miss this time. Didn’t remember this behavior from earlier ROOT versions, thanks for the feedback…
This can be change of course… what would you except … ?
I see nothing wrong with the current behaviour but we you can come with a better one for good reason we may take it. May be you can even prototype it yourself in TImage ?
That sounds great. The attached picture should give you an idea and some reasons why I think the 1x1 pixel zoom is unhelpful. I also can’t imagine why anyone would want to default-zoom into just one pixel in the first place, but that might just be my lack of imagination…
If you have a lot of draw objects like in the picture and do a lot of manual placement by mouse and so on, it can happen a lot that you left-click into the image. If you accidentially zoom to 1 pixel all the time and have to unzoom all the time… well, some people are more patient than others.
However, have a look at the freehand polygon in the lower left. Until now, I was creating freehand regions from a series of left-clicks into the image which is now impossible with the involuntary zoom. I can probably come up with something else, but all other mouse button events also cause conflicts with ExecuteEvent, so I’d rather leave it with the left-click.
Maybe reason 1 is more important, you’d do a great favor to people who click a lot into images during their office hours!
Here’s why I think it’s a bug. TASImage::ExecuteEvent has a catch for too small zoom areas (below 5x5) which is not working for some reason:
case kButton1Up:
// do nothing if zoom area is too small
if ( TMath::Abs(pxl - pxt) < 5 || TMath::Abs(pyl - pyt) < 5)
return;
When overwriting the function in my child class of TASImage in order to to some debugging I’m getting into trouble with “struct ASImage”, however, whose members cannot be resolved. Is there an easy way around that or do I have to change TASImage.cxx itself and recompile ROOT?
Ok, I got it working by copying the libAfterImage header files from the build tree to $ROOTSYS/include, including them in my cxx file and using “fScaledImage->GetImage()” instead of “fScaledImage->fImage” as fImage is protected.
Turns out that the variables pxl, pxt, pyl, and pyt are not reset on event kButton1Up, so the next event still thinks the zoom box is greater than 5x5 which is not true. Simply resetting the 4 (no longer needed) variables does the trick:
case kButton1Up:
// do nothing if zoom area is too small
if ( TMath::Abs(pxl - pxt) < 5 || TMath::Abs(pyl - pyt) < 5)
return;
pxl = 0;
pxt = 0;
pyl = 0;
pyt = 0;
...
One last question: I’ve noticed that in ExecuteEvent function “gVirtualX->DrawBox()” from ROOT5 was replaced by drawing a TBox in ROOT6. Is there an important reason for that and I change that as well in the rest of my code or was it just a whim of the author?
