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
