JunoCam projection code aimed at mosaicing |
JunoCam projection code aimed at mosaicing |
Dec 15 2021, 08:08 PM
Post
#1
|
|
Newbie Group: Members Posts: 4 Joined: 19-November 21 Member No.: 9121 |
Hello!
I wanted to share a code that I've been working on to project and mosaic JunoCam images. The code is written in Python and uses the SPICE library: https://github.com/ramanakumars/JunoCamProjection. I thought people in this forum might be interested in using it or comparing with existing pipelines. The goal of this code is to generate mosaics by stacking multiple images for a given perijove pass with little manual labor. An example of both the projection and the mosaicing process is in the examples folder. Here is an example of a mosaic from PJ27 data: Ramana |
|
|
Dec 16 2021, 03:39 PM
Post
#2
|
|
Member Group: Members Posts: 223 Joined: 13-October 09 From: Olympus Mons Member No.: 4972 |
That is not bad! Though the color is a little too heavy on the blue, I am not sure if it is the program or the raw images causing that.
-------------------- "Thats no moon... IT'S A TRAP!"
|
|
|
Dec 16 2021, 07:49 PM
Post
#3
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
I wanted to share a code that I've been working on to project and mosaic JunoCam images. Very nice, the code is very clean and readable. Seems like you have a lot of blending artifacts in the mosaic, only to be expected. I haven't really examined your blending method in detail, it's working really well to hide gross seams but there's feature doubling, I think, at small scales. This is a tough problem and I'm not sure what the best way to do it is that isn't very labor-intensive. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Dec 16 2021, 08:06 PM
Post
#4
|
|
Newbie Group: Members Posts: 4 Joined: 19-November 21 Member No.: 9121 |
Thank you!!
QUOTE Though the color is a little too heavy on the blue, I am not sure if it is the program or the raw images causing that. Yeah, that is an artifact of the color correction and histogram equalization. The code outputs a "raw" mosaic which goes through a color correction function. I think it should be possible to get better representations by post-processing the raw image directly rather than getting the output from the color correction step. I use the color correction function to de-haze the mosaic since I'm interested in uniform image representations across multiple perijoves, so my use case tends to be less aesthetic. QUOTE Seems like you have a lot of blending artifacts in the mosaic, only to be expected. Yes, and it's much more noticeable near the poles. I've been trying to figure out a way out of this. I fixed a lot of the artifacts a while ago by doing jitter correction (by fitting the limb of Jupiter in each image to find the start time offset). That might not be accurate enough for polar latitudes. I also think it's due to the changing resolution with latitude... I don't have a clear fix for that right now, except for doing lower resolution reconstruction. |
|
|
Dec 16 2021, 11:10 PM
Post
#5
|
|
Senior Member Group: Members Posts: 2511 Joined: 13-September 05 Member No.: 497 |
I fixed a lot of the artifacts a while ago by doing jitter correction (by fitting the limb of Jupiter in each image to find the start time offset). That might not be accurate enough for polar latitudes. I also think it's due to the changing resolution with latitude... I don't have a clear fix for that right now, except for doing lower resolution reconstruction. It's always tough to debug these sorts of things. You might compare what your code produces for a single framelet against what ISIS produces, if you can make the investment in time to install and understand ISIS. I would expect that if you are using reconstructed SPKs and all the correct up-to-date kernel files (spacecraft clock and leapsecond are very important for C kernel use), the residual errors would be maybe 2-3 pixels? As far as I could tell in a quick skim, you weren't applying the 61.88 msec start time bias described in https://naif.jpl.nasa.gov/pub/naif/JUNO/ker..._junocam_v03.ti but your limb offset should fix that if it's done correctly. -------------------- Disclaimer: This post is based on public information only. Any opinions are my own.
|
|
|
Dec 17 2021, 12:34 AM
Post
#6
|
|
IMG to PNG GOD Group: Moderator Posts: 2250 Joined: 19-February 04 From: Near fire and ice Member No.: 38 |
At least in my experience, 2-3 pixels is typical for residual errors.
This looks very promising. Do I understand correctly from the code/examples that in the PJ27 mosaic above you are using FFT to do the illumination correction? |
|
|
Dec 17 2021, 01:32 AM
Post
#7
|
|
Newbie Group: Members Posts: 4 Joined: 19-November 21 Member No.: 9121 |
QUOTE You might compare what your code produces for a single framelet against what ISIS produces That's a good point! I have worked with the ISIS package (and pysis) before but dropped it because it got a little cumbersome to update kernels. I'll check out what the differences are. QUOTE As far as I could tell in a quick skim, you weren't applying the 61.88 msec start time bias I add this when calculating the spacecraft ET for each framelet. Here, for example: https://github.com/ramanakumars/JunoCamProj...ojector.py#L254. The time_bias is 61.88ms pulled from the SPICE kernel pool. QUOTE At least in my experience, 2-3 pixels is typical for residual errors. This is in the original framelet projection, right? Is this with jitter correction? QUOTE Do I understand correctly from the code/examples that in the PJ27 mosaic above you are using FFT to do the illumination correction? Yup, that's correct. |
|
|
Lo-Fi Version | Time is now: 17th April 2024 - 11:31 PM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE COPYRIGHT |
OPINIONS AND MODERATION Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators. |
SUPPORT THE FORUM Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |