Works for me. Here's the pull request, and while I was there I noticed another problem with TGA reads and fixed it:
https://github.com/OpenImageIO/oiio/pull/587 Let me know if you need this backported to any release branches, or if the master is sufficient for you. Also if you are working with TGA files, it would be helpful for you to grab this pull request and test it on your end (including my fixes) to confirm that it works for you and doesn't break anything else. I have a limited number of TGA files to test against. On Apr 29, 2013, at 12:16 AM, Michel Lerenard wrote: > Yes of course. > > I've attached the file to this message. > > > On 04/29/2013 01:01 AM, Larry Gritz wrote: >> >> This sounds reasonable. >> >> Can you send me an example TGA that has this problem? >> >> >> On Apr 24, 2013, at 6:13 AM, Michel Lerenard wrote: >> >>> Resuming my previous monologue... >>> >>> Digging a bit in the targa plugin i found that no check was done between >>> the flags of the channels and the actual channels in the file. >>> >>> I modified the code from >>> >>> m_alpha = (m_tga.attr & 0x0F) > 0 ? TGA_ALPHA_USEFUL : TGA_ALPHA_NONE; >>> >>> to >>> >>> m_alpha = TGA_ALPHA_NONE; >>> if (((m_tga.type == TYPE_RGB || m_tga.type == TYPE_RGB_RLE) && >>> m_tga.bpp == 32 ) >>> || ((m_tga.type == TYPE_GRAY || m_tga.type == TYPE_GRAY_RLE) && >>> m_tga.bpp > 8 )) { >>> m_alpha = (m_tga.attr & 0x08) > 0 ? TGA_ALPHA_USEFUL : >>> TGA_ALPHA_NONE; >>> } >>> >>> The idea is to make sure there is a channel in the file, even if the flag >>> says the data is used. In the file I have, the m_tga.attr value is equal >>> to 8, which is, as far as I understand, absolutely inconsistent with the >>> channel in the file. >>> If I understand the meaning of the flag, I should be set to 1, meaning the >>> first channel has useful information, instead of 8 meaning the last channel >>> (here, alpha), has useful info. >>> >>> I'd appreciate very much if someone could tell me if my fix is correct, and >>> if i understood correctly how the tga header work ? >>> Thanks. >>> >>> PS : I used this page http://www.paulbourke.net/dataformats/tga/ to get TGA >>> specs. >>> >>> On 4/24/2013 1:30 PM, Lerenard Michel wrote: >>>> I found why OIIO finds two channels in the file. The tga_alpha_type of the >>>> file has been set to TGA_ALPHA_UNDEFINED_RETAIN. >>>> >>>> I do not know how TGA works, I then have a question: what is the use of >>>> such a flag ? How is it set ? Can i ignore it ? >>>> >>>> To be able to load correctly this type of file (ie discard the alpha >>>> layer), i have to parse the data buffer returned by OIIO, and it costs >>>> quite some time. I there another way to detect such an empty channel >>>> before calling "read_scanlines" which i use ? >>>> >>>> >>>> 2013/4/24 Michel Lerenard <[email protected]> >>>> Hi, >>>> >>>> I've spotted a weird behavior when opening grayscale files, i'm wondering >>>> if I have to check something else in the header or if it is the >>>> correct behavior: the ImageSpec structure tells me there are >>>> two channels in the file, one called 'I' and another called 'A', which is >>>> absolutely black. (ie empty ?) >>>> >>>> The file i'm opening is a simple black and white TGA used as a mask, with, >>>> according to Gimp, photoshop, xnview, etc... a single color channel. ( 8 >>>> bits ) >>>> Is there a way to check if a given channel is empty ? Apparently the file >>>> does not hold any data for alpha, so i'm wondering if OIIO is creating an >>>> alpha channel for compatibility and if I should check some attributes to >>>> detect if there is actually any data in it ? >>>> >>>> >>>> Thanks for your help. >>>> >>> >>> _______________________________________________ >>> 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 > > <monochrome.tga>_______________________________________________ > 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
