| Age | Commit message (Collapse) | Author |
|---|
|
Summary:
Issue was caused by the same tile being written twice to
the EXR file. This was happening because of partial update
of work-in-progress tiles was merging result to the final
render result in order to make color management pipeline
happy.
We need to avoid such a merges and keep memory usage as
low as possible when Save Buffers is enabled.
Now render pipeline will allocate special display buffer
in render layer which will contain combined pass in the
display space. This keeps memory usage as low as we can
do at this moment.
There's one weak thing which is changing color management
settings during rendering would lead to lossy conversion.
This is because render result's display buffer uses color
space from the time when rendering was invoked.
This is actually what was happening in previous release
already actually so not a big issue.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D162
|
|
It allows to schedule tasks of smaller size without having
threads overhead or extra worry about splitting tasks into
smaller pieces.
This simplifies code in color management which was manually
splitting task into smaller chunks to keep memory usage low.
Further optimization is possible by avoid malloc called from
threads, but that's how it used to work for ages already
and would be optimized as a separate patch.
|
|
This callback is used when cache limiter needs to remove
some cached objects when running out of limit.
From blender side it's used to keep painted images always
in memory.
This fixes issue when painted images were removing from
the memory after image cache rewrite.
|
|
It applies color management on a pixel in a way, based on number of
channels of this pixel.
Simplifies partial update code a bit.
|
|
It was only used by opengl render and in fact it needed just to
set DISPLAY_BUFFER_INVALID flag for the image buffer.
In theory it wouldn't make any change to opengl render speed
(because this change just moved rect_from_float from color
management code to image save code). And could not see any speed
changes on my laptop.
|
|
The issue wasn't new in fact, just partial buffer update
function was still broken. Not sure how those issues were
not noticed for so long.
Perhaps partial_buffer_update_rect() could be simplified,
but i've got some more upcoming changes here which might
run into conflicts if i'll do simplification now.
|
|
Summary:
Mainly addressed to solve old TODO with color managed fallback
to CPU mode when displaying render result during rendering.
That fallback was caused by the fact that partial image update
was always acquiring image buffer for composite output and was
only modifying display buffer directly.
This was a big issue for Cycles rendering which renders layers
one by one and wanted to display progress of each individual
layer. This lead to situations when display buffer was based on
what Cycles passes via RenderResult and didn't take layer/pass
from image editor header into account.
Now made it so image buffer which partial update is operating
with always corresponds to what is set in image editor header.
To make Cycles displaying progress of all the layers one by one
made it so image_rect_update switches image editor user to
newly rendering render layer. It happens only once when render
engine starts rendering next render layer, so should not be
annoying for navigation during rendering.
Additional change to render engines was done to make it so
they're able to merge composite output to final result
without marking tile as done. This is done via do_merge_result
argument to end_result() callback. This argument is optional
so should not break script compatibility.
Additional changes:
- Partial display update for Blender Internal now happens from
the same thread as tile rendering. This makes it so display
conversion (which could be pretty heavy actually) is done in
separate threads. Also gives better UI feedback when rendering
easy scene with small tiles.
- Avoid freeing/allocating byte buffer for render result
if it's owned by the image buffer. Only mark it as invalid
for color management.
Saves loads of buffer re-allocations in cases when having
several image editors opened with render result. This change
in conjunction with the rest of the patch gave around
50%-100% speedup of render time when displaying non-combined
pass during rendering on my laptop.
- Partial display buffer update was wrong for buffers with number
of channels different from 4.
- Remove unused window from RenderJob.
- Made image_buffer_rect_update static since it's only used
in single file.
Reviewers: brecht
Reviewed By: brecht
CC: dingto
Differential Revision: http://developer.blender.org/D98
|
|
Cache iterator might return unused keys as well.
Now unused keys are being removed before cleanup
and iteration.
|
|
limit
|
|
Before this it was a runtime check for number of displays/views
which is rather really annoying.
This simplifies code a bit and allows to do some more tricks
in other patches.
|
|
Cast dimensions to size_t before multiplication.
Also made add_ibuf_size survive cases when image
buffer allocation failed.
|
|
|
|
|
|
Summary:
Behaves very much the same as cache for Movie Clip datablock:
- Image now have `MovieCache *cache` field which replaced
legacy `ListBase ibufs`.
This allows image datablock to easily keep of image
buffers which are owned by itself. This field isn't
saved to the file and getting restored on undo steps.
However, cache limit is global for movies, sequences
and image datablocks now. So overall cached image buffers
size will not go above cache limit size in user
preferences.
- Image buffers which are marked as BITMAPDIRTY will never
be freed from the cache.
- Added utility function to iterate over image buffers
saved in movie cache.
- Movie cache cleanup check callback now have ImBuf argument
which can be used in a condition of cleanup.
- Added some utility functions which replaces legacy ibufs
iterations with image cache iteration which happens from
inside a lock.
- Fixed `image_mem_size()` which was only counting one of
the buffers if both float and byte buffer present.
Additional notes:
- `BKE_image_get_first_ibuf()` is rather stupid, but direct
access to ibufs->first was also the same stupid idea.
Would consider avoid this function is another project.
- There are some places which doesn't look threadsafe, but
they already were not so much threadsafe anyway before.
So think not a big deal with solving this later.
Finally solves infinite memory usage by image sequences! :)
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: sebastian_k
Differential Revision: http://developer.blender.org/D95
|
|
Summary:
Uses some magic pseudo-random which is actually a
texture coordinate hashing function.
TODOs:
- Dither noise is the same for all the frames.
- It's different from Floyd's dither we've been
using before.
- Currently CPU and GPU dithering used different
implementation. Ideally we need to use the same
dither in CPU.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: http://developer.blender.org/D58
|
|
Reviewed By: brecht
Differential Revision: http://developer.blender.org/D85
|
|
Summary:
Version of those libraries might be useful to know.
- OIIO and OCIO is exposed via bpy.app.oiio and bpy.app.ocio.
There're "supported", "version" and "version_string" defined
in those modules.
- OSL is available as _cycles.osl_version and _cycles.osl_version_string.
Reviewers: campbellbarton
Reviewed By: campbellbarton
CC: dingto
Differential Revision: http://developer.blender.org/D79
|
|
Was a mistake in own optimization commit.
|
|
inputs.
http://wiki.blender.org/uploads/4/4c/Compo_image_interpolation_borders.png
Problem is that all image buffer reader nodes (RenderLayer, Image,
MovieClip) were clipping pixel coordinates to 0..N range (N being width
or height respectively). Bilinear interpolation works ok then on the
upper-right borders (x, N) and (N, y), since the last (N-1) pixel fades
out to N (background). But the lower-left (x, 0) and (0, y) borders are
not correctly interpolated because the nodes cut off the negative pixels
before the interpolation function can calculate their value.
To fix this, the interpolation functions are now entirely responsible
for handling "out of range" cases, i.e. setting (0,0,0,0) results for
invalid pixels, while also handling interpolation for borders.
Callers should not do pixel range checks themselves, which also makes
the code simpler. Should not have any real performance penalty,
the interpolation functions do this check anyway, so is probably even
slightly faster.
|
|
|
|
Issue was caused by linear float buffer creating for every working
thread. This buffer actually duplicated original buffer which doubles
amount of required memory.
We can not avoid such a duplication, because OCIO needs to work on a
float buffer and it modifies this buffer.
Alternative for now is to not allocate linear buffer for the whole chunk
which needs to be handled by the thread and use further chunk cutting in
thread itself.
So now every thread will handle the chunk in blocks of 64 scanlines.
This reduces memory overhead significantly without speed loss in own
tests.
Ideally, IMB_processor_apply_threaded need to be switched to generic
task scheduler and made it so this function generates tasks with
reasonable number of scanlines. This requires much more testing to
be sure there're no conflicts with object update and so.
Such a change to IMB_processor_apply_threaded would not be noticed by
users, so do not consider this is a crucial to do right now.
|
|
Changes for VC2013
Now, I can build Blender with VC2013 with Cycles, Collada, OpenExr,OpenImageIO disabled. Also, you need VC2008 sp1 installed to make old libs compatible.
|
|
|
|
|
|
|
|
|
|
|
|
CHANGE: writing an animation in the ogg movie format now defaults to .ogv (ogg/video) which is recommended by Xiph.org for video
CHANGE: for .ogg files a check is added whether Blender can read it as a movie (is avi or ffmpeg movie), otherwise assume audio
CHANGE: the anim player now filters for the same extensions as the file browser
|
|
(Patch by Philipp Oeser, submitted in [#37199], many thanks)
|
|
|
|
obtained from OIIO by geterror().
|
|
|
|
We now have openimageio building when cycles builds or when it's
manually set to build.
(I reverted the _IMAGE_ in the define name because I think the closer
the cmake flags match the defines in the software the better, and there
is no reason to rename all the existent WITH_OPENIMAGEIO references in
CMakeLists.txt - which would be the alternative)
|
|
|
|
broken.
|
|
todo: cleanup
|
|
based on patch by Shinsuke Irie
note: scons is not working for me at the moment so I did not test this
patch. It should work fine though.
|
|
As per Brecht van Lommel's suggestion.
|
|
|
|
|
|
The title says it all, now having curve mapping
enabled in color management settings wouldn't
force fallback from GLSL to CPU based color space
conversion.
|
|
|
|
reported via email, patch by PerfectionCat
|
|
|
|
We now support the combined layer of Photoshop files (stored as layer 0
in the file). This way users can keep their files as multilayer PSD and
Blender always handle them as flat images.
For perfect alpha this requires an OpenImageIO update:
https://github.com/OpenImageIO/oiio/commit/342cc2633ff590a3bb278481c61ae798c7148361
Photoshop sample files:
https://github.com/OpenImageIO/oiio-images
Brecht has some pending fixes to push for OIIO as well, so we may as
well wait to update our libraries.
What works:
===========
* 8bit images (with or without alpha)
* 16bits images (alpha discarded)
* Photoshop files saved with 'Maximum Compatibility'
* Cycles, Blender internal, BGE (and player)
Known limitations
(due to OIIO dependency):
=========================
* Images with less than 4 channels show a wrong thumbnail (bug may be in OIIO)
* Packed images are not supported
* We do not write PSD files.
Note: old Blenders have support for PSD via Quicktime library. But due
to license issues this was discontinued.
Many thanks for Brecht van Lommel for reviewing the patch, suggesting
multiple improvements and to help solving the alpha issue.
|
|
|
|
|
|
checks should never be done in color management. Instead this makes sure the look identifier is always initialized correctly to
the default if not defined.
|
|
check in color management look access from r59945. The look_desc pointer is NULL if the look string is undefined (empty).
|
|
|
