The file thumbnail generator would write 0x0 size png's to the .thumbnails/fail
folder. However libpng throws an error when doing this. Instead we now write 1x1
png's, which nautilus seems to be doing as well. The content shouldn't matter
anyway since we won't use it.
notes,
- Use our own callback which doesnt exit() blender.
- Hard coded 'MONOSCNR.ICM' is bad, should this be a user preference or stored per image?
- imb->crect was being set to imb->rect in some cases, disable this because its possible 'rect' gets reallocated and crect becomes freed memory.
- when crect cant be created draw pink checkers, so users dont get confused if color correction isnt working. (previously would draw the uncorrected image, if it didnt crash)
replace some long duplicated, ifdef'd if statements for image extension.
- new function: BLI_testextensie_array(), can take an array of extensions.
- define extension arrays: imb_ext_image, imb_ext_movie, imb_ext_sound - we could have more of these.
- removed amiga extensions iff and lbm
This is a fix for the following issues in ffmpeg movie reader:
* mpeg transport stream seeking (HDV) failed completely, since ffmpeg
doesn't want to seek by timestamp (those aren't guaranteed to be
strictly monotonic within those file formats)
We therefore seek by byte and use the bitrate in those cases.
This isn't a real fix,
I will add a seperate index building process, soon, so that we can
finally seek by timecode properly (optionally with "free run timecode"
on consumer video camcorders, stay tuned :) )
* Recent versions of ffmpeg do set the ALPHA channel to 0xff properly,
so we test the first pixel for proper ALPHA and then workaround
optionally.
- Saving a typical byte buffer as an exr wasnt converting into linear colorspace.
- Remove checks for 1 and 2 channel images, these will write as RGB anyway and are very rare.
- 3 Channel images were having the alpha channel written from the red color channel, write 1.0 instead.
* Allow loading non 3/4 channel TIFFs (eg. greyscale). This was already
working, but disabled out of caution. Seems to work fine in my recent tests though.
- fix for blend file thumbnails not being immediately visible in an external file manager (was writing the thumb before the blend)
- move overlay function from wm_files.c into thumbs_blend.c
- uses same thumbnail system as image browser
- blend files show thumbnails in ubuntu/gnome (freedesktop spec)
- 128x128 images are embedded into the blend file header, a simple loader avoids reading the entire blend file to extract it when generating thumbnails in the file selector.
When the image browser reads a directory it loads images and creates thumbnails, blend files embedded images are treated just like loading an image.
- the thumbnail is created from the camera view in solid mode. (no camera == no thumbnal).
- readfile/writefile.c: had to use the 'TEST' code name to save thumbnails, anything else would segfault older blender versions on load. (its not used elsewhere).
- fix implicit decloration of DAG_scene_sort()
- same fix for tiff as made in renderbranch
- rename 'combined peak' --> 'peak' for shorter messages while rendering.
* Removed dynamic linking libTIFF code and change it to static linking
(built into the blender executable). Dynamic linking made things a
fair bit more complicated and wasn't working at all before on OS X -
the dylib didn't exist and wasn't being copied. Since TIFF is more heavily
depended upon now in Blender, it makes sense to make it less 'optional'
and more in line with other libraries.
I've updated both CMake and scons, and CMake on OS X/64bit works fine.
It's now up to other platform/build system maintainers to enable this for
their respective platforms (Campbell will check it for linux). For windows,
and non-64bit osx, we need static libtiff libraries in /lib.
I've added options WITH_TIFF for CMake and WITH_BF_TIFF for scons,
so if blender won't build because of this, you should be able to disable
these options until your build system has been updated.
* Bonus feature: while doing this, I added support for loading 16bit and 32bit
per channel TIFFs - they get converted to Blender's float buffers. Handy for
zbrush displacement maps!
looks like a threading problem:
Easy to redo, 1024x436, FSA, 4 threads.
With 1 thread it runs ok, need to look into this further but no time now so reverting.
famous upside down EXR bugfix from Xavier Thomas
- Files from blender 2.4x will be flipped on load.
- New files will be saved correctly
tracker has detailed info for further reference.
