If you are me and are suspecting that some remaining issues are due to the USGS global mosaic being... less than perfect when it comes to using it for geometric control, there is a new controlled global mosaic produced for the JUICE mission:
https://www.sciencedirect.com/science/artic...032063321001495 (article is open-access)
It maybe a few weeks before I get a chance to try it, but... not a bad thing to test instead of the USGS global mosaic.
(small note: why oh why would the JUICE team use planetocentric East longitudes. insert panda smashing keyboard gif here)
Full Version: Ganymede Flyby - PJ34
Alas for us old-timers who have used West longitudes forever, East longitudes are going to be the new standard for the Galilean satellites. I think JUICE started the trend, but Europa Clipper is adopting the same standard for consistency, amid much grumbling from the old guard.
John
John
QUOTE (volcanopele @ Jul 22 2021, 07:38 PM) 
If you are me and are suspecting that some remaining issues are due to the USGS global mosaic being... less than perfect when it comes to using it for geometric control, there is a new controlled global mosaic produced for the JUICE mission:
https://www.sciencedirect.com/science/artic...032063321001495 (article is open-access)
It maybe a few weeks before I get a chance to try it, but... not a bad thing to test instead of the USGS global mosaic.
(small note: why oh why would the JUICE team use planetocentric East longitudes. insert panda smashing keyboard gif here)
https://www.sciencedirect.com/science/artic...032063321001495 (article is open-access)
It maybe a few weeks before I get a chance to try it, but... not a bad thing to test instead of the USGS global mosaic.
(small note: why oh why would the JUICE team use planetocentric East longitudes. insert panda smashing keyboard gif here)
Thanks for pointing this out, this was the perfect time for a Ganymede map with better geometric control. Measuring a few points in Juno image PJ34_1 and the corresponding points in the new map I get a distance from Ganymede that is ~5 km larger than the distance value from the reconstructed SPK. This is almost identical to the distance value I get by decreasing Ganymede's radius until the limb fits for image PJ34_1 match an interframe delay value of 0.372 (shrinking Ganymede is easier in my processing pipeline than increasing the target center distance).
Using the USGS map resulted in the same distance as from the reconstructed SPK (or possibly 1-2 km larger distance). To me this result was surprisingly different from the limb fit result but inaccuracies in the USGS map are probably to blame.
The above results are preliminary though and I need to double check them.
Adopting a new longitude system must be highly confusing.
QUOTE (john_s @ Jul 22 2021, 03:01 PM)
Alas for us old-timers who have used West longitudes forever, East longitudes are going to be the new standard for the Galilean satellites.
We lost this battle for Mars back in 2001. https://www.msss.com/mgcwg/mgm/letter.txt
I blame the spectroscopists.
Seriously, it doesn't matter THAT much, as long as... oh I don't know, your image search tool sticks with ONE of them and doesn't use East on the search page and West on the results page and east in the individual image page... (not directed at you Mike, but at another Mars instrument...)
It matters for Io... my mental map is based in west longitude...
Seriously, it doesn't matter THAT much, as long as... oh I don't know, your image search tool sticks with ONE of them and doesn't use East on the search page and West on the results page and east in the individual image page... (not directed at you Mike, but at another Mars instrument...)
It matters for Io... my mental map is based in west longitude...
This is giving me choleric nostalgia for south-is-up maps of the Moon and Mars in astronomy books because observers with their sketchpad and eyepiece were too set-in-their ways to take one second to rotate their sketchpad 180° when they were done sketching. 
QUOTE (JRehling @ Jul 23 2021, 10:44 AM)
too set-in-their ways to take one second to rotate their sketchpad 180° when they were done sketching.
Alternatively, they could move the telescope to Australia. That would be the XKCD way.
Moved the discussion about the PJ35 flyby to its own topic:
http://www.unmannedspaceflight.com/index.php?showtopic=8643
http://www.unmannedspaceflight.com/index.php?showtopic=8643
QUOTE (volcanopele @ Jul 22 2021, 12:38 PM)
If you are me and are suspecting that some remaining issues are due to the USGS global mosaic being... less than perfect when it comes to using it for geometric control, there is a new controlled global mosaic produced for the JUICE mission:
https://www.sciencedirect.com/science/artic...032063321001495 (article is open-access)
https://www.sciencedirect.com/science/artic...032063321001495 (article is open-access)
The mosaics are available at https://janus.dlr.de/publications/ganymede/...ede_Mosaic.html
to get the first mosaic into ISIS I used the following commands:
CODE
std2isis from=Ganymede_global_equi_000_359m.tif \
to=Ganymede_global_equi_000_359m.cub mode=grayscale
maptemplate map=projection_dlr.map projection=EQUIRECTANGULAR clat=0.0 clon=0.0 \
londir=POSITIVEWEST londom=360 eqradius=2631200 polradius=2631200 \
lattype=Planetocentric Targetname=Ganymede targopt=user rngopt=user \
minlat=-90.0 maxlat=90.0 minlon=0.0 maxlon=360.0 resopt=mpp \
resolution=358.774244364249967
maplab from=Ganymede_global_equi_000_359m.cub map=projection_dlr.map \
sample=23040.5 line=11520.5 x=0.0 y=0.0
to=Ganymede_global_equi_000_359m.cub mode=grayscale
maptemplate map=projection_dlr.map projection=EQUIRECTANGULAR clat=0.0 clon=0.0 \
londir=POSITIVEWEST londom=360 eqradius=2631200 polradius=2631200 \
lattype=Planetocentric Targetname=Ganymede targopt=user rngopt=user \
minlat=-90.0 maxlat=90.0 minlon=0.0 maxlon=360.0 resopt=mpp \
resolution=358.774244364249967
maplab from=Ganymede_global_equi_000_359m.cub map=projection_dlr.map \
sample=23040.5 line=11520.5 x=0.0 y=0.0
I would just post the cub file but it came out to be 4.25 GB
I’ve posted preliminary PJ34 Ganymede equirectangular maps at missionjuno.
PJ34_01 https://www.missionjuno.swri.edu/junocam/processing?id=11142
PJ34_02 https://www.missionjuno.swri.edu/junocam/processing?id=11141
PJ34_03 https://www.missionjuno.swri.edu/junocam/processing?id=11140
PJ34_04 https://www.missionjuno.swri.edu/junocam/processing?id=11139
PJ34_05 https://www.missionjuno.swri.edu/junocam/processing?id=11138
Maps are 32 pixel/degree. The spacecraft position and image timing solution used a 420 control-point network and a limb fit with 120 to 220 points.
The control network is strictly self-referential. No attempt was made to tie features to other maps or IAU nomenclature points.
No attempt was made to mitigate illumination/view angle dependent brightness changes or camera internal reflections, other than application of a scale factor to produce roughly similar brightness between images. The contrast is intended to be natural-ish.
Below is a transfer format SPK file covering just the period of the Ganymede encounter images for anyone who wants to try this solution with ISIS. It can be converted to a binary SPK with the SPICE “tobin” utility.
This Juno SPK just implements a fixed offset to the default reconstructed SPK by adding {-2.625, 19.375, 2.125} to the Juno XYZ position in its native ephemeris configuration (Reference frame=“J2000”, Observing body=“JUPITER BARYCENTER”).
The start time additive offsets in seconds are:
"P34_01" -> -0.0399998, "P34_02" -> 0.00188565, "P34_03" -> 0.00839715, "P34_04" -> 0.00361281, "P34_05" -> 0.
Caveat: Solution derived using my camera model, so a constant shift may need to be applied to the timing offsets.
PJ34_05 didn't participate in the solution but is included just for completeness.
cat pj34bsspktbl.xsp
FWIW, 98% of control network residuals < 3.6km, 89%<2km.
Click to view attachment
PJ34_01 https://www.missionjuno.swri.edu/junocam/processing?id=11142
PJ34_02 https://www.missionjuno.swri.edu/junocam/processing?id=11141
PJ34_03 https://www.missionjuno.swri.edu/junocam/processing?id=11140
PJ34_04 https://www.missionjuno.swri.edu/junocam/processing?id=11139
PJ34_05 https://www.missionjuno.swri.edu/junocam/processing?id=11138
Maps are 32 pixel/degree. The spacecraft position and image timing solution used a 420 control-point network and a limb fit with 120 to 220 points.
The control network is strictly self-referential. No attempt was made to tie features to other maps or IAU nomenclature points.
No attempt was made to mitigate illumination/view angle dependent brightness changes or camera internal reflections, other than application of a scale factor to produce roughly similar brightness between images. The contrast is intended to be natural-ish.
Below is a transfer format SPK file covering just the period of the Ganymede encounter images for anyone who wants to try this solution with ISIS. It can be converted to a binary SPK with the SPICE “tobin” utility.
This Juno SPK just implements a fixed offset to the default reconstructed SPK by adding {-2.625, 19.375, 2.125} to the Juno XYZ position in its native ephemeris configuration (Reference frame=“J2000”, Observing body=“JUPITER BARYCENTER”).
The start time additive offsets in seconds are:
"P34_01" -> -0.0399998, "P34_02" -> 0.00188565, "P34_03" -> 0.00839715, "P34_04" -> 0.00361281, "P34_05" -> 0.
Caveat: Solution derived using my camera model, so a constant shift may need to be applied to the timing offsets.
PJ34_05 didn't participate in the solution but is included just for completeness.
cat pj34bsspktbl.xsp
CODE
DAFETF NAIF DAF ENCODED TRANSFER FILE
'DAF/SPK '
'2'
'6'
'SPK '
BEGIN_ARRAY 1 70
'pj34bsspktbl.csv '
'2850637E^8'
'285065B8^8'
'-3D'
'5'
'1'
'8'
70
'1DDD8878FAEB96^5'
'-E9D2BA4353183^5'
'-6F539DF67390F4^5'
'-27670A7FAC37DE^1'
'A929B182A93A88^1'
'97B1438A61696^1'
'1DD4B3D51EB7A^5'
'-E9AD12CDA8EEE^5'
'-6F31E0913EE95C^5'
'-27E716FF58BEEC^1'
'A90B883384996^1'
'975AAA50702CB8^1'
'1DCBC662B63C4F^5'
'-E98774BC4A938^5'
'-6F1038F0DFAA84^5'
'-2842194DDEB866^1'
'A8D8241BB85F2^1'
'96F229CF0B4E1^1'
'1DC2C9C7DE8125^5'
'-E961E2ABC2A778^5'
'-6EEEA80F53D18C^5'
'-287052C9FE8C9E^1'
'A8A2DF087B7CF8^1'
'9692117F0AD2E8^1'
'1DB9C6AF953F1B^5'
'-E93C5B551FBC^5'
'-6ECD2A3A0DA61^5'
'-287F4845AA4D1E^1'
'A87906E9352E38^1'
'9647EBB7CFF618^1'
'1DB0C2415940AA^5'
'-E916DBB55D29C8^5'
'-6EABBA66E49724^5'
'-287E6D91631E42^1'
'A85D7666A89618^1'
'961397D23E14A^1'
'1DA7BED7E6B912^5'
'-E8F160CFB6A4A^5'
'-6E8A5440AD0AC8^5'
'-28773897123834^1'
'A84E10A23458E8^1'
'95F0213B2BC75^1'
'1D9EBD4A482941^5'
'-E8CBE84436308^5'
'-6E68F495DB4374^5'
'-286E382A11683^1'
'A847DAAA2E081^1'
'95D8A9C93C4698^1'
'1D95BDBF44C7B7^5'
'-E8A670514EC4A^5'
'-6E47992776CEB4^5'
'-28655D084814F^1'
'A84857F37F8688^1'
'95C994E15A8F4^1'
'1D8CC0160F5546^5'
'-E880F7AFECBBE^5'
'-6E264062718444^5'
'-285D624E2EA57^1'
'A84DB752C580A8^1'
'95C0698E6C6E8^1'
'1D83C41532EA5B^5'
'-E85B7D70873D18^5'
'-6E04E92838892^5'
'-28567CCD933D54^1'
'A856B1571DB91^1'
'95BB7DD96EE0F8^1'
'2850637E^8'
'39^2'
'5^1'
'B^1'
END_ARRAY 1 70
TOTAL_ARRAYS 1
~NAIF/SPC BEGIN COMMENTS~
********************************************************************************
Juno PJ34 Ganymede Photogrametric reconstruction, preliminary
********************************************************************************
MKSPK RUN DATE/TIME: 2021-07-28T21:13:42
MKSPK SETUP FILE: pj34bsspktbl.setup
MKSPK INPUT FILE: pj34bsspktbl.csv
MKSPK OUTPUT FILE: pj34bsspktbl.bsp
OUTPUT FILE STATUS: NEW FILE
********************************************************************************
\begindata
INPUT_DATA_TYPE = 'STATES'
OUTPUT_SPK_TYPE = 8
OBJECT_ID = -61
CENTER_ID = 5
REF_FRAME_NAME = 'J2000'
PRODUCER_ID = 'Brian Swift'
DATA_ORDER = 'epoch x y z vx vy vz '
DATA_DELIMITER = ','
LINES_PER_RECORD = 1
LEAPSECONDS_FILE='/Users/bswift/Downloads/junospice/kernels/lsk/naif0012.tls'
INPUT_DATA_FILE = 'pj34bsspktbl.csv'
OUTPUT_SPK_FILE = 'pj34bsspktbl.bsp'
COMMENT_FILE = 'pj34bsspktbl.comment'
IGNORE_FIRST_LINE = 0
LINES_PER_RECORD = 1
TIME_WRAPPER = '# ETSECONDS'
POLYNOM_DEGREE = 5
APPEND_TO_OUTPUT = 'NO'
\begintext
********************************************************************************
~NAIF/SPC END COMMENTS~
'DAF/SPK '
'2'
'6'
'SPK '
BEGIN_ARRAY 1 70
'pj34bsspktbl.csv '
'2850637E^8'
'285065B8^8'
'-3D'
'5'
'1'
'8'
70
'1DDD8878FAEB96^5'
'-E9D2BA4353183^5'
'-6F539DF67390F4^5'
'-27670A7FAC37DE^1'
'A929B182A93A88^1'
'97B1438A61696^1'
'1DD4B3D51EB7A^5'
'-E9AD12CDA8EEE^5'
'-6F31E0913EE95C^5'
'-27E716FF58BEEC^1'
'A90B883384996^1'
'975AAA50702CB8^1'
'1DCBC662B63C4F^5'
'-E98774BC4A938^5'
'-6F1038F0DFAA84^5'
'-2842194DDEB866^1'
'A8D8241BB85F2^1'
'96F229CF0B4E1^1'
'1DC2C9C7DE8125^5'
'-E961E2ABC2A778^5'
'-6EEEA80F53D18C^5'
'-287052C9FE8C9E^1'
'A8A2DF087B7CF8^1'
'9692117F0AD2E8^1'
'1DB9C6AF953F1B^5'
'-E93C5B551FBC^5'
'-6ECD2A3A0DA61^5'
'-287F4845AA4D1E^1'
'A87906E9352E38^1'
'9647EBB7CFF618^1'
'1DB0C2415940AA^5'
'-E916DBB55D29C8^5'
'-6EABBA66E49724^5'
'-287E6D91631E42^1'
'A85D7666A89618^1'
'961397D23E14A^1'
'1DA7BED7E6B912^5'
'-E8F160CFB6A4A^5'
'-6E8A5440AD0AC8^5'
'-28773897123834^1'
'A84E10A23458E8^1'
'95F0213B2BC75^1'
'1D9EBD4A482941^5'
'-E8CBE84436308^5'
'-6E68F495DB4374^5'
'-286E382A11683^1'
'A847DAAA2E081^1'
'95D8A9C93C4698^1'
'1D95BDBF44C7B7^5'
'-E8A670514EC4A^5'
'-6E47992776CEB4^5'
'-28655D084814F^1'
'A84857F37F8688^1'
'95C994E15A8F4^1'
'1D8CC0160F5546^5'
'-E880F7AFECBBE^5'
'-6E264062718444^5'
'-285D624E2EA57^1'
'A84DB752C580A8^1'
'95C0698E6C6E8^1'
'1D83C41532EA5B^5'
'-E85B7D70873D18^5'
'-6E04E92838892^5'
'-28567CCD933D54^1'
'A856B1571DB91^1'
'95BB7DD96EE0F8^1'
'2850637E^8'
'39^2'
'5^1'
'B^1'
END_ARRAY 1 70
TOTAL_ARRAYS 1
~NAIF/SPC BEGIN COMMENTS~
********************************************************************************
Juno PJ34 Ganymede Photogrametric reconstruction, preliminary
********************************************************************************
MKSPK RUN DATE/TIME: 2021-07-28T21:13:42
MKSPK SETUP FILE: pj34bsspktbl.setup
MKSPK INPUT FILE: pj34bsspktbl.csv
MKSPK OUTPUT FILE: pj34bsspktbl.bsp
OUTPUT FILE STATUS: NEW FILE
********************************************************************************
\begindata
INPUT_DATA_TYPE = 'STATES'
OUTPUT_SPK_TYPE = 8
OBJECT_ID = -61
CENTER_ID = 5
REF_FRAME_NAME = 'J2000'
PRODUCER_ID = 'Brian Swift'
DATA_ORDER = 'epoch x y z vx vy vz '
DATA_DELIMITER = ','
LINES_PER_RECORD = 1
LEAPSECONDS_FILE='/Users/bswift/Downloads/junospice/kernels/lsk/naif0012.tls'
INPUT_DATA_FILE = 'pj34bsspktbl.csv'
OUTPUT_SPK_FILE = 'pj34bsspktbl.bsp'
COMMENT_FILE = 'pj34bsspktbl.comment'
IGNORE_FIRST_LINE = 0
LINES_PER_RECORD = 1
TIME_WRAPPER = '# ETSECONDS'
POLYNOM_DEGREE = 5
APPEND_TO_OUTPUT = 'NO'
\begintext
********************************************************************************
~NAIF/SPC END COMMENTS~
FWIW, 98% of control network residuals < 3.6km, 89%<2km.
Click to view attachment
getting the following error with tobin:
Not sure what it hates about the text file. It can definitely see it. A quick change to CR-LF line endings gave me a different error.
CODE
perry@Surt PJ34 % tobin pj34bsspktbl.xsp
Converting: pj34bsspktbl.xsp
To: pj34bsspktbl.bsp
================================================================================
Toolkit version: N0066
SPICE(FILEREADFAILED)
Error reading the text file: pj34bsspktbl.xsp. IOSTAT = -1.
A traceback follows. The name of the highest level module is first.
TOBIN --> ZZCONVTB
================================================================================
Converting: pj34bsspktbl.xsp
To: pj34bsspktbl.bsp
================================================================================
Toolkit version: N0066
SPICE(FILEREADFAILED)
Error reading the text file: pj34bsspktbl.xsp. IOSTAT = -1.
A traceback follows. The name of the highest level module is first.
TOBIN --> ZZCONVTB
================================================================================
Not sure what it hates about the text file. It can definitely see it. A quick change to CR-LF line endings gave me a different error.
QUOTE (volcanopele @ Jul 30 2021, 09:38 AM)
...
Not sure what it hates about the text file. It can definitely see it. A quick change to CR-LF line endings gave me a different error.
Not sure what it hates about the text file. It can definitely see it. A quick change to CR-LF line endings gave me a different error.
I just copied the text from the post above and pasted into a file test1.xsp.
It gave me the same file that I produced, and "tobin" worked on it.
The bsp file produced from "tobin" matches my initial bsp.
You can check your files against the below md5 checksum.
CODE
bswift@HiCat j6 % diff pj34bsspktbl.xsp test1.xsp
bswift@HiCat j6 % /Users/bswift/Downloads/cspice/exe/tobin test1.xsp
Converting: test1.xsp
To: test1.bsp
bswift@HiCat j6 % ls -l pj34bsspktbl.xsp test1.xsp
-rw-r----- 1 bswift staff 2827 Jul 28 22:01 pj34bsspktbl.xsp
-rw-r----- 1 bswift staff 2827 Jul 30 12:23 test1.xsp
bswift@HiCat j6 % md5 pj34bsspktbl.xsp test1.xsp
MD5 (pj34bsspktbl.xsp) = 6d37da4d86ae344ac8a5d54c997dbb7e
MD5 (test1.xsp) = 6d37da4d86ae344ac8a5d54c997dbb7e
bswift@HiCat j6 % ls -l pj34bsspktbl.bsp test1.bsp
-rw-r----- 1 bswift staff 6144 Jul 28 22:04 pj34bsspktbl.bsp
-rw-r----- 1 bswift staff 6144 Jul 30 12:24 test1.bsp
bswift@HiCat j6 % md5 pj34bsspktbl.bsp test1.bsp
MD5 (pj34bsspktbl.bsp) = 51f7fb8ac06c4a84ef468b1f7335b909
MD5 (test1.bsp) = 51f7fb8ac06c4a84ef468b1f7335b909
bswift@HiCat j6 % /Users/bswift/Downloads/cspice/exe/tobin test1.xsp
Converting: test1.xsp
To: test1.bsp
bswift@HiCat j6 % ls -l pj34bsspktbl.xsp test1.xsp
-rw-r----- 1 bswift staff 2827 Jul 28 22:01 pj34bsspktbl.xsp
-rw-r----- 1 bswift staff 2827 Jul 30 12:23 test1.xsp
bswift@HiCat j6 % md5 pj34bsspktbl.xsp test1.xsp
MD5 (pj34bsspktbl.xsp) = 6d37da4d86ae344ac8a5d54c997dbb7e
MD5 (test1.xsp) = 6d37da4d86ae344ac8a5d54c997dbb7e
bswift@HiCat j6 % ls -l pj34bsspktbl.bsp test1.bsp
-rw-r----- 1 bswift staff 6144 Jul 28 22:04 pj34bsspktbl.bsp
-rw-r----- 1 bswift staff 6144 Jul 30 12:24 test1.bsp
bswift@HiCat j6 % md5 pj34bsspktbl.bsp test1.bsp
MD5 (pj34bsspktbl.bsp) = 51f7fb8ac06c4a84ef468b1f7335b909
MD5 (test1.bsp) = 51f7fb8ac06c4a84ef468b1f7335b909
The easiest solution might be to simply post the binary SPK file here as an attachment. Recent versions of the SPICE toolkit are able to read non-native SPK files (plus other binary files like CKs).
I got it to work. needed another return after "~NAIF/SPC END COMMENTS~"
QUOTE (Bjorn Jonsson @ Jul 30 2021, 01:01 PM)
The easiest solution might be to simply post the binary SPK file here as an attachment. Recent versions of the SPICE toolkit are able to read non-native SPK files (plus other binary files like CKs).
Thanks. I didn't realize I could post non-image attachments.
And....
Apparently *I* can't. Tried attaching the ".bsp" to this post, but received error:
Upload failed. You are not permitted to upload this type of file
Interesting, I thought it was possible to post more file types than images provided they are not executables, ZIP files or similar. But I managed to convert the transfer format file using the tip posted above.
So here is 34C00001 using Brian's SPK file and my control network:
Click to view attachment
Definitely improves the limb fit and the color fringing that's easiest to see near the terminator is much reduced, though there are a few area where it is more noticeable. I didn't change the start time for this observation. I just took the framelets that already have some processing done to them, used spiceinit to change the SPK file, then ran jigsaw again using my control network. Then I map projected each framelet and mosaicked again. Still not perfect, not sure if that's due to the camera model or some remaining spacecraft offset issues.
EDIT: looking carefully, I'm not sure this is true... honestly, it doesn't look like the pointing really improved all that much except for the limb fit now being spot on.
Not entirely happy with doing it this way. I thank Brian for the edited SPK file, that certainly works. But I am still hopeful that ISIS 6 (now a release candidate) will solve the issue with jigsaw with updating spacecraft position. A big reason for going through this exercise was to craft a processing plan/script for the later Io encounters by using Ganymede as a test case (Ganymede better get used to that position, it'll be used in much the same way later in the early 2030s). so I will come back to this once ISIS6 is released in a few weeks.
On a side note, while the Ganymede map produced by the JANUS team is fantastic, and very detailed, I am not getting good results using it with my control network. Mid- to high-northern latitudes are a particular concern. Could be my fault. Maybe there is something wrong with the mapping labels I applied, but I don't think so. I pulled those numbers from the geotiff. So I reverted to using the USGS map. I don't have the time to attempt to fix the issue if it is my fault.
EDIT: Jason is having way too much fun with control point networks:
Click to view attachment
Click to view attachment
Definitely improves the limb fit and the color fringing that's easiest to see near the terminator is much reduced, though there are a few area where it is more noticeable. I didn't change the start time for this observation. I just took the framelets that already have some processing done to them, used spiceinit to change the SPK file, then ran jigsaw again using my control network. Then I map projected each framelet and mosaicked again. Still not perfect, not sure if that's due to the camera model or some remaining spacecraft offset issues.
EDIT: looking carefully, I'm not sure this is true... honestly, it doesn't look like the pointing really improved all that much except for the limb fit now being spot on.
Not entirely happy with doing it this way. I thank Brian for the edited SPK file, that certainly works. But I am still hopeful that ISIS 6 (now a release candidate) will solve the issue with jigsaw with updating spacecraft position. A big reason for going through this exercise was to craft a processing plan/script for the later Io encounters by using Ganymede as a test case (Ganymede better get used to that position, it'll be used in much the same way later in the early 2030s). so I will come back to this once ISIS6 is released in a few weeks.
On a side note, while the Ganymede map produced by the JANUS team is fantastic, and very detailed, I am not getting good results using it with my control network. Mid- to high-northern latitudes are a particular concern. Could be my fault. Maybe there is something wrong with the mapping labels I applied, but I don't think so. I pulled those numbers from the geotiff. So I reverted to using the USGS map. I don't have the time to attempt to fix the issue if it is my fault.
EDIT: Jason is having way too much fun with control point networks:
Click to view attachment
QUOTE (volcanopele @ Aug 2 2021, 09:27 AM)
So here is 34C00001 using Brian's SPK file and my control network:
...
EDIT: looking carefully, I'm not sure this is true... honestly, it doesn't look like the pointing really improved all that much except for the limb fit now being spot on.
...
EDIT: looking carefully, I'm not sure this is true... honestly, it doesn't look like the pointing really improved all that much except for the limb fit now being spot on.
Your comments caused me to go take another look at my timing parameters. I see the PJ34_01 timing offset is not "good". I hadn't noticed that it is stuck up against the edge of the range my optimization uses for timing offsets. Will rerun with a larger range, but a timing offset this large is an indication to me there could be some other problem.
QUOTE
...
EDIT: Jason is having way too much fun with control point networks:
EDIT: Jason is having way too much fun with control point networks:
Yup, fun with control networks.
https://vimeo.com/581719195
It sounds like this is not the issue for this flyby, but what is the resolution of a control point? It certainly has to have some limit, and when it's topographical, like the central peak of a crater, it will shift depending upon different illumination. What makes that thorny is that many such points will shift systematically under different illumination conditions. (That will not happen with albedo features on a flat body, like if someone conveniently painted crosshairs all over a world.) On a world like Europa, the situation may approximate the latter, but with a world where albedo variations are muted and topographical features predominate, the second order effects are going to be the limiting factor on resolution, until/unless topography is accounted for.
QUOTE (JRehling @ Aug 3 2021, 12:47 PM)
It sounds like this is not the issue for this flyby, but what is the resolution of a control point?
https://ntrs.nasa.gov/citations/19880057291
Unfortunately if there's an online version I don't know where.
QUOTE (JRehling @ Aug 3 2021, 11:47 AM)
...It certainly has to have some limit, and when it's topographical, like the central peak of a crater, it will shift depending upon different illumination. What makes that thorny is that many such points will shift systematically under different illumination conditions. ...
The abstract of this (paywalled) 2016 article states the authors have techniques of addressing different illumination conditions.
A technique for processing of planetary images with heterogeneous characteristics for estimating geodetic parameters of celestial bodies with the example of Ganymede
For these observations, it doesn't really matter that much because the lighting conditions don't change all that much between the two observations I used, but it was enough that I did have to do some matches by sight (using the blink feature in qnet) between 34C00001 and 2. For some of the fixed points, I used a few points that matched up albedo features rather than topographic features and again didn't rely in autoreg for co-registration.
JIRAM results for Ganymede (both flybys) look promising; I'm sure that analysis will be forthcoming.
https://www.nasa.gov/feature/jpl/nasa-s-jun...f-moon-ganymede
https://www.nasa.gov/feature/jpl/nasa-s-jun...f-moon-ganymede
The bug I've mentioned in jigsaw in ISIS is now fixed in the version out today (5.0.2). Just tested it out and I have to say, it looks spectacular:
Click to view attachment
Click to view attachment
QUOTE (volcanopele @ Aug 6 2021, 02:58 PM)
The bug I've mentioned in jigsaw in ISIS is now fixed in the version out today (5.0.2). Just tested it out and I have to say, it looks spectacular:
That looks great. Did you use my SPK or the default? And does ISIS report its optimized spacecraft position, attitude, or image timing offset?
I'm curious to compare with what I'm coming up with.
I used juno_sc_rec_210606_210612_v01.bc and juno_rec_210513_210630_210707.bsp for a priori pointing and position, not your kernel.
I've put the trajectory and pointing kernels that ckwriter and spkwriter output in a Dropbox folder:
https://www.dropbox.com/sh/p7dsul2eyocjp3u/...tSP0Us_0la?dl=0
Note that these kernels only cover the first two Ganymede observations. I also made no adjustments to the start time of either observation.
EDIT: I threw in some of the files that jigsaw output as well as that might help with seeing the offsets I measured. note that offsets are WRT Ganymede.
I've put the trajectory and pointing kernels that ckwriter and spkwriter output in a Dropbox folder:
https://www.dropbox.com/sh/p7dsul2eyocjp3u/...tSP0Us_0la?dl=0
Note that these kernels only cover the first two Ganymede observations. I also made no adjustments to the start time of either observation.
EDIT: I threw in some of the files that jigsaw output as well as that might help with seeing the offsets I measured. note that offsets are WRT Ganymede.
QUOTE (volcanopele @ Aug 6 2021, 03:59 PM)
...
Note that these kernels only cover the first two Ganymede observations. I also made no adjustments to the start time of either observation.
Note that these kernels only cover the first two Ganymede observations. I also made no adjustments to the start time of either observation.
Yup, no need for a start time offset since your configuration is solving for camera pointing angles.
QUOTE
EDIT: I threw in some of the files that jigsaw output as well as that might help with seeing the offsets I measured. note that offsets are WRT Ganymede.
Thanks, good stuff. I must say, the 12 second optimization looks pretty tempting, compared to my .5 to 2.5 hour optimization runs.
To come back to JIRAM data represented at:
https://www.jpl.nasa.gov/images/ganymede-co...ent-aboard-juno
The coverage shown is from the 2 distant flybys. I expect spectacular pics from the close flyby, with an amazing resolution (localized at the overlapping part). I think we will have to wait analysis and publication of data to see them.
I'm also confused by the picture published in the link. The background map in inverted and the surface structures actually covered by JIRAM are not those shown in the pic. I'm quite amazed that such a mistake could have been made.
Best regards,
Marc.
https://www.jpl.nasa.gov/images/ganymede-co...ent-aboard-juno
The coverage shown is from the 2 distant flybys. I expect spectacular pics from the close flyby, with an amazing resolution (localized at the overlapping part). I think we will have to wait analysis and publication of data to see them.
I'm also confused by the picture published in the link. The background map in inverted and the surface structures actually covered by JIRAM are not those shown in the pic. I'm quite amazed that such a mistake could have been made.
Best regards,
Marc.
Corresponding Points Search Visualization https://vimeo.com/586883448
QUOTE (MarcF @ Aug 7 2021, 04:24 AM)
I'm also confused by the picture published in the link. The background map in inverted and the surface structures actually covered by JIRAM are not those shown in the pic. I'm quite amazed that such a mistake could have been made.
Did you notice that the "first" flyby in this work is not the first flyby from 2021, but a previous flyby from Dec. 26, 2019? Then, the "second" flyby in this work is from July 20, 2021. The June 7, 2021 flyby is not represented.
Mike, I just noticed that for the PJ34 Ganymede images, the missionjuno metadata position values aren't relative to Ganymede.
Maybe relative to Jupiter, but I haven't confirmed.
"SPACECRAFT_ALTITUDE": "994649.2 <km>",
"SUB_SPACECRAFT_LATITUDE": "-0.0391",
"SUB_SPACECRAFT_LONGITUDE": "302.9353",
Maybe relative to Jupiter, but I haven't confirmed.
"SPACECRAFT_ALTITUDE": "994649.2 <km>",
"SUB_SPACECRAFT_LATITUDE": "-0.0391",
"SUB_SPACECRAFT_LONGITUDE": "302.9353",
QUOTE (Brian Swift @ Nov 16 2021, 04:44 PM)
Mike, I just noticed that for the PJ34 Ganymede images, the missionjuno metadata position values aren't relative to Ganymede.
Yes, I complained about that.
QUOTE (mcaplinger @ Nov 16 2021, 05:42 PM)
Yes, I complained about that.
Ok. I'll send missionjuno site a note about it too.
I guess I had the wrong impression - that MSSS produced the data/images for the missionjuno site.
QUOTE (volcanopele @ Aug 2 2021, 09:27 AM)
EDIT: Jason is having way too much fun with control point networks:
Jason, for your ISIS control network production did you try "autoseed Path" footprintinit-> findimageoverlaps-> autoseed ?
If so, did you notice an issue with control points not being seeded in polygons that spanned the prime meridian?
QUOTE (Brian Swift @ Nov 20 2021, 09:32 AM)
I guess I had the wrong impression - that MSSS produced the data/images for the missionjuno site.
We do. I didn't say who I complained to, but it was the people at MSSS who generated these files.
QUOTE (mcaplinger @ Nov 20 2021, 03:29 PM)
We do. I didn't say who I complained to, but it was the people at MSSS who generated these files.
My bad. Looks like updated versions of the Ganymede images with corrected metadata were produced at the end of August and posted to missionjuo.
FWIW I've uploaded ISIS Control Networks for the PJ34 Ganymede images to https://doi.org/10.5281/zenodo.6377926
The initial network has 184,659 control points and 369,318 control measures (2 measures per control point).
Combining measures and extracting control points with 4 or more measures yields a network with 16,709 control points and 75,197 control measures.
The initial network has 184,659 control points and 369,318 control measures (2 measures per control point).
Combining measures and extracting control points with 4 or more measures yields a network with 16,709 control points and 75,197 control measures.
From AGU fall meeting (December 2021):
"JIRAM data acquired in PJ34 yielded unprecedented pixel resolution values between 0.25 and 0.61 km/px (average value 0.36 km/px), which is 92 times better than the previous flyby and 3 to 7 times better than the most resolved hyperspectral image ever acquired in the past by the Galileo/NIMS instrument at Ganymede. "
Any idea when these data will be published online ? Usually JIRAM images are published online rather quickly and the Ganymede flyby took place one year ago.
Best regards,
Marc.
"JIRAM data acquired in PJ34 yielded unprecedented pixel resolution values between 0.25 and 0.61 km/px (average value 0.36 km/px), which is 92 times better than the previous flyby and 3 to 7 times better than the most resolved hyperspectral image ever acquired in the past by the Galileo/NIMS instrument at Ganymede. "
Any idea when these data will be published online ? Usually JIRAM images are published online rather quickly and the Ganymede flyby took place one year ago.
Best regards,
Marc.
The raw data from this flyby was released some weeks ago. These Ganymede images (calibrated version; raw is also available) can be found here:
https://atmos.nmsu.edu/PDS/data/PDS4/juno_j...brated/orbit34/
This is an example of quick and dirty processing of one of these images, enlarged by a factor of 2:
Click to view attachment
The images are interesting but not particularly photogenic.
https://atmos.nmsu.edu/PDS/data/PDS4/juno_j...brated/orbit34/
This is an example of quick and dirty processing of one of these images, enlarged by a factor of 2:
Click to view attachment
The images are interesting but not particularly photogenic.
I haven’t spent much time looking at the Ganymede JIRAM data. At first I thought that the images were hopelessly smeared, but a quick comparison with the JunoCAM data does seem to suggest that they are more useful than I thought.
Click to view attachment
Click to view attachment
Thanks Volcanopele for the information and for the link,
Yes the JIRAM pics are indeed very smeared, I expected a better resolution. However, they should be fine for studying surface composition. But I think I will have to wait for the journal articles to get more information. JIRAM covered the boundary between the north polar cap, which is bombarded by radiation, and the equatorial belt, which is protected by the Ganymede intrinsic magnetic field, and I expected spectacular views of that boundary.
Best regards,
Marc.
Yes the JIRAM pics are indeed very smeared, I expected a better resolution. However, they should be fine for studying surface composition. But I think I will have to wait for the journal articles to get more information. JIRAM covered the boundary between the north polar cap, which is bombarded by radiation, and the equatorial belt, which is protected by the Ganymede intrinsic magnetic field, and I expected spectacular views of that boundary.
Best regards,
Marc.
QUOTE (volcanopele @ Jul 22 2021, 12:38 PM)
If you are me and are suspecting that some remaining issues are due to the USGS global mosaic being... less than perfect when it comes to using it for geometric control, there is a new controlled global mosaic produced for the JUICE mission:
https://www.sciencedirect.com/science/artic...032063321001495 (article is open-access)
Same DLR group have incorporated the JunoCam PJ34 Ganymede imagery into an updated mosaic.https://www.sciencedirect.com/science/artic...032063321001495 (article is open-access)
There was a session on it at EPSC2022 session Updated Ganymede Mosaic from Juno Perijove 34 Images
Updated mosaic downloads available at https://janus.dlr.de/publications/ganymede/...osaic_Juno.html
A lot of good stuff published in Geophysical Research Letters:
https://agupubs.onlinelibrary.wiley.com/doi...-8007.GANYMEDE1
Enjoy.
Best regards,
Marc.
https://agupubs.onlinelibrary.wiley.com/doi...-8007.GANYMEDE1
Enjoy.
Best regards,
Marc.
Excellent stuff! The Stellar Reference Unit paper was especially interesting.
Shame they only got one image.
P
Shame they only got one image.
P
I was just at the annual American Geophysical Union meeting. Preliminary results for the the Europa flyby were presented (assume papers like those just published for the Ganymede flyby will be available for Europa in a yearish).
Two key highlights:
1) No plumes were detected during this flyby with this set of instruments
2) The microwave profiles of the interior ice structures of Ganymede and Europa are very different. The presenters noted that at one frequency, the microwave results for Europa were consistent with a homogeneous transition layer to water but that MUCH more work was needed to interpret the data.
So, stay tuned.
I was also impressed with the quality of the images from JunoCam, which was never designed for satellite imaging or mapping.
Two key highlights:
1) No plumes were detected during this flyby with this set of instruments
2) The microwave profiles of the interior ice structures of Ganymede and Europa are very different. The presenters noted that at one frequency, the microwave results for Europa were consistent with a homogeneous transition layer to water but that MUCH more work was needed to interpret the data.
So, stay tuned.
I was also impressed with the quality of the images from JunoCam, which was never designed for satellite imaging or mapping.
QUOTE (vjkane @ Dec 17 2022, 02:29 PM)
I was just at the annual American Geophysical Union meeting. Preliminary results for the the Europa flyby were presented (assume papers like those just published for the Ganymede flyby will be available for Europa in a yearish).
Two key highlights:
1) No plumes were detected during this flyby with this set of instruments
2) The microwave profiles of the interior ice structures of Ganymede and Europa are very different. The presenters noted that at one frequency, the microwave results for Europa were consistent with a homogeneous transition layer to water but that MUCH more work was needed to interpret the data.
So, stay tuned.
I was also impressed with the quality of the images from JunoCam, which was never designed for satellite imaging or mapping.
Two key highlights:
1) No plumes were detected during this flyby with this set of instruments
2) The microwave profiles of the interior ice structures of Ganymede and Europa are very different. The presenters noted that at one frequency, the microwave results for Europa were consistent with a homogeneous transition layer to water but that MUCH more work was needed to interpret the data.
So, stay tuned.
I was also impressed with the quality of the images from JunoCam, which was never designed for satellite imaging or mapping.
From the press conference here were the microwave radiometer images for the two moons
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.