I got an email from someone who didn't feel comfortable posting in public,
providing some of the backstory on this feature.
It seems that the channel subsampling is (a) something that hasn't been used,
even at ILM, in many years; (b) is recalled to be troublesome, and perhaps does
not work properly at all in stock copies of OpenEXR, except when using the
RgbaInputFile (which we don't, it lacks the flexibility we need).
So unless somebody says they NEED this to work, my current plan is just to
detect it and gracefully error when encountering a file with channel
subsampling.
Jordi, does your script work as intended with other exr files?
-- lg
> On Jan 20, 2018, at 10:55 AM, Larry Gritz <[email protected]> wrote:
>
> Interesting! I was able to witness strange behavior just using
>
> oiiotool -stats StarField.exr
>
> (The -stats forces it to read the pixels.)
>
> That crashes for me. So it's not your python script, and it's not the python
> bindings generally.
>
> Upon doing a debug build and running it in the debugger, I get this:
>
> Failed OpenEXR read: X and/or y subsampling factors of "BY" channel of input
> file "StarField.exr" are not compatible with the frame buffer's subsampling
> factors.
>
> Aside: I don't know why it manages to print the error and exit cleanly when
> in lldb, but when not in the debugger it triggers a crash. I looked into this
> for a few minutes but don't have a satisfactory answer.
>
> But in any case, this is an unusual file! Confirmed by running `exrheader` on
> it, which shows:
>
> channels (type chlist):
> BY, 16-bit floating-point, sampling 2 2
> RY, 16-bit floating-point, sampling 2 2
> Y, 16-bit floating-point, sampling 1 1
>
> I don't think I've ever seen any of these "subsampled" files in the wild, and
> it's not hard for me to believe that OIIO does something incorrect when
> setting up the read in that case.
>
> In 10 years of OIIO, nobody has complained or noticed this, so unless you or
> somebody else says they need it, I'm not sure it's a priority to deal with
> these files (though it may be nice to detect the case we have trouble with
> and more gracefully refuse to read it).
>
> Before proceeding, I will await feedback from you: Is this just an
> unfortunate coincidence that you chose this file and hit an edge case that we
> don't handle, and it's not something to worry about? Or are you actually
> needing to read files where the different channels have different subsampling
> rates, and we should figure out how to do it right?
>
> -- lg
>
>> On Jan 20, 2018, at 10:28 AM, Larry Gritz <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Your code looks correct to me; I'll download the image and give it a try on
>> my end.
>>
>>
>>
>>> On Jan 20, 2018, at 7:43 AM, Jordi Bares <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Thank you so much Larry… I have encountered a crash though… this is my
>>> function when dealing with this particular image
>>>
>>> https://github.com/openexr/openexr-images/blob/master/LuminanceChroma/StarField.exr
>>>
>>> <https://github.com/openexr/openexr-images/blob/master/LuminanceChroma/StarField.exr>
>>>
>>> And exists with an error likes this
>>>
>>> Fatal Python error: deallocating None
>>> Abort trap: 6
>>>
>>>
>>>
>>> THE CODE
>>>
>>> ——————————————————8<———————
>>>
>>> OK, BROKEN, SUSPICIOUS, UNKNOWN, SKIPPED, OTHER = range(0, 6)
>>>
>>> def validateImageIntegrity(_filepath, _fastMode):
>>>
>>> imageMode = ''
>>> result = OK
>>>
>>> # Exhaustive method of analysing images
>>> image = oiio.ImageInput.open(_filepath)
>>> spec = image.spec()
>>>
>>> # If this is scanline mode
>>> if spec.tile_width == 0:
>>> imageMode = 'Scanline'
>>> for y in range(spec.y, spec.y+spec.height):
>>> print 'inside scanline', y
>>> pixels = image.read_scanline(y, spec.z, oiio.UNKNOWN)
>>> if pixels == None :
>>> status = BROKEN
>>> else:
>>> imageMode = 'Tiled'
>>> for z in range(spec.z, spec.z+spec.depth, spec.tile_depth):
>>> for y in range(spec.y, spec.y+spec.height,
>>> spec.tile_height):
>>> for x in range(spec.x, spec.x+spec.width,
>>> spec.tile_width):
>>> pixels = image.read_tile(x, y, z,
>>> oiio.FLOAT)
>>> if pixels == None :
>>> status = BROKEN
>>> image.close ()
>>>
>>> return status
>>>
>>> ——>8———————————————————————
>>>
>>>
>>> Am I missing something?
>>>
>>> Thanks in advance and I hope it helps
>>> Jb
>>>
>>>
>>>
>>>> On 19 Jan 2018, at 20:14, Larry Gritz <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> There's no built-in function to do this all in one step, but it's not hard
>>>> to do "by hand".
>>>>
>>>> I think the general approach is:
>>>>
>>>> * Make an ImageInput, open the file
>>>> * For each tile of the image:
>>>> * read_tile(), observe its return code (indicating error)
>>>> * If an error occurs, the file is incomplete, note which tile is missing
>>>>
>>>>
>>>>
>>>>> On Jan 19, 2018, at 2:48 AM, Jordi Bares <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> My name is Jordi Bares and work for Framestore Advertising in the UK and
>>>>> I hope I can contribute a bit on the OpenImageIO mailing list.
>>>>>
>>>>>
>>>>> My first question is, how can I do an sanity check on an image, specially
>>>>> EXR images.
>>>>>
>>>>> Is there any way to verify if an image has been properly closed and is
>>>>> well formed? What about missing (black) tiles?
>>>>>
>>>>> I don’t see anything in the documentation referring to that… am I missing
>>>>> something?
>>>>>
>>>>>
>>>>> Thanks in advance.
>>>>> jb
>>>>
>>>> --
>>>> Larry Gritz
>>>> [email protected] <mailto:[email protected]>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>
>> --
>> Larry Gritz
>> [email protected] <mailto:[email protected]>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> [email protected] <mailto:[email protected]>
>
>
>
>
> _______________________________________________
> 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
