Thanks for the sanity check Larry - it was a dependencies linking issue that I 
have now fixed.

That said, whilst the image looks just fine in VI, the information about the 
image says that the format is still float - I thought it would say half like it 
does when you use oiiotool --info -v to dump the file information out (which 
does indeed say half).


Regarding the no-mipmap, this was set purely for other test reasons - normally 
it would not be there.

Best Regards,
   Simon

---
Simon C Smith
Co-Founder & CTO
www.hdrlightstudio.com

On 1 Oct 2014, at 07:59, Larry Gritz wrote:

> Since it looks fine for you in Preview.App as well as IrfanView, I think we 
> should assume that the maketx portion is working fine and the problem is iv 
> or something else about reading the image back.
> 
> It also looks fine for me in iv (compiled from the master, running on OSX). 
> What version of OIIO are you using? Maybe it's something that has already 
> been fixed.
> 
> Additional test: if you convert the output to any other data format, can you 
> then view it?
> 
>       oiiotool test_halfConverted.exr -d float -o float.exr
>       oiiotool test_halfConverted.exr -d uint8 -o uint8.tif
> 
> And see if you can display those ok. (If so, then further evidence that it's 
> strictly on the iv side, and particular to the data format).
> 
> As an aside, the image you attached is 16 bit float and tiled, but does not 
> appear to have MIP levels. I'm somewhat concerned about the "maketx:nomipmap" 
> line. Did you have that for a reason? It's pretty unusual to specifically 
> request not to make MIP levels.
> 
>       -- lg
> 
> 
> On Sep 30, 2014, at 9:44 AM, Simon Smith <[email protected]> wrote:
> 
>> Hi guys, just looking for some pointers/help here.
>> 
>> I have a 32-bit floating point lat/long EXR file on disk, and I want to 
>> convert it to a tiled & mipampped16-bit (half) file via code.
>> 
>> So, I create a new image spec setting just the following:
>> 
>> ImageSpec cFinalImageSpec;
>> cFinalImageSpec.attribute ("maketx:fileformatname", "exr");
>> cFinalImageSpec.format = TypeDesc::HALF;
>> cFinalImageSpec.attribute ("maketx:nomipmap", false);
>> 
>> Then I call:
>> 
>> ImageBufAlgo::make_texture(ImageBufAlgo::MakeTxEnvLatl, fileIn, fileOut, 
>> cFinalImageSpec);
>> 
>> This generates a file OK, but if I load it with IV, it comes out looking 
>> quite corrupt (from the point of view that the pixel colours look wrong, but 
>> the general "shape" of the image is correct). If I bring up the image 
>> information in IV, it states that it's a float format, which it should not.
>> 
>> Interestingly, if I load it into IrfanView, it all looks fine (as does the 
>> preview of them both on my Mac).
>> 
>> Any suggestions? It's driving me nuts trying to work out why IV seems to 
>> think it's a floating point format, yet it should have been written out as a 
>> half format.
>> Perhaps I should not be using ImageBufAlgo::make_texture to convert …
>> I have build OpenEXR (including the IV viewer etc) from source here (based 
>> on 2.1) - I did wonder if something has not quite gone right in the 
>> compilation.
>> I'm running this under Windows too.
>> 
>> I have attached a before/after exr image - it's a 200x100 black image, with 
>> a small green circle in the middle as a test.
>> The before is a 32-bit float, scan line image.
>> The after is a 16-bit half, tiled image.
>> 
>> Best Regards,
>>    Simon
>> 
>> <test_32-bit.exr>
>> <test_halfConverted.exr>
>> _______________________________________________
>> 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

Reply via email to