The struct member is an unsigned int, not a pointer, so it is mysterious why the orignal code cast it to an uintptr_t.
I changed the code to cast it to an unsigned long so that it matches the format.
The new node that outputs multilayer was using longer names than default.
Caused old code that truncated pass names to 11 chars to fail on loading exr.
This was an old limit in openexr - but that got fixed long ago.
On todo: check current openexr name lenghts, and all code in Blender that
defines pass/layer names.
There was incorrect formula applied on color components, used the same
as gimp uses. It makes image looking nicer in blender, however it's
still not 100% correct. Seems lots of software are handling profiles
from jpeg file nicely. But that's another topic.
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.
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.
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.
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.
