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
