Add false color and rotate channels in place

[arcdarcd]

Adds an attempt to colorize the image using data from both channels. Based on the algorithm by enigmastrat.

I've had some good results for images where contrast adjustment was based on telemetry:

For other input files (such as argentina.wav), it messes things up (maybe the wav file was normalized beforehand?):

It kinda works when using histogram equalization:

For the future, maybe it's a good idea to show some sliders for the ice / grass / water / dirt threshold values on the UI and let the user tweak the image if it looks wrong.

There are some things I'm not really happy about (cloning the image to get a reference to IR channel while holding a mutable reference to the image for the visible channel). Maybe you have some suggestions as well.

[arcdarcd]

Btw, I've had great results with the wav files from here: http://www.fredvandenbosch.nl/satellites_WAV.html I'm also curious how other peoples' images look. 😄

[arcdarcd]

The values for the width of the sync / deep space / telemetry and image data bands are from here:

[arcdarcd]

I also noticed we can rotate the channels in place, saving the memory for a new allocation. There are some offsets I had to adjust (1px wide), not sure where those came from, but the rotated image would not align into place otherwise, it would "bite" a piece (1-2 pixels) out of the telemetry band.

I'll try and figure out why this happens.

[martinber]

You are the best! I'm going to look at this later with more time

For the future, maybe it's a good idea to show some sliders for the ice / grass / water / dirt threshold values on the UI and let the user tweak the image if it looks wrong.

Yes! I don't know if I wrote that somewhere or if you read my mind

[martinber]

Some images for reference, let me know if you want some WAV:

# Mine

## gqrx_20180917_204712_137100000 From telemetry:  Histogram equalization:  # gqrx_20181222_203941_137100000 From telemetry:  Histogram equalization:  # gqrx_20190131_211722_137097000 From telemetry:  Histogram equalization: 

---

# I don't remember where I got this from

From telemetry:  Histogram equalization: 

---

# Provided by users to test the map overlay

## By BGNLouie From telemetry:  Histogram equalization:  ## By nosduh2 From telemetry:  Histogram equalization:  ## By samarrangepas From telemetry:  Histogram equalization:  ## By KiwiEntropy From telemetry: Histogram equalization: ## By budude2 From telemetry:  Histogram equalization:  ## By K2SDR From telemetry: Histogram equalization: ## By K6KZO From telemetry: Histogram equalization: ## By TheLAX18 From telemetry: Histogram equalization:

[martinber]

Seeing the output images from several WAVs, I'm seeing that this method works only in daytime passes when the surface is completely illuminated, and it makes sense.

Before I forget. SatSignal uses a different approach: color look-up tables, where the x axis is temperature (from -40to 60) and the y axis is pixel brightness (see https://www.satsignal.eu/software/satsignal_clut.zip). I don't know how it calculates the temperature, and we should be a little careful with licensing issues if we take ideas from there

[arcdarcd]

Hi, thanks for the feedback!

... But when using histogram equalization, we should do a telemetry contrast adjustment, colorize and then do histogram equalization. This is too much work, so I would add a note to the GUI saying that telemetry contrast adjustment is recommended, like you did in the command-line option

Unfortunately histogram equalization after colorization does not yield good results:

Sample output


I expect this happens because it's a synthetic image, and the histogram fills only some regions (based on the water, vegetation, clouds thresholds), and when we equalize each channel separately, it leads to overblown red, blue and in-between.

I tried this on a separate branch here, if you want to take a look: https://github.com/Arcadie/noaa-apt/blob/c60c439bd108725acc570634374bb5d6367da3bd/src/processing.rs#L93

But maybe equalization is not the right tool for the job, and another algorithm should be used. Please let me know what you think.

The constants should be specified in the settings toml file

I've added this, and also updated the documentation to include the correct path to the settings file for MacOS.

At least three values should be editable in the GUI: the 13000, 35000 and 27000. It's not necessary to add command-line options, these users can just edit the settings toml file

Do you mind adding these to GUI? I'm struggling with the glade template and I'm unfamiliar with the available GTK widgets. Do you edit the file manually or use some kind of IDE like https://glade.gnome.org/ ?

13000, 35000 and 27000.

Since we're working with u8, I'm using 50, 137 and 105 instead. (please see default settings file).

Please let me know if I've missed something.

[martinber]

I've added three sliders to the GUI. It's working quite well, the default value for each slider is marked with a small line

And yes, I'm using Glade.

Also I forgot to explain better the problem with histogram equalization in color images: It can't be done for each R G B channel separately, it should be done in the "luma" channel and keep the "chroma" untouched. Or something like that, I didn't check if I'm right

I checked the code and I didn't see anything strange apart that you are changing the constants to operations and back to constants or something like that. Either way is OK for me

Also I changed the internals of how the thresholds configured in the settings propagate until they reach the processing() function, now there is a ColorSettings struct. I don't really like it but it was necessary to make the values modifiable from the GUI

Do you want me to merge this PR and then push my code to master? Or do you want me to create a new branch and do a PR to your Arcadie:false-color?

[arcdarcd]

That looks good!

... it should be done in the "luma" channel and keep the "chroma" untouched.

Oh, you're absolutely right! I should have done the RGB -> YCbCr, equalized the Y channel, and convert back to RGB. (source). I'll take another stab at this one when I have some time, as it sounds promising.

... you are changing the constants to operations and back to constants

I reverted because I like seeing the actual value when I hover over the constant name 😄

Do you want me to merge this PR and then push my code to master? ...

Sure, I think this would be the easiest!

One thing to consider is if the default values are "good enough" for the average quality pictures (low contrast, noise) or they need some tweaking. Either way, I'm happy to have this merged! 😃