Reading the PNG appears to be correct, it gets identified as YA and spec.alpha_channel is 1. I'm more concerned about the resulting .tx (TIFF) or .exr files. iinfo also reports it as YA.
When writing to .tx file, I can trace maketx through TIFFOutput::open() and see that it writes a file with TIFFTAG_SAMPLESPERPIXEL=2. It does however not set TIFFTAG_EXTRASAMPLES, as that only gets set when m_spec.nchannels > 3. Later, when reading that .tx file, TIFFInout::readspec() looks at TIFFTAG_EXTRASAMPLES to figure out whether or not there is an alpha channel. As the tag is not present in the .tx file, alpha_channel now remains -1 and the texture cache interprets it as an RG TIFF file and does not recognise it as YA. iinfo also lists the channels of the image as RG. For what it's worth, I notice that 3rd party programs have trouble opening the resulting .tx file as TIFF. I suppose two channel TIFF files are just not common enough? OpenEXR seems somewhat better. There the converted channels are marked as Y and A, but the order is revesed - A has index 0, Y is at index 1. However, fill_gray_channels() doesn't look for A or Y channels by their names, it simply looks at whether an image has two channels with the alpha being at index 1. The case of two channels, alpha at 0 seems to be ignored and does not get converted from AY to YYYA. -Stefan On Tue, Jul 4, 2017 at 10:28 PM, Larry Gritz <[email protected]> wrote: > The idea is supposed to be that gray_to_rgb is only concerned with the > special case of turning Y->RGB and YA->RGBA (I'm using Y to signify > greyscale luminance). If it's a 2-channel image where the second channel > isn't alpha (let's call it JK), in general you don't want to wreck it by > changing it to a 4-channel image JJJK, that would be confusing. > > So it seems like the real bug might be that when the original image is > read, it's not setting alpha_channel correctly, so it's seeing a 2-channel > image but not recognizing it as the YA special case. > > In png_pvt.h, there is code circa line 7: > > if (spec.nchannels == 2) { > // Special case: PNG spec says 2-channel image is Gray & Alpha > spec.channelnames[0] = "Y"; > spec.channelnames[1] = "A"; > spec.alpha_channel = 1; > } > > that sure makes it seem like any 2-channel PNG image that is input will > necessarily know that channel 1 in alpha, so I'm not sure where things go > wrong. > > Can you maybe send me an image that exhibits this problem? I'd like to > trace through the logic and see how and why in the PNG gets confused about > what the channels mean. (Or, feel free to take a stab at that yourself as > well.) > > > > On Jul 4, 2017, at 12:40 PM, Stefan Werner <[email protected]> wrote: > > > > Hi, > > > > I ran across one texture that I can’t quite figure out how to deal with > it correctly using TextureSystem. The original texture is a gray scale PNG > with alpha channel, and I’m converting it with maketx. I’m trying to get > that back as RGBA via the gray_to_rgb=1 option in the texture cache, but I > always get the gray channel as R and the alpha channel as G, with B and A > empty/default. > > > > I stepped through the code, and I see that in > TextureSystemImpl::fill_gray_channels(), line 848, the case for two > channel input files only does the conversion when spec.alpha_channel = 1. > When I use TIFF for my cache file format, spec.alpha_channel is -1, when I > use OpenEXR as cache file format, spec.alpha_channel is 0. Maketx > apparently only marks TIFF as containing an alpha channel when there are 4 > or more channels, see tiffoutput.cpp line 485. OpenEXR does set the channel > name to alpha. > > > > Is there a reason that fill_gray_channels() checks for index of the > alpha channel rather than just its presence? Is there any way that I can > get this texture to be read as RGBA through the texture cache? > > > > Thanks, > > Stefan > > _______________________________________________ > > 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] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
