nullpainter / sanchez

False-colour geostationary satellite image compositor
Apache License 2.0
127 stars 9 forks source link

EWS-G1 settings for .json file #70

Closed creinemann closed 3 years ago

creinemann commented 3 years ago

Corrected after initial post changed from band 02 to 04

Using EWS-G1 GVAR imagery from Band 04 IR- Upped the brightness to 1.3 and changed the file name prefix to match the naming convention used by @Aang and @Zybichu to EWS-G12

// Preliminary EWS-G1 configuration { "DisplayName": "EWS-G1", "FilenamePrefix": "EWS-G14", "FilenameParser": "Goesproc", "Invert": true, "Longitude": 61.5, "Brightness": 1.3, "Crop": [ 0.01, 0.05, 0.0, 0.0

nullpainter commented 3 years ago

Thanks, Carl. To clarify, you note that the update is to EWS-G1_2_ but the JSON has EWS-G1_4_. Should this actually be EWS-G1_[0-9]_ to support all channels? If so, having separate non-inverted config is presumably also desirable.

Also, it could just be the old file that I have floating around, but I'm sure we can do a better job of the crop. Any volunteers?

image

creinemann commented 3 years ago

I would reccomend the EWS-G1[0-9] though currently there are only 1-5, and that photo is an old one from when I used the SSEC imagery which was cropped by them, and a gif. the current version with the latest EWS-G1 looks good

nullpainter commented 3 years ago

Okay, just refamiliarised myself with the EWS-G1 processing. To be honest, it leaves a bit to be desired right at the moment.

Firstly, we do need two entries in the Satellites.json - one with invert: false for channel 1, and the other for invert: true for channels 2-5.

Secondly, that brightness is too high for single-image rendering and results in some seriously blown highlights (see below). I know it's required for stitching. I'm wondering whether I'm going to have to think of a less brute-force / manual brightness method for blending images. In any case, I think I'm going to have to leave the brightness as it is for now.

Thirdly, yes - some serious crop work required.

And finally, I seem to be producing greyscale output images if the output is a .PNG (Unrelated to EWS - I just noticed. This seems to be a regression).

image

nullpainter commented 3 years ago

Secondly, that brightness is too high for single-image rendering and results in some seriously blown highlight

Actually, brightness adjustment does nothing (good) for single images, as we are already performing histogram equalisation. If I change it so Brightness is only read for stitching, we can have our cake and eat it.

Okay, one problem down...

creinemann commented 3 years ago

I experienced the B/W in .png creation as well. And I have two entries in the JSON file like this invert: false for channel 1, and the other for invert: true for channel 4. In your image above the only way I could get the white blowout was to adjust -S 0.3 and use this in the json and use ch01 // Preliminary EWS-G1 VIS configuration { "DisplayName": "EWS-G1", "FilenamePrefix": "EWS-G11", "FilenameParser": "Goesproc", "Invert": false, "Longitude": 61.5, "Brightness": 1.0, "Crop": [ 0.01, 0.05, 0.0, 0.0 ] } EWS-G1vis05km_02082021

nullpainter commented 3 years ago

Fixed in v1.0.18.