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.
Done by Julien Enche (aka trap), thanks!
From the patch comment:
This patch speeds up Cineon/DPX file loading.
Some more checks are done in dpxOpen and cineonOpen functions so IB_test
flag can now be taken into account safely, and an unnecessary call to
IMB_rect_from_float has been removed.
DPX/Cineon file now loads around 3 times faster on my computer.
Own comment:
Ideally, IB_rect shall indeed indicate which buffers to load, however
currently all places which reads image uses this flag.
This fact already mentioned in OpenEXR reader and it shall be fine
to skip doing rect_from_float in readers themselves.
in case image buffer contains byte buffer only and it's
color space matches display space.
It was already check for this case, but it happened later
in color management routines, which is needed for saving
files, but not fast enough for realtime playback of 4K.
imb_exr_split_channel_name didn't set any value to layer and pass names,
leaving them uninitialized.
This is likely solves initial report, but will know for sure after testing
windows build only.
from Lawrence D'Oliveiro (ldo)
Get rid of BLI_splitdirstring, replace with calls to BLI_split_dirfile, BLI_split_dir_part and BLI_split_file_part as appropriate.
from Lawrence D'Oliveiro (ldo)
More use of bool type, necessitating adding inclusion of BLI_utildefines.h, or moving it up in the inclusion order if it was already included, in various places
- storage.c: make some variables only used in bli_builddir local to that
- storage.c: BLI_file_descriptor_size should allow 0 as a valid file descriptor
- path_util.c: make pointers to non-reentrant storage returned from folder routines const, necessitating making variables holding these returned pointers const elsewhere as well
- path_util.c: BLI_string_to_utf8 closes iconv context in case of conversion error
- blf_lang.c: fill_locales routine now has its own "languages" local variable to construct paths (was stealing internal storage belonging to BLI_get_folder before)
Before alpha channel was simply ignored causing bad looking
straight colors which is pretty much useless.
Now saving RGB would alpha-over image on top of black color,
which makes final image look really nice. It's also very
such the same what other graphics software does this.
In the future we could easily support configurable backdrop
color, which would be really the same as other SW does it.
Also, it'll probably worth adding the same mode to RGB
display of image editor.
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),
Adding non-RGBA float buffers as texture crashes MipMap code.
Images with less than 4 channels not supported (yet). Not sure
if we ever should even... normals, Z, vectors, UV, Index, all
don't like downsampling.
Used by image painting mode, so every brush step would mark area
if affected on, but actual color space conversion would happen
later when actually displaying image.
Implemented as a rcti stored in ImBuf which is getting merged with
partial rect passed to IMB_partial_display_buffer_update_delayed.
This makes painting as fast as it currently possible and finally
solves #33935: Texture painting slow down with mouse, but not with tablet
Multilayer files saved from Maya (and I bet others) store the 'primary' layer without
layer or pass name, just as R G B A. Allows viewers to show stuff too, I guess.
Blender now reads this as well, just allowing an empty string for the layer and pass.
Issue is solved for painting on byte buffer with default sRGB display enabled.
In this case it is possible to skip any color space transform and just apply
dither if needed.
Still not sure if there's a regression in painting on flaots or not, will
continue investigation.
16bit PNG images were not doing any conversions when saving linear float buffers, but would always load them as SRGB.
apply the same method used for 16bit images from floats as used in jpeg2000.
the existence of a float buffer can depend on the image being used in the compositor for example, so better give the user what they expect - 16bit png if its selected from the UI.
Patch makes it possible to compile blender with recent ffmpeg
and libav libraries, mainly by getting rid of deprecated API.
Original patch by Campbell Barton with own modifications to
support compilation with older ffmpeg versions.
This patch could break compatibility of FFV1 videos playing
back in older players, mainly because of alpha support changes.
Preserving compatibility with such players became a headache
and think it's high time to get rid of workarounds here.
without hurting quick texture painting
- ED_view3d_draw_offscreen will now output buffer with
transparent alpha, if sky needed it should be alpha-undered
later.
- ED_view3d_draw_offscreen_imbuf now accepts alpha mode as an
argument which could be either R_ADDSKY or R_PREMULALPHA
- OpenGL render and sequencer's opengl preview will now reflect
scene's Alpha Mode
- Quick Edit will use OpenGL with transparent alpha mode
Additional changes:
- Made mipmapping operate with unsigned short instead of char
which allowed to eliminate extra division by 255, so prevision
should be a bit better now.
- Actually, this is not real unsigned short range, but it's a
range of 255*255 which is more convenient for mipmapping, so
made conversion functions private for scaling.c
Not sure it worth making this functions operate in 65535
range, for now current behavior seems to be just fine.
Regression was caused by alpha premul cleanup commit and the reason
of slowdown was uchar <-> float conversion which is slow.
Replaced with uchar <-> int conversion which seeps to be accurate
enough and mostly eliminates slowdown.
Slowdown was easy to notice when movie clip is used for 3d vierport
background and undistortion is enabled. In this case every frame
will re-calculate mipmaps.
It's still a nit slower than mipmap generation before cleanup
commit, but couldn't think about extra boost here atm.
