| Age | Commit message (Collapse) | Author |
|---|
|
|
|
free_main().
|
|
|
|
|
|
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.
|
|
|
|
files since its done throughout the code in some places.
|
|
listing.
also remove logImageLib.c - empty file.
|
|
|
|
|
|
|
|
|
|
|
|
not do correct partial updates, now it remembers if the opengl texture is a
non-color data texture or not and takes that into account for the update.
Also includes some renaming ncd => is_data for consistency with color space
terminology used elsewhere.
|
|
|
|
when saving, rather we flip the compressed texture during load. The code used
here comes from the chromium O3D project:
http://src.chromium.org/chrome/trunk/o3d/core/cross/bitmap_dds.cc
Also made it only load compressed for power-of-two resolution images, it doesn't
seem to work for other resolutions, just falls back to non-compressed then.
|
|
after adding compressed DDS texture loading.
DDS images can be flipped compared to the Blender standard, however we do not
unflip them because we also don't flip compressed textures. If we would flip
those we'd need to uncompress, flip and recompress them, and so losing the
speed benefit that you get from using them. Users are expected to save DDS
image in OpenGL compatible format.
|
|
- minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
|
|
when tree is being executed. This could lead to nor initialized color space
for the image.
Solved by insuring image buffer is loaded before checking for whether color
conversion is needed.
|
|
than normal
There was a missing byte buffer linearization for shader nodes.
Also fixed incorrect image input color space refresh when image is packed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Patch by Julien Enche, thanks!
From the patch comment:
It allows Blender to load:
- 1, 8, 10, 12 and 16 bits files. For 10 and 12 bits files, packed or
filled type A/B are supported.
- RGB, Log, Luma and YCbCr colorspaces.
- Big and little endian storage.
- Multi-elements (planar) storage.
It allows Blender to save :
- 8, 10, 12 and 16 bits file. For 10 and 12 bits files, the most used
type A padding is used.
- RGB and Log colorspaces (Cineon can only be saved in Log colorspace).
For Log colorspace, the common default values are used for gamma,
reference black and reference white (respectively 1.7, 95 and 685 for
10 bits files).
- Saved DPX/Cineon files now match the viewer.
Some files won't load (mostly because I haven't seen any of them):
- Compressed files
- 32 and 64 bits files
- Image orientation information are not taken in account. Here too,
I haven't seen any file that was not top-bottom/left-right oriented.
|
|
also left bmesh decimator on in previous commit.
|
|
|
|
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.
|
|
|
|
|
