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] > <mailto:[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 <http://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 <http://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] >>>> <mailto:[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 <http://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] >>>>>> <mailto:[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 <http://www.hdrlightstudio.com/> >>>>>>> _______________________________________________ >>>>>>> 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 >>> <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
