OK, here's what's going on: You are doing everything correctly, OIIO is doing
everything correctly, but Gimp and Gnome appear to incompletely support the
TIFF spec, in particular not supporting floating-point pixel data.
I don't know the nature of your data. What is the range and how much precision
do you really need?
If this is non-HDR data (i.e., you expect all values to to lie between 0.0 and
1.0), and you don't need the saved image to be exactly the same as the original
float data from your app beyond "looks more or less the same on a display",
then you could write it out as 8-bit data, which will surely be read by any
application that supports TIFF at all. To do that, all you need to do is
change one line:
> ImageSpec spec (width, height, nbchannels, TypeDesc::UINT8);
That just tells it to write a file with 8-bit unsigned values. Your buffer is
still float, and write_image will automatically do the conversion from the
buffer format to the file format.
On Oct 13, 2012, at 5:16 AM, Lerenard Michel wrote:
> Thanks for your answers.
>
> Here is the export code i'm using. Almost a copy of the code available in the
> documentation:
>
> ImageOutput *out = ImageOutput::create (filename);
> if (! out)
> return false;
> ImageSpec spec (width, height, nbchannels, TypeDesc::FLOAT);
> out->open (filename, spec);
> bool success = out->write_image (TypeDesc::FLOAT, buffer);
> if( !success){
> LOG_ERROR ("Could not write " << filename << ", error = " <<
> out->geterror().c_str() << "\n");
> }
> out->close ();
> delete out;
>
> The buffer variable is a float buffer with RGBA data interlaced.
>
> I've done more tests, with disturbing results. The file i've attached can be
> read by imagemagick or read back by my application.
> *Gimp says: " Sorry, can not handle image with 32 bits samples.
> Unsupported layout, no RGBA loader".
>
> *Gnome document viewer displays a black image with bits of color on the top
> rows.
> *Gnome image viewer shows nothing the first time, but when switch back and
> forth it displays, randomly:
> - nothing
> - the correct image
> - a part of the image
> - a tiled version of the image in which the tiles position are random ( i can
> get half the cube on the left border, the other half on the middle top for
> example.) As if data was not read sequencially.
>
> So it seems the export is correct after all, but the application I used to
> read the file were not. I need to check one last thing:
> The tests i've performed today are on a Debian Wheezy. Yesterday I worked on
> a CentOS 6.2, using the same binaries. (compiled on a CentOS 5). Tried Gimp
> and gnome viewer, but not ImageMagick nor my application. I need to check
> that to know if there is differences between systems.
>
> I'll check iconvert as you advised on monday, i don't have it here.
>
> Thanks !
>
>
> 2012/10/12 Larry Gritz <[email protected]>
> Needless to say, if iconvert works, please feel free to post the code
> surrounding the write_image call, maybe we can spot an error.
>
> -- lg
>
>
> On Oct 12, 2012, at 9:59 AM, Larry Gritz wrote:
>
> > Are you able to write TIFF files with the utilities that come with OIIO?
> >
> > iconvert foo.png foo.tif
> >
> > Does that give you a valid TIFF file? If so, the problem is probably in
> > the way you are calling write_image or somewhere else in your program.
> >
> > -- lg
> >
> >
> > On Oct 12, 2012, at 9:35 AM, Michel Lerenard wrote:
> >
> >> Hi everyone,
> >>
> >> Sorry to bother you with this issue but i don't find any reason why it
> >> happens:
> >> I can't write files in TIFF format. The same data is correctly exported in
> >> several format (png, jpg, exr, etc...).
> >> In TIFF, i get a blank (transparent) image.
> >>
> >> I only have this problem with linux. Windows version works fine. I've
> >> tried using different version of the lib, it does not work.
> >> (i've tried 3.8.2, 3.9.4, 4.0.2)
> >>
> >> I can't find any reason why it doesn't work, i use a simple
> >> ImageOutput::write_image() call.
> >>
> >> Do anyone have a clue about this kind of problem ?
> >>
> >> Thanks in advance.
> >>
> >>
> >> Michel
> >>
> >> _______________________________________________
> >> Oiio-dev mailing list
> >> [email protected]
> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> >
> > --
> > Larry Gritz
> > [email protected]
> >
> >
> > _______________________________________________
> > Oiio-dev mailing list
> > [email protected]
> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> [email protected]
>
>
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> <linux64.00000.tif>_______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
