| Age | Commit message (Collapse) | Author |
|---|
|
No need to linearize byte buffer when converting to display space which is data space.
|
|
few of selected objects failed to bake.
|
|
Just makes progressive refine :)
This means the whole image would be refined gradually using as much
threads as it's set in performance settings. Having enough tiles is
required to have this option working as it's expected.
Technically it's implemented by repeatedly computing next sample for
all the tiles before switching to next sample.
This works around 7-12% slower than regular tile-based rendering, so
use this option only if you really need it.
This commit also fixes progressive update of image when Save Buffers
option is enabled.
And one more thing this commit fixes is handling display buffer with
Save Buffers option enabled. If this option is enabled image buffer
wouldn't have neither byte nor float buffer until image is fully
rendered which could backfire in missing image while rendering in
cases color management cache became full.
This issue solved by allocating byte buffer for image buffer from
tile update callback.
Patch was reviewed by Brecht. He also made some minor edits to
original version to patch. Thanks, man!
|
|
had a typo too.
|
|
|
|
|
|
Used the same hack as BLI gzip is using -- calculate short path and
send it to OCIO library.
|
|
Was caused by mixing up own C-API typedefs with OCIO's
|
|
The issue was caused by compositor was allocating float buffer for image and
then this buffer was filled with data converted from byte buffer.
If display happens at time between float was allocated and it was filled black
areas were appearing on the screen.
Made it so IMB_float_from_rect locks color management thread so display
transform wouldn't use uninitialized buffer anymore.
|
|
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.
|
|
|
|
to prevent null pointer dereference if the named color profile isn't found
|
|
write wrong colors for float and crash for half-float.
|
|
on newlines (to better add breakpoints).
|
|
|
|
|
|
display
|
|
IMB_colormanagement_check_file_config
|
|
Solved two issues here:
- RNA update function for cache limiter wasn't type-casting to size_t
type, which lead to long int overflow.
- Display buffer size in color management wasn't calculated properly,
ended up with much more extra memory usage than it's needed.
|
|
|
|
|
|
saving routines
|
|
|
|
we choose 16.
File type was checking for wrong flags, now it should be checked against
actual file format flags which would be used on save.
We also can not free float buffer if file format doesn't have IM_FTYPE_FLOAT
flag -- i.e. TIFF doesn't have such flag and it decides whether float or
byte buffer should be used based on image depth.
|
|
Crash was caused by missed color management initialization -- it was
happening too late.
Move it to generic ImBuf init/exit functions, so now color management
is properly initializing when animation player is launched.
|
|
Color management would be applied on both of float and byte buffers on image
save in cases if file format doesn't require linear float buffer and if image
is saving as render result.
This solves both initial report issue and TODO marked in previous fix.
Also de-duplicated image buffer color managing code and gave some more
meaningful names for few functions. Also wrote documentation around this
function, so current assumptions about spaces should be clear enough.
Made regression tests by saving EXR/PNG images to all supported format and
rendering OpenGL/Normal animation, in all cases seems everything is fine,
but more tests for sure would be welcome.
|
|
this is a regression with color management, TIFF's were always being written as 8bit
however the float buffer is assumed to be linear when converting from float to 16bit pixels per channel, so support for color management might need to be added here.
|
|
|
|
- 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
|
|
Memory limitor's queue could be affected when it's being iterated
on enforcing limits -- that's because iteration could free color
managed image buffers.
Fixed by getting least priority element after every element was
freed. Could be optimized a bit, but it anyway shouldn't be so
slow due to specific of cache limiting and limit enforcing finish
condition.
|
|
matches image's one
Solves slowdown when re-encoding byte image sequence or movie in sequencer.
Fixes #32605: Blender vse renders take more time to render than before
|
|
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.
|
|
or good to keep for completeness. quieted some warnings and add flags -Wmissing-include-dirs and -Wno-div-by-zero to cmake/gcc
|
|
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
|
|
|
|
|
|
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!
|
|
unneeded size_t -> int conversions.
|
|
of the vars were in fact NULL)
|
|
C with gcc.
helps for finding unused functions and making functions static, also did some minor code cleanup.
|
|
Movie cache is using global memory limitor, which isn't thread safe
in some of operations, so it required to add mutex around limitor
operations in movie cache.
It's probably could be solved in a way with less locks involved by
using different limitor for different areas (like use own limitor
for clips, own limitor for sequencer and so), but that wouldn't be
so easy to control overall memory usage.
--
svn merge -r50125:50126 ^/branches/soc-2011-tomato
|
|
|
|
have been removed by accident as code has been updated.
|
|
|
|
This fixes [#32399] VSE doesn't show last 3 frames of Quicktime movie.
Some decoders store frames internally until EOF.
So one has to feed the decoding engine with empty packets after EOF
until all frames could be extracted properly.
|
|
|
|
situations.
|
