Here's where the nomenclature gets hairy.
Let's use "first" and "last" to refer to the order of the pixel data in the
file. OIIO will always read pixel data into your buffer in the same order that
it appeared in the file.
"Bottom" and "top" are about how you DISPLAY the image.
The default ordering of the data in a TIFF file is the same as the order that
you read English text, and the same that the electron beam would sweep across a
CRT: top to bottom, and within each scanline, left to right.
There is a field in the TIFF header called Orientation that can be used to
communicate how you want the pixels displayed, if not the canonical ordering.
Smart display programs will honor this hint, if present. (But you never know --
lots of applications are blissfully unaware of that metadata.)
Just for the heck of it, I want to show you another way to skin this cat, using
the ImageBuf abstraction rather than ImageInput/ImageOutput:
ImageBuf buf (argv[1]);
buf.read (0, 0, true, TypeDesc::UINT16); // force a read and conversion to
uint16
if (buf.spec().get_int_attribute("Orientation",1) != 1) {
ImageBuf oriented;
ImageBufAlgo::reorient (oriented, buf);
buf.swap (oriented);
}
buf.set_write_format (TypeDesc::UINT16);
buf.write (dstPath);
The IBA::reorient() function will copy the image and do whatever rotations are
necessary to convert to the canonical "scanline 0 at top, column 0 at left"
orientation.
The nice thing about orienting everything canonically is that if you are
combining two or more images in any way, you probably will not like the results
if they don't agree on their orientations. Code like the above makes your app
not need to worry about all the possible combinations.
> On May 31, 2018, at 2:53 PM, Patrick Cusack <patrickcus...@mac.com> wrote:
>
> So, when I read the file, does OIIO read from the bottom to the top into my
> buffer? I open the image and display it using opencv and the image appears
> upside down. Thanks for your time. Would not have caught that.
>
> Patrick
>
>> On May 31, 2018, at 2:44 PM, Larry Gritz <l...@larrygritz.com
>> <mailto:l...@larrygritz.com>> wrote:
>>
>> It's not related to endianness.
>>
>> Your source image has Orientation metadata that indicates that it should be
>> displayed with scanline indices increasing from BOTTOM to TOP.
>>
>> When you write the image, you are losing that metadata from the original, so
>> although you output the scanlines in the same order that they appeared in
>> the input file, you no longer have the hint that it should be displayed
>> "upside down."
>>
>> Change:
>>
>> ImageSpec oSpec (oXres, oYres, oChannels, TypeDesc::UINT16);
>>
>> to:
>>
>> ImageSpec oSpec = spec;
>>
>> thus initializing the output spec to have all the metadata from the input.
>>
>>
>>> On May 31, 2018, at 2:28 PM, Patrick Cusack <patrickcus...@mac.com
>>> <mailto:patrickcus...@mac.com>> wrote:
>>>
>>> Larry,
>>>
>>> I have a 50mb tiff file from a movie trailer that you can grab at the
>>> following link (
>>> https://drive.google.com/file/d/1E-QjKXOOiALD5GQddVL4QS5m4CzJE0kA/view?usp=sharing
>>>
>>> <https://drive.google.com/file/d/1E-QjKXOOiALD5GQddVL4QS5m4CzJE0kA/view?usp=sharing>).
>>> Just so you know, my libtiff is 4.0.8_5. I experienced this on a Centos 6
>>> install as well. FWIW, Google rendered the preview upside down as well in
>>> google docs. See the following screenshot:
>>>
>>> <Screen Shot 2018-05-31 at 2.21.16 PM.png>
>>>
>>> Here is the code:
>>>
>>> char dstPath[200] = "/Users/patrickcusack/Desktop/output.tiff\0";
>>>
>>> ImageInput *in = ImageInput::open (argv[1]);
>>> if (!in)
>>> return -1;
>>>
>>> const ImageSpec &spec = in->spec();
>>> int xres = spec.width;
>>> int yres = spec.height;
>>> int channels = spec.nchannels;
>>> std::vector<uint16_t> pixels (xres*yres*channels*sizeof(uint16_t));
>>> in->read_image (TypeDesc::UINT16, &pixels[0]);
>>>
>>> const int oXres = xres, oYres = yres;
>>> const int oChannels = channels;
>>> ImageOutput *out = ImageOutput::create (dstPath);
>>> ImageSpec oSpec (oXres, oYres, oChannels, TypeDesc::UINT16);
>>> out->open (dstPath, oSpec);
>>> out->write_image (TypeDesc::UINT16, &pixels[0]);
>>> out->close ();
>>> ImageOutput::destroy (out);
>>>
>>> in->close ();
>>> ImageInput::destroy (in);
>>>
>>>
>>>
>>>> On May 31, 2018, at 1:48 PM, Larry Gritz <l...@larrygritz.com
>>>> <mailto:l...@larrygritz.com>> wrote:
>>>>
>>>> Also, can you show the code for how you're writing it out?
>>>>
>>>>
>>>>> On May 31, 2018, at 1:47 PM, Larry Gritz <l...@larrygritz.com
>>>>> <mailto:l...@larrygritz.com>> wrote:
>>>>>
>>>>> That would be surprising! Can you email me directly with an image (any
>>>>> image) that shows this effect?
>>>>>
>>>>> What platform are you running on, and specifically which version of OIIO?
>>>>> Also, do you know what version of libtiff is on your system?
>>>>>
>>>>>
>>>>>> On May 31, 2018, at 1:10 PM, Patrick Cusack <patrickcus...@mac.com
>>>>>> <mailto:patrickcus...@mac.com>> wrote:
>>>>>>
>>>>>> I am opening 16 bit 3 channel TIFFS with OpenImageIO to calculate values
>>>>>> on the pixels. I perform some logic to grab matting information and I
>>>>>> noticed that when I open little endian files and save them out using
>>>>>> OpenImageIO, the images appear to be flipped around the x axis. This
>>>>>> does not happen when working with Big Endian TIFF files. The images
>>>>>> appear upside down. Here is my very rudimentary code to open the files.
>>>>>> If I save this file out, then it is flipped.
>>>>>>
>>>>>> Patrick
>>>>>>
>>>>>> ImageInput *in = ImageInput::open (argv[1]);
>>>>>> if (!in)
>>>>>> return -1;
>>>>>>
>>>>>> const ImageSpec &spec = in->spec();
>>>>>> int xres = spec.width;
>>>>>> int yres = spec.height;
>>>>>> int channels = spec.nchannels;
>>>>>> std::vector<float> pixels (xres*yres*channels*sizeof(float));
>>>>>> in->read_image (TypeDesc::FLOAT, &pixels[0]);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On May 1, 2018, at 2:59 PM, Larry Gritz <l...@larrygritz.com
>>>>>>> <mailto:l...@larrygritz.com>> wrote:
>>>>>>>
>>>>>>> We have tagged official stable Release-1.8.11 and moved the "release"
>>>>>>> branch marker to match.
>>>>>>>
>>>>>>> Also, we updated the obsolete 1.7 family to Release-1.7.17.
>>>>>>>
>>>>>>> Release notes are below. Both are very minor releases with mostly build
>>>>>>> issue fixes.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Release 1.8.11 (1 May 2018) -- compared to 1.8.10
>>>>>>> -------------------------------------------------
>>>>>>> * Fix to strtof, strtod for non-C locales. #1918
>>>>>>> * Add up-to-date Nuke versions to FindNuke.cmake. #1920
>>>>>>> * Allow building against ffmpeg 4.0. #1926
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Release 1.7.18 (1 May 2018) -- compared to 1.7.17
>>>>>>> -------------------------------------------------
>>>>>>> * Allow building against ffmpeg 4.0. #1926
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Larry Gritz
>>>>>>> l...@larrygritz.com <mailto:l...@larrygritz.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>>
>>>>> --
>>>>> Larry Gritz
>>>>> l...@larrygritz.com <mailto:l...@larrygritz.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>
>>>> --
>>>> Larry Gritz
>>>> l...@larrygritz.com <mailto:l...@larrygritz.com>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>
>> --
>> Larry Gritz
>> l...@larrygritz.com <mailto:l...@larrygritz.com>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
