This commit makes it so CameraIntrinsics is no longer hardcoded
to use the traditional polynomial radial distortion model. Currently
the distortion code has generic logic which is shared between
different distortion models, but had no other models until now.
This moves everything specific to the polynomial radial distortion
to a subclass PolynomialDistortionCameraIntrinsics(), and adds a
new division distortion model suitable for cameras such as the
GoPro which have much stronger distortion due to their fisheye lens.
This also cleans up the internal API of CameraIntrinsics to make
it easier to understand and reduces old C-style code.
New distortion model is available in the Lens panel of MCE.
- Polynomial is the old well-known model
- Division is the new one which s intended to deal better with huge
distortion.
Coefficients of this model works independent from each other
and for division model one probably want to have positive values
to have a barrel distortion.
This gives a huge speedup gain for cases when you've got
rather huge markers on a byte images.
Done by skipping IMB_float_from_rect()/IMB_rect_from_float()
for such cases. We can sample the buffers without color space
conversion.
Basically proxy colorspace didn't work well enough.
It is still a bit weird and mainly:
- Proxies for image sequences are built in the image color space.
- Proxies for movies are built in the movie color space.
This could be unified but would need some work in proxy build
to make it not just pipe frames from one FFmpeg context to
another but also apply OCIO on it.
Issue was caused by NULL-pointer de-reference when post-processing
the frame without putting the frame to movie cache.
Differential Revision: https://developer.blender.org/D276
Previously this only worked for some datablocks relevant to rendering, now it
can be used to detect if any type of datablock was added or removed (but not
yet to detect if it was modified, we need many more depsgraph tags for that).
Most of the changes are some function parameter changes, the important parts
are the DAG_id_type_tag calls.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D195
existing code was very stupid.
- all ID pointers for clipboard strips are handled uniformly.
- clipboard stores a duplicate ID pointer which are restored on paste.
- restoring pointers...
-- use ID's that are still in the database (copy&paste within the same file).
-- fallback to name lookup.
-- fallback to loading them from the original filepath (movie-clip and sound only).
also fix bug pasting where initialing the sound wasn't done if there was no frame-offset.
- Display additional information about channels
and buffer type (float/byte).
- Don't show frame number beyong sequence length.
- Also fixed issues with footage length calculation,
so it's pronbably will be needed to reload some
of existing footages.
- Nearest interpolation was always used when there's
no rotation for stabilization. Was a failure of
optimization heuristic.
- Made 2d stabilization frame acquiring threaded.
This function is only used for display and sequencer
which will only benefit of threads here.
- Fixed bug introduced in r48749 which lead to
re-making stable frame on every redraw.
- When changing clip in clip editor, remove all frames
from it's cache to free memory for new clip.
- When changing proxy render settings, free cache as well.
Made it an operator instead of automatic prefetching.
Filling the whole memory with frames is not always
desired behavior.
Now prefetching is available via P-key, or from Clip
panel in toolbox or from Clip menu.
Also enabled prefetching for non-proxied movies.
When trying to load file below actual sequence range
(like trying to load file for scene frame 10 when clip's
start frame is 20) first frame from file sequence is used.
Before this change first file used to be loaded for every
scene frame below start frame, which polluted memory with
unwanted data.
Now first frame would be loaded only once in this case.
This commit basically implements frames prefetching for
movie clip datablock.
Number of frames to be prefetched is controlled in User
Preferences, System tab, Prefetch Frames option.
Currently prefetching is destructive-less for movie cache,
meaning mo frames will be removed from the cache when while
prefetching. This is because it's half of simplier to
implement, but it also makes sense from tracking point of
view -- we could want to playback in both directions and
removing frames from behind time cursor is not always a
good idea.
Anyway, smarter prefetching strategy could be developed
later.
Some implementation notes:
- Added MEM_CacheLimiter_get_memory_in_use function to get
memory usage of specified memory limiter.
- Fixed prototype of MEM_CacheLimiter_get_maximum which
was simply wrong (used wrong data type for output).
- Added some utility functions to movie clip and movie
cache for direct cache interaction and obtaining cache
statistics.
- Prefetching is implemented using general jobs system.
which is invoking from clip draw function.
- Prefetcing will stop as soon other job or playback starts.
This is done from performance point of view. Jobs will
likely require lots of CPU power and better to provide
whole CPU to it.
Playback is a bit more complicated case. For jpeg sequence
playback prefetching while paying back is nice. But trying
to prefetch heavy exr images and doing color space
conversion slows down both playback and prefetching.
TODO:
- Think of better policy of dealing with already cached frames
(like when cached frames from other clips prevents frames
from current clip to be prefetched)
- Currently a bit funky redraw notification happens from
prefetch job. Perhaps own ND_ is better to have here.
- Hiding clip while prefetch is active in theory shall stop
prefetching job.
- Having multiple clips opened on file load will prefetch
frames for only one of them.
PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements.
=== Dynamic node type registration ===
Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes.
Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2].
=== Node group improvements ===
Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3].
The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there.
[1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes
[2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender
[3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
Handle sequences in a special case for dealing with
sequence sources.
Namely handle separate frames in separate threads,
but do disk read from a critical section since HDD
is not so friendly with lots threads requesting for
data from it.
Makes proxy building much faster than it was before.
This commit implements multi-threaded calculation of frames
when building proxies. Both scaling and undistortion steps
are now threaded.
Frames and proxy resolution are still handled one-by-one,
saving files after every single step. So if HDD is not so
fast, this commit could have not so much benefit.
Internal changes:
- Added IMB_scaleImBuf_threaded which scales given image
buffer in multiple threads and uses bilinear filtering.
- libmv's camera intrinsics now have SetThreads() method
which is used to specify how many OpenMP threads to use
for buffer distortion/undistortion.
And yeah, this code is using OpenMP for threading.
- Reshuffled a bit libmv-capi calls and added function
BKE_tracking_distortion_set_threads to specify number
of threads used by intrinscis.
Issue happened for scene. movie clip and mask strips, which contains
pointers to datablocks which are freeing on loading new file.
Also, scene strip would crash when pasted from clipboard after scene
was unlinked from file.
Such kind of image sequences wouldn't be displayed still
and supporting them would take some additional time, but
for now it'll be no memory leak on attempt opening such
images.
alpha was used for them which doesn't work for cleaned footage stored
in EXR file format.
Perhaps we need to support configurable alpha mode for clips, but
that's for later (maybe even after release),
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
This is probably versioning issue happened when both trunk and tomato
were mixed to work on the same file.
Anyway, there're few files here locally and it's probably other users
do have the same files, so lets keep things safe here :)
Use IMB_testiffname to check whether file could be handled by ImBuf or
whether it should be handled by anim routines.
It solves the issue when file without extension is used for movie clip.
- movieclip unlink didn't clear node ID pointers from the scene (leaving dangling pointers).
- mask datablock unlink was clearning references from scene nodes twice.
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!
Replace pseudo-LRU approach of determining which buffer
to remove when running out of space allowed for cache
with approach which would remove the frame which is most
far away from newly added frame.
This is still a bit tricky because it's impossible to
distinguish which frame to delete in situation of:
CCCC...CC
^
it's either user wants to extend left segment of cached
frames and buffers from right segment should be removed
or he wants to join this two segments and in that case
buffers from right segment should be removed.
Would need a bit more investigation which situation
is more common in general usecase.
Additional changes:
- Cleanup some memutil files (which are familiar to cache limiter)
- Add option to make moviecache verbose. If DEBUG_MESSAGES is
defined in moviecache.c detailed logs would be printed to the
console.
- Movie caches are now named which helps reading debug messages.
