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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Also, can you show the code for how you're writing it out?
>>
>>
>>> On May 31, 2018, at 1:47 PM, Larry Gritz <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>> <mailto:[email protected]>> 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
>>>>> [email protected] <mailto:[email protected]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>> --
>>> Larry Gritz
>>> [email protected] <mailto:[email protected]>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>
>> --
>> Larry Gritz
>> [email protected] <mailto:[email protected]>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> _______________________________________________
> 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
