So now non-invertible color spaces can not be used as input color space
for images and as working color space for sequencer.
Currently have got two hard-coded families which are rrt and display.
If color space belong to one of this families, it would be considered
as non-invertible.
Data color spaces are always considered invertible.
If color space has got to_reference transformation, it'll be considered
invertible.
This commit hopefully finishes color management pipeline changes, implements
some missed functionality and fixes some bugs.
Mainly changes are related on getting rid of old Color Management flag which
became counter-intuitive in conjunction with OpenColorIO.
Now color management is always assuming to be enabled and non-color managed
pipeline is emulated using display device called None. This display has got
single view which is basically NO-OP (raw) transformation, not applying any
tone curve and displays colors AS-IS. In most cases it behaves the same as
disabling Color Management in shading panel, but there is at least one known
difference in behavior: compositor and sequence editors would output images
in linear space, not in sRGB as it used to be before.
It'll be quite tricky to make this behave in exactly the same way as it
used to, and not sure if we really need to do it.
3D viewport is supposed to be working in sRGB space, no tonemaps would be
applied there. This is another case where compatibility breaks in comparison
with old color management pipeline, but supporting display transformation
would be tricky since it'll also be needed to make GLSL shaders, textures
and so be aware of display transform.
Interface is now aware of display transformation, but it only uses default
display view, no exposure, gamma or curve mapping is supported there.
This is so color widgets could apply display transformation in both
directions. Such behavior is a bit counter-intuitive, but it's currently
the only way to make color picking working smoothly. In theory we'll need
to support color picking color space, but it'll be also a bit tricky since
in Blender display transform is configurable from the interface and could
be used for artistics needs and in such design it's not possible to figure
out invertable color space which could be used for color picking.
In other software it's not so big issue since all color spaces, display
transform and so are strictly defined by pipeline and in this case it is
possible to define color picking space which would be close enough to
display space.
Sequencer's color space now could be configured from the interface --
it's settings are situated in Scene buttons, Color Management panel.
Default space is sRGB. It was made configurable because we used vd16
color space during Mango which was close to Film view used by grading
department.
Sequencer will convert float buffers to this color space before operating
with them hopefully giving better results. Byte buffers wouldn't be
converted to this color space an they'll be handled in their own colors[ace.
Converting them to sequencer's working space would lead to precision loss
without much visible benefits. It shouldn't be an issue since float and
byte images would never be blended together -- byte image would be converted
to float first if it's needed to be blended with float image.
Byte buffers now allowed to be color managed. This was needed to make code
in such areas as baking and rendering don't have hardcoded linear to sRGB
conversions, making things more clear from code point of view.
Input color space is now assigning on image/movie clip load and default
roles are used for this. So for float images default space would be rec709
and for byte images default space would be sRGB.
Added Non-Color color space which is aimed to be used for such things as
normal/heights maps. It's currently the same as raw colorspace, just has
got more clear naming for users. Probably we'll also need to make it not
affected by display transformation.
Think this is all main pipeline-related changes, more details would be there:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
Other changes and fixes:
- Lots of internal code clean up in color management module.
- Made OpenColorIO module using guarded memory allocation. This allowed to
fix couple of memory leaks and would help preventing leaks in the future.
- Made sure color unpremultiply and dither are supported by all OpenColorIO
defined color transformations.
- Made compositor's preview images be aware of display transformation.
Legacy compositor still uses old Color Management flags, but likely we'll
disable compositor for the release and remove legacy code soon, so don't
think we'll need to spend time on porting that code to new color management
system.
- Made OpenGL rendering be aware of display transform when saving render
result. Now it behaves in the same way as regular rendering.
TODO:
- HSV widgets are using linear rgb/sRGB conversions for single channel,
not sure how this should be ported to new color pipeline.
- Image stamp would use hardcoded linear rgb to sRGB conversion for
filling rectangles. Probably it should use default display view
for this instead, would check this with Brecht.
- Get rid of None color space which was only used for compatibility reasons.
- Made it more clear which color spaces could be used as input space.
- There're also some remained TODO's in the code marked as OCIO_TODO,
but wouldn't consider them as stoppers for at least this commit.
Mainly behaves in the same way as legacy color transformation, but it'll
give different result on over and under exposured areas.
Not sure if it's indeed issue -- seems this behaves crappy in both of
current stable release and OCIO branch.
* Added a Brick Texture Node to Cycles.
* Based on the Blender Internal Brick Texture with some modifications.
* Tested on CPU and GPU (CUDA & OpenCL)
Documentation: http://wiki.blender.org/index.php/User:DingTo/CyclesBrickTexture
ToDo: Only works correct on flat surfaces, like a Plane. If you attach the shader to 3D objects like a cube, the mapping is not correct on the Y/Z vector.
Thanks to Lukas Toenne for fixing a issue I had with the Node code! :)
- Move color management settings to scene, so it's now clear for
all areas (such as compositor, sequencer) which settings to
use for display buffers
- Currently removed per-editor color management settings. It could
be nice to have them, but they don't fit nicely into overall
pipeline and could be added as a override settings for display
only later.
- Make sequencer working in space defined by sequencer_workspace
role in OCIO configuration file.
If this role is not set, sequencer will fallback to legacy sRGB
Gamma 2.2 space.
Currently use vd16 color space for sequencer. Not sure what exactly
this color space is, but it's pretty close to SPI Film view and
it's still invertable.
- Sequencer will now output linear float buffers, not color managed
float buffers.
Before this sequencer used to output float buffers in sRGB space,
which was sequencer's working space. Now it can not output buffers
in this space since other areas are not aware of this space.
This also makes it's consistent that all float buffers in Blender
are in linear space.
- When saving render result into byte file format scene's display
transform would be applied on this buffer.
When saving files from image editor, there'll be a display
transform settings which are default set to scene's settings but
could also be overwritten.
Additional details are there (would be extended soon):
http://wiki.blender.org/index.php/User:Nazg-gul/ColorManagement
Incorrect read was happening after nodes which are not affect on output
were removed from the graph. Other nodes could have been connected to
this nodes which lead to accessing freed memory in some other places.
Solved by removing links from unused nodes before removing them from
the graph.
Seems some variables used for light sampling should be reset when
integrator's use_direct_light flag is setting to false, otherwise
this values could be used from previously rendered layer resulting
in using freed memory of __light_distribution texture.
Apparently for viewport rendering on GPU tile size of 1024 gives
much better performance than using single tile. Not sure why it
doesn't work for background rendering, need to be investigated
further.
Meanwhile use old debug value of 1024 for tile size.
Before this debug_tile_size was used as a size of tile, which
became hidden property since tile-based rendering implementation
and couldn't have been controlled.
This resolves the issue with single thread used for viewport
rendering in some cases. Also it makes possible to control tiles
for CUDA viewport rendering, which still behaves much faster when
using the single tile.
Also fixed issue with minimal tile size which was used to calculate
divider of final resolution to be used for initial rendering. Now
it's a Resolution Divider property in Performance tab. This option
could be used to tweak initial resolution of viewport for faster
navigation or faster refresh when changing some properties.
