Thanks so much for this. I use this library at NBCUniversal for some internal tools. Its invaluable.
Patrick > On May 31, 2018, at 3:05 PM, Larry Gritz <[email protected]> wrote: > > 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 <[email protected] >> <mailto:[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 >>> <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 > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > > _______________________________________________ > 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
