Isis3: phocube does not handle NULL pixels correctly

[lavalaz]

ISIS version(s) affected: all (3.9.0)

Description

Phocube calculates values for pixels where there are no valid DNs

How to reproduce

Run phocube on a map projected cube and you will find values reported outside the region where there are valid pixel values

Possible Solution

Provide at least an option to NULL phocube values wherever the input DN is NULL or a special pixel value

Additional context

This is essential when doing photometric analyses (i.e., comparing DN versus phase angle). We do not want to feed phase angles for which there are no valid DNs into the analysis.

[jessemapel]

I'm not sure if this behavior is incorrect. Just because the pixel is null in an image, doesn't mean you can't compute photometric angles from it. With a lvl1 image, you can still get a look vector and with a map projected image it still maps to a point on the body.

[lwellerastro]

Not necessarily friendly, but a user can always mask the phocube output with the original input image to punch the NULL DN's through if they don't want to use them.

[lavalaz]

For photometry analysis, you need angles that correspond to valid DNs. For other uses, you may want angles computed for areas with no image data. Lynn is correct that mask could do this (I did not know how mask worked until she pointed this out). It would be much nicer (efficient) to do this within phocube but I suppose you can consider this a feature request instead of a "bug".

[jessemapel]

To be specific, a new argument that is just a flag if pixels containing Null data should be processed. Phocube can take a while to run and ignoring large Null regions would save a lot of time, so putting a flag in phocube seems resonable as opposed to just requiring users to mask afterwards.

[jessemapel]

@blandoplanet @jlaura Is this an ASC products issue? It looks like it is to me. This is something that supports another ASC project. Same with #3645

[blandoplanet]

Yep. I concur with @jlaura

[lwellerastro]

Just wondering if all special pixels need to be considered or only NULL. I believe this recent astrodiscuss post demonstrates any special pixel value needs to be avoided in the resulting output file: (https://astrodiscuss.usgs.gov/t/changing-special-pixels-to-null/413)

[jessemapel]

@lwellerastro It makes sense to ignore all special pixels and not just NULL.

[kaitlyndlee]

To clarify, if a user wants the input image to be copied to the output using the DN parameter, should the special pixels be set to NULL in the DN band or set to their original value and just the pixels in the other bands get set to NULL?

[jessemapel]

@kaitlyndlee The special pixels should be set to their original values. The band should be a copy of the input DNs.

[kaitlyndlee]

Another quick question. The latest work on phocube allowed ra and dec to be calculated regardless if the point is on the body or not. Right now, I am keeping that functionality with the "ignore special pixels" parameter. That is, only special pixels are being set to NULL. If a pixel is not special, but is off the body, ra and dec still get calculated for that pixel. Is this the intended functionality when a user wants to ignore special pixels?

[jessemapel]

Another quick question. The latest work on phocube allowed ra and dec to be calculated regardless if the point is on the body or not. Right now, I am keeping that functionality with the "ignore special pixels" parameter. That is, only special pixels are being set to NULL. If a pixel is not special, but is off the body, ra and dec still get calculated for that pixel. Is this the intended functionality when a user wants to ignore special pixels?

I would assume this is correct, but @lavalaz or @lwellerastro may have more input.

[lavalaz]

The hope behind this ticket was to speed up _phocube_ by not doing any math on pixels that do not have valid DN values. If you still do all the math and then replace the calculations with NULL for certain pixels, it is helping by being able to skip the step of running _mask_ after _phocube_ but does not help _phocube_ finish faster. In any case, for photometric analysis, RA and Dec are not used so I do not have any opinion on what happens with those values. I suggest you do whatever is easiest - some other user might have a different opinion someday, but it'll be good either way for now.