McIDAS-V Support Forums

Hi HP -

Thanks for the information. Looking at your image, it seems like you are creating a RGB display. I've done a lot of my testing thus far with your sequence_FD function from earlier, which loads in and displays just a single band of data. If you are displaying your data through a script or a function, can you please send it to us? This might help us replicate the issue you are now seeing.

Thanks -
Bob

Hi Bob -

The good news is that the distorted projection stems from an obvioulsy bad Viewpoint (no clue what is wrong there). Other saved Viewpoints just work as expected. Thus, correct time series are saved now. The bad news is however, there are still a couple of blank images (the matte is there though) in half a day worth of rather large Dust RGB composites (48 frames). I have 16GB of RAM, McV indicates that it is using about half of it.

Find attached the script for generating the RGBs (add the accounting information). The script call goes like:

The sequence is then saved with my script like:

Note from the call that the data are saved to 800x600 frames using the Viewpoint 'SaAt'. You may create a similar viewpoint, trying to ~reproduce the image below, in Mercator projection).

cheers, HP

Thank you for the script, HP. I'm glad that the odd projection/viewpoint issue has been resolved. I'll let our programmer know that you are still seeing blank images (with the exception of the matte being there). I'll keep you updated on any progress with this issue.

Thanks again -
Bob

Hi HP -

Our programmer put in another code change. I've tested out using your most recent script on Windows 7 with switch values of 0, 1, and 2 and I'm not seeing any issues on my end using Windows 7. If you get a chance, can you give a new 1.5beta2 nightly build a try and let us know your results?

Thanks -
Bob

Hi Bob -

Excellent. Same result by me. And it appears not to need any explicit delay code in the script.

Just one question. What about the writeImageAtIndex() module that goes with my script - still no code in the libraries that would replace it?

cheers, HP

Hi HP,

First of all: thank you for being so patient while we attempted to get this sorted out.

I'm glad you noticed that the delays could be removed. Some of my other changes introduced other delays that we may also now be able to remove…and I'd be very happy if we could cease having to suggest using "pause()". But that stuff will require more testing.


Also, writeImageAtIndex is included in McV's Jython library (~line 2935 of the "Background Processing Functions").

Jon

Hi Jon -

Also many thanks from my side to all that have been involved in recent months! To be precise, I have been running the tests even without pause(), e.g. 100 RGBs of 1000x1000 pixels.

In addition, I have also successfully removed the writeAtIndex() code.

I am happy, HP

Good people -

Using my 'saving script' routinely, there are two things that annoy me a little bit.
1. Saving in this way in the background is much more time consuming than saving through View > Capture > Movie. Is there any possibility to accelerate the job? Remember that I am saving from a 'full-screen' display window.
2. Would it be possible to have no popping up of the 'full-screen' display durign the saving process?

cheers, HP

Hi HP -

We noticed the slowness of the image captures with your script, and wrote up investigating it as Inquiry 2015. We did some experimenting with speeding up the process, but any of these attempts would lead to the black image problems we were seeing earlier. This inquiry is still under evaluation, but I'll add to it that you also noticed the slowness of it and I'll link this forum post to the inquiry.

As for having a window not appear, to your scripts, you can try using:

I've done some quick testing of this in a script where I would have setOffScreen(True), load a bundle, and capture a movie. This appears to work well. If you give this a try and have any questions or problems, please let us know.

Thanks -
Bob

Hi Bob -

Thank you for the hint to switch off the screen. However, it appears not to work in combination with a 'full screen' display.

HP