Hi Larry,
sorry my mistake.
The file I sent is the one that triggers the crash, I was wrongly
thinking it had only 2 channels. I just checked it on photoshop, it has
4 channels, R G and B are identical, hence the grayscale result.
I was getting confused with another crash I have when mipmaps are
getting computed on a single channel file. (i'll get back on this topic
after I have done some investigation.)
Back on the crash. I'm crash on when "x" = 1536, "y"=536, it's a
2048*2048px image.
What's currently puzzling me is that the xstride and ystride are
respectively 4 and 8096 in the premult function. I am only reading a
channel, so my data buffer has only 2048*2048 cells. I'm completely off
my data buffer.
I'm calling read_scanline with autostride, and asking for a single
channel. The data buffer i'm passing as parameter has only space for one
channel.
In TIFFInput::read_scanlines the call to ImageInput::read_scanlines
seems to work correctly as bypassing the convert_alpha gives a correct
image and no crash.
Thinking about it, things start to get messy in premult: how can the
premult function work when we read only one channel ?
Looking at the premult function, I think there may be another bug: at
the beginning of the function we're calling the ImageSpec::autostride
function giving as parameter not the number of channels we want but the
number of channels there is in the file. If you have RGBAZ in the file,
and only read RGBA, the premult shouldn't be able to work at the stride
will be 5, but the data buffer should only contains RGB and A.
Blundly, I'd said we need to modifications: in TIFFInput::read_scanlines
do not call premult if the alpha channel has no been read. In fact, we
should only call it if all beauty channels have been read, it doesn't
really make any sense other wise.
Secondly, the premult function should check the number of channels read
instead of the number of channels there are in the files.
It seems so obvious I'm wondering if i'm on the good path here. Maybe
i'm simply not calling read_scanline correctly ?
Any help is welcome !
On 01/12/2016 07:04 PM, Larry Gritz wrote:
The last file you pointed me to is 4 channel, not 2 channel. Can you
send me an example file that exhibits this problem?
-- lg
On Jan 12, 2016, at 9:53 AM, Larry Gritz <[email protected]
<mailto:[email protected]>> wrote:
OK, I see, totally different problem that was only coincidentally
also involving unassociated files.
Hang on, let me try your file again...
On Jan 12, 2016, at 8:45 AM, Michel Lerenard <[email protected]
<mailto:[email protected]>> wrote:
Hi
sorry about not testing this sooner, it took my some time to
understand what's going on.
I've removed the modification I made to keep unassociated alpha, and
updated to OIIO 1.6.10.
My app crashes the same way it was crashing before when loading my
test file, so I guess your patch didn't have any effect on this issue.
It's very weird that you didn't get the crash.
Here's the stack I get:
#0 0x7f2fbfbdcde7 in
_ZN11OpenImageIO4v1_612convert_typeIhfEET0_RKT_
(0x1ebde7:0x1ebdb6+0x31) from ./libOpenImageIO.so.1.6
#1 0x7f2fbfc71cad in _ZNK11OpenImageIO4v1_69DataProxyIhfEcvfEv
(0x280cad:0x280c92+0x1b) from ./libOpenImageIO.so.1.6
#2 0x7f2fbfc6765a from ./libOpenImageIO.so.1.6
#3 0x7f2fbfc663e4 in
_ZN11OpenImageIO4v1_67premultEiiiiiiNS0_8TypeDescEPvlllii
(0x2753e4:0x2752a1+0x143) from ./libOpenImageIO.so.1.6
#4 0x7f2fbfff9a47 in
_ZN11OpenImageIO4v1_69TIFFInput14read_scanlinesEiiiiiNS0_8TypeDescEPvll
(0x608a47:0x608920+0x127) from ./libOpenImageIO.so.1.6
I guess the issue is here, in premult_impl:
DataArrayProxy<T,float> val ((T*)pixel);
_*float alpha = val[alpha_channel];*_
for (int c = chbegin; c < chend; ++c) {
alpha_channel is set to 3 in the spec, but the file only has a
luminance and an alpha channel.
My call to OIIO is:
if(file->read_scanlines(y_start, y_end, 0, i, 1, spec.format, out_data))
'i' being the index of the current channel to read: I'm reading
channel one after the other.
I hope this can help.
On 01/06/2016 08:36 AM, Larry Gritz wrote:
I am unable to reproduce, and suspect it is fixed by this
patch:https://github.com/OpenImageIO/oiio/pull/1278
That should be in both the current master and RB-1.6.
Can you confirm on your end?
-- lg
On Jan 5, 2016, at 4:47 AM, Michel Lerenard<[email protected]> wrote:
Hi,
First, happy new year to all of you. May 2016 be bug free. ;)
Sorry to bother you again with this, but did anyone had some time to have a
look at the file attached ?
On 10/26/2015 09:21 AM, Michel Lerenard wrote:
Sorry, I didn't realize the website converted the file when I uploaded it.
It seems all site are converting the picture to their own format, so here's the
file on a standard hosting site:
http://s000.tinyupload.com/index.php?file_id=42596689254225391199
Hopefully it should work.
On 10/23/2015 07:34 PM, Larry Gritz wrote:
I'm confused, that's a png file, how does it ever hit TIFFInput::read_scanlines?
On Oct 23, 2015, at 9:07 AM, Michel Lerenard<[email protected]> wrote:
Hi,
I've encountered a file that makes OIIO crashes during load. The file has an
unassociated alpha channel, and by default OIIO tries to premult it in
TIFFInput::read_scanlines.
The process crashes.
I can prevent the crash by adding "config.attribute ("oiio:UnassociatedAlpha",
1);" into my config spec before I load the file.
I've upped the file here, if anyone can have a look at it ?
http://s28.postimg.org/df6s8zbn1/zlf_density.png
I'm wondering if I can detect that the process will fail and add the flag at
load ?
I made a test with a smaller file (256*256), and it does no crash, weirdly.
Thanks.
Michel
--
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] <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] <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
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
