[Gs-devel] Re: color_info.depth

Dan Coby dan at artifex.com
Mon Sep 17 23:00:58 PDT 2001


Peter,

Thanks for the response.

>As far as I know, 4 bit RGB does not work.  The only device I can think of
>that produces 4-bpc RGB output, tiff12nc, is a 24 bit device internally: it
>discards the low 4 bits of each byte when writing the output file.

The "bit" devices and the "pbm" devices also look at the GrayValues,
RedValues, etc., device parameters and change the number of bits per
component.
Thus they can also try to produce 4 bit RGB but will have problems.
Likewise
they will have similar problems with 4 and 5 bit CMYK.  It looks like these
devices should keep a separate "bitspercomponent" value instead of relying
upon dividing depth by ncomp.  People must not be using these devices in
these modes or we would be receiving some complaints.


>There are assumptions in various places that 24-bit devices are 8-bpc RGB.
>See, for example, gdevm24.c.

Thanks for the information.  I will add this to list of things that I need
to keep an eye on for DeviceN color.  You said "for example, gdevm24.c".
Any other places that you can remember?


>Ghostscript's use of "opaque" native gx_color_index values also avoids
>making assumptions about the order in which components are packed into a
>device pixel, the amount and location of padding if any, etc.  Those issues
>are left up to the driver.
>
>The current scheme works reasonably well for the 3 standard colorant sets
>(DeviceGray/RGB/CMYK) with the most common component depths.  It will need
>some new thinking to handle open-ended colorant sets.

I agree that having gx_color_index be "opaque" is desirable.  In general if
we do need some information about what a device is doing with a
gx_color_index
or anything else then the information should come from the driver rather
than be inferred.  For the most part, the current code follows that theory.
The major exception being the assumptions which are made about the device's
process color model based upon the number of colorants.  I assume that this
derives simply from the way that the handling of process color models have
evolved within Adobe's image model.

The implementation of DeviceN color does require more information to come
back from the device.  The most obvious new information is a specification
of the device's process color model instead of inferring it from the number
of colorants.


Dan



-----Original Message-----
From: gs-devel-admin at ghostscript.com
[mailto:gs-devel-admin at ghostscript.com]On Behalf Of L. Peter Deutsch
Sent: Monday, September 17, 2001 11:39 AM
To: dan at artifex.com
Cc: gs-devel at ghostscript.com
Subject: [Gs-devel] Re: color_info.depth


Dan, I'm moving the discussion to gs-devel, and including your original
message.

> The color_infor structure contains a filed called "depth".  This field
> has a comment of (gxdevcli.h):  /* # of bits per pixel */
>
> The value also seems to be rounded up to the nearest byte unless the value
> will fit evenly into a byte.  Thus legal values are 1, 2, 4, 8, 16, 24 and
> 32.

Correct.

> I also notice that there are many places that calculate the number of bits
> per component by taking the depth and dividing by the number of
> components.

Correct.

> 1.  If the device is an RGB device (real_ncomp=3) and bpc is 4
> (RedValue=16) then the depth is 16.  But depth/3 = 5 (not 4).  This seems
> like a problem.  Does anyone know if 4 bit RGB works?  If so how?  I note
> that in gdevpbm.c (which contains similar logic to gdevbit.c) that the 5
> bit case is only allowed for RGB.  Both facts seem curious.

As far as I know, 4 bit RGB does not work.  The only device I can think of
that produces 4-bpc RGB output, tiff12nc, is a 24 bit device internally: it
discards the low 4 bits of each byte when writing the output file.

> 2.  For a CMYK device and 5 bit color, the depth is 32 and not 24.  The
> required number of bits is only 20.  Thus it would seem that 24 would be
> enough.  Is there another requirement that I do not know about?

There are assumptions in various places that 24-bit devices are 8-bpc RGB.
See, for example, gdevm24.c.

