Subject: [IPP] (PWG) Raster Question on what is required

From: "Petrie, Glen" <[email-masked]>
Date: Thu, 28 Apr 2011 09:51:36 -0700

In the (PWG) Raster, the specification states support for 16-bits per
color.  TIFF seems to the only image file format supporting it and even
the TIFF libraries I could find only support up to 8-bits per color.

While I believe the (PWG) Raster specification indicates the range of
possible values; will or is there is a specification or compliance
requirements on what must be supported?  (The same would apply to color
spaces.)

Or is the situation that the printer provides it capabilities, which
must be one or more of the of the (PWG) Raster values.  Thus, there are
no mandatory values just a possible range of supported values. 

glen

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Thu, 28 Apr 2011 10:09:21 -0700

On Apr 28, 2011, at 9:51 AM, Petrie, Glen wrote:
> In the (PWG) Raster, the specification states support for 16-bits per color.  TIFF seems to the only image file format supporting it and even the TIFF libraries I could find only support up to 8-bits per color.

libtiff (the most widely-used TIFF library) supports 16-bits per color.

> While I believe the (PWG) Raster specification indicates the range of possible values; will or is there is a specification or compliance requirements on what must be supported?  (The same would apply to color spaces.)

I thought I had included this, but couldn't find any requirements in the PWG Raster or IPP Everywhere specs.

My thought was to require sgray-1 and sgray-8 for all printers and srgb-8 for color printers. 

> Or is the situation that the printer provides it capabilities, which must be one or more of the of the (PWG) Raster values.  Thus, there are no mandatory values just a possible range of supported values.

I think for interoperability we want a minimum set for interoperability (and to address the use cases/design requirements). But most values of color space and bit depth should be optional.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Petrie, Glen" <[email-masked]>
Date: Thu, 28 Apr 2011 10:21:35 -0700

________________________________

From: Michael Sweet [mailto:[email-masked]] 
Sent: Thursday, April 28, 2011 10:09 AM
To: Petrie, Glen
Cc: [email-masked]
Subject: Re: [IPP] (PWG) Raster Question on what is required

	In the (PWG) Raster, the specification states support for
16-bits per color.  TIFF seems to the only image file format supporting
it and even the TIFF libraries I could find only support up to 8-bits
per color.

I must be looking at the wrong version because TIFF 6.0 shows only
<8,8,8> http://www.libtiff.org/support.html 

I thought I had included this, but couldn't find any requirements in the
PWG Raster or IPP Everywhere specs.

Not in (PWG) Raster spec (I believe it would in section 4.3.4 or is
there another section)

The conformance section (6.x)  the "MUST" for attributes but not for
values 

My thought was to require sgray-1 and sgray-8 for all printers and
srgb-8 for color printers. 

Sound good to me.

	Or is the situation that the printer provides it capabilities,
which must be one or more of the of the (PWG) Raster values.  Thus,
there are no mandatory values just a possible range of supported values.

I think for interoperability we want a minimum set for interoperability
(and to address the use cases/design requirements). But most values of
color space and bit depth should be optional.

Ok, then from your color-spaces, the required bits-per-color would 1 and
8.  Also, the required bits-per-pixel would be 1, 8, 24

One more time.  Does conformance to pwg-raster-back-side mean "the
printer will perform the indicated transforms" or this is an identifier
stating what the "state" of the back-side image is?

---

From: Michael Sweet <[email-masked]>
Date: Thu, 28 Apr 2011 10:26:38 -0700

On Apr 28, 2011, at 10:21 AM, Petrie, Glen wrote:
> ...
> I must be looking at the wrong version because TIFF 6.0 shows only <8,8,8> http://www.libtiff.org/support.html

Hmm, they must have removed 16-bit support at one point - back when I was doing print software for SGI workstations the "Sam Leffler" version of libtiff supported it...

> ... 
> Ok, then from your color-spaces, the required bits-per-color would 1 and 8.  Also, the required bits-per-pixel would be 1, 8, 24

Right.

> One more time.  Does conformance to pwg-raster-back-side mean “the printer will perform the indicated transforms” or this is an identifier stating what the “state” of the back-side image is?

Conformance for a printer means that it will advertise what it needs. For a client it means the client will transform the back side images as indicated by the printer.

---

From: "Petrie, Glen" <[email-masked]>
Date: Thu, 28 Apr 2011 13:22:46 -0700

Mike,

Question on your definition of bytes-per-line (BPL): You have it ending
at an octet (8-bit) but I have seen cases where the boundary is at the
word or 32-bit level.   In fact, I have seen were people clip a line by
changing the number of pixel per line but not the bytes-per-line.   What
has been your experience?   Suggestion: Leave the equation out of
specification and it is understood or is stated that new raster lines
begin at multiples of bpl.

Glen

From: Michael Sweet [mailto:[email-masked]] 
Sent: Thursday, April 28, 2011 10:27 AM
To: Petrie, Glen
Cc: [email-masked]
Subject: Re: [IPP] (PWG) Raster Question on what is required

	...

	libtiff (the most widely-used TIFF library) supports 16-bits per
color.

	I must be looking at the wrong version because TIFF 6.0 shows
only <8,8,8> http://www.libtiff.org/support.html

Hmm, they must have removed 16-bit support at one point - back when I
was doing print software for SGI workstations the "Sam Leffler" version
of libtiff supported it...

... 

Right.

	One more time.  Does conformance to pwg-raster-back-side mean
"the printer will perform the indicated transforms" or this is an
identifier stating what the "state" of the back-side image is?

Conformance for a printer means that it will advertise what it needs.
For a client it means the client will transform the back side images as
indicated by the printer.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 28 Apr 2011 13:44:22 -0700

We need the definition in the spec, if for any reason to avoid getting the wrong interpretation.

Yes, some platforms align on words (I have seen 16-, 32-, and 64-bit alignment), but for PWG (CUPS) Raster we want 8-bit (octet) alignment. In practice this means that we only have extra/leftover bits for the 1-bit grayscale/black case since the other depths supported in PWG Raster are 8- and 16-bits per color.

On Apr 28, 2011, at 1:22 PM, Petrie, Glen wrote:

> Mike,
>  
> Question on your definition of bytes-per-line (BPL): You have it ending at an octet (8-bit) but I have seen cases where the boundary is at the word or 32-bit level.   In fact, I have seen were people clip a line by changing the number of pixel per line but not the bytes-per-line.   What has been your experience?   Suggestion: Leave the equation out of specification and it is understood or is stated that new raster lines begin at multiples of bpl.
>  
> Glen
>  
>  

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Thu, 28 Apr 2011 13:46:50 -0700

Oh, and since we are using the compressed version new raster lines begin where the last line ends. Hopefully the other examples I'll be adding will make that more clear...

---

From: James Cloos <[email-masked]>
Date: Sat, 30 Apr 2011 16:39:18 -0400

>>>>> "PG" == Petrie, Glen <[email-masked]> writes:

PG> I must be looking at the wrong version because TIFF 6.0 shows
PG> only <8,8,8> http://www.libtiff.org/support.html 

Libtiff has support for 8, 16, and 32 bit int per sample and 32 bit
ieee-float per sample images.  Support for signed ints might be limited
to 16 and 32 bit.  I'm not sure to what exetent libtiff supports tiff's
options for 64 bit ieee float, complex signed int and complex ieee float
sizes and formats, beyond recognizing and reporting them.

IIRC, libtiff.org was hijacked some time back.
The real homepage for libtiff is:

http://www.remotesensing.org/libtiff/

Also, PNG (and libpng) supports 16 bit per sample images, and OpenEXR
supports arbitrary sizes, much like tiff.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6