Isis3: cisscal calibration fails for I/F units

[michaelaye]

ISIS version(s) affected: x.y.z
3.9.1
Description

cisscal fails to calibrate towards I/F units:

$ cisscal from=test.cub to=test_cal.cub units=I/F
**ERROR** Unable to calibrate image using I/F. Cannot calculate Solar Distance using Isis::Camera object.

How to reproduce

• Download https://pds-rings.seti.org/holdings/volumes/COISS_2xxx/COISS_2115/data/1880794265_1880940914/N1880813812_1.LBL
• Download https://pds-rings.seti.org/holdings/volumes/COISS_2xxx/COISS_2115/data/1880794265_1880940914/N1880813812_1.IMG
• ciss2isis from=N1880813812_1.LBL to=test.cub
• spiceinit from=test.cub
• cisscal from=test.cub to=test_cal.cub

Additional context

Using cisscal from=test.cub to=test_cal.cub units=intensity works.
It's so weird though that the general Solar Distance calculator would be broken? If that's a general case, hundreds of people should have complained about this, shouldn't they?

I made sure, today, that the conda env is updated (conda update isis3), and that both the base and the cassini data areas are updated, using:

rsync -azv --delete --partial isisdist.astrogeology.usgs.gov::isis3data/data/base .
rsync -azv --exclude='kernels' --delete --partial isisdist.astrogeology.usgs.gov::isis3data/data/cassini .

[lwellerastro]

I can reproduce this error. I also tested under isis3.9.0, isis3.8.0 and isis3.7.0 since there have been a number of changes to this software over the past few months - they all fail in the same way.

Perhaps the target (SKY, I see rings), is causing the problem. I have not encountered this sort of error when working with Titan or Enceladus data.

[michaelaye]

So, years ago we had a similar issue with spiceinit failing:
https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,3922.0.html
and I implemented a workaround, specific for ring data:

        if not self.is_ring_data:
            return
        targetname = getkey(
            from_=self.pm.raw_cub, grp="instrument", keyword="targetname"
        ).decode().strip()

        if targetname.lower() != "saturn":
            editlab(
                from_=self.pm.raw_cub,
                options="modkey",
                keyword="TargetName",
                value="Saturn",
                grpname="Instrument",
            )

but this doesn't work anymore since ISIS 3.9.1, it seems (although I'm not sure since when it doesn't) and the error appears with cisscal instead of spiceinit.

[michaelaye]

Hm, I confirmed that this specific image doesn't work in 3.8.1 either, using this workaround:

 editlab from=test.cub options=modkey keyword=TargetName value=Saturn grpname=Instrument

Need to dig further which scenario fails (only this image?) and which doesn't.

[lwellerastro]

I just got everything to work under isis3.9.1 doing the following:

ciss2isis from=N1880813812_1.LBL to=N1880813812_1.cub
editlab from=N1880813812_1.cub options=modkey keyword=TargetName value=Saturn grpname=Instrument
spiceinit from=N1880813812_1.cub
cisscal from=N1880813812_1.cub to=N1880813812_1.cal.cub

It seems you did things in this order, but you don't say so explicitly.
Could you try my order and see if that does it?

[michaelaye]

oh, might have forgotten the rerun of spiceinit. will check.

[lwellerastro]

Well, I just looked at the calibrated file and although it looks ok, there are no lat/lons, but maybe this is expected because of the target? I have zero experience with this type of data.

[michaelaye]

i'm in a telecon right now, but for ring data you got to do:

spiceinit from=... shape=ringplane

[michaelaye]

i mean, you don't have to, but i usually reproject later to the ringplane.

[lwellerastro]

Qview has a problem with the data after spiceinit shape=ringplane - error about North Azimuth not being available. Darn pop up will not go away. You familiar with this problem? That would be a new post if "no".

[michaelaye]

haven't seen it in 3.8.1

[lwellerastro]

Yeah, works there, break/bug begins in isis3.9.0
Wonder what was added/removed that is creating the problem.

[michaelaye]

I confirm that this script works in 3.9.1:

EDIT: Sorry I renamed filenames to test.xxx for this script.

ciss2isis from=test.LBL to=test.cub
editlab from=test.cub options=modkey keyword=TargetName value=Saturn grpname=Instrument
spiceinit from=test.cub web=no shape=ringplane cksmithed=yes spksmithed=yes
cisscal from=test.cub to=test.cal.cub units=I/F

Note that web=yes doesn't work with shape=ringplane, but works for default shape.

[jlaura]

@michaelaye It looks like this is not a software bug?

[michaelaye]

I guess not, but I was wondering if the error message can be improved in a way where the error would state why the solar flux can’t be calculated? I’m also not sure why that isn’t possible? I created a spice routine that calculates the intersect point of the camera boresight with the ring plane in j2000 coords, should we maybe implement that here?

[ascbot]

I am a bot that cleans up old issues that do not have activity.

This issue has not received feedback in the last six months. I am going to add the inactive label to
this issue. If this is still a pertinent issue, please add a comment or add an emoji to an existing comment.

I will post again in five months with another reminder and will close this issue on it's birthday unless it has
some activity.

[michaelaye]

@scsides @jessemapel @jlaura could somebody help me understand why this fails and why Jay thinks this is not a software bug?

[michaelaye]

ah, it's okay, this was related to the fact that it's a data configuration problem. And then I was suggesting that the error message is very misleading. do ppl agree and how/where could we improve it?

[jlaura]

@michaelaye Re-reading the thread, I think (?) my thinking was that this is/was working for you using:

ciss2isis from=test.LBL to=test.cub
editlab from=test.cub options=modkey keyword=TargetName value=Saturn grpname=Instrument
spiceinit from=test.cub web=no shape=ringplane cksmithed=yes spksmithed=yes
cisscal from=test.cub to=test.cal.cub units=I/F

If that isn't the case (sorry!), could you post the steps to reproduce (or link them if I missed them above). Otherwise, I am not sure how to alter the error message, but would be very open to improving it however is most informative.

[jessemapel]

This is likely not a bug in the software because it can't know what target it has to calibrate for. The issue is with the underlying data not properly labeling the target. Here's the terget information from the PDS label:

TARGET_DESC = "Saturn-Rings"
TARGET_LIST = "N/A"
TARGET_NAME = "SKY"

To help fix these situations before, we've added an optional argument to ingestion apps that allows the user to specify a target that overwrites what's on the label (exactly what the editlab work around does).

So, I would recommend adding an optional target argument to ciss2isis.