dials.image_viewer: image should be shown in image frame

[graeme-winter]

#1182 introduced a "bug / feature" that single panel images are now shown at a jaunty angle if they have been refined, which is probably not what we want in an image viewer.

In fact, to me it would seem canonical that an image viewer shows the image in the image coordinate frame not the laboratory frame. As an example:

It is also known that the shoeboxes are not plotted in this rotated frame - #1189 - and I really see no benefit in what is shown here for a single panel. dials.show is a much better way of showing that the detector is misaligned and gives actual data not just some dodgy image which confuses users:

Detector:
Panel:
  name: /entry/instrument/detector
  type: SENSOR_PAD
  identifier: 
  pixel_size:{0.075,0.075}
  image_size: {4148,4362}
  trusted_range: {-1,53338}
  thickness: 0.45
  material: Si
  mu: 1.41469
  gain: 1
  pedestal: 0
  fast_axis: {0.999977,0.00662009,-0.00137573}
  slow_axis: {0.00661354,-0.999967,-0.00471405}
  origin: {-156.829,166.876,-138.646}
  distance: 139.65
  pixel to millimeter strategy: ParallaxCorrectedPxMmStrategy
    mu: 1.41469
    t0: 0.45

I've previously stated "I’m just asking to be able to have the original behaviour, not to remove the opportunity to see your detector slightly misaligned"

We could have a vote on this 🙂 - if you agree that the default should be image frame => 👍 i.e. revert to previous behaviour. If you feel that it should be shown in some lab-frame-like system then 👎 would capture this nicely.

[phyy-nx]

I still disagree about this. I think it's better to educate users and to fix #1189 than to not have the image viewer display reality.

Also, misalignment is one thing, but we have in the past added 90 degree rotations to the experiment model to fix image headers and ensure polarization correction is applied correctly. We depend on the image viewer representing this properly so the display matches what we expect.

[graeme-winter]

I’m pretty convinced here that our users are right, but I’ll tot up the votes in a few days and let democracy do its work

[graeme-winter]

🤔 @phyy-nx slightly confused here actually - for your use case, for a single panel, you should never see a rotation as the rotation would be w.r.t. the goniometer axis which is not a thing for still shots.

For rotation data we want to have the detector slightly misaligned as it improves the data quality (since 180° rotation puts the spot "somewhere different") so we don't want to punish beamlines and users for this. So from what I can tell it only affects rotation data, and those are the same folk asking to not have this. If it does affect still shots, then I guess that is a bug. But the image viewer is not there for bug finding.

[alyubimov]

Gonna throw my own rock into this lake: I'm a visual guy and like visual information over numbers, especially when the information I seek is qualitative. That said, the jaunty angle is weird, confusing, and not informative. There's zero meaning attached to it aside from "uh, so the, ah, orientation of something was off, I guess?" And more crucially, no idea what one should do - if anything - when encountering this. "Educating users" would, presumably, involve tutorials buried in some wiki or somesuch? Or presentations at the ACA attended by a half-dozen grad students who won't remember any of it after the party that night? If so, I'm a believer in the interface being as self-explanatory as possible. There's a Russian proverb that applies here: if you call yourself a mushroom, then climb into the basket. In other words: if we're going to put our foot into the "visual information" thing, that visual information should be *informative* without any additional education necessary. If we're going to educate users, might as well educate them to use the much more informative output from dials.show. If we're going to just show 'em a picture, let's show 'em a picture they can intuitively understand. So my vote is in two parts. On the UI element as stands: 👍. As in: revert, because the weird angle thing sucks. However, if we truly want to do a visual thing, let's have: *primus,* explicit toggle in the image viewer, *secundus*, some labeled axes or somesuch, at the very minimal, so that the users know what the F we're showing them. So the above were my two cents; hope that helps our fledgling Republic, if we can keep it. Cheers, Art

…

On Mon, Jul 27, 2020 at 11:22 AM Graeme Winter ***@***.***> wrote: I’m pretty convinced here that our users are right, but I’ll tot up the votes in a few days and let democracy do its work — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/dials/dials/issues/1358#issuecomment-664560378>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADU6QONB3H6PWP4NNUL453TR5XAUPANCNFSM4PIZ4EUQ> .

-- Artem Y. Lyubimov, PhD Staff Scientist SSRL SMB Crystallography 2525 Sand Hill Road mail stop 99 Menlo Park, CA 94025-7015 (415) 325-2057

[graeme-winter]

Also I’m totally fine as I mentioned before on bulk multiples of 90 degree rotations, it’s the jaunty angles which get me

[dagewa]

I appreciate the work that went into #1182 (special cases are bad), but I do feel that the consequence of slightly misaligned images for the standard MX use case is a big negative, which I didn't pick up on at the time. I would be happy with a "snap to orthogonal" option as @phyy-nx mentioned in the support mailing list, but I think it should be the default.

[phyy-nx]

I'd be ok with a snap to orthogonal checkbox, that was only visible for single panel detectors, was checked by default, and respected bulk 90 degree rotations by using rounding.

[graeme-winter]

I'd be ok with a snap to orthogonal checkbox, that was only visible for single panel detectors, was checked by default, and respected bulk 90 degree rotations by using rounding.

On the face of it, this would be explicitly counter to the goals of #1182 namely getting rid of special cases for single panels?

Is there a reason not to allow "snap to grid" for multi-panel detectors?

[phyy-nx]

For some multipanel detectors, the gaps between panels are orthogonal and exactly a known integer of pixels wide. For others, none of the panels line up with each other. I don't know how the image viewer would know the difference, and in the latter case, there is no grid to snap to.

[graeme-winter]

OK, fair - however we have such instruments -

• detector on i23 made of 120 p2 modules which is treated as 24 separate panels
• flat pilatus / eiger than can be treated as multiple modules separately
• timepix detectors being built at the moment

For these we would like to have the ability to show the image as recorded with the overlays in the right place - so I'm not convinced that the option must be hidden as you request.

[dagewa]

I believe snapping to the fast, slow of the panel closest to the beam centre would be a reasonable approach for multi-panel detectors

[phyy-nx]

That would be ok.

[graeme-winter]

I believe snapping to the fast, slow of the panel closest to the beam centre would be a reasonable approach for multi-panel detectors

I think that ... depends (discussion topic) -

Eiger 16M is 32 panels - it may be nice to be able to see them on the "regular grid" which one would assume if treated as a single panel, or the per-panel local frame if your interest is looking at e.g. powder rings. Simply aligning one module then having all others at a jaunty angle would not necessarily do what we want / expect here (on principle of minimising user surprise)

Since the overlays are done in a coordinate system local way (i.e. per-panel) this would mean that snapping all panels to a grid (optionally) would give a clean representation of the image, even if it is less "true" [1]

On the topic of truth: all of this presupposes that all panels are coplanar right, so as soon as they are not coplanar then any idea about showing them in the "correct way" goes out of the window unless you enter some 3D representation.

The necessary "secret sauce" for this would be for the detector model to have the information on how to define a regular grid to snap all panels / images to - which is not a new idea viz:

cctbx/dxtbx#167
cctbx/dxtbx#17

However @phyy-nx the presence or absence of this secret information could be sufficient to hide / show the snap to grid option and set the default: no information on how to snap? Then don't show -> job done.

[1] motivation - if we process a 16M Eiger data set then one may hope that the results of processing as single panel are easily compared with results of processing as 32 panels -> there is a justification here.

[dagewa]

Interesting. It seems like much of the work here could be done by an alignment of the Formats detector model (i.e. the model you get from a plain import before geometry modification) onto a coplanar grid. That is, this could be achieved in most cases with a new method that doesn't require new data in the Format. Special cases like I23 would have to override this.

[dagewa]

For example, most Formats set the panels somewhere in the X-Y plane with distance along Z. For all those formats a 2D representation on a pixel grid can easily be obtained by taking the origin vector for each panel, dropping the Z component and then dividing through by the pixel size