CMake might have a problem finding non-system python includes on OSX Lion.
Please see this description I filed on Homebrew
Here I am asking for a make variable so I can override it's choice. I think that's better
than trying to patch the Makefile with an extra MY_CMAKE_FLAGS += -DPYTHON_INCLUDE_DIR

Master testsuite is failing after merging changes from my branch (using OpenJpeg instead of Jasper). It looks like p0_04.j2k, p0_05.j2k and p0_06.j2k images aren't correctly converted and hash of this images can differ on different platforms (here MacOS and Ubuntu x64).

On Arch Linux i686 I issue "make" while in the root dir of the project. After building, I check out iv (or one of the other tools and execute it). It segfaults with: https://bugs.archlinux.org/task/27771?getfile=8000

This does not happen when doing "make debug" or when doing a release build on a x86_64 system. My compiler is gcc 4.6.2. I used no parameters or system cflags apart from those used by default when doing "make" in your project.

I will try to find the particular flag that causes this behavior.

Currently calling get_texture_info with the "exists" token will report an error if the file is missing. This sort of defeats the purpose of making the query in the first place :)

Hello,

For example: we open in iv program any image, for example 3. In status bar we can see information about it: (3/3)....

Now we have 3 displaying images. For example i open 4 image, but it's not open. In statusbar we have (4/4)... but iv displaying 3 images now and 4 black screen and note that image cannot be opened. I suggest if iv cannot load image, show error message to user and close this image. I want to write patch. What do you think about it?

Thank you.

When you do an nm on OIIO, there are still quite a few symbols that are not properly namespaced related to plugins. If possible, we should address them. (for example, the libdpx code is internal and can certainly be namespaced).

nm -C -D libOpenImageIO.so | grep --invert-match OpenImageIO | wc -l
2347

The cineon and dpx codepaths share many common chunks of code. However, the dpx has had many bugfixes that were not ported to cineon.

For example, if we compare cineon.imageio/libcineon/BaseTypeConverter.h dpx.imageio/libdpx/BaseTypeConverter.h we see the dpx has code to preserve white point scaling. However, cineon does not have that code (and it should!).

Additionally, cineon has a compile warning that should be addressed:

In file included from /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/Writer.cpp:41: /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/WriterInternal.h: In function ‘void cineon::WritePackedMethod(IB*, IB*, int, bool, cineon::BufferAccess&) [with IB = unsigned int, int BITDEPTH = 32]’: /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/WriterInternal.h:273: instantiated from ‘int cineon::WriteBuffer(cineon::OutStream*, cineon::DataSize, void*, cineon::U32, cineon::U32, int, cineon::Packing, bool, int, char*, bool&) [with IB = unsigned int, int BITDEPTH = 32, bool SAMEBUFTYPE = true]’ /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/Writer.cpp:286: instantiated from here /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/WriterInternal.h:145: warning: right shift count is negative /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/WriterInternal.h: In function ‘void cineon::WritePackedMethod(IB*, IB*, int, bool, cineon::BufferAccess&) [with IB = long unsigned int, int BITDEPTH = 64]’: /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/WriterInternal.h:273: instantiated from ‘int cineon::WriteBuffer(cineon::OutStream*, cineon::DataSize, void*, cineon::U32, cineon::U32, int, cineon::Packing, bool, int, char*, bool&) [with IB = long unsigned int, int BITDEPTH = 64, bool SAMEBUFTYPE = true]’ /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/Writer.cpp:293: instantiated from here /net/homedirs/jeremys/git/oiio.js/src/cineon.imageio/libcineon/WriterInternal.h:145: warning: right shift count is negative

I am marking this as a bug, due to the issue that at least one of these changes (the bit depth 10->16 promotion) will affect image results.

Based on private mail with Terrance Mali..., the author of OpenDCP, he brought up the fact that Jasper does not support profile 3 or 4 of the jpeg2000 spec as well as supporting codestream lengths or single tiles, making it unsuitable for DCDM creation.

The solution I put forward is to rewrite the jpeg2000 plugin to use libopenjpeg instead.

DPX files come in two endian flavors, and all systems are expected to read both. However, for hardware compatibility purposes it's often preferable to force Big Endian. The dpx writer currently does not allow the writing endian to be toggle at runtime. We should add writer support for an optional hint such as oiio:Endian, to control the output.

See this previous email chain on oiio-dev, "DPX Endian", 12/08/10.

I'm seeing some oddness (which may be my fault) but I'm not sure where to go from here.

The symptom is a crash in makecolortx when using a 'fixnan' option, but as I went to investigate things started going all crazy on me. It feels a bit like memory corruption, but I've ran this all in valgrind and nothing pops up.

The outer-most symptom (other than the crash) is that I'm getting different results for using the
ImageBuf::Iterator array [] syntax, vs the ImageBuf.getchannel() call.

/net/homedirs/jeremys/svn/makecolortx

./_spinux1_gcc44m64_D/makecolortx_d -o /tmp/a.exr dev.mtl_lgts_dougs_sphere_aov_test_sphere_aov_test_v1_tvfa_lnf.0001.exr --fixnan box3

Where the relevant code is...
`ImageBuf dst
ImageBuf::Iterator pixel(dst);

while (pixel.valid()) {
    for (int c = 0;  c < spec.nchannels;  ++c) {
        float value = pixel[c];
        float value2 = src.getchannel(pixel.x(), pixel.y(), c);

        if(isfinite(value)!= isfinite(value2))
        {
            std::cerr << "ERROR" << std::endl;

...`

OUTPUT: ERROR value -nan value2 1 x 591 y 546 c 3

When I run this through valgrind, there is a bit of suspiciousness:
`==821== Invalid read of size 4
==821== at 0x42A4A4: float OpenImageIO_Arnold::v0::convert_type<float, float>(float const&) (fmath.h:434)
==821== by 0x4277EC: OpenImageIO_Arnold::v0::DataProxy<float, float>::operator float() const (fmath.h:485)
==821== by 0x41C971: fixnan_box3(int_, int_, OpenImageIO_Arnold::v0::ImageBuf&, OpenImageIO_Arnold::v0::ImageBuf const&) (makecolortx.cpp:595)
==821== by 0x41F949: make_texturemap(char const_) (makecolortx.cpp:1139)
==821== by 0x422553: main (makecolortx.cpp:1503)
==821== Address 0xadca2d0 is 0 bytes after a block of size 2,568,960 alloc'd
==821== at 0x4C25A0E: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==821== by 0x42E534: gnu_cxx::new_allocator::allocate(unsigned long, void const) (new_allocator.h:89)
==821== by 0x42CCC4: std::Vector_base<char, std::allocator >::M_allocate(unsigned long) (stl_vector.h:140)
==821== by 0x5089468: std::vector<char, std::allocator >::M_fill_insert(__gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator > >, unsigned long, char const&) (vector.tcc:414)
==821== by 0x5086271: std::vector<char, std::allocator >::insert(__gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator > >, unsigned long, char const&) (stl_vector.h:851)
==821== by 0x5083EBD: std::vector<char, std::allocator >::resize(unsigned long, char) (stl_vector.h:557)
==821== by 0x50710E5: OpenImageIO_Arnold::v0::ImageBuf::realloc() (imagebuf.cpp:143)
==821== by 0x5071EEC: OpenImageIO_Arnold::v0::ImageBuf::read(int, int, bool, OpenImageIO_Arnold::v0::TypeDesc, bool ()(void, float), void) (imagebuf.cpp:256)
==821== by 0x41E04B: make_texturemap(char const) (makecolortx.cpp:936)
==821== by 0x422553: main (makecolortx.cpp:1503)
==821==
==821== Conditional jump or move depends on uninitialised value(s)
==821== at 0x41C9D5: fixnan_box3(int_, int_, OpenImageIO_Arnold::v0::ImageBuf&, OpenImageIO_Arnold::v0::ImageBuf const&) (makecolortx.cpp:598)
==821== by 0x41F949: make_texturemap(char const*) (makecolortx.cpp:1139)
==821== by 0x422553: main (makecolortx.cpp:1503)
==821==

ImageBuf temp local allocation: 6301440
ImageBuf local allocation: 1572480

`

It says that my code depends on an uninitialized value:

if(isfinite(value)!= isfinite(value2))
but both are set directly above:
float value = pixel[c]; float value2 = src.getchannel(pixel.x(), pixel.y(), c);

Also, I've gotten other weirdness (like crashes in boost) when building a debug makecolortx against an opt OIIO, and vice-versa. As far as I know, this should be completely legit. Am I mistaken?

I know I havent provided a simple test-case, please let me know what you'd like me to test... ;)

Trying to compile 0.9.0 against boost 1.46.0 on OS X 10.6.6 gives:
/tmp/homebrew-openimageio-0.9.0-Bwtq/OpenImageIO-oiio-82db2e5/src/libOpenImageIO/imageioplugin.cpp: In function ‘void OpenImageIO::v0:: ::catalog_all_plugins(std::string)’:
/tmp/homebrew-openimageio-0.9.0-Bwtq/OpenImageIO-oiio-82db2e5/src/libOpenImageIO/imageioplugin.cpp:278: error: conversion from ‘boost::filesystem3::path’ to non-scalar type ‘std::basic_string<char, std::char_traits, std::allocator >’ requested
make[2]: *** [libOpenImageIO/CMakeFiles/OpenImageIO.dir/imageioplugin.cpp.o] Error 1

I followed the instructions on the website to grab the external library pack from svn (r1823), and built that, but the cmake stage was failing to find the ILMBase libraries (or OpenEXR when I fixed that problem).

I don't know whether it's an unmerged change in the external libraries package, or a mis-configuration on my platform, but the FindIlmBase and FindOpenEXR modules search for the libraries in:

${ILMBASE_HOME}/ilmbase-${ILMBASE_VERSION}/lib

Whereas they were actually built into:

${ILMBASE_HOME}/lib/ilmbase-${ILMBASE_VERSION}

I committed a very simple fix to solve this, and could then compile without a hitch: ndevenish/oiio@20e90ef44c985aa3df7325c87d891812620e06d7, but like I said, I don't know if this is an oiio problem or an "external packages for oiio" problem (and don't know if there is a separate bug tracker for that)

I noticed a few build problems in the "external" project, and have some simple fixes:

1. The makefile for openexr references ${ilmbase-1.0.1_obj_dir} - which means the makefile for ilmbase needs to be sourced first... but the order the various module.mk files is sourced is currently undefined. So, instead of using

${ilmbase-1.0.1_obj_dir}/ilmbase-1.0.1.d

instead use

${build_obj_dir}/ilmbase-1.0.1/ilmbase-1.0.1.d

and it fixes the problem.

2. The makefile for tiff tries to ensure that jpeg / zlib are built first, but does it incorrectly; replace the line

ALL_DEPS := ${my_zlib} ${my_jpeg} ${ALL_DEPS}

with

${${name}_depfile} : ${build_obj_dir}/${my_zlib}/${my_zlib}.d ${build_obj_dir}/${my_jpeg}/${my_jpeg}.d

I didn't make a patch, but here's a script you can run from a bash prompt that will make the appropriate fixes - run it from the base of the external repo:

#!/bin/bash
openexr=$(basename $(ls -d src/openexr-*))
ilmbase=$(basename $(ls -d src/ilmbase-*))
sed -i 's>${${name}_depfile} : ${'${ilmbase}'_obj_dir}/'${ilmbase}'.d>${${name}_depfile} : ${build_obj_dir}/'${ilmbase}'/'${ilmbase}'.d>' src/${openexr}/module.mk

# The makefile for tiff has a bug - it doesn't specify jpeg / zlip as prereqs correctly 
tiff=$(basename $(ls -d src/tiff-*))
sed -i 's>ALL_DEPS := ${my_zlib} ${my_jpeg} ${ALL_DEPS}>${${name}_depfile} : ${build_obj_dir}/${my_zlib}/${my_zlib}.d ${build_obj_dir}/${my_jpeg}/${my_jpeg}.d>' src/${tiff}/module.mk

1. The -a option does not work.
2. "Stats Avg" reports negative numbers, even though there are no negative valued pixels in the texture.

Now that we can read higher bit depth jpeg2000 images, it makes sense to be able to write them as well.

Couple changes to make CPack work on Fedora 14 (and I'd imagine Debian/Ubuntu too)

CPACK_PACKAGE_CONTACT (needed for .deb) also probably needs a valid email.

Patch:
http://www.pasteall.org/21173/diff

Using a common code for testing different formats I get error on writing DPX format (reads fine). Writing UINT8 RGB data.

Compilation of OIIO 0.9.2 (gb1da558) in MSVC90 both 32 and 64 bit.
Project testing input and output routines uses shared DLL.

I'm not sure if that's a good place to report it, so sorry if I'm wrong.

small patch to support multilib, like lib64:

--- CMakeLists.txt
+++ CMakeLists.txt
@@ -91,11 +91,11 @@

Exec Install Locations

set (BINDIR "${CMAKE_INSTALL_PREFIX}/bin")
-set (LIBDIR "${CMAKE_INSTALL_PREFIX}/lib")
+set (LIBDIR "${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}")
set (PYLIBDIR "${CMAKE_INSTALL_PREFIX}/python")
if (EXEC_INSTALL_PREFIX)
set (BINDIR "${EXEC_INSTALL_PREFIX}/bin")

• set (LIBDIR "${EXEC_INSTALL_PREFIX}/lib")
• set (LIBDIR "${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX}")
  set (PYLIBDIR "${EXEC_INSTALL_PREFIX}/python")
  endif ()

Hi,

I'm just trying to get OIIO to compile - this is on Linux (Ubuntu), with the current master branch of the repository.

[ 80%] Building CXX object libOpenImageIO/CMakeFiles/optparser_test.dir/optparser_test.cpp.o
In file included from /mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/src/libOpenImageIO/optparser_test.cpp:39:
/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/src/include/optparser.h: In function ‘bool OpenImageIO::v0_11::optparse1(C&, const std::string&)’:
/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/src/include/optparser.h:69: error: there are no arguments to ‘strchr’ that depend on a template parameter, so a declaration of ‘strchr’ must be available
/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/src/include/optparser.h:69: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/src/include/optparser.h: In function ‘bool OpenImageIO::v0_11::optparse1(C&, const std::string&) [with C = MySystem]’:
/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/src/include/optparser.h:118:   instantiated from ‘bool OpenImageIO::v0_11::optparser(C&, const std::string&) [with C = MySystem]’
/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/src/libOpenImageIO/optparser_test.cpp:84:   instantiated from here
/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/src/include/optparser.h:69: error: ‘strchr’ was not declared in this scope
make[3]: *** [libOpenImageIO/CMakeFiles/optparser_test.dir/optparser_test.cpp.o] Error 1
make[3]: Leaving directory `/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/build/linux64'
make[2]: *** [libOpenImageIO/CMakeFiles/optparser_test.dir/all] Error 2
make[2]: Leaving directory `/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/build/linux64'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/mount/nvizible_users/hughmacdonald/development/OpenIO/Image/ocio/build/linux64'
make: *** [cmake] Error 2

In optparser_test.cpp, replacing this:

#include <string>

with

#include <string.h>

seems to fix it.

I can submit a pull request for this fix, if people consider it appropriate...?

In iconoutput.cpp, lines 201-203, there is the code:

    // Force 8 bit integers
    if (m_spec.format != TypeDesc::UINT16)
        m_spec.set_format (TypeDesc::UINT8);

Is this a typo? The comment implies that it only supports 8-bit, but then it only changes it to 8-bit if it isn't 16-bit.

Hey,

Using the latest trunk, I've noticed that decoding 12bit jpeg2000 images is working incorrectly.

See links [1], [2] and [3] for examples of openimageio's decoding, image magick's decoding and the sample file.

I am using Ubuntu 10.10.

iinfo identifies the files as:

$ iinfo j2c/00004554.j2c
j2c/00004554.j2c : 4096 x 1744, 3 channel, uint8 jpeg2000

while image magick:

$ identify j2c/00004554.j2c
j2c/00004554.j2c JPC 4096x1744 4096x1744+0+0 12-bit DirectClass 1.302MB 2.910u 0:02.909

Perhaps this is related to imageio's detection of the image as 8bit instead of 12?

If anyone is curious, the still is from Sintel and the jpeg2000 was created with opendcp.

Cheers,

Andrew

[1] http://files.aehunter.net/oiio/Screenshot-j2c-00004554.j2c%20-%20iv%20Image%20Viewer.png
[2] http://files.aehunter.net/oiio/imagemagic%204554.png
[3] http://files.aehunter.net/oiio/00004554.j2c

-filter option should be split into -mipfilter and -filter (to separately control the resize filter from the mipmap filter). This naming matches prman (which makes life simple for many facilities)

I can not build oiio with python 3 support on openSUSE 12.1
I tried 'make PYTHON_VERSION=3.2'
Did not work - fall back to python2.7
Manually edited cmake configuration (python executable/include/lib plus boost_python3.so) results in compilation error.
On Debian there was no such problem.

[CODE]
Linking CXX executable iv
[ 95%] Built target iv
Scanning dependencies of target PyOpenImageIO
[ 96%] Building CXX object python/CMakeFiles/PyOpenImageIO.dir/py_imageinput.cpp.o
[ 96%] Building CXX object python/CMakeFiles/PyOpenImageIO.dir/py_imageoutput.cpp.o
[ 97%] Building CXX object python/CMakeFiles/PyOpenImageIO.dir/py_imagecache.cpp.o
[ 98%] Building CXX object python/CMakeFiles/PyOpenImageIO.dir/py_imagespec.cpp.o
/home/bartus/src/OpenImageIO-svn/src/python/py_imagespec.cpp: In function ‘boost::python::api::object PyOpenImageIO::ImageSpec_get_channelnames(const OpenImageIO::v0_11::ImageSpec&)’:
/home/bartus/src/OpenImageIO-svn/src/python/py_imagespec.cpp:44:89: error: ‘PyString_FromString’ was not declared in this scope
make[2]: *** [python/CMakeFiles/PyOpenImageIO.dir/py_imagespec.cpp.o] Błąd 1
make[1]: *** [python/CMakeFiles/PyOpenImageIO.dir/all] Błąd 2
make: *** [all] Błąd 2
[/CODE]

When dealing with a deep, multi channel image, some string mojo is required to guess what channels are considered r,g,b,a, etc. I.e., in a exr prman AOV, you often see mydata.r, mydata.g, etc. Currently this logic is hidden inside the exr plugin. We should move it to the base library, so that it can be used by other clients or plugins too.

Steps to reproduce:

1. check out and build my DDS branch (https://github.com/inequation/oiio/tree/dds),
2. iconvert any cube map (e.g. this one: http://www.speedyshare.com/files/29882163/Animus128.dds) from DDS back to DDS,
3. compare images with idiff - always FAIL.

Note that upon visual inspection the images are identical.

Also using a "proxy" format for comparison (e.g. converting both images to PNG and comparing those) results in a PASS.

Difference image is somewhat weird - the first cube face is totally black (i.e. no difference), but the others are there unchanged, as if we were comparing the original image with a black one.

It may be a bug of mine. The fact that the first face passes comparison suggests that it might have something to do with the fact that a DDS cube map's full_width/height is the size of the cube map, while the spec.width/height are dimensions of the entire map.

Currently in the tiffoutput.cpp code, write_tile includes code where if the y value == 0, TIFFCheckpointDirectory is called. In the context of a very long tiled render, this probably makes sense. However, in the context of maketx this causes the tiff file to be written many, many times to disk. In my test example, txmaking an 8K tiff should write 240 MB to disk, but instead i've measured that 6.6 GB are being written! We should either make this checkpoint code an option, or perhaps have a time-based threshold where we auto-checkpoint if more than say 5 min since the last tile-write have passed.

A bunch of functions are appropriate in ImageBufAlgo (rather than directly on ImageBuf).

void zero ();

/// Fill the entire image with the given pixel value.
///
void fill (const float *pixel);

/// Fill a subregion of the image with the given pixel value.  The
/// subregion is bounded by [xbegin..xend) X [ybegin..yend).
void fill (const float *pixel, int xbegin, int xend, int ybegin, int yend);

/// Fill a subregion of the volume with the given pixel value.  The
/// subregion is bounded by [xbegin,xend) X [ybegin,yend) X [zbegin,zend).
void fill (const float *pixel, int xbegin, int xend, int ybegin, int yend,
           int zbegin, int zend);

I'm working in a studio where we're using displayWindow to describe the size of the image and dataWindow to describe the DOD for image data. It's common for our element renders to have a dataWindow smaller than the displayWindow, defining the bounds of the rendered element.

idiff is failing with "Images do not match in size" when the dataWindows don't match, even when the displayWindows are the same size and the pixels outside the dataWindow are black. This might be OIIO's error, or it might be ours: the OpenEXR documentation is a bit vague about what those windows actually mean.

Example images which produce this failure:

http://dl.dropbox.com/u/17507118/111004-150627.exr dataWindow (type box2i): (0 0) - (511 388)
http://dl.dropbox.com/u/17507118/111102-104031.exr dataWindow (type box2i): (0 90) - (511 328)

I've tested this on the current oiio 0.11.0, last commit was 31c7f32 on Mon Oct 31 14:25:08.

Write out an rgba image from nuke, oiio can't load it.

This PNG file:
http://azureabstraction.com/upload/files/aaron/linked_to_from_permenant_places/stuck_up_european_input.png

Does not read in properly with this test code:
http://azureabstraction.com/upload/files/aaron/linked_to_from_permenant_places/matte.cpp.txt

Using the 0.11 version of the OIIO library.

When I run the simple cpp program, I get this output:
Channels names: RGBA
Format: uint8
Quantization: 0 255 0 255
Resolution, channels: 666 890, 4
First 4 channels: 0 0 0 255

(I expect the first four channels to not indicate a black pixel).

And the output image is this:
http://azureabstraction.com/upload/files/aaron/linked_to_from_permenant_places/stuck_up_european_output.png

When I open the input image in Paintbrush and save it out again (as stuck_up_european_input2.png for example), it is read in and written out as I expect. (So this is a workaround for my project). But it does seem that whatever is different about this particular PNG file, it should be process properly by this simple program (as it opens in viewers properly).

As I am fairly new to graphics, I cannot diagnose what is special about this PNG further.

Ever since MIP levels are not subimages, iv is not capable of displaying them.

Rough Plan...

• Leaving the public APIs as they are (in terms of text), but merely changing the declaration of the ColorTransfer opaque type (and possibly the name) for example in convert_image.
• Having a new utility routine that will return a ColorTransfer given two space names.
• Auto-detect at compile time if OCIO is present. If it is, these things just wrap OCIO routines that do color conversion. If not, they should just be built to understand "linear" and "sRGB", so that at least works if no OCIO is present.
• OK to have a more direct OCIO use in iv to display things properly. (again, falling back on something simple if not found at build time)
• Appropriate options added to maketx and oiiotool to do named color space conversions.

A lot of people, especially before GSoC starts, write to me that settin up build enviorment on Windows is great pain. Binaries of externals that we store on our site not alway work - I'm not sure why, maybe the reason is that they were compiled for other version of Visual Studio that user have. Second problem is that our externals were compiled only for 32-bit build, so the are useless for 64-bit build on Windows.

So there is a need for a script (python, powershell or ruby) that will download dependencies, compile it with given compiler and install in given directory. Thanks to that we could remove our externals for windows and user will build dependencies with the compiler he/she use.

Probably not very high priority, but there was some discussion about supporting DPX 1-bit images.

Kevin Wheatley said:

1 bit DPX images are generated by Northlight scanners as a secondary
image element for the IR dirt map, the first image is your typical
3x10 or 3x16 bit RGB as normal, the 1 bit images are packed in a
particular way because the DPX spec is a bit ambiguous Filmlight have
a PDF available here:

http://www.filmlight.ltd.uk/resources/documents/northlight/white-papers_nl.php

Kevin

Hi all and thanks for this great lib! :)

It seems that the latest stable 0.10 doesn't compile on OSX Lion:

https://groups.google.com/group/coral-app/browse_thread/thread/3b18ae89820cece

But the dev branch does.

I actually have only one simple question:

Is there any plan for a new release soon? If yes: When?

Thanks in advance for this! :)

Regards,

Dorian

The general philosophy is that oiiotool ought should just be glue that strings together a bunch of calls to ImageBufAlgo methods. To get there, we'll need to port a bunch of the oiiotool code over to corresponding ImageBufAlgo methods.

ImageBufAlgo::flip and flop still use the very inefficient getpixel/setpixel, so I don't want to have oiiotool use that without rewriting them for iterators.

The CinemaDNG format is designed for storing high-resolution image streams in camera raw format. CinemaDNG is an open, documented format leveraging standard formats for video and imaging — DNG, TIFF, TIFF/EP, MXF, XMP. Each image is encoded using the DNG image format. The image stream can be stored in one of two formats: either as video essence in an MXF file, or as a sequence of image files in a file directory.

I don't think it is within OpenImageIO's design to support the MXF encoded CinemaDNG files, but it would be benificial to support the reading and writing of the image sequence format.

Specification is available here: http://download.macromedia.com/pub/labs/cinemadng/cinemadng_p1_spec_091009.pdf

One of my co-workers claims that TextureSystem::get_imagespec has a leak ("due to a std::vector copy related to ParamValue"). Apparently switching to TextureSystem::imagespec() works around the leak. No repro case, sorry.

Should double check all the corner cases, make sure maxval maps to maxval, etc.

I've been fighting with an issue which appeared like an RLA decoding error for the past 5 days and finally arrived at the conclusion that my code is all right and the error lies in the way that per-channel formats are handled.

Symptoms: a scanline-based uint16/uint16/uint16 image (i.e. the m_spec.channelformats vector has such contents) only has the left half displayed correctly - the right one is apparently rubbish which is left over in memory. The artifacts in the right half are vertically continuous, which suggests that that memory isn't overwritten. And zeroing the scanline buffer before returning it in read_native_scanline doesn't get rid of them. This suggests that only half of the scanline returned by read_native_scanline is copied upstream.

Steps to reproduce: check out my RLA OIIO branch, switch the "#if 0"s to "#if 1", build and open any 16-bit RLA image (iv, iconvert, doesn't matter).

My wild guess is that somewhere in there a call to m_spec.scanlinebytes() is left without an argument (the 'native' parameter defaults to false), when in fact it should have 'native' set to true. Iv, for instance, seems to convert everything from native format to uint8 on load (at least in GL 1.x mode, which I'm using on my laptop), and it appears to be copying only a half of the scanline that the plugin provides.

$ svn checkout http://svn.openimageio.org/external/trunk external
[...]
$ cd external/
$ make
[...]
./build/linux/boost_1_43_0/lib/libboost_wserialization.a' ->./dist/linux/lib/boost_1_43_0/libboost_wserialization.a'
./build/linux/boost_1_43_0/lib/libboost_wserialization.so' ->./dist/linux/lib/boost_1_43_0/libboost_wserialization.so'
./build/linux/boost_1_43_0/lib/libboost_wserialization.so.1.43.0' ->./dist/linux/lib/boost_1_43_0/libboost_wserialization.so.1.43.0'
platform=linux, hw=i686
Reading srcpackage.mk for boost_1_43_0
Reading srcpackage.mk for glew-1.5.1
Reading srcpackage.mk for gtest-1.3.0
Reading srcpackage.mk for ilmbase-1.0.1
Reading srcpackage.mk for jasper-1.900.1
Reading srcpackage.mk for jpeg-6b
Reading srcpackage.mk for libpng-1.2.40
Reading srcpackage.mk for openexr-1.6.1
Reading srcpackage.mk for tbb22_004oss
Reading srcpackage.mk for tiff-3.8.2
Reading srcpackage.mk for zlib-1.2.3
./build/linux/openexr-1.6.1/include/OpenEXR/OpenEXRConfig.h' ->./dist/linux/include/openexr-1.6.1/OpenEXR/OpenEXRConfig.h'
cp: cannot stat ./build/linux/openexr-1.6.1/lib/*.a': No such file or directory make: *** No rule to make targetdist/linux/openexr-1.6.1.d', needed by `build'. Stop.

Looks like iinfo, even when called with --stats, no longer computes the statistics.

iinfo --stats /net/homedirs/jeremys/svn/makecolortx/dev.mtl_lgts_dougs_sphere_aov_test_sphere_aov_test_v1_tvfa_lnf.0001.exr

(no stats)

I would expect to see

Stats Min: -0.012939 -0.016922 -0.016922 -0.071655 (float)
Stats Max: 4.308594 3.939453 3.939453 1.071289 (float)

... (continued).

This should work on both mipmapped, and non-mipmapped, images.

Crash when texture path points to a drive that doesn't exist, or an unmounted drive, due to an uncaught exception (?).

There was a commit to fix this (lgritz@de3e109), but I can't find it any more.

Hi,

Our current pipeline is predominantly Half-float OpenEXR based.

While testing the various tools e.g. iprocess and iconvert (cloning and building from the trunk), we found that support for half is lesser compare to full-float.

For example, to work around these, we put in a quick fix as follows

diff --git a/src/libOpenImageIO/imagebufalgo.cpp b/src/libOpenImageIO/imagebufalgo.cpp
index 3707af9..62db9c9 100644
--- a/src/libOpenImageIO/imagebufalgo.cpp
+++ b/src/libOpenImageIO/imagebufalgo.cpp
@@ -684,7 +684,7 @@ bool resize_ (ImageBuf &dst, const ImageBuf &src,
const ImageSpec &dstspec (dst.spec());
int nchannels = dstspec.nchannels;

• if (dstspec.format.basetype != TypeDesc::FLOAT ||
• if ((dstspec.format.basetype != TypeDesc::FLOAT && dstspec.format.basetype != TypeDesc::HALF ) ||
  nchannels != srcspec.nchannels) {
  return false;
  }

Unfortunately, this works on Linux but the same changes didn't help with the Windows build. It appears that on windows, more needed to be done to improve support for 'Half'

Is anyone able to comment on the validity of our observation or have we used the tools wrongly ?

Regards

The oiio:BitsPerSample currently is a bit muddled in implementation, conflating the concepts of integer bit depth, float bit depth, and signed vs. unsigned. After a quick discussion with lg, we would recommend we revisit this attribute and instead of using an integer, use a string value where the allowed options correspond to the maketx -d types:
uint8, sint8, uint10, uint12, uint16, sint16, half, float, double

On input, all readers would be expected to set this value to the intrinsic type in the original file (regardless of what ctype the returned pixel data is stored in). On output, the writers would use this as an output hint.

The current cineon reader (which is a copy of the dpx code) is incomplete, does not compile, and is not suitable for inclusion by default. I believe there are also namespace issues with the dpx reader. We should bring this up to snuff.

Hi,

In the current master branch, if I try to convert an EXR to a DPX using the following:

oiiotool /jobs/temp/colorwheel.exr -d uint10 -o /jobs/temp/colorwheel.dpx, I get a crash here:

Thread 1: status = VgTs_Runnable
==19498==    at 0x4C26DCF: operator delete(void*) (vg_replace_malloc.c:387)
==19498==    by 0x5B338CB: __gnu_cxx::new_allocator<unsigned char>::deallocate(unsigned char*, unsigned long) (new_allocator.h:95)
==19498==    by 0x5B327B9: std::_Vector_base<unsigned char, std::allocator<unsigned char> >::_M_deallocate(unsigned char*, unsigned long) (stl_vector.h:146)
==19498==    by 0x5B2DCEC: std::_Vector_base<unsigned char, std::allocator<unsigned char> >::~_Vector_base() (stl_vector.h:132)
==19498==    by 0x5B2BF47: std::vector<unsigned char, std::allocator<unsigned char> >::~vector() (stl_vector.h:313)
==19498==    by 0x5BF1A01: OpenImageIO::v0_11::DPXOutput::~DPXOutput() (dpxoutput.cpp:123)
==19498==    by 0x42B4E7: output_file(int, char const**) (oiiotool.cpp:261)
==19498==    by 0x5B62901: OpenImageIO::v0_11::ArgOption::invoke_callback(int, char const**) const (argparse.cpp:81)
==19498==    by 0x5B614C2: OpenImageIO::v0_11::ArgParse::parse(int, char const**) (argparse.cpp:381)
==19498==    by 0x42FC74: getargs(int, char**) (oiiotool.cpp:1067)
==19498==    by 0x430033: main (oiiotool.cpp:1093)

I can't figure out quite what's causing it... However, I haven't spent too much time with this, as one of my own branches, which I'll be putting a pull request in for in soon (probably a few minutes) doesn't have this crash. The branch that I'll be putting the pull request in for is to deal with image formats that do not support differing data/display windows (everything apart from EXR, RLA and TIFF)

As per title, the tiff plugin does not gracefully scale 10 and 12 bit tiff into a 16 bit buffer.

Generate an image that uses 16-bits of precision (such as a gradient in dark values).
Then use maketx or iconvert such that the pixel processing goes from uint16->float->uint16.

The output image will differ by 2 code values. My suspicion is that convert_types in imageio.cpp is asymmetric for handling pixel operations, and successive calls from int->float->int do not roundtrip in the LSB. This has been confirmed with multiple 16-bit int formats, including tiff/png.

oiio-iconvert -d float /tmp/input.tif /tmp/tmp.exr
oiio-iconvert -d uint16 /tmp/tmp.exr /tmp/output_iconvert.tif
(input/output differ)

maketx -o /tmp/output_maketx.tif input.tif
(input/output differ)

Rather than using the ColorTransfer mechanism, we should have an optional dependency on OpenColorIO. Whether this should be in the core library, or only used in the examples apps, is to be determined.