Colour Temperature

[abassign]

It seems clear that the colors of FGFs are often too cold, not because they are not the right ones, but because often the display media has a color temperature incorrect or effectively the colors are too cold.

This is an example:



I tried to change the color temperature with GIMP:



Honestly I think the result is improved.
I thought how the filter brightness, is it possible to insert a color temperature filter? This way everyone does as it wants, without fear of criticism or the confrontation between diffrenti tastes.

"De gustibus non est disputandum" ( https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum )

[ludomotico]

The final color (value and brightness) your eyes see is a complex process with tons of variables involved: the color requested by FlightGear, the color profile of your monitor, the viewing angle and the lighting conditions of your room. For example, many of the cheap monitors we use (specially laptop screens) are slightly shifted to blue. There is a reason for designers to spend 500€ in a high profile NEC monitor, when you can buy DELL monitors for less than 100€.

The color temperature your monitor represents could be modified inside FlightGear with a filter, but since it is a parameter so easy to set outside FlightGear without any cost in terms of processing power or coding complexity, I cannot see any reason to include this setting inside the simulator. Use your monitor settings, your video card settings or an external application to control the color temperature of your monitor (up to the limit your monitor can represent, of course)

For example, you seem to be using some kind of Linux. There is a little utility named redshift:

Code: Select all

redshift -O 4820


sets the color temperature to 4820K (redshift assumes your monitor is calibrated to 6500K, which it is not true for most laptop screens)

Other examples:

Code: Select all

# sets color temperature to 4820K, with an additional gamma correction of 1.2 for those that complain about "scenery is too dark at night"
redshift -O 4820 -g 1.2
# reset changes
redshift -x


redshift also runs as a daemon, changing the color temperature depending if it is daytime or night. Check the manual in case you are interested in redshift.

You can run this command at any moment (before running FlightGear or in the middle of a flight) to set the color temperature that pleases your eye.

[abassign]

My monitor costs about $ 500 , has the color control etc ... you'd be right ... if the images I have attached photographs had been taken from the monitor , but they are screen-shot ( F3 ) !
The problem is how FGFS manages the colors that tend to be very cold , the two photos see what FGFS direct produced and I think that will give me reason that the latte is much closer to what you see in reality.
Certainly at 20000-30000 feet the colors are colder ( there is a higher percentage of UV ), but at 1,000 feet with clear skies is different...

Unfortunately do not know how Fgfs manages the color temperature, I think there is a relation with the time of day and I hope that there is a relationship with the cloud cover. I do not know if there is also a relationship with the flight altitude (the higher the aircraft, the greater the presence of the UV component, and then the colors are colder ie color temperature is higher). My impression is that during a clear day (with a few clouds) the ambient light is too cold, while at sunset is too hot especially at hight altitude. Dawn seems ok. All this means that we should have a "color profile" table that allows you to change colors in the different stages of the day and cloud cover and altitude. I do not think that it is difficult to obtain and provide a clearer calibrate the ambient light. This color profile is useful to be inserted between the permanent parameters.

"De gustibus non est disputandum" ( https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum )

[daveculp]

I think the second screenshot definitely looks better. I need to experiment with that here.

[abassign]

I think the second screenshot definitely looks better. I need to experiment with that here.

It is indeed just that, but the amazing thing that I got the result using the PNG image file type from the screen-shot. This may mean that in the picture there is already all the information, how do you see the effect of diffusion of the sky is in the second image much more real. At this point I made "on the fly" a couple of tests with GIMP and RAW-Therapie and can confirm that the problem is too flat in the return of the full color range which allows FGFS.

From GIMP (Retinex filter)



From RAW-Therapie HDR filter



So the problem is how do I transfer the 256 gray levels per channel color produced by the rendering system of FGFS to my monitor and then to my eye! It is not a matter of color temperature, that's just an imbalance, just simply apply an appropriate HDR filter and how it shows the image obtained with RAW-Therapie, it all comes back ok So the effect "too blue" is just a kind of fake that can be corrected through an algorithm HDR or with an appropriate balance which compresses the displayed colors. Of course, applying the filter it can be made within the application limiting this way any artifacts always present in HDR.

A HDR by opengl is in this example: http://learnopengl.com/#!Advanced-Lighting/HDR

[erik]

Before you do anything it might be good to determine which renderer you use:

Is it the default?
Is it ALS?
Is it ALS with realistic visibility? (can be set in Detailed weather).

Erik

[abassign]

Ii ALS with max Quality settings, Nvidia 870 with 6GB. I try with Rembrand, but the results is similar. The time is 10AM in summer season. The west is in the left of the picture. The detail weather is active and is in the realistic visibility.

[Catalanoic]

No HDR under ALS implemented yet. its just a postprocessed picture with GIMP. It would be cool to have the same effect with/without ALS in real time under FG.

[erik]

Strangely enough I get about the same results in FlightGear as the post processed image but I see the difference in the screenshots in the forum.

Erik

[Thorsten]

No HDR under ALS implemented yet.

As technique to dump lights into a buffer and post-process the scene, no. As concept rendering the correct intensity when multiple lights illuminate the same surface - definitely yes.

See Light intensity for how to do the math from perception to intensity space (in my view working in perception space is more elegant than a buffer, but to each his own).

As for color temperature - I understand that's largely a property of the monitor. Why is adjusting color temperature in the monitor settings not the proper way to take into account the specifics of your monitor?

[abassign]

As for color temperature - I understand that's largely a property of the monitor. Why is adjusting color temperature in the monitor settings not the proper way to take into account the specifics of your monitor?

Image with redshift command: redshift -O 4820 -g 1.2


Image without redshift command:


I see no difference, of course, the F3 key to Fgfs print the image produced internally by the program, not what you see on the monitor, and assure you that with the active command "redshift -O 4820 -g 1.2" was really all pink ...

So we return to the basic problem, Fgfs produces a very rich color image that does not fit the limitations of monitor display, that's why the image so "sad." I think that the introduction of a HDR mechanism that has nothing to do with the image formatting technique is definitely the best way to make everything brighter.

Sometimes it takes very little to make an incredible leap Without disturbing particular things and the same mechanism can satisfy both ALS, which Rembrandt (who suffers from the same problem). I wish someone would do the test, just to understand, because the HDR functionality in OpenGL is well documented.

Here there is something that can be useful

http://developers-club.com/posts/238425/

[Thorsten]

I see no difference, of course, the F3 key to Fgfs print the image produced internally by the program, not what you see on the monitor

Yes - but then again, in your first example screenshots, the first is the one which looks better to me rather than the second one - because they all appear different on my monitor, so I don't see the same things you do (the fact that 'out of the box' appears best to me is of course no surprise as ALS likely has a preference for my monitor settings for obvious reasons...)

See, if you shift the rgb values of the frame buffer to generate a screenshot you really like on your monitor settings, you're making it wrong for someone with a different monitor.

Whereas if we all do the same rgb values in FG and correct out monitor color temperatures ourselves, we'll all judge the same screenshots most realistic (well, if we all compensate for the monitors the same way, there's an element of taste).

I know, it's hard to imagine because you always see the differences on your equipment and imagine everyone else sees the same thing - but we do not.

So we return to the basic problem, Fgfs produces a very rich color image that does not fit the limitations of monitor display, that's why the image so "sad."

Yes - so you set your monitor to compensate for its characteristics, and you see it all okay. I set my monitor in a different way to compensate for its different characteristics, and I see it all okay, and in fact we see it the same way.

Whereas if you change your rgb values and not your monitor mapping function, I start to wonder why all your screenshots look widely unrealistic if I use a correct monitor mapping for my equipment.

What precisely is the problem with compensating for hardware characteristics hardware/driver side - it's how this is intended to work?

I think that the introduction of a HDR mechanism that has nothing to do with the image formatting technique is definitely the best way to make everything brighter.

I guess you didn't read what I linked or didn't understand it - ALS has an HDR filter, just not implemented as a buffer and post-processing. You can't put a second one on top, because that'd assume ALS outputs intensity space - which it does not, it outputs perception space.

I think changing your monitor settings is the best way to compensate for any effect that's a characteristic of your monitor.

[bugman]

On my laptop, the second image looks better. But on a tablet, the first one does If I put them side-by-side, image 1 on the tablet looks almost identical in colour to image 2 on the laptop! Abassign, what monitor do you have?

Regards,
Edward

[abassign]

"De gustibus non est disputandum" ( https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandum )

Unfortunately here we're talking about a topic that is often linked to personal tastes and therefore difficult to argue.
Objectively it is not a color temperature problem, as I have already pointed out!
A suitable monitor configuration, which I find truly complicated as the computer is also used for other things that it is not only to fly a plane into FGFs, could solve part of the problem, but not the fact that the amount of color information of FGFs is at least 4 times higher (64 vs 256) to the eye's ability to discern colors. You need to compress too many levels of color in less levels, this is what makes the HDR.



This is an example which shows that changing the display settings may serve some purpose, but it is not the same thing! As you see, the problem is that the original image has a lot more blue than green and even less to red, are not balanced! This is the reason that the image looks cool, I'm sorry, but this is a defect not a quality! If I go to see well-balanced photographic images I will see that the three curves to the right end (high-lights) finish together. In this case you see a picture with an obvious unbalance (Blue finished much more to the right of the green and the green to the right of the red) that is NOT due to the monitor, but only from an incorrect color balance that generated the engine rendering! Of course if an image is all blue, we will have the dominant blue curve, but if it is well balanced, it will be seen, although smaller, the curves of green and red that always end with the blue.

Of course you can correct with the monitor, but the fix is only fictitious and leads to unbalance the colors of all the applications in the system, including the menu;) the canvas etc ... sucks!
The easiest thing is to correct the defect, because that is the right name!

In the picture "B" you see the HDR image obtained from the first, not only is more balanced because I changed the color temperature, but now the curves are missing peaks in order to reduce the spatial frequency and thus improve the visual perception. The HDR is not a whim, but a powerful tool for generating an interface between the application and the eye of the observer.

I wish you would avoid saying things without checking carefully, in this case it seems clear that there is a problem and its solution could be simple and handy.

This is another example ...

Original image with blue high light dominant



Correct image:



Obviously if you increase the flight altitude increases the more dominant blue and in this case has a sense to move the blue curve further to the right, ie to increase the color temperature, but always with great care since the eye is not a camera

[Thorsten]

As you see, the problem is that the original image has a lot more blue than green and even less to red, are not balanced!

The picture shows about 50% sky, which to me knowledge is blue (yep, looking outside, that's actually the case), you have a plane with a blue livery, the distant haze is blue due to Rayleigh scattering - so I'd be surprised if the picture would not be dominated by blue.

Reality isn't balanced, if you take a picture of a summer day over the ocean, it's going to be dominated by blue and balancing colors would be silly.

(case in point, your post-processes shot looks completely overexposed to me, especially the whiteout of the horizon).

Light (rgb) values aren't random choices, they're extracted from series of calibrated photographs for instance - if the photograph represents reality sufficiently well (which is the case unless at low light) and FG is made to match the photograph, FG (rgb) values represent reality sufficiently well.

It would follow that your monitor then must show both FG and the photograph in the wrong way (which is quite possible) or if calibrated well both FG and photograph nicely. But since the light (haze, skylight,...) (rgb) values are derived that way, altering them is a bad idea.

I wish you would avoid saying things without checking carefully, in this case it seems clear that there is a problem and its solution could be simple and handy.

Indeed - go calibrate your monitor, and everything will be fine