Hi,
If I choose a large section of the 4th most recent image using an ADDE request in the McIDAS-V data chooser, the only option I have is to load 4 large images, using more memory than I need. Could there be a way to develop the chooser so that I can select only POS=-4 in the ADDE call and load only that into the field selector?
I know that I can select all the images and load them into the field selector and then only display the 4th most recent image, but is this the most efficient way to work?
Thanks,
Joleen
Loading Images using relative times
Re: Loading Images using relative times
Hi Joleen,
Like you say, right now the only way is to select the 4 most recent images from the Data Sources tab, then in the field selector go to the Times tab deselect use default and choose the image you'd like. Are you requesting that this functionality be moved to the Data Sources tab?
Rick
Like you say, right now the only way is to select the 4 most recent images from the Data Sources tab, then in the field selector go to the Times tab deselect use default and choose the image you'd like. Are you requesting that this functionality be moved to the Data Sources tab?
Rick
Re: Loading Images using relative times
Rick,
It does seem to be a buried feature at the moment. In many programs, I would select a group a times with the shift+left click method or just make a single selection. However, that may not be possible in the way the data must be requested from the ADDE server. The reason I needed only the POS=-1 and not the POS=0 was small. I only wanted an image that was guaranteed to be on the server for the purposes of a script which loaded the bundle. In addition, I may have confused myself. When the data is selected in the Data Sources and added to the field selected, does it just queue the data? Is the data actually loaded when the display is created and that is when memory for large amounts of data becomes an issue?
Joleen
It does seem to be a buried feature at the moment. In many programs, I would select a group a times with the shift+left click method or just make a single selection. However, that may not be possible in the way the data must be requested from the ADDE server. The reason I needed only the POS=-1 and not the POS=0 was small. I only wanted an image that was guaranteed to be on the server for the purposes of a script which loaded the bundle. In addition, I may have confused myself. When the data is selected in the Data Sources and added to the field selected, does it just queue the data? Is the data actually loaded when the display is created and that is when memory for large amounts of data becomes an issue?
Joleen
Re: Loading Images using relative times
I'll write a request to see if we can make the time selection more prominent with one possibility of moving that capability to the data sources tab. Once and ADDE server is updated to McIDAS-X version 2010.1, it will no longer track (process as the image is being ingested). That means, only the data on the currently resides on the server will be sent to McIDAS-V to be processed. In the case of background processing, this may not be desirable and you may want to wait until the image finishes the ingest (let me know if you agree). McIDAS-V dynamically allocates, so you will only use as much memory as needed. Let me know if that helps.
Rick
Rick
Re: Loading Images using relative times
Rick,
In some cases, I will want the entire image before I would start background processing. At the same time there are a number of scripts initiated when an area is scanning and continues immediately after a small subset of the sector completes scanning. This would be the case for the convective initiation algorithm where time latency is important. They currently would run the algorithm after completion of
imgcopy.k EASTL/CONUS LATLON=32 100.5 SIZE=250 250 BAND=ALL
During full disk scans, the time difference between waiting until the entire image scans versus the tiny subset is very large. The fire algorithm will also process as soon as the data is available.
Joleen
In some cases, I will want the entire image before I would start background processing. At the same time there are a number of scripts initiated when an area is scanning and continues immediately after a small subset of the sector completes scanning. This would be the case for the convective initiation algorithm where time latency is important. They currently would run the algorithm after completion of
imgcopy.k EASTL/CONUS LATLON=32 100.5 SIZE=250 250 BAND=ALL
During full disk scans, the time difference between waiting until the entire image scans versus the tiny subset is very large. The fire algorithm will also process as soon as the data is available.
Joleen