IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
Beginner level projection
Brian Swift
post Nov 26 2019, 10:33 AM
Post #31


Member
***

Group: Members
Posts: 103
Joined: 18-September 17
Member No.: 8250



QUOTE (adamg @ Nov 25 2019, 01:43 PM) *
Anyone have any good advice on scaling the RGB to give the closest to true color? I tried these two [0.487, 0.408, 0.172] [0.444, 0.341, 0.155] from Brian's flow and I get a strong orange hue.

My colorBalance values specify the upper end of the range of the input components, so you'd divide by them.
When rescaled, they are similar to Bjorn's.
1/colorBalance/Min[1/colorBalance] = {1., 1.193, 2.8378}
Go to the top of the page
 
+Quote Post
Brian Swift
post Nov 26 2019, 10:54 AM
Post #32


Member
***

Group: Members
Posts: 103
Joined: 18-September 17
Member No.: 8250



QUOTE (Bjorn Jonsson @ Nov 25 2019, 03:01 PM) *
I usually multiply by [1, 1.12, 2.3] after decompanding. I'm surprised that [1, 1, 0.95] seemed close - are you decompanding the images before applying these?

I've been wondering, is your natural color process more involved than a scaling?
And also how you derived your color balance values?

My current (too blue) values come from the median of my flat fields. Early on they came from the max values from an image of Europa.
Go to the top of the page
 
+Quote Post
adamg
post Nov 26 2019, 12:26 PM
Post #33


Junior Member
**

Group: Members
Posts: 20
Joined: 31-October 19
Member No.: 8699



Sounds like I'm miles off for some reason. I used the RDR product assuming it had already been decompanded, I recall I have a range to 4kish so it has certainly been through something.
Go to the top of the page
 
+Quote Post
fredk
post Nov 26 2019, 02:48 PM
Post #34


Senior Member
****

Group: Members
Posts: 3955
Joined: 17-January 05
Member No.: 152



QUOTE (Brian Swift @ Nov 26 2019, 11:54 AM) *
I've been wondering, is your natural color process more involved than a scaling?
And also how you derived your color balance values?

In particular, shouldn't a colour space matrix transformation to, eg, sRGB be performed from the raw colour channels? That generally can't be approximated by a simple scaling of each channel.
Go to the top of the page
 
+Quote Post
adamg
post Nov 26 2019, 06:14 PM
Post #35


Junior Member
**

Group: Members
Posts: 20
Joined: 31-October 19
Member No.: 8699



The RDR data set says "For planetary targets, these values are then scaled such that a white surface at the solar distance at the time of imaging and with the commanded exposure time would have a pixel value of 10,000 data numbers.", so I'm assuming the blue already got scaled before I got to it. I probably ought to use the EDR data set if I want to actually know how it got scaled.

Regarding sRGB, it seems sensible to me that you can scale the linear raw IMG which is what I'm doing but should I be trasforming to sRGB at some point?
Go to the top of the page
 
+Quote Post
mcaplinger
post Nov 26 2019, 09:44 PM
Post #36


Senior Member
****

Group: Members
Posts: 1903
Joined: 13-September 05
Member No.: 497



QUOTE (adamg @ Nov 26 2019, 10:14 AM) *
The RDR data set says "For planetary targets, these values are then scaled such that a white surface at the solar distance at the time of imaging and with the commanded exposure time would have a pixel value of 10,000 data numbers."

Well, I wrote that, and I don't know how to make it any clearer than that.

"Natural color" requires you to model the human eye response. The Junocam RGB filters are not much like the human eye response (unlike the Bayer pattern used for MSL) so one would have to do something, but I'm not sure what.

In case you care, the EDR-RDR scaling code (after decompanding) is

CODE

ref = [111, 4766, 10331, 12669] # ch4, blue, green, red
scale = 16.3
sunrange /= 1.5e8 # km to AU
ex = float(i.info["exposure"])*int(i.info["tdi"])

dnout = int(dn*scale/ex/(ref[f]*(5.2)**2/sunrange**2)*10000)


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post Nov 27 2019, 04:47 AM
Post #37


Member
***

Group: Members
Posts: 103
Joined: 18-September 17
Member No.: 8250



QUOTE (adamg @ Nov 26 2019, 10:14 AM) *
Regarding sRGB, it seems sensible to me that you can scale the linear raw IMG which is what I'm doing but should I be trasforming to sRGB at some point?

My colorBalance scaling is applied to decompanded raw non-calibrated image values. I usually use the "raw" files from the missionjuno.swri.edu, but
have also used PDS EDR files. I haven't worked with the RDR files.

I don't apply a linear to sRGB conversion unless I want to produce a natural-ish contrast image. Not performing the linear to sRGB makes the files from my pipeline display with more contrast.
Go to the top of the page
 
+Quote Post
adamg
post Nov 27 2019, 11:30 AM
Post #38


Junior Member
**

Group: Members
Posts: 20
Joined: 31-October 19
Member No.: 8699



Interesting, [1,1.23,2.66] I actually dropped my 0.95 so I think you nailed it.

mcaplinger, sorry I didn't spot your name on the technical report, that was pretty lazy of me! Congratulations on such a successful piece of hardware, as an electronics guy it's the camera itself that's got me interested, I've been very impressed.
Go to the top of the page
 
+Quote Post
Brian Swift
post Nov 27 2019, 06:59 PM
Post #39


Member
***

Group: Members
Posts: 103
Joined: 18-September 17
Member No.: 8250



QUOTE (adamg @ Nov 27 2019, 03:30 AM) *
...as an electronics guy it's the camera itself that's got me interested, I've been very impressed.

Mike will correct me if I'm wrong, but I believe this is the hardware info for the CCD https://www.onsemi.com/pub/Collateral/KAI-2020-D.PDF

This and various other JunoCam reference links are at the top of the Juno24u notebook on GitHub.
Go to the top of the page
 
+Quote Post
adamg
post Dec 9 2019, 02:25 AM
Post #40


Junior Member
**

Group: Members
Posts: 20
Joined: 31-October 19
Member No.: 8699



How are peoples' inter frame delays looking?

In the attached images for JNCE_2016239_01C06109_V01 I added the recommended 1ms inter frame delay (right) and also tried 10ms (left) that got it looking better but not perfect. It's probably not right adding this accumulating delay and seems more likely to be some offset between the three colours instead which is why I ask.

I did see jitter mentioned but I tried a couple of images and the error seems similar between them so it does seem systematic.
Attached thumbnail(s)
Attached Image
Attached Image
 
Go to the top of the page
 
+Quote Post
mcaplinger
post Dec 9 2019, 05:50 PM
Post #41


Senior Member
****

Group: Members
Posts: 1903
Joined: 13-September 05
Member No.: 497



QUOTE (adamg @ Dec 8 2019, 06:25 PM) *
How are peoples' inter frame delays looking?

If we had ever seen anything that would make the interframe delay different than the header value plus 1 msec, we would have said that, but we haven't.

AFAIK nobody has ever said anything about jitter on the interframe delay, only on the start time.

I don't have any measurements for the specific image you posted, but for PJ1-6160 the time offset was about 1 pixel different from the reported values. But again, that's a start time offset, not an interframe delay change.


--------------------
Disclaimer: This post is based on public information only. Any opinions are my own.
Go to the top of the page
 
+Quote Post
Brian Swift
post Dec 9 2019, 06:15 PM
Post #42


Member
***

Group: Members
Posts: 103
Joined: 18-September 17
Member No.: 8250



QUOTE (adamg @ Dec 8 2019, 06:25 PM) *
How are peoples' inter frame delays looking?

I add 0.001035 sec to the INTERFRAME_DELAY value. (This is the value ifdAdjustment in selectedCameraParams in my pipeline.)
The extra 35us beyond the recommended 1ms is probably only relevant to align features that appear in first and last frames of a 360 image.

(BTW, the earth flyby image JNCE_2013282_00C00102_V01.IMG is a good exercise of pipeline robustness)

QUOTE
In the attached images for JNCE_2016239_01C06109_V01 I added the recommended 1ms inter frame delay and also tried 10ms that got it looking better but not perfect. It's probably not right adding this accumulating delay and seems more likely to be some offset between the three colours instead which is why I ask.

I did see jitter mentioned but I tried a couple of images and the error seems similar between them so it does seem systematic.

The ~20ms jitter mentioned in juno_junocam_v03.ti just applies to the START_TIME.
Several pipelines perform some type of limb fit to produce a refined start time estimate.
Go to the top of the page
 
+Quote Post
Bjorn Jonsson
post Dec 9 2019, 06:29 PM
Post #43


IMG to PNG GOD
****

Group: Moderator
Posts: 2053
Joined: 19-February 04
From: Near fire and ice
Member No.: 38



The value you add to the interframe delay should always be 1 ms (or close to 1 ms) as Mike said. If you need something like 10 ms there is a bug somewhere in your code. Small deviations from 1 ms are possible due to various factors (limb position uncertainties in especially the hi-res images, possible variations in the haze or cloudtop altitude, tiny variations in Juno's spin rate etc.). I have never gotten values lower than 0.5 ms or higher than 1.5 ms (and I should add that if I get 0.5 or 1.5 that's a big deviation - I usually consider values like these with some suspicion).

I usually determine the start time, end time and interframe delay by measuring the position of Jupiter's limb in the first and last framelets where a significant part of Jupiter's limb is visible. These measurements are then used to automatically determine the actual image time of these two framelets, the interframe delay and from this the start time.

If everything is working correctly the color channel alignment of the resulting image should be close to perfect - maybe a small error (1 pixel or 2 at most) near the image edges in a few cases.
Go to the top of the page
 
+Quote Post
adamg
post Dec 10 2019, 11:20 PM
Post #44


Junior Member
**

Group: Members
Posts: 20
Joined: 31-October 19
Member No.: 8699



Thanks guys, apparently I'm a goose. I hard coded the inter frame delay from that P8 image I was looking at before (my code is only a couple hundred lines long so it's a bit bare bones) and this one is different by 8ms.
Go to the top of the page
 
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic

 



RSS Lo-Fi Version Time is now: 13th December 2019 - 05:47 PM
RULES AND GUIDELINES
Please read the Forum Rules and Guidelines before posting.

IMAGE COPYRIGHT
Images posted on UnmannedSpaceflight.com may be copyrighted. Do not reproduce without permission. Read here for further information on space images and 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 a project of the Planetary Society and is funded by donations from visitors and members. Help keep this forum up and running by contributing here.