IFX Mail Archive: IFX> UIF ISSUE 02: Break C Profile into 2

IFX Mail Archive: IFX> UIF ISSUE 02: Break C Profile into 2

IFX> UIF ISSUE 02: Break C Profile into 2 profiles: color and grayscal e; L Profile REQUIRE LAB palette (n=6)

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Aug 08 2001 - 16:36:36 EDT

  • Next message: Hastings, Tom N: "IFX> NOT - Minutes of IPPGET telecon, Thursday, Aug 9, 8-10 AM PDT (11 -1 PM EDT)"

    Lloyd,
     
    Some thoughts on UIF ISSUE 02:
     
    ISSUE 02: Should we break UIF Profile C into two profiles-one to represent a
    baseline grayscale configuration and the other to represent a baseline color
    configuration? This way, a greater number of device capabilities
    configurations would be allowed without requiring an implementation of
    CONNEG. What about L profile which currently only requires gray scale with
    color optional?
     
    The IPP FAX WG agreed that having separate color and gray scale profiles for
    UIF Profile C would be a good idea. However, there is a strong precedent
    for profiles being identified by a single letter in both the IETF and the
    ITU TIFF/FX standards.
     
    Currently, profile C in both TIFF/FX and UIF REQUIRE only 8 bits per pixel
    gray scale with color OPTIONAL.
     
    One possibility, would be for UIF to increase the requirements for the UIF C
    Profile to REQUIRE full color LAB, (24 bits per pixel). This would mean
    changing Table 9 (UIF Profile C Baseline Fields) in the UIF spec as follows:
     
       SamplesPerPixel:
       Change: 1**: L* (lightness) To: 1: L* (lightness)
       Change: 3: LAB To: 3**: LAB
     
    Then invent a new profile that has 8 bits per pixel gray scale as a minimum
    and doesn't have color at all. We could call that Profile, G, for
    grayscale. The (new) Tables for UIF Profile G would be the same as the old
    Tables for C with the following change:
     
       SamplesPerPixel:
       No change: 1**: L* (lightness)
       Delete: 3: LAB
     
     
    What does breaking C into C and G do for the tree diagram in section 3.1?
    Would M require C, or G, or both?
     
    Would the letter G be a good choice for the gray scale UIF Profile (G for
    gray scale)? Or is TIFF/FX likely to want to add a new profile that
    REQUIRES color too, but they can't change what the C Profile means to
    REQUIRE color, since C currently only REQUIRES gray scale. If TIFF/FX might
    also want to have a new color-required Profile, then UIF would want to
    assign a new letter to the color-required Profile and keep C to mean gray
    scale required. If so, what letter do you suggest for the new
    color-required UIF and TIFF/FX Profile?
     
     
    For the UIF L profile, you suggested that its main purpose was business
    graphics, i.e., a small number of colors with a color palette, rather than
    gray scale. Instead breaking the UIF L Profile into two profiles since gray
    scale isn't so useful for business graphic, how about increasing the minimum
    requirement for UIF L profile from 8-bits per pixel gray scale to LAB
    palette with n equals 2 through 6**, giving 2 to the power n palette entries
    with n=6 REQUIRED (64 palette entries)?
     
    This would mean changing Table 12 (UIF Profile L Baseline Fields) as
    follows:
     
       BitsPerSample:
       Add: n=2-6**: 2 to the power n palette entries
       Change: 8**: 8 bits per color sample To: 8: 8 bits per color sample
     
    and changing Table 13 (UIF Profile L Extension Fields) as follows:
     
       Indexed:
       Change: 1: palette-color image To: 1**: palette-color image
       Change: MUST if image uses palette color; otherwise MAY To: MUST
     
     
    Comments?
     
    Thanks,
    Tom Hastings and John Pulera

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Monday, August 06, 2001 13:34
    To: Lloyd McIntyre (E-mail)
    Cc: IPP FAX DL (E-mail)
    Subject: FW: IFX> IPPFax Minutes -- August 2001 [questions for Lloyd McInt
    yre]
    Importance: High

    Lloyd,
     
    From the IPPFAX WG meeting last week, there are two issue resolutions that
    the group wants your input on for the UIF document. I've also asked for
    your advice on Issue 01 and Issue 04. We're having another telecon, this
    Thursday, August 9, 8 AM PST. It would help if you could respond by then to
    the mailing list.
     
    Here are the 4 issues, agreements, and questions to you, extracted from the
    IPPFAX minutes:
     
    ISSUE 01: Should the capabilities discovery portion of this spec be removed
    and placed into a specification that deals solely with how IPPFAX uses
    capabilities discovery? Advantages: other applications interested in using
    UIF simply as a data format can do so (no prohibitive excess baggage).

    The group thought it was a good idea to either create a new document or move
    the sections relating to capabilities discovery (e.g., UIF Section 4) to the
    IFX protocol spec.

    Lloyd: The advantage of a separate document, as opposed to moving it to the
    IFX protocol spec (IPP FAX Protocol spec), is that if some other protocol
    wanted to use UIF as a document format and use CONNEG, such as Internet FAX,
    they could do so without having to reference the IFX protocol).

     

    ISSUE 02: Should we break UIF Profile C into two profiles-one to represent a
    baseline grayscale configuration and the other to represent a baseline color
    configuration? This way, a greater number of device capabilities
    configurations would be allowed without requiring an implementation of
    CONNEG. (The same could apply to UIF Profile L).

     

    The group decided this is a good idea; however we felt it a good idea to
    check with Lloyd McIntyre about the direction in which TIFF-FX is heading
    and why TIFF-FX hasn't adopted a similarly tiered scheme for Profiles C and
    L. Also, we need to check with Lloyd about what the consequences should be
    to the tree diagram shown in section 3.1.

     

    Lloyd: Can you answer?

     

     

    ISSUE 04: (not in the document; see section 5.1.1) Should we change the MIME
    media registration to be simply a single value for the application parameter
    and add a new 'profile' parameter which is multi-valued to indicate the
    profiles that are in the document? For example:

    Content type: image/tiff; application=uif; profile=uif-s,uif-c,uif-mcs

     

    Yes this is a good idea, except the profile portion of the mime type (i.e.,
    "profile=uif-s,uif-c,uif-mcs" in above example) should be OPTIONAL, and
    indicates those profiles that a Receiver can expect to (but not necessarily)
    find in the UIF data.

     

    Lloyd: Do you see any problem if the MIME Content Type includes some
    profiles that the document doesn't actually use?

    I'd like to hear the group's ideas on why they added this caveat. For
    example, if a client is capable of scanning color, but the user requests
    that the document be scanned in gray scale, the client MUST NOT include the
    color profile in the Content Type. On the other hand, if the user didn't
    request to scan in gray scale, and the Sender's default is to scan in color,
    but the document scanned only had black and white, is that when it is ok for
    the Sender to include the color profile in the Content Type, even though the
    document didn't actually contain any color?

     

     

    Additional UIF-related issues raised at meeting:

    ISSUE 06: (raised at meeting) In the current spec, the 'FaxProfile' tag
    introduced in RFC2301 is re-interpreted as the 'UIFProfile' tag for UIF
    Documents. Also, the meaning of each value for this tag is redefined to
    refer to inclusion of UIF profiles rather than IFAX ones. The group thought
    this is not a legitimate thing to do. Should we register a new TIFF tag to
    represent the UIF profiles present in a given IFD? Ask Lloyd about this...

     

    Lloyd: Your comments on the above questions.

     

    Thanks,

    Tom

    -----Original Message-----
    From: John Pulera [mailto:jpulera@minolta-mil.com]
    Sent: Friday, August 03, 2001 19:23
    To: IPP-Fax Group
    Subject: IFX> IPPFax Minutes -- August 2001

    Meeting minutes are now available from the August 1 IPPFAX meeting in
    Toronto. Thanks Marty for taking notes during review of IFX issues:
     
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.doc
    <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.doc>
     <ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.pdf>
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.pdf
     
     
    John Pulera
     

    -----------------------------------------
    John Pulera
    Minolta Systems Laboratory
    jpulera@minolta-mil.com <mailto:jpulera@minolta-mil.com>
    (949)737-4520 x348
     



    This archive was generated by hypermail 2b29 : Wed Aug 08 2001 - 16:38:16 EDT