Hi Larry, there’s a slight misunderstanding here. testtex using the png file works fine for me too. What isn’t working for me is when I insert a conversion to a mip map in between:
so either: $ dist/macosx/bin/maketx picture_frame_friedrich_nietzsche.png $ build/macosx/src/testtex/testtex -res 256 256 picture_frame_friedrich_nietzsche.tx -graytorgb -o out.exr or $ dist/macosx/bin/maketx picture_frame_friedrich_nietzsche.png -o picture_frame_friedrich_nietzsche.exr $build/macosx/src/testtex/testtex -res 256 256 picture_frame_friedrich_nietzsche.exr -graytorgb -o out.exr give me screwed up colors. This is using OIIO master, commit a4c784575b8e93e788f2e7fafd8a39fde68f364f (June 30th) My apologies, I realise now that I should have used the maketx/testtex sequcence from the beginning, this makes it much easier to report issues than trying to describe it it in words. -Stefan On 6. Jul 2017, at 18:08, Larry Gritz <[email protected]> wrote: Stefan, thanks for sending me (offline) the test case. Unfortunately, it works for me! Simple test: $ build/macosx/src/testtex/testtex -res 256 256 picture_frame_friedrich_nietzsche.png -o out.exr And I can see the colors are screwed up because channel 0 is being used for red, channel 1 (actually alpha) for green, and fill color for blue. Turn on the gray_to_rgb attribute: $ build/macosx/src/testtex/testtex -res 256 256 picture_frame_friedrich_nietzsche.png -graytorgb -o out.exr And it all looks fine. So I think it's working properly. Maybe whatever is going wrong is somehow specific to the sequence in which you are setting up the texture system, turning on the gray_to_rgb attribute, etc.? I tested both the current master as well as the current release branch (1.7.15). What version of OIIO are you using? Maybe you have stumbled across a problem that has already been fixed? Can you start by replicating the commands I have above and see if just the 'testtex' example works for you? On Jul 5, 2017, at 4:59 AM, Stefan Werner <[email protected]> wrote: 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 -- 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
