I definately couldn’t understand how endianness would be related to this. If 
there were an endianness issue, the picture would be different and the issue 
wouldn’t evidence itself with a flip.

> On May 31, 2018, at 2:53 PM, Patrick Cusack <[email protected]> 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 <[email protected] 
>> <mailto:[email protected]>> 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 <[email protected] 
>>> <mailto:[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 
>>>> <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
> 
> _______________________________________________
> Oiio-dev mailing list
> [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

Reply via email to