Here's my proposed solution to proper detection and rejection of the subsampled channels: https://github.com/OpenImageIO/oiio/pull/1849 <https://github.com/OpenImageIO/oiio/pull/1849>
> On Jan 20, 2018, at 11:39 AM, Larry Gritz <[email protected]> wrote: > > 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] >> <mailto:[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 >>> <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
