I think this should be fixed by https://github.com/OpenImageIO/oiio/pull/1172
If there are no objections, I'll merge this today and also backport to 1.5. On Jun 23, 2015, at 1:15 PM, Larry Gritz <[email protected]> wrote: > I'll submit a fix for that, should be easy. > > > On Jun 23, 2015, at 12:31 PM, Simon Smith <[email protected]> wrote: > >> Basically I’ve used my build of OIIO to create a texture that Renderman is >> happy with, so all looks good on that front! >> >> The only outstanding issue was that if you set the envlatmode (ie, >> ImageBufAlgo:MakeTxEnvLatl - which I am as i'm creating a lat/long images) >> the src_samples_border boolean in maketexture.cpp is left uninitialised, >> causing Visual Studio to trap this at runtime in debug. This logic can only >> fire off if you are not creating an EXR image. I assume this should perhaps >> be initialised to false then all would be good. >> >> Best Regards, >> Simon >> >>> On 23 Jun 2015, at 19:30, Larry Gritz <[email protected]> wrote: >>> >>> Whew, glad that was cleared up. Yeah, PRMan is very unforgiving about how >>> the TIFF textures are structured, and doesn't seem to actually check upon >>> opening that all the parameters of the TIFF file are to its liking. It's >>> been a long time since we used PRMan here (and thus since I've had to worry >>> on a daily basis that maketx was generating the textures that make it >>> happy), so sometimes I forget the details (and also hope/assume that as the >>> years go buy, maybe it's more flexible). >>> >>> So there are no remaining issues? >>> >>> >>> On Jun 23, 2015, at 10:10 AM, Simon Smith <[email protected]> wrote: >>> >>>> It looks like the problem was that I was not generating power of 2 sized >>>> images. >>>> As soon as I did that, the generated texture files were working happily >>>> with PRMan and IT. >>>> >>>> Apologies that this was me thinking there was an issue with OIIO - 'twas a >>>> red herring :( >>>> >>>> >>>> >>>> Best Regards, >>>> Simon >>>> >>>> --- >>>> Simon C Smith >>>> Co-Founder & CTO >>>> www.lightmap.co.uk >>>> >>>> On 12 Jun 2015, at 14:05, Simon Smith wrote: >>>> >>>>> Apologies for not supplying that info Larry :( >>>>> >>>>> OK, so I was using OIIO build 1.4.8 along with Tiff 4.0.3 >>>>> I did a quick test with OIIO build 1.5.16 and I had the same issues (also >>>>> using Tiff 4.0.3) >>>>> >>>>> With zip compression I get an error about both AdobeDeflate, but also >>>>> that it cannot read the TIFF directory count. >>>>> With compression set to "none" I just get the directory count error. >>>>> >>>>> Neither of these files can be opened by IrfanView either (which can >>>>> normally open anything). >>>>> >>>>> >>>>> To generate these files, I used the following code (the raw data being >>>>> held as 32-bit float rgba data): >>>>> >>>>> ImageBufAlgo::make_texture(ImageBufAlgo::MakeTxTexture, buf, >>>>> strTempFilename.c_str(), cFinalImageSpec) >>>>> >>>>> To define the image spec I took the code basics from what MakeTx does as >>>>> follows. >>>>> >>>>> std::string dataformatname = ""; >>>>> std::string fileformatname = "tif"; >>>>> std::vector<std::string> mipimages; >>>>> int tile[3] = { 64, 64, 1 }; // FIXME if we ever support volume MIPmaps >>>>> std::string compression = "zip"; >>>>> bool updatemode = false; >>>>> bool checknan = false; >>>>> std::string fixnan; // none, black, box3 >>>>> bool set_full_to_pixels = false; >>>>> bool do_highlight_compensation = false; >>>>> std::string filtername; >>>>> // Options controlling file metadata or mipmap creation >>>>> float fovcot = 0.0f; >>>>> std::string wrap = "black"; >>>>> std::string swrap; >>>>> std::string twrap; >>>>> bool doresize = false; >>>>> Imath::M44f Mcam(0.0f), Mscr(0.0f); // Initialize to 0 >>>>> bool separate = false; >>>>> bool nomipmap = false; >>>>> bool prman_metadata = true; >>>>> bool constant_color_detect = false; >>>>> bool monochrome_detect = false; >>>>> bool opaque_detect = false; >>>>> int nchannels = -1; >>>>> bool prman = true; >>>>> bool oiio = false; >>>>> bool ignore_unassoc = false; // ignore unassociated alpha tags >>>>> bool unpremult = false; >>>>> std::string incolorspace; >>>>> std::string outcolorspace; >>>>> std::string channelnames; >>>>> >>>>> >>>>> rFinalImageSpec.tile_width = tile[0]; >>>>> rFinalImageSpec.tile_height = tile[1]; >>>>> rFinalImageSpec.tile_depth = tile[2]; >>>>> rFinalImageSpec.attribute ("compression", compression); >>>>> if (fovcot != 0.0f) >>>>> rFinalImageSpec.attribute ("fovcot", fovcot); >>>>> rFinalImageSpec.attribute ("planarconfig", separate ? "separate" : >>>>> "contig"); >>>>> std::string wrapmodes = (swrap.size() ? swrap : wrap) + ',' + >>>>> (twrap.size() ? twrap : wrap); >>>>> rFinalImageSpec.attribute ("wrapmodes", wrapmodes); >>>>> >>>>> // rFinalImageSpec.attribute ("maketx:stats", stats); >>>>> rFinalImageSpec.attribute ("maketx:resize", doresize); >>>>> rFinalImageSpec.attribute ("maketx:nomipmap", nomipmap); >>>>> rFinalImageSpec.attribute ("maketx:updatemode", updatemode); >>>>> rFinalImageSpec.attribute ("maketx:constant_color_detect", >>>>> constant_color_detect); >>>>> rFinalImageSpec.attribute ("maketx:monochrome_detect", >>>>> monochrome_detect); >>>>> rFinalImageSpec.attribute ("maketx:opaque_detect", opaque_detect); >>>>> rFinalImageSpec.attribute ("maketx:unpremult", unpremult); >>>>> rFinalImageSpec.attribute ("maketx:incolorspace", incolorspace); >>>>> rFinalImageSpec.attribute ("maketx:outcolorspace", outcolorspace); >>>>> rFinalImageSpec.attribute ("maketx:checknan", checknan); >>>>> rFinalImageSpec.attribute ("maketx:fixnan", fixnan); >>>>> rFinalImageSpec.attribute ("maketx:set_full_to_pixels", >>>>> set_full_to_pixels); >>>>> rFinalImageSpec.attribute ("maketx:highlightcomp", >>>>> (int)do_highlight_compensation); >>>>> if (filtername.size()) >>>>> rFinalImageSpec.attribute ("maketx:filtername", filtername); >>>>> rFinalImageSpec.attribute ("maketx:nchannels", nchannels); >>>>> rFinalImageSpec.attribute ("maketx:channelnames", channelnames); >>>>> if (fileformatname.size()) >>>>> rFinalImageSpec.attribute ("maketx:fileformatname", >>>>> fileformatname); >>>>> rFinalImageSpec.attribute ("maketx:prman_metadata", prman_metadata); >>>>> rFinalImageSpec.attribute ("maketx:oiio_options", oiio); >>>>> rFinalImageSpec.attribute ("maketx:prman_options", prman); >>>>> if (mipimages.size()) >>>>> rFinalImageSpec.attribute ("maketx:mipimages", >>>>> Strutil::join(mipimages,";")); >>>>> >>>>> if (ignore_unassoc) { >>>>> rFinalImageSpec.attribute ("maketx:ignore_unassoc", >>>>> (int)ignore_unassoc); >>>>> ImageCache *ic = ImageCache::create (); // get the shared one >>>>> ic->attribute ("unassociatedalpha", (int)ignore_unassoc); >>>>> } >>>>> >>>>> And that's it >>>>> So, same result from both 1.4.8 and the latest 1.5.16 >>>>> >>>>> Oh, I tried the maketx on the generated file with the --prman flags, but >>>>> I got the same 2 errors when loading into Maya. >>>>> >>>>> One of my suspicions is on the the Tif library that I'm using - what >>>>> version do you recommend people use by the way? >>>>> >>>>> >>>>> >>>>> Just a couple of other notes. >>>>> If I run the above with envlatmode set (ie, mageBufAlgo:MakeTxEnvLatl - >>>>> which is what I should be doing as I am creating lat/long images) the >>>>> src_samples_border boolean in maketexture.cpp is left uninitialised and >>>>> Visual Studio traps this at runtime. I assume this should perhaps be >>>>> initialised to false? (It only gets set currently when you have the >>>>> EnvLatl flag set and writing to an exr file.) >>>>> When using CMake to create the visual studio projects for OIIO, there >>>>> were a few references to just libraries without specifically splitting >>>>> debug and release up. In the case of the Tif lib, you cannot mix a debug >>>>> build of OIIO whilst linking to a release lib of Tif (TiffOpenW will >>>>> throw an exception). Basically what I'm saying is that is might be a good >>>>> idea to have the option of setting the debug and release library paths >>>>> for all dependencies (quite a few are done already, but there were a few >>>>> that I had to manually change inside Visual Studio afterwards) >>>>> >>>>> Best Regards, >>>>> Simon >>>>> >>>>> --- >>>>> Simon C Smith >>>>> Co-Founder & CTO >>>>> www.lightmap.co.uk >>>>> >>>>> On 11 Jun 2015, at 18:05, Larry Gritz wrote: >>>>> >>>>>> Which version of OIIO is this? And precisely what was the maketx command >>>>>> line you used to create the texture? >>>>>> >>>>>> I recommend using maketx's "--prman" option, which sets several other >>>>>> options automatically. PRMan is extremely picky and can crash in weird >>>>>> ways with a TIFF texture file that defies its expectations. >>>>>> >>>>>> If a modern maketx (let's say, 1.5 or newer) and the --prman option >>>>>> don't fix it, then let's take a closer look at exactly what's going on. >>>>>> I'm also concerned that PRMan itself may somehow (on Windows only?) be >>>>>> linked against a very old libtiff that doesn't understand the zip >>>>>> compression. You could also try "--compression none" on the maketx >>>>>> command line just to rule this out, of if that confirms a problem, then >>>>>> try another compression (--compression lzw perhaps?). >>>>>> >>>>>> -- lg >>>>>> >>>>>> >>>>>> On Jun 11, 2015, at 9:24 AM, Simon Smith <[email protected]> wrote: >>>>>> >>>>>>> Hi Larry, >>>>>>> >>>>>>> Thanks for pointing me in the right direction - that call is kind of >>>>>>> obvious in hind sight :) >>>>>>> >>>>>>> OK, so the tx file gets written just fine, and I can happily load it >>>>>>> back into the same texture system (i.e., OIIO is happy with it) but >>>>>>> when I try to use this file in Maya 2015 (with RMS 19.0) I get an error >>>>>>> that reads along the lines of: >>>>>>> >>>>>>> rfm Error: T03007 Bad texture data in "TIFFReadDirectory: test.tex: Can >>>>>>> not read TIFF directory count". >>>>>>> rfm Error: T03007 Bad texture data in "test.tex: AdobeDeflate tile >>>>>>> decoding is not implemented". >>>>>>> >>>>>>> Using oiiotools, this is what the image is looking like (which looks OK >>>>>>> to me when compared to other tex files that RMS is happy with) >>>>>>> >>>>>>> ImagTools\oiiotool.exe -v -info test.tex >>>>>>> Reading test.tex >>>>>>> test.tex : 200 x 100, 4 channel, float tiff >>>>>>> MIP-map levels: 200x100 100x50 50x25 25x12 12x6 6x3 3x1 1x1 >>>>>>> channel list: R, G, B, A >>>>>>> tile size: 32 x 32 >>>>>>> oiio:BitsPerSample: 32 >>>>>>> ImageDescription: "SHA-1=E6A372868A822A176B1A0425A59914FFCAA836D0" >>>>>>> Orientation: 1 (normal) >>>>>>> DateTime: "2015:06:11 16:58:52" >>>>>>> textureformat: "Plain Texture" >>>>>>> wrapmodes: "black,black" >>>>>>> fovcot: 2 >>>>>>> tiff:PhotometricInterpretation: 2 >>>>>>> tiff:PlanarConfiguration: 2 >>>>>>> planarconfig: "separate" >>>>>>> tiff:Compression: 8 >>>>>>> compression: "zip" >>>>>>> IPTC:Caption: "SHA-1=E6A372868A822A176B1A0425A59914FFCAA836D0" >>>>>>> >>>>>>> Has anyone come across this issue before? >>>>>>> I wondered if it was something to do with the version of libTiff or >>>>>>> ZLib that i compiled OIIO against (looks like we are using tiff-4.0.3 & >>>>>>> 1.2.8 of zlib). >>>>>>> Or maybe I've just missed something off the ImageSpec. >>>>>>> >>>>>>> I'm running this under Windows - if that makes any difference at all! >>>>>>> >>>>>>> Thanks for any help in advance! >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> Simon >>>>>>> >>>>>>> --- >>>>>>> Simon C Smith >>>>>>> Co-Founder & CTO >>>>>>> www.lightmap.co.uk >>>>>>> >>>>>>> On 23 Apr 2015, at 00:10, Larry Gritz wrote: >>>>>>> >>>>>>>> You already have the image data in memory? If the pixels are all >>>>>>>> contiguous, you can create an ImageBuf that "wraps" your buffer >>>>>>>> without allocating its own memory or doing any copying. >>>>>>>> >>>>>>>> Let's say you have 8 bit pixels like this: >>>>>>>> >>>>>>>> unsigned char pixels[HEIGHT][WIDTH][CHANS]; >>>>>>>> >>>>>>>> Then wrap: >>>>>>>> >>>>>>>> ImageBuf buf (ImageSpec(WIDTH,HEIGHT,CHANS,TypeDesc::UINT8), >>>>>>>> pixels); >>>>>>>> >>>>>>>> Then make the texture: >>>>>>>> >>>>>>>> ImageSpec config; // read the docs to know what to do with >>>>>>>> this >>>>>>>> ImageBufAlgo::make_texture (ImageBufAlgo::MakeTxTexture, buf, >>>>>>>> "texturename.tx", config); >>>>>>>> >>>>>>>> >>>>>>>> On Apr 22, 2015, at 3:09 AM, Simon Smith <[email protected]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm pretty sure I'm missing something simple here ... >>>>>>>>> >>>>>>>>> I can happily convert from one file format to another by creating a >>>>>>>>> suitable ImageSpec and calling ImageBufAlgo::make_texture with the >>>>>>>>> spec, input, and output filenames. >>>>>>>>> >>>>>>>>> I have an alternative scenario where I have the image data in memory >>>>>>>>> (linear, RGBA floating point data) and I want to get that into a >>>>>>>>> similar renderman compliant file on disk. It doesn't look like >>>>>>>>> ImageBufAlgo can help me here as they require either an existing >>>>>>>>> file, or an ImageBuf object with such an ImageSpec. >>>>>>>>> >>>>>>>>> How do I go about creating such a file from what I have as input? >>>>>>>>> I'm pretty sure I'm missing something obvious … how to craft >>>>>>>>> arbitrary raw image data with an ImageSpec into an ImageBuf in memory. >>>>>>>>> >>>>>>>>> Any pointers welcome! >>>>>>>>> >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> --- >>>>>>>>> Simon C Smith >>>>>>>>> Co-Founder & CTO >>>>>>>>> www.hdrlightstudio.com >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> Larry Gritz >>> [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 > > -- > 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