This does, however, bring up a larger issue.  Ghostscript currently works
quite hard not to assume that device color values (gx_color_index) consist
of separate fields for the different components.  More specifically,
Ghostscript is explicitly intended to support devices that use indexed color
as their native color space, and do their own color management.  This was
essential for reasonable performance on indexed-color displays, to avoid
forcing the driver to do color mapping / color management / halftoning /
etc. at a later and less efficient stage of rendering, and I think it is
still valuable.  For this reason, Ghostscript's bitmap processing code
distinguishes between "native" (a.k.a. DevicePixel) and "standard" device
color representation, e.g., in src/gxbitfmt.h.

Ghostscript's use of "opaque" native gx_color_index values also avoids
making assumptions about the order in which components are packed into a
device pixel, the amount and location of padding if any, etc.  Those issues
are left up to the driver.

The current scheme works reasonably well for the 3 standard colorant sets
(DeviceGray/RGB/CMYK) with the most common component depths.  It will need
some new thinking to handle open-ended colorant sets.

--

L. Peter Deutsch     |    Aladdin Enterprises   |  203 Santa Margarita Ave.
ghost at aladdin.com    |  http://www.aladdin.com  |  Menlo Park, CA 94025

	The future of software is at http://www.opensource.org

----------------------------------------------------------------

From: "Dan Coby" <dan at artifex.com>
Subject: color_info.depth
Date: Fri, 14 Sep 2001 15:49:36 -0700

I have a couple questions that have come up looking at the color_info
structure inside of the device structure.

The color_infor structure contains a filed called "depth".  This field
has a comment of (gxdevcli.h):  /* # of bits per pixel */

The value also seems to be rounded up to the nearest byte unless the
value will fit evenly into a byte.  Thus legal values are 1, 2, 4, 8, 16,
24 and 32.

For instance this piece of code in gdevbit.c calculates the depth from
the number of bits per component and the number of components.

This translation array is defined:

    static const byte depths[4][8] = {
	{1, 2, 0, 4, 8, 0, 0, 8},
	{0},
	{4, 8, 0, 16, 16, 0, 0, 24},
	{4, 8, 0, 16, 32, 0, 0, 32}
    };

Then the number of values is determined and the number of bits per component
is calculated:

    if ((code = param_read_int(plist, (vname = "GrayValues"), &v)) != 1 ||
	(code = param_read_int(plist, (vname = "RedValues"), &v)) != 1 ||
	(code = param_read_int(plist, (vname = "GreenValues"), &v)) != 1 ||
	(code = param_read_int(plist, (vname = "BlueValues"), &v)) != 1
	) {
	if (code < 0)
	    ecode = code;
	else
	    switch (v) {
		case   2: bpc = 1; break;
		case   4: bpc = 2; break;
		case  16: bpc = 4; break;
		case  32: bpc = 5; break;
		case 256: bpc = 8; break;
		default:
		    param_signal_error(plist, vname,
				       ecode = gs_error_rangecheck);
	    }
    }

Then a value for the depth is determined:

    pdev->color_info.depth = depths[real_ncomps - 1][bpc - 1];


I also notice that there are many places that calculate the number of bits
per component by taking the depth and dividing by the number of components.

The questions that I have are:

1.  If the device is an RGB device (real_ncomp=3) and bpc is 4 (RedValue=16)
then the depth is 16.  But depth/3 = 5 (not 4).  This seems like a problem.
Does anyone know if 4 bit RGB works?  If so how?  I note that in gdevpbm.c
(which contains similar logic to gdevbit.c) that the 5 bit case is only
allowed for RGB.  Both facts seem curious.

2.  For a CMYK device and 5 bit color, the depth is 32 and not 24.  The
required number of bits is only 20.  Thus it would seem that 24 would be
enough.  Is there another requirement that I do not know about?


Dan

----------------------------------------------------------------
_______________________________________________
Gs-devel mailing list
Gs-devel at ghostscript.com
http://www.ghostscript.com/mailman/listinfo/gs-devel




More information about the gs-devel mailing list