We need to assign color space for generated images when it's empty.
Do this in add_ibuf_size function in cases image's color space is
empty.
So now color management is always called with correct color space.
P.S. At least it should. If there're more similar issues please
let me know :)
fix pose-group-sort and pose-group-moving being disabled for pinned poses.
also fix for own missing NULL check for pose mask clear which would crash when run without an active object
- Color space of byte buffer for generated images haven't been
updated properly on change
- Byte buffers weren't handling data color spaces on display transform
properly
Issue was caused by completely different way how multi-layer EXRs are loading,
they're bypassing general image buffer loading functions.
Solved by running color space transformation on render result construction
from multi-layer EXR image.
Also fixed issue with wrong display buffer computing for buffers with less
than 4 channels. Issues were:
- Display buffer is always expected to be RGBA
- OpenColorIO can not apply color space transformations on non-{RGB, RGBA}
pixels.
Use object_get_derived_final() function instead of accessing to object's
derived final directly.
The same happens for shrinkwrap constraint and it should deal better in
cases when depth object is in edit mode. In other cases should be no
functional changes.
In fact, color management settings shouldn't be editing from this operator since
screenshot is using OpenGL which is in sRGB space, but fixed issues with Image
Format initialization and added NULL pointer checks.
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
Currently float buffers are always linear, space of byte buffer is defined by
rect_colorspace property.
Replaced logic of IMB_rect_from_float and IMB_float_from_rect to use this
assumptions (before it was special function used in some areas only, now it's
default behavior).
Almost all functions from ImBuf module which are actually used are got rid from
profile flag. Only remained issue is IMB_float_profile_ensure which only used by
CIneon/DPX exporter which is broken for a while already. Need to be fixed
separately.
This also fixed clone brush when cloning byte image on top of float, before
this result would be gamma-corrected twice.
Before this color space settings in image/movie clip data blocks
defined space in which loaded image buffer is, based on whether
this buffer contains float or byte buffer. This didn't work well
for formats like 16bit PNG, which are in fact non-linear formats
but were represented in Blender as float buffers.
Now image buffer loader is responsible to set up input default
color space for image/movie clip data blocks, which could be
based on format itself only or on particular file properties.
This means image/movie clip data blocks' input colorspace will
be initialized at time first image buffer is loaded.
This also resolves old confusing thing with image buffer's profile
flag, which in could have been non-linear for image buffer which
contained float buffer only -- this happened in mentioned case of
16 bit PNG format, i.e. Now float buffer would always be linear
which should make it easier to get rid of image buffer's profile.
This avoids having bunch of cached images when doing animation rendering,
keeping all the memory available for rendered itself.
This keeps memory usage low when rendering huge edits with mixed
scenes and movie strips.
This should not affect on sped of video encoding, which was confirmed by
some own tests.
--
svn merge -r50051:50052 ^/branches/soc-2011-tomato
