How to deal with the image cache: key off of something... about stginga HOT 7 CLOSED

If you set numImages=0 either in ~/.ginga/general.cfg or ~/.ginga/channel_Image.cfg, it sets unlimited cache (then you have to watch your memory usage). I use this setting for QUIP.

The setting in channel_Image.cfg overwrites the setting in general.cfg, if exists. Or inherits from the latter, if not.

from stginga.

The actual cache is handled by Datasrc class.

from stginga.

As @pllim says, the deque length for a channel can be set to unlimited by setting the numImages preference to 0.

In regard to naming images, though, it is possible to have total control over the name of the image if you are creating the AstroImage object yourself (in the typical case the reference viewer creates it for you) and specify the name kwarg. Then this name will be used everywhere in the viewer. One thing we do at Subaru Telescope is to override the file opening and do it with a custom opener. Our opener does some parsing on the name to decide which channel the image should end up in, etc. Something like this may be an option for stginga.

One thing to keep in mind--an image can be loaded into more than one channel (unless you control how it is loaded--e.g. someone can just drag a file to a channel). So you may end up with the same name in more than one channel. The Thumbs will show a duplicate name, but if you click each one it will take you to the image in the channel in which it resides. If this kind of behavior is not wanted, then it might be better to write your own opener as described above, because then you can control which images end up in which channels.

from stginga.

For this plugin, I am aiming to not having need of any global environmental changes to occur. And, ideally, this should be invariant against whether cache is on/off, etc. Also, there should be no dependency on loaders either.

I'm currently examining the Thumbs* classes to get some clues. It is looking like path is the answer.

from stginga.

If you think the plugin might be generally useful, consider submitting a PR to the ginga home repo when you have it at a reasonable state. It looks very interesting!

from stginga.

Most definitely! Once we get things good for the sprint, will be doing so.

from stginga.

PR #22

from stginga.