Layer Label Size, Annotation varies

[joleenf]

Hi,

When scripts are run which iterate over a number of times, there is an inconsistency in label size when using layer label, this behavior has also been seen in color bar labels, and annotations. This type of inconsistency will frustrate and cause users to move to a different system. I am currently trying to rectify the problem in this script which generated these images by only apply labels when necessary, setting the projection only once (while making sure that auto-set projection is off) and adding sleep statements. However, users should not have to worry about this much detail.

Joleen


animation at
ftp://ftp.ssec.wisc.edu/pub/ssec/jf/201 ... isanim.gif

You may notice there is an error in the label. This is not GOES-14 but GOES-13. I was modifying an old script and that was hard coded. Here is one solution to getting that information from the data....

Code: Select all

metaDataVIS, visibleData = getADDEImage(<parameters>)

sensorName = metaDataVIS["sensor-type"]
?sensorName

sensorNameSplit = sensorName.split(" ")   #reconstruct name, split into array to make this easier
?sensorNameSplit

sensorName = sensorNameSplit[0] + '-' + sensorNameSplit[1]   # I don't like this path because this could cause inconsistency.  Ideas?
?sensorName

This returns:

GOES 13 imager # from metaDataVIS["sensor-type"] command
['GOES', '13', 'imager'] # the metaDataVIS.split(" ") command
GOES-13 # the final string

[TJS]

We have seen this issue in other scripts. Agreed that this issue of inconsistent results over a loop in a script needs to be addressed. This is especially important if someone is working with lots of 1min SRSOR data or lots of ABI bands/sectors/times.

Thanks,
TJS

[joleenf]

Here is what happens when I only apply the annotation the first time in the run. Note, the first frame, there is no black box around the "Albedo" text, but in the following frames, there is. I need to change the order of the layers. Too complicated. In fact, my attempt to bring the layer forward failed.

[kaba]

Just to add onto this topic.
A good way we have found out to avoid the changes in font size for the color-bar label
is to actually tell it in the script what fun size you want it to be.
In my recent script runs, I noticed that the fonts on the fist image color-bar was always bigger
than the rest. by setting the size parameter in "setColorScale" to a fixed number they became consistent.

layerVIS.setColorScale(placement='Top', size=20)

[joleenf]

However, font size will still vary for the annotate (interactive: draw freely) command regardless of whether or not the font size is being specified. It seems that when I limited re-projection of the data to one time, but redrew the labels each iteration of the loop, the problem was rectified. However, this was for a much smaller dataset than full disk data and on a normal GOES-EAST schedule from 13:45-20:45 UTC.

Joleen

[barryr]

Hi Joleen,
Thanks for the report. I spent time with Bob trying to replicate these issues. We mostly did it through the Jython Shell, both with and without explicitly setting the font size. We were not able to replicate the problem of font sizes changing in layer labels, color scale labels, annotation text, etc., nor the problem of a text background color showing up on some frames but not others.

So we must not be testing it correctly. Can you provide a sample script (post here or email to the help desk) that we could use to replicate the problems (and use to test any fixes)?

Thanks,
Barry

[joleenf]

First, in this case, the black box behind the text was due to the fact that I did not properly remove the label before adding a new layer. This can be replicated by commenting the line layerVIScolorbarLabel.doRemove() in either script.

Next, this is the script which will produce the shifting labels. When it is run, the reason behind the inconsistency is obvious. In this case, the labels are applied, then the zoom occurs. The display then attempts to shift the label size, and the save occurs before the label resize is done. It would be nicer if the user did not have to worry about this problem.

Note: the time range can be reduced to 13:00:00-14:00:00, this should still reproduce the problem.

varyingLabelSizes.py

(3.75 KiB) Downloaded 341 times

This is the script which fixes the issue for now. I believe it is also a little better model. Auto-set projection turned off in the mcidas-v session. (I really need a way to set that at the beginning of the script!). The image is displayed, then on only the first iteration of the loop, the display is reprojected and zoomed. Labels are last.

varyingLabelSizesFixed.py

(3.76 KiB) Downloaded 338 times

Kaba noticed the same behavior in his script when setColorScale was called without setting a font size. In this case, adding the font name and size solved the problem. However, by default, this method should get the font and size from the user preferences when no keyword is set. It does not make sense to see that variation.

Is there any way to let the following step know that the previous step is really finished?

Joleen

[barryr]

Thanks for the samples! We ran varyingLabelSizes.py and were able to see the problems you reported.

I wrote this up as McIDAS-V Inquiry 1646:
http://mcidas.ssec.wisc.edu/inquiry-v/?inquiry=1646

Although it's rather kludgy and inelegant, I was told the only workaround for now is to use the pause function if you need to have a step wait until the previous one finishes.

Barry

[joleenf]

Unfortunately, pause is not a guarantee that a process will finish.

Joleen