| Age | Commit message (Collapse) | Author |
|---|
|
This commit implement's OCIO's Looks idea which
is about applying some color correction on the
buffer before it get's affected by a display
transform.
This is mainly used to modify images in an
artistics way.
Currently we've got looks generated from film
response curves for all sorts of cameras.
Patch by both of me and Brecht.
|
|
|
|
|
|
shader for converting colors from linear to display space, based on the scene
color management settings.
if engine.support_display_space_shader(scene): # test graphics card support
engine.bind_display_space_shader(scene)
# draw pixels ..
engine.unbind_display_space_shader()
|
|
|
|
Also extend 3DLUT edge size to 64 (1 meg of memory) to increase
transform accuracy as well.
|
|
Previous GLSL code had error, the if() statement had to be negated.
|
|
Previous version worked, now a version with simplifying this GLSL code.
|
|
There's no logical reason I can find... but I commit it because many others have
the same error, so we can check.
|
|
We do not need to premul shader result, opengl
is already configured for straight alpha.
|
|
it used to apply alpha on source color after
conversion, not on result.
|
|
Fix from debug session of self and Ton, was affecting OSX
builds, making GLSL display transform not working on this
platform.
|
|
|
|
|
|
Issue was caused by some mesa drivers does not support GL_RGBA16F.
Now added check around glTexImage2D to verify whether requested
internal format is actually supported. If not blender will fall
back to non-GLSL image display.
|
|
- GLSL shader wasn't aware of alpha predivide option,
always assuming alpha is straight. Gave wrong results
when displaying transparent float buffers.
- GLSL display wasn't aware of float buffers with number
of channels different from 4, crashing when trying to
display image with different number of channels.
This required a bit larger changes, namely now it's
possible to pass format (GL_RGB, GL_RGBAm GL_LUMINANCE)
to glaDrawPixelsTex, This also implied adding format to
glaDrawPixelsAuto and modifying all places where this
functions are called.
Now GLSL will handle both 3 and 4 channels buffers,
single channel images are handled by CPU.
- Replaced hack for render result displaying with a bit
different hack.
Namely CPU conversion will happen only during render,
once render is done GLSL would be used for displaying
render result on a screen.
This is so because of the way renderer updates parts
of the image -- it happens without respect to active
render layer in image user. This is harmless because
only display buffer is modifying, but this is tricky
because we don't have original buffer opened during
rendering.
One more related fix here was about when rendering
multiple layers, wrong image would be displaying when
rendering is done. Added a signal to invalidate
display buffer once rendering is done (only happens
when using multiple layers). This solves issue with
wrong buffer stuck on the display when using regular
CPU display space transform and if GLSL is available
it'll make image displayed with a GLSL shader.
- As an additional change, byte buffers now also uses
GLSL display transform.
So now only dutehr and RGB curves are stoppers for
using GLSL for all kind of display transforms.
|
|
- Building without OCIO will give correct results again
- If GLSL failed to compile, fallback to glaDrawPixelsAuto
will happen.
|
|
now builds with opencollada
|
|
Apparently C== allowed to have implementations of
OCIOImpl::setupGLSLDraw, OCIOImpl::finishGLSLDraw and
OCIOImpl::freeGLState in two different files.
STUPID!
|
|
|
|
Implemented using GLSL API from OpenColorIO library and
some general functions were added to it's c-api:
- OCIO_setupGLSLDraw prepares OpenGL context for GPU-based
transformation for a giver processor.
This function compiles and links shader, sets up it's
argument. After this transformation would be applied
on an image displaying as a 2D texture.
So, glaDrawPixelsTex called after OCIO_setupGLSLDraw will
do a proper color space transform.
- OCIO_finishGLSLDraw restores OpenGL context after all
color-managed display is over.
- OCIO_freeOGLState frees allocated state structure used
for cacheing some GLSL-related stuff.
There're some utility functions in IMB_colormanagent which
are basically proxies to lower level OCIO functions but
which could be used from any place in blender.
Chacheing of movie clip frame on GPU is also removed now,
and either glaDrawPixelsTex or glaDrawPixelsAuto are used
for display now. This is so no code duplication happens
now and no large textures are lurking around in GPU memory.
Known issues:
- Texture buffer and GLSL are no longer checking for
video card capabilities, possibly could lead to some
artifacts on crappy drivers/cards.
- Only float buffers are displaying using GLSL, byte
buffers will still use fallback display method.
This is to be addressed later.
- If RGB curves are used as a part of display transform,
GLSL display will also be disabled. This is also thing
to be solved later.
Additional changes:
- glaDrawPixelsTexScaled will now use RGBA16F as an
internal format of storing textures when it's used
to draw float buffer. This is needed so LUT are
applied without precision loss.
|
|
|
|
Also fixed typo in function name.
|
|
Also changed shebang to '#!/usr/bin/env python', this is more portable across unixes...
|
|
Seems was simply caused by wrong destructor used in processorRelease
|
|
- move object_iterators.c --> view3d_iterators. (ED_object.h had to include ED_view3d.h which isn't so nice)
- move projection functions from view3d_view.c --> view3d_project.c (view3d_view was becoming a mishmash of utility functions and operators).
- some some cmake includes as system-includes.
|
|
Was caused by mixing up own C-API typedefs with OCIO's
|
|
Still fails when it's enabled though (unresolved symbols).
|
|
ocio configuration file failed to load
This solves issues with infinite NULL-checks to prevent crashes in
such situations. Currently only happens if there's no configuration
file at all, but could be tweaked further to fallback if this file
isn't usable by blender.
|
|
|
|
enabled
|
|
Also don't color manage data buffers in texture painting.
Makes it possible to view heights and normal maps in proper space
and also paint on them without applying extra transformation.
|
|
configuration
Also fix some missing color spaces when loading some OCIO configurations, by falling
back to scene linear if role is not found. There can still be some errors in the
console, need to check this further.
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management#OpenColorIO_Configuration
|
|
disabled buildtime
|
|
This commit integrates support of OpenColorIO library into build systems.
It also contains C-API for OpenColorIO library which could be used by Blender.
CMake has got find rules familiar to OpenImageIO's one which makes it easier
for build system to find needed libraries and includes. Scons only could use
explicitly defined paths to libraries and includes.
C-API would be compiled and Blender would be linked against C-API and OpenColorIO
but it wouldn't affect on Blender behavior at all.
OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and
setting WITH_BF_OCIO in Scons.
|
