Great. I cleaned up a little more and pushed an update.
How badly do you need this in a release branch? It doesn't change any public
APIs or link compatibility, but I'm worried that some people may inadvertently
have scripts that depend on oiiotool's old behavior (not exiting when certain
errors are encountered), so I'm hesitant to backport it. If you need it in a
release branch, I think that at least we should let it sit in master for a
while before porting it to RB-1.4, to give the people working out of master a
while to encounter any possible problems.
-- lg
On Jun 22, 2014, at 4:08 AM, Sebastian Elsner <[email protected]> wrote:
> Great! Your changes work for my usecase. Thanks!
>
> Am 21.06.2014 23:23, schrieb Larry Gritz:
>> I think I've addressed a lot of this in
>> https://github.com/OpenImageIO/oiio/pull/888
>>
>> We were just dropping a lot of errors on the floor.
>>
>>
>> On Jun 19, 2014, at 11:36 PM, Sebastian Elsner <[email protected]> wrote:
>>
>>> I see. Since iconvert does fail, I thought this is an oversight in
>>> oiiotool. A command line flag is totally fine. Just to be sure, I dont know
>>> if it makes any difference: I am not talking about tiled images. These are
>>> scanline images.
>>>
>>>
>>>
>>> Am 20.06.2014 08:18, schrieb Larry Gritz:
>>>> How about a command-line option for oiiotool that would trigger a failure
>>>> upon a tile read error?
>>>>
>>>> I don't necessarily want it to be the default, because apparently an EXR
>>>> file which is missing tiles is still a proper EXR file, and at my work we
>>>> have a couple circumstances where this is used purposely and need those
>>>> images to process correctly.
>>>
>>>>
>>>>
>>>>
>>>> On Jun 19, 2014, at 11:06 PM, Sebastian Elsner <[email protected]>
>>>> wrote:
>>>>
>>>>> With the image incomplete.exr (rendered by Houdini as scanline, zip1,
>>>>> pixel data is missing from scanline 139 on) execute:
>>>>>
>>>>> oiiotool.exe incomplete.exr --autotrim -o incomplete_trimmed.exr
>>>>>
>>>>> This will write the output image and not complain about the broken input
>>>>> image. In my mind this should error (message to stderr), return an error
>>>>> code and NOT write a totally black incomplete_trimmed.exr. This is even
>>>>> more important when working on incomplete.exr in-place:
>>>>>
>>>>> oiiotool.exe incomplete.exr --autotrim -o incomplete.exr
>>>>>
>>>>> Right now the half-rendered incomplete.exr is overwritten by an empty exr.
>>>>>
>>>>>
>>>>> Am 20.06.2014 07:37, schrieb Larry Gritz:
>>>>>> I'm not sure that any behavior with incomplete images is "intentional".
>>>>>> Whatever we do with incomplete image that isn't to your liking, is
>>>>>> either a bug, or a default behavior that we haven't really thought
>>>>>> through.
>>>>>>
>>>>>> Can you give an example oiiotool command line involving this image, and
>>>>>> explain what you'd like it to do in that case?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jun 18, 2014, at 12:24 AM, Sebastian Elsner <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> On a second note I found that oiiotool is also not setting the correct
>>>>>>> exitcode (1) when dealing with broken images of any kind.
>>>>>>>
>>>>>>>
>>>>>>> On 06/16/2014 03:05 PM, Sebastian Elsner wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> sometimes we have incomplete exrs from renderings. When using oiiotool
>>>>>>>> to convert those images, oiiotool will silently convert them ignoring
>>>>>>>> the incomplete/broken file state, resulting in completely black
>>>>>>>> converted images. I think it would be better for oiiotool to fail in
>>>>>>>> this case. Other tools (like iconvert) already do. Or is this
>>>>>>>> behaviour intentional? (I have attached a small image demonstrating
>>>>>>>> the issue).
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>
>>>>>> --
>>>>>> 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
>>
>> --
>> 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
