Behavior of colormap cuts and zoom different when using arrows or thumbs to select

[hcferguson]

This is easiest to describe via the movie attached to the the Trello card at https://trello.com/c/flKiUXGV/17-strange-behavior-when-setting-colormap-cuts-and-zoom. The log file is there as well.

The movie shows several issues. I was trying to set the colormap cuts differently on two different images. I only partially succeeded in that -- it depended on whether I stepped through the images using the thumbs or the arrow. Also changed the zoom on one of the images and the behavior was different depending on whether I used the thumbs or the arrows.

[ejeschke]

@hcferguson, can you give me access to the Trello? Tnx.

[pllim]

I think the resetting of pan/scale in 1:54 is due to this:

2015-10-21 14:59:06,610 | I | Control.py:570 (load_image) | Loading image from gs_all_candels_ers_udf_f160w_060mas_v0.5_drz.fits kwdargs={'numhdu': None}
2015-10-21 14:59:10,426 | I | Control.py:930 (switch_name) | Image 'gs_all_candels_ers_udf_f160w_060mas_v0.5_drz[0]' is no longer in memory; attempting reloader

If I am correct, maybe this can be fixed by attaching the current pan/scale/cuts to Datasrc, so the settings remain even when image is reloaded from file.

Also, I cannot see what the numImages is set to in the video. I think it is hidden inside the "General" section that was not expanded for viewing. It is unusual for Ginga to reload from file when only two images are displayed. So either numImages is set to a very small number, or Ginga does not have sufficient memory to handle the images.

As for the extra hidden image at 2:20, I think it is fixed by #176. I had problem with Ginga treating image.fits[None] and image.fits[SCI,1] as separate buffers although they are the same extension.

[ejeschke]

Currently, I think the default number of images stored per channel is 10. After that they start getting pushed out, and as @pllim points out, have to be reloaded. I think it would be a fairly easy modification to save some of the last settings and apply them again. The reason this is not done currently is because the AstroImage wrapper is dereferenced and that is where those items are stored. I have periodically considered an idea to keep the AstroImage object, but just dereference the data and header (which can be large).

As a workaround, you can set the limit to 0 (numImages preference) and save that in your settings, which means that no images will ever be pushed out. You then have to watch your memory usage more carefully and remove them manually as needed.

[ejeschke]

@hcferguson, I joined the Trello invitation you sent, but when I click on the link you posted here, I get: "Card not found. This card may be on a private board. If someone gave you this link, they may need to invite you to one of their boards or teams."

I am able to browse manually to "Data Analysis Tools" and a bunch of sub-boards, but I couldn't figure out how to get to this card.

[hcferguson]

@ejeschke the Trello problem should be fixed. I added you as a member to the board. Let me know if it's still a problem.

[ejeschke]

Thanks, I am able to view the video--very helpful to understand what you are doing!

I think the basic problem here is that by using the "Remember" functions you are asking ginga to save the scale and the cut levels for each image. When you bring each image back into the window it will ignore the current cuts and scale and instead use the ones stored with the image. This overrides any current manual setting of cuts or automatic calculations of same.

It sounds like for your way of working you should unset any of the "Remember" preferences (a good idea in general, I think, and the way I like to work). Then the "Cut New" and "Zoom New" preferences will take effect when you bring an image back. When an image is brought into the viewer (and no "remember" setting is in effect) the cuts will be set as follows, depending on the "Cut New" setting: off: use the current cut levels once: automatic cut levels is applied (based on your algorithm preferences) and then the cut new setting is turned to "off" override: automatic cut levels is applied (based on your algorithm preferences). The setting stays at "override". If you should attempt to adjust cuts manually the "Cut New" control will be turned to "off" on: automatic cut levels is applied

If you like to have ginga automatically adjust cuts until you override it, then the "override" setting is the one you want. After a manual override the setting turns to "off" and it will respect the current cuts from then on. There is a handy keyboard shortcut to set the setting back to "override" (semicolon), if you decide that you want to go back to having ginga automatically calculate the cuts.

[ejeschke]

I think that the issue with the "third" image is due to an issue regarding naming that is currently being resolved (issue #175 and PR #176).

[ejeschke]

Another way that a lot of our scientists like to use ginga cut levels is to just set the setting to "off". You can then always get an automatically calculated levels by pressing the "Auto Levels" button or using the "a" keyboard shortcut.

[ejeschke]

@hcferguson, did this information help to make sense of what you are seeing? I think the fix for the third image that didn't show up in Thumbs is now committed, so I would be interested to hear an update on this issue.