Better false color

[martinber]

I'm leaving information about how to improve false color images, in case someone (or me) decides to improve it someday

This page explains the methods available in WXtoImg

xwxapt (GPLv3) by Neoklis Kyriazis (5B4AZ) has a false color method similar to #25 implementation. This is the relevant part of the configuration file:

### Color maps for pseudo-colorization ###
#
# Each row in the table specifies a range (pair) of gray values
# with a corresponding range of Red, Green and Blue values.
#
# SOME RULES!!
# All Values between 0 and 255
# At least one Gray From = 0
# At least one Gray To = 255
# All gray values (0-255) must be included
# Max 6 entries (6 rows) per map
#
#       NOAA Channel A (Day-time)
# Number of colormap ranges (rows) (max 6)
5
#
# Gray          Red          Green        Blue
# From  To      From  To     From  To     From  To
  0     40      0     0      0     0      175   255
  41    80      40    80     32    64     26    52
  81    130     0     0      110   220    0     0
  131   220     130   220    104   176    84    140
  221   255     220   255    198   255    160   220
#
# White (clouds) threshold. If a pixel's value is above this
# threshold in a NOAA B channel image, it is considered as part
# of cloud and its value is entered in colorized image. It applies
# only to NOAA satellite images, for Meteor it is a dummy value.
220

SatSignal uses a different approach: color look-up tables, where the x axis is temperature (from -40 to 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 ideas are taken from there

[JoshuaKimsey]

Here's an idea I had for making false color a little bit more accurate. Based on the map boundaries, could hard coded coloration values be set? That then can be modified based on data received from the satellites. That way instead of the program trying to determine from scratch what colors go where, you can use the default coloration to set a baseline. This way also when the different values are adjusted, they are working between B/W and the base color map, which should prevent the wild colors you can get from playing with the color levels.

I am not overly familiar with Rust, or else I would try and code this change myself. I just thought I'd suggest it here as an alternative to the current system and proposed solutions above in case it turned out to be a better way of creating a colored image.

[martinber]

Yes, that would work really well when the map overlay is correctly aligned with the image. Right now, to draw the map lines the code calculates the mapping between (latitude, longitude) -> (x, y) in the image, for this to work we need to do the inverse, that is to go from each (x, y) -> (latitude, longitude) to see if each pixel is water or not.

Also I don't remember which program went even further and colorized the image according to a color image of the earth like this one. In that case one can get the latitude and longitude of each pixel and set a hue or color according to that image

[martinber]

Now there are two more projects from where ideas can be stolen:

• https://github.com/Xerbo/aptdec mentioned on Precipitation overlay, temperature image (feature) #50. Apparently has several palettes taken from WXtoImg
• https://github.com/zeke800/apt_color which is on issue Add more color palettes #49

[martinber]

I implemented color palettes as in https://github.com/Xerbo/aptdec. In conclusion, now the possible ways to improve the false color are:

• Add more palettes
• Add sliders in the GUI that will stretch the palette, which will allow to fine-tune a bit more the results
• Create a GUI to modify palettes. For example generate the 256x256 images from gradients (too much work...)
• Create another new false-color system which is based in map coordinates (too much work...)