Some more info on this topic...
I upgraded to libtiff 4.0.3 and stepped through an OIIO debug build. The
call to TIFFWriteTile(), made from TIFFOutput::write_tile, from
src/tiff.imageio/tiffoutput.cpp around line 1016 still fails, with the same
specific error message coming out of libtiff ("Application transferred too
few scanlines"), which seems to indicate that it expects more of the image
to be compressed in one go. I tried various tile sizes but no luck there.
What's a bit odd is the error message is printed once per row of tiles,
instead of once per tile.
I started looking through libtiff spec and stumbled upon an interesting
section titled "Strips and Tiles" specific to Jpeg-compressed tiff files
(see http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf, page
103). Here are two sentences that caught my attention:
- "Multiple strips or tiles are supported in JPEG compressed images using
restart markers..."
- "... when the JPEGInterchangeFormat Field is present and non-zero, states
that the tile height must be equal to the height of one JPEG Minimum Coded
Unit (MCU)."
And then finally there is also this technical note in the libtiff
distribution (share/doc/tiff-4.0.3/html/TIFFTechNote2.html) which goes on
for pages about "serious problems that have been found in TIFF 6.0's design
for embedding JPEG-compressed data in TIFF".
I feel I just landed in a mine field... but still it would be useful to get
lossy compression working for 8-bit render-ready textures.
On Fri, Jul 15, 2016 at 12:33 PM, Eric Tabellion <
[email protected]> wrote:
> I also juts tried the version of maketx that ships with Arnold (4.2.13.3),
> which statically links all it can. That elegantly fails by falling back to
> using "lzw" compression.
>
> On Fri, Jul 15, 2016 at 12:17 PM, Larry Gritz <[email protected]> wrote:
>
>> I'm having trouble, too. On Linux building against libtiff 4.0.3, I seem
>> to be able to write a jpeg-in-tiff file, but can't read it (for example,
>> with iinfo --stats). But maybe only some files, because I can read the line
>> in libtiff's testsuite that is written with jpeg (quad-jpeg.tif).
>>
>> On my Mac against libtiff (4.0.6), I get the same error you reported,
>> oiiotool ERROR: -o : TIFFWriteTile failed writing tile x=0,y=0,z=0
>> (Application transferred too few scanlines)
>> TIFFWriteTile failed writing tile x=0,y=64,z=0 (Application transferred
>> too few scanlines)
>> ...
>>
>> So not sure what's going on.
>>
>> These are both with OIIO master TOT.
>>
>>
>> On Jul 15, 2016, at 10:09 AM, Eric Tabellion <
>> [email protected]> wrote:
>>
>> If this works for you or someone else on the list, would you mind posting
>> what your configuration is including versions of OIIO, libtiff, and libjpeg
>> ? I'm looking for a recommendation of what version to upgrate to.
>>
>> Thanks!
>>
>> On Thu, Jul 14, 2016 at 5:02 PM, Larry Gritz <[email protected]> wrote:
>>
>>> Well that certainly makes me suspect that perhaps your TIFF library is
>>> too old or was built with JPEG support disabled.
>>>
>>>
>>> On Jul 14, 2016, at 3:25 PM, Eric Tabellion <
>>> [email protected]> wrote:
>>>
>>> FWIW, this works fine using my local custom build and makes a valid
>>> jpeg-compressed .tif file that is recognized as such in iv / iinfo /
>>> tiffinfo:
>>>
>>> oiiotool test.exr --colorconvert linear sRGB -d uint8 --attrib
>>> CompressionQuality 90 --compression jpeg -o tmp.tif
>>>
>>>
>>> On Thu, Jul 14, 2016 at 3:03 PM, Eric Tabellion <
>>> [email protected]> wrote:
>>>
>>>> I am using OIIO 1.6.13 although using a custom build, so there are many
>>>> reasons why this could fail for me.
>>>>
>>>> It would be good to know if what I'm trying is known to be (or not be)
>>>> working, if this has been tried before, or if you think this is just plain
>>>> foolish for some reason.
>>>>
>>>>
>>>> tiffinfo, which links with the same version of libtiff and libjpeg as
>>>> maketx reports:
>>>>
>>>> tiffinfo -v
>>>> LIBTIFF, Version 3.9.4
>>>>
>>>> My test image is a 4K half-float linear .exr:
>>>>
>>>> oiiotool -v -info test.exr
>>>> Reading test.exr
>>>> test.exr : 4096 x 4096, 3 channel, half openexr
>>>> channel list: R, G, B
>>>> oiio:ColorSpace: "Linear"
>>>> compression: "zip"
>>>> a_color_render_transform: 0
>>>> a_colorspace: 1
>>>> a_format: -1
>>>> a_res: 0
>>>> dwaVersion: 200
>>>> machine: "xlimepuma.anim.dreamworks.com"
>>>> PixelAspectRatio: 1
>>>> screenWindowCenter: 0 0
>>>> screenWindowWidth: 1
>>>> uuid: "052f9d17-dc1b-46f3-abcf-8e58ff3aab93"
>>>>
>>>>
>>>>
>>>> On Thu, Jul 14, 2016 at 2:13 PM, Larry Gritz <[email protected]> wrote:
>>>>
>>>>> Which version of OIIO are you using? ("maketx --help | head")
>>>>>
>>>>> Do you know precisely which libtiff you're using, and whether it was
>>>>> compiled with JPEG support?
>>>>>
>>>>> Finally, what's the input test_linear.exr? ("oiiotool -v -info
>>>>> test_linear.exr")
>>>>>
>>>>>
>>>>> On Jul 14, 2016, at 12:14 PM, Eric Tabellion <
>>>>> [email protected]> wrote:
>>>>>
>>>>> Hi oiio-dev!
>>>>>
>>>>> I am trying to save on disk space and network bandwidth for our
>>>>> OIIO-based texture pipeline and I am wondering what is a good lossy
>>>>> compression to use for .tx files.
>>>>>
>>>>> Has anyone ever tried and/or been successful at making mipped/tiled
>>>>> "render-ready" .tx textures using good old "jpeg" compression ?
>>>>>
>>>>> I've tried this with our build of maketx and got the following error:
>>>>>
>>>>> maketx test_linear.exr -d uint8 --oiio --colorconvert linear sRGB
>>>>> --attrib CompressionQuality 90 --compression jpeg -o test_srgb.tx
>>>>>
>>>>> maketx ERROR: Write failed " : TIFFWriteTile failed writing tile
>>>>> x=0,y=0,z=0 (Application transferred too few scanlines)
>>>>> TIFFWriteTile failed writing tile x=0,y=64,z=0 (Application
>>>>> transferred too few scanlines)
>>>>> TIFFWriteTile failed writing tile x=0,y=128,z=0 (Application
>>>>> transferred too few scanlines)
>>>>> TIFFWriteTile failed writing tile x=0,y=192,z=0 (Application
>>>>> transferred too few scanlines)
>>>>> TIFFWriteTile failed writing tile x=0,y=256,z=0 (Application
>>>>> transferred too few scanlines)
>>>>> (message repeated until "y" reaches the vertical resolution of the
>>>>> input texture)
>>>>>
>>>>>
>>>>> For reference, I'm on Red-Hat 6 and maketx/OIIO uses:
>>>>>
>>>>> ldd `which maketx` | grep tiff
>>>>> libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00000036b7200000)
>>>>>
>>>>>
>>>>> Does this look familiar to anyone ? Could it be our build or version
>>>>> of libtiff that is fishy ?
>>>>> Thanks for any insight!
>>>>> :-)
>>>>> Eric
>>>>>
>>>>> --
>>>>> ---------------------------------------------------------------
>>>>> Eric Tabellion [email protected]
>>>>> R&D Staff (650)-562-9146
>>>>> PDI/Dreamworks
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ---------------------------------------------------------------
>>>> Eric Tabellion [email protected]
>>>> R&D Staff (650)-562-9146
>>>> PDI/Dreamworks
>>>>
>>>>
>>>
>>>
>>> --
>>> ---------------------------------------------------------------
>>> Eric Tabellion [email protected]
>>> R&D Staff (650)-562-9146
>>> PDI/Dreamworks
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> ---------------------------------------------------------------
>> Eric Tabellion [email protected]
>> R&D Staff (650)-562-9146
>> PDI/Dreamworks
>>
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> ---------------------------------------------------------------
> Eric Tabellion [email protected]
> R&D Staff (650)-562-9146
> PDI/Dreamworks
>
>
--
---------------------------------------------------------------
Eric Tabellion [email protected]
R&D Staff (650)-562-9146
PDI/Dreamworks
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
