pggray() issue

[karlglazebrook]

Note the implementation of pggray() has the black and white reversed, and produces incorrect results if they are in the correct order.

Note the definition:

 SUBROUTINE PGGRAY (A, IDIM, JDIM, I1, I2, J1, J2,FG, BG, TR)

" The shade is a number in the
range 0 to 1 obtained by linear interpolation between the background
level (BG) and the foreground level (FG)"

This means that FG is the white colour, and BG the black. If I load in a FITS image and want stars to be white on /xwin (with real pgplot) - i.e. a 'positive' image, then I have FG > BG. And similarly the same ordering gives a negative image on a /PS output. These are both flipped if FG<BG.

giza has the ordering backward and only produces a postive image. Obviously this is somewhat of a matter of convention, but it would be best if the default convention was the same as pgplot.

More seriously, if FG<BG then you do not get an inverted image, you just get a black frame. This is why test4.p in perl-pgplot does not work (it should show the galaxy M51) and you can not produce a negative image by swapping FG and BG which is undesirable behaviour.

[haavee]

Hi Karl,

giza has the ordering backward and only produces a postive image. Obviously this is somewhat of a matter of convention, but it would be best if the default convention was the same as pgplot.

This is readily fixed because there seems to be a difference of opinion between the order of values passed to cpggray() and its implementation forwarding those to the actual rendering function.

As far as I can tell the case FG < BG is not handled by the code so that would require a bit more thought and I'm not yet up to speed with colouring/rendering of the pixels

[karlglazebrook]

Hi there In the pggray() original doc http://www.astro.caltech.edu/~tjp/pgplot/subroutines.html#PGGRAY <http://www.astro.caltech.edu/~tjp/pgplot/subroutines.html#PGGRAY> FG comes first and that maps to the white value? In any case the best thing is for giza to produce the same thing as pgplot when called with the same arguments. The FG/BG is important as it is common to switch between positive and negative images. Karl

…

On 10 Nov 2018, at 2:09 am, Harro Verkouter ***@***.***> wrote: Hi Karl, giza has the ordering backward and only produces a postive image. Obviously this is somewhat of a matter of convention, but it would be best if the default convention was the same as pgplot. This is readily fixed because there seems to be a difference of opinion between the order of values passed to cpggray() and its implementation forwarding those to the actual rendering function. As far as I can tell the case FG < BG is not handled by the code so that would require a bit more thought and I'm not yet up to speed with colouring/rendering of the pixels — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOnymnE8hQnAxPnfbhPYVwGjzBBt0nHrks5utZqpgaJpZM4XyZiP>.

[karlglazebrook]

One could fix this by reversing FG/BG in the code after the call. Then my test would produce the same result.

It might be more work to reproduce the other PGPLOT behaviour where if FG<BG the image is inverted.