Yeah, sorry about that. I fixated so quickly on "is the texture 1->3 channel
conversion somehow going awry" that I failed to notice that you said BMP, which
is an unusual enough file format that there could be something particular to
its reader.
And indeed, that is the case.
There's not really such a thing as a BMP "grayscale" image.
As I understand it, BMP files are either RGB[A] full color per pixel (24 or 32
bits), or 16 bits per pixel (where those 16 bits encode R, G, and B), or else
are "palette" images. For palette images, the number of bits per pixel
indicates the number of palette entries, e.g., 8 bits means 256 entries in the
color palette, 4 bits means only 16 colors in the palette. But either way, the
palette itself consists of entries of what they call an "RGBQUAD", so these
palette images are reported by OIIO to be RGB images (OIIO hides the palette
itself from you so that apps don't need to worry about it and can just ask for
pixel colors).
You could make an 8-bit per pixel BMP appear to encode a grayscale image by
making it a palette image in which all the palette entries coincidentally have
their RGB triplets all have equal values. But that is just trickery -- it's
still a color image, just a very, very gray-looking one because of the special
choice of which colors are in the palette.
I could imagine some surgery of the BMP reader that would make it operate as
follows: The palette is examined for whether every palette entry has the
property that R==G==B, and if so, it could report the file as being a true
1-channel image and the palette conversion for pixels can just be result =
palette[pixelval][0]. If any of the palette entries have R,G,B not all equal,
then it reports back as if it were a RGB 3-channel image as before. This is
kind of a hack -- it's taking that the BMP space says is a RGB image and lying
to report it back as at 1-channel grayscale, just because "all the RGB colors
in that image look gray enough to me". Still, it's a neat idea, and I would
welcome a patch from anybody who would make this change, but I don't have time
at the moment to do it myself.
I always thought that BMP was primarily for low-res old Windows images such as
file icons and such, and other stuff from back when images were assembled by
horse-drawn wagons. I'm a little surprised to hear that anybody is dealing with
a MILLION bmp images at 4k resolution. Can I ask what is the application of
this and whether it might be better to use a different file format? Maybe one
that not only has a proper grayscale, but also has better compression methods
than are supported by BMP?
-- lg
> On Apr 5, 2021, at 3:11 PM, Larry Gritz <l...@larrygritz.com> wrote:
>
> Oh, bmp specifically, I get it. Hang on, let me look at that case.
>
>
>
> On April 5, 2021 2:53:56 p.m. PDT, Phil Miller <philip.mil...@sri.com
> <mailto:philip.mil...@sri.com>> wrote:
> No, when I was debugging, the spec comes out with nchannels=3 instead of 1.
> Let me extract some sample reader code that I can share and I will get back
> to you.
>
> From: Oiio-dev <oiio-dev-boun...@lists.openimageio.org> On Behalf Of Larry
> Gritz
> Sent: Monday, April 5, 2021 2:58 PM
> To: OpenImageIO dev list <oiio-dev@lists.openimageio.org>
> Subject: [EXTERNAL] Re: [Oiio-dev] Reading single channel bmp
>
> There is logic in the TextureSystem so that individual texture lookups will
> expand a 1-channel greyscale image to all 3 channels of a 3-channel lookup
> (versus using the "fill" color for the second two channels).
>
> Even when using that TextureSystem option, it's only about what data value it
> copies into a user result for that individual texture lookup. It doesn't
> actually duplicate any image data in memory in the cache.
>
> But there is nothing in ImageCache or ImageBuf, as far as I can tell, that
> does anything like that. An ImageBuf that references a 1-channel file should
> just report as 1 channel.
>
> Are you doing something that indicates that it's actually replicating the
> data? Or are you just worried, based on this option of the texture system,
> that something weird might end up happening for an ordinary ImageBuf?
>
>
>
> On Apr 5, 2021, at 11:30 AM, Phil Miller <philip.mil...@sri.com
> <mailto:philip.mil...@sri.com>> wrote:
>
> I am having trouble using an ImageBuf with an ImageCache to read a single
> channel (grayscale/monochrome) bmp image as a single channel image. The spec
> in the internal oiio logic seems to always expand to 3 channels. I can use
> the force flag when I read it, but then that bypasses the cache. The images
> are fairly large (4k x 3k) and I need to read a million of them, so the
> difference between one and three channels is significant.
>
> I appreciate any help and guidance.
>
> Sincerely,
> Phil
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <https://urldefense.us/v3/__http:/lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org__;!!Nv3xtKNH_4uope0!xOYMMZQ_G451K0HfPRe1lqeW_Z4EG0Oep39UNfj0cKUGt0-jxrGFh-9CA29gUrlK$>
>
> --
> Larry Gritz
> l...@larrygritz.com <mailto:l...@larrygritz.com>
>
>
>
>
>
> --
> Larry Gritz
> l...@larrygritz.com <mailto:l...@larrygritz.com>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org <mailto:Oiio-dev@lists.openimageio.org>
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
--
Larry Gritz
l...@larrygritz.com
_______________________________________________
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
