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
