IMHO that’s not true, and we do a ton of interior lighting.
In fact the only way to get comparable pictures with the ones from other engines like Corona (with the physical sky) was to use one of the available physical sky addons out there, we used Real Sky, the one made by @nacioss, because it delivered a way better quality than other solutions.
If the defaults in Cycles would be enough, then the Photographer addon would not be needed and so popular.
I am a bit confused. I assumed the unaltered exposure level for this new sky map would give you overexposed, almost blank white picture at default exposure level of 0 only in exterior scenario around noon. I’d assume that if one had interior with not very large window, and used the new sky model without any changes to exposure in interior lighting scenario, it would not end up pitch white… ?
I’ve just edited my response, there was a typo in it.
How the new sky exposes indoors - of course that depends on the window size, time of day, albedo of interior walls,etc.
Yes, exactly. It just further invalidates the “Users would be confused by sky texture if it did not have the hardcoded under-exposure.”
In case of a sphere on a plane, yeah, they will probably see (almost) pitch white. But in case of interior scenario with lower albedo walls and small window, unaltered luminance of the sky texture may be just about right at default Exposure value of 0. So it’s all the less worth it to hardcode some sort of under exposure constant right into it in the name of “better UX”.
(BTW I know this wasn’t your argument, but Brecht’s one. I am just showing how many holes it has.)
So, at this point do we all disagree with the Brecht’s decision to hardcode the sky?
Or are there any other opinions/ideas to support it?
How did you come to this conclusion.
I always found cycles sun and sky to be incredibly useless personally, if I look at luxcore or octane how powerful the sun and sky system is by default, cycles looks like something is terribly wrong in that regard.
That’s because Cycles had no sun sky system until now. There was unusable, unfinished sky implementation but it was not connected to sun lamp in any way.
I think this confusion mainly stems from the fact that it’s named sun, which is a wrong name as it implies some sort of physical sun implementation. What’s called “Sun” in Blender is simply called “Directional Light” in most other software. It’s just meant to simulate a light source of infinite distance. It does not have any real world intensity by default, nor does it change color based on an angle. As a cherry on top, it has no visible physical representation in the scene (visible sun disc).
It is hard to express an opinion when the question is put in those terms (it is as if someone should be against or in favor of one of the developers). We appreciate you and all Blender developers. Perhaps according to what has already been expressed in this thread, the final decision should be discussed between you and the Cycles developer on a private channel.
Thank you all for your work.
@YAFU I disagree with that.
This is not something to be discussed only by the two developers involved in this, this is something that needs artists input, and as far as I understand, this is the correct place to have that talk 
It’s not about being in favour Brecht ot Nacioss, it’s about reasoning why from an artist perspective , which are the ones that will use the feature, having the sky clamped by default it’s a problem, a bad practive, and something that is not done in any other engines, since in the end the target we have ALWAYS with a physical sun/sky system is to simulate the real sun/sky, and any lighting artist knows what happens when you do a photograph outside in a bright sunny summer day and you don’t compensate with exposure.
It is true, sure.
But my point was, have not each of you already expressed your point of view enough? Is there really something valuable to add? Or will the discussion become repetitive, becoming a race to see who expresses more times what has already been expressed multiple times? Isn’t the discussion at risk of becoming a personal matter at this point?
Having such a place for discussions is quite valuable.
In my opinion, it is important that the discussion focuses on that and does not diverge into other aspects. At the same time, it would be important to minimize repetitions. No one is going to dive through this discussion again, because it has way too many posts. That’s unfortunate.
I personally would prefer much stricter moderation guidelines where posts get deleted which have no new aspects or the ones that are not on topic. That’s for sure an unpopular opinion for many, but it would keep the discussions tight without participants leaving due to the unnecessary length.
Just bumping this,
@nacioss I didnt see any reply to @Jacon_C question why the sky colors loos odd using filmic compared to aces? . I have also noticed the colors seem wrong when using this new sky with filmic which is why i decided to not use it for now…
This is more a question for @troy_s or any colorist out there really. The model is outputting RGBs based on correct conversion formulas from Spectrum to XYZ and then to RGB ultimately (unless there is still another math mistake somewhere).
EDIT:
@Jason_C where have you been testing ACES on by the way?
No i havent been testing ACES, I was referring to @Jason_C post a few bumps up.
It’s your thing. If it’s broken, it’s on you.
I don’t have a horse in this race, and I don’t particularly care much about what the outcome is, but I’ll just chime in here and say that 61 votes is hardly 90% of the community. Don’t try to spin your straw poll as evidence of some kind of zeitgeist, it just discredits anything else you have to say because now you come off as disingenuous.
https://github.com/sobotka/ACES-1.2-Displays-Formatted/tree/blender-configuration
Config is available there that has some modifications, including an “XYZ” role to allow the sky texture to output in ACEScg
I have not retested it recently, I don’t know if it has already been fixed.
a lot has been said - i just want to add an artists (with math skills) perspective:
I used vray since forever, and without the physical camera the first thing you do, is set the sky intensity to 0.02. Is that a good choice? I don’t know - and I don’t care too much.
No viz-artist I ever talked to had any problems with that, we are not doing scientific light simulations, but ‘nice’ images.
I claim that the popularity of the photographer addon is because of per camera exposure control and white balance (which behaves strange), not physical accuracy with units.
Once you start with physical units its getting complicated. Those render-engines which tried, became unintuitive fast: lm/m²/sr, iso, f-stop, you name it…
V-Ray is a good reference for how to do things, as they allow for generic and scientific units. Arnold is even simpler/better with multipliers and exposure values combined (for lights):
color * intensity * 2^exposure
And last but not least the current lonely ‘Watt’ unit with Blender lights is absolutely useless.
edit: as an artist i am much more concerned with not having a horizon offset on the sky node, as this impacts the amount of post-work i have to do as scenes rarely extend to the horizon.
I don’t really understand what the problem is with Brecht’s proposal of adding a strength slider. To me as an (admittedly non-photographer) rather noobish Blender user a strength slider in the sky settings would be the most logical place to get the balance between the sky and my (pre-existing?) other light sources correct. Where ‘correct’ means ‘the way I want them to be’, not ‘physically accurate’. For all I care you set the default to 1 (meaning physically accurate),. If a HDRI is blown out or too dark I adjust the strength to my liking as well.
I’d much prefer a strength slider to having to adjust all other lights in the scene when adding the sky at a later stage.
I can understand the sky model is your (very pretty!) baby, but you seem to me a bit more agitated than needed for a simple slider.
p.s. I can’t wait to use the pretty skies in my own projects.
I wasn’t sure if I should join the party, this seems like a pretty heated discussion…
\ OFF TOPIC
I saw a few references to my add-on or absolute HDRIs, let me first say that I never claimed these were the ultimate-scientifically-based toolset. I know they aren’t, I gave a description of my capturing workflow and mentioned where approximations were done, and I am not even touching color management…
But I also know that they are not based on thin air. I see a lot of comments that, to me ear, sound like this: “if it’s not 100% correct, then it shouldn’t even exist”. I don’t this is how CGI was built and progressed. I prefer to work with something that is 90% correct, rather than just guessing everything I do. I have compared exposure and physical lights with Unreal (sRGB against sRGB) and they “surprisingly” matched, so I don’t think I’m completely wrong. Now if you want to discuss if Unreal is right or not, that’s another debate. I do prefer to follow current industry standards, even if they still are somewhat inaccurate.
Unreal decided to not follow ISO standards for their virtual camera (https://www.unrealengine.com/en-US/tech-blog/how-epic-games-is-handling-auto-exposure-in-4-25?sessionInvalidated=true), so I decided not to, and to offer a similar Lens Attenuation factor. This way, 9.416 ended up being the magic number. I don’t think Physical cameras were ever trying to fool users into thinking the engine will render exactly like a silver halide film.
I am just offering a certain lighting workflow that works for me, a workflow that I designed while working on an open world with dynamic time of day system. I have always advocated for using physically-based references as a base, but never be afraid to break it to reach the final output that YOU want. It just needs to be a conscious decision and to know what it implies for the rest of the pipeline.
Having said that, I am a simple artist. I keep learning every day, and I gladly correct my mistakes. If you find any errors in my work, please contact me and teach me. I ended up developing this add-on on my own because I couldn’t find anyone with the scientific knowledge who shared the same interest as me in cameras and lighting. It would have been much faster and much easier for me if I got support when I needed it.
And I claim that your claim is unfounded 
Again, please report any issue you have, this is the only way I can improve it. White balancing only supports sRGB at the moment, Troy and I talked about OCIO support and I know that I will have to do a lot of work to get it to function correctly with any view transform.
My add-on also has multipliers and exposure values for lights like Arnold, it is designed for all type of lighting artists, not just the physically-accurate aficionados.
\ End of OFFTOPIC
While I understand @nacioss concerns and I really appreciate the work he has done for Blender, I don’t find Brecht proposition unreasonable, as long as a Strength of 1 means physically based radiance. This is still a step in the right direction.