On Tue, 20 Oct 2009, Tim Connors wrote:
> On Mon, 19 Oct 2009, Peter W. Draper wrote:
>
>> On Mon, 19 Oct 2009, Tim Connors wrote:
>>
>>> I'm trying to feed realtime 16 bit unsigned data into skycat and gaia
>>> (the skycat window displays bitpix=-16), but have encountered a
>>> probable bug where if the min cut value is set to < 0 with the max
>>> value > 0 (such as by right-dragging the mouse in gaia to decrease the
>>> contrast and increase the brightness - which is what most of our
>>> telescope operators have been trained to do), the display blanks
>>> completely when it is loaded with unsigned data as soon as min<0.
>>>
>>> Up until now, for our aquisition cameras, we've been feeding 8 bit
>>> unsigned data into a plugin that told skycat/gaia it was dealing with
>>> 8 bit signed data, and this has strangely worked even when the the
>>> data input is > 127 (I don't understand why it works, but let that
>>> slide for now; our code is a mass of spagetti). Now that we have
>>> moved to 16 bit for some of our cameras, the data values > 32767 now
>>> get mapped to "blacker than black" as I would have expected, but I
>>> can't simply get gaia to display unsigned 16 bit values as I would
>>> desire, because of the aforementioned min/max cut bug.
>>
>> Hi Tim,
>>
>> if you're using the rtdevt interface to do this (I expect so, since
>> you're sending -16 bitpix), then there are two elements in the
>> rtdIMAGE_INFO struct, "highCut" and "lowCut" that you can define to set
>> the initial limits used in the display. That should stop the going
>> negative issue.
>
> We're using something called dserv ("Drama Interface to pskycat", pskycat
> helpfully being described as the "pskycat image viewer"), which may or may
> not be AAO specific things, and rtdserver ("Files extracted from ESO RTD
> for use in AAO2 CCD software"; sounds like rtdevt to me, especially since
> it has the rtdIMAGE_INFO struct in there) but I haven't yet worked out how
> they interface together.
>
> Nevertheless, on our monitors, we'd want to be able to freely adjust the
> brightness in software, which would be more difficult if the minimimum cut
> levels were set to 0 (although the workaround would at least be useful in
> order to get the telescope operator out of trouble).
>
> Also, don't highCut and lowCut in rtdIMAGE_INFO just apply to the initial
> limits (that's what the description says anyway)? The autoadjusted
> initial limits are (usually - I haven't tested for cosmic rays yet) fine
> here, it's just when we right click-drag the mouse to set new limits that
> the image suddenly disappears if lowCut<0.
Hi Tim,
I've come across this limitation myself now, so have made some changes to
Skycat so that the cuts can now be outside the data range of short
integers. This allows the lower limit for unsigned shorts to be less than
zero, with the desired effect of brightening the background.
Don't know where you go to with all this, but the changes are committed to
the JAC repository:
http://starlink.jach.hawaii.edu/git/?p=skycat.git
Cheers,
Peter.
|