Your fix does seem to work, and makes sense to me. I will prepare a pull
request for it. I also saw another couple unrelated fixes while I was in there.
-- lg
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
