RFC3949 日本語訳
3949 File Format for Internet Fax. R. Buckley, D. Venable, L.McIntyre, G. Parsons, J. Rafferty. February 2005. (Format: TXT=204903 bytes) (Obsoletes RFC2301) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Buckley
Request for Comments: 3949 D. Venable
Obsoletes: 2301 Xerox Corporation
Category: Standards Track L. McIntyre
Consultant
G. Parsons
Nortel Networks
J. Rafferty
Brooktrout
February 2005
コメントを求めるワーキンググループR.バックリーの要求をネットワークでつないでください: 3949 D.ヴェナブルは以下を時代遅れにします。 2301年のゼロックス社のカテゴリ: 規格はJ.Rafferty Brooktrout2005年2月にL.マッキンタイヤコンサルタントG.教区牧師ノーテルネットワークを追跡します。
File Format for Internet Fax
インターネットファックスのためのファイル形式
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex B, are based on discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing.
このドキュメントはRFC2301の改訂版です。 Annex Bとして添付されたリストにまとめられた改正はRFC2301が1998年3月に発行されて以来されている改良と、独立している実現と相互運用性テストの結果における議論と提案に基づいています。
This RFC 2301 revision describes the Tag Image File Format (TIFF) representation of image data specified by the International Telecommunication Union (ITU-T) Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF for Fax eXtended (TIFF-FX). It formally defines minimal, extended, and lossless Joint Bi-level Image experts Group (JBIG) profiles (Profiles S, F, J) for black-and-white fax and base JPEG, lossless JBIG, and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations.
2301年のこのRFC改正は白黒と色のための推薦が電送する国際電気通信連合(ITU-T)によって指定されたイメージデータのTag Image File Format(TIFF)表現について説明します。 このファイル書式仕様はファックスeXtended(TIFF-FX)のためのTIFFとして一般的に知られています。 それは正式に、色とグレースケールファックスのための白黒のファックスのための最小量の、そして、拡張していて、lossless Joint Bi平らなImage専門家Group(JBIG)プロフィール(プロフィールS、F、J)、ベースJPEG、lossless JBIG、およびMixed Raster Contentプロフィール(プロフィールC、L、M)を定義します。 これらのプロフィールは適切なITU-T Recommendationsの内容に一致しています。
Buckley, et al. Standards Track [Page 1] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[1ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Approach. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Overview of this Document . . . . . . . . . . . . . . . . 5
2. TIFF and Fax . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. TIFF Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. File Structure . . . . . . . . . . . . . . . . . . 8
2.1.2. Image Structure. . . . . . . . . . . . . . . . . . 10
2.1.3. TIFF File Structure for Fax Applications . . . . . 11
2.2. TIFF Fields for All Fax Applications. . . . . . . . . . . 12
2.2.1. TIFF Fields required for all fax profiles. . . . . 13
2.2.2. Additional TIFF Fields required for all fax
profiles . . . . . . . . . . . . . . . . . . . . . 14
2.2.3. TIFF Fields recommended for all fax profiles . . . 17
2.2.4. New TIFF Fields recommended for fax profiles . . . 18
3. Profile S: Minimal Black-and-White Fax Profile . . . . . . . . 20
3.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 21
3.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 21
3.2.2. Extension Fields . . . . . . . . . . . . . . . . . 23
3.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 23
3.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 23
3.4. End of Line (EOL) and Return to Control (RTC) . . . . . . 23
3.4.1. RTC Exclusion. . . . . . . . . . . . . . . . . . . 24
3.5. File Structure. . . . . . . . . . . . . . . . . . . . . . 24
3.6. Profile S: Minimal Black-and-White Profile Summary. . . . 26
4. Profile F: Extended Black-and-White Fax Profile. . . . . . . . 27
4.1. TIFF-F Overview . . . . . . . . . . . . . . . . . . . . . 28
4.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 29
4.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 29
4.2.2. Extension Fields . . . . . . . . . . . . . . . . . 32
4.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 32
4.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 32
4.3.1. Baseline Fields. . . . . . . . . . . . . . . . . . 32
4.3.2. Extension Fields . . . . . . . . . . . . . . . . . 33
4.3.3. New Fields . . . . . . . . . . . . . . . . . . . . 33
4.4. Technical Implementation Issues . . . . . . . . . . . . . 34
4.4.1. Strips . . . . . . . . . . . . . . . . . . . . . . 34
4.4.2. Bit Order. . . . . . . . . . . . . . . . . . . . . 34
4.4.3. Multi-Page . . . . . . . . . . . . . . . . . . . . 35
4.4.4. Compression. . . . . . . . . . . . . . . . . . . . 35
4.4.5. Example Use of Page-quality Fields . . . . . . . . 36
4.4.6. Practical Guidelines for Writing and Reading
Multi-Page TIFF-F Files. . . . . . . . . . . . . . 36
4.4.7. Use of TIFF-F for Streaming Applications . . . . . 38
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1。 範囲. . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2。 アプローチしてください。 . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. このDocument. . . . . . . . . . . . . . . . 5 2の概観。 いさかいとファックス. . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1。 いさかい概観. . . . . . . . . . . . . . . . . . . . . . 7 2.1.1。 構造. . . . . . . . . . . . . . . . . . 8 2.1.2をファイルしてください。 画像構造。 . . . . . . . . . . . . . . . . . 10 2.1.3. ファックスアプリケーション. . . . . 11 2.2のためのいさかいファイル構造。 すべてのためのいさかい分野はファックスでアプリケーションを送ります。 . . . . . . . . . . 12 2.2.1. TIFFフィールズがすべてのファックスプロフィールに必要です。 . . . . 13 2.2.2. 追加TIFFフィールズがすべてのファックスプロフィール. . . . . . . . . . . . . . . . . . . . . 14 2.2.3に必要です。 TIFFフィールズはすべてのファックスのためにプロフィール. . . 17 2.2.4を推薦しました。 新しいTIFFフィールズはファックスのためにプロフィール. . . 18 3を推薦しました。 プロフィールS: 最小量の白黒のファックスプロフィール. . . . . . . . 20 3.1。 概観。 . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. 必要ないさかい分野。 . . . . . . . . . . . . . . . . . . 21 3.2.1. 基線分野。 . . . . . . . . . . . . . . . . . 21 3.2.2. 拡大分野. . . . . . . . . . . . . . . . . 23 3.2.3。 新しい分野. . . . . . . . . . . . . . . . . . . . 23 3.3。 お勧めのいさかい分野. . . . . . . . . . . . . . . . . 23 3.4。 行末(EOL)と(RTC). . . . . . 23 3.4.1を制御するリターン。 RTC除外。 . . . . . . . . . . . . . . . . . . 24 3.5. 構造をファイルしてください。 . . . . . . . . . . . . . . . . . . . . . 24 3.6. プロフィールS: 最小量の白黒のプロフィール概要。 . . . 26 4. プロフィールF: 拡張白黒のファックスプロフィール。 . . . . . . . 27 4.1. いさかいF概観. . . . . . . . . . . . . . . . . . . . . 28 4.2。 必要ないさかい分野。 . . . . . . . . . . . . . . . . . . 29 4.2.1. 基線分野。 . . . . . . . . . . . . . . . . . 29 4.2.2. 拡大分野. . . . . . . . . . . . . . . . . 32 4.2.3。 新しい分野. . . . . . . . . . . . . . . . . . . . 32 4.3。 お勧めのいさかい分野. . . . . . . . . . . . . . . . . 32 4.3.1。 基線分野。 . . . . . . . . . . . . . . . . . 32 4.3.2. 拡大分野. . . . . . . . . . . . . . . . . 33 4.3.3。 新しい分野. . . . . . . . . . . . . . . . . . . . 33 4.4。 技術的な導入問題. . . . . . . . . . . . . 34 4.4.1。 .2に.344.4を剥取ります。 オーダーに噛み付きました。 . . . . . . . . . . . . . . . . . . . . 34 4.4.3. マルチページ.354.4、.4 圧縮。 . . . . . . . . . . . . . . . . . . . 35 4.4.5. ページ品質分野. . . . . . . . 36 4.4.6の例の使用。 マルチページいさかいFファイルを書いて、読むための実際的なガイドライン。 . . . . . . . . . . . . . 36 4.4.7. いさかいFのストリーミング・アプリケーション. . . . . 38の使用
Buckley, et al. Standards Track [Page 2] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[2ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
4.5. Implementation Warnings . . . . . . . . . . . . . . . . . 38
4.5.1. Uncompressed Data. . . . . . . . . . . . . . . . . 38
4.5.2. Encoding and Resolution. . . . . . . . . . . . . . 38
4.5.3. EOL byte-aligned . . . . . . . . . . . . . . . . . 39
4.5.4. EOL. . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.5. RTC Exclusion. . . . . . . . . . . . . . . . . . . 40
4.5.6. Use of EOFB for T.6 Compressed Images. . . . . . . 40
4.6. Example Use of TIFF-F . . . . . . . . . . . . . . . . . . 40
4.7. Profile F: Extended Black-and-white Fax Profile Summary . 41
5. Profile J: Lossless JBIG Black-and-White Fax Profile . . . . . 43
5.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 44
5.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 44
5.2.2. Extension Fields . . . . . . . . . . . . . . . . . 44
5.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 44
5.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 45
5.4. Profile J: Lossless JBIG Black-and-White Profile Summary. 45
6. Profile C: Base Color Fax Profile. . . . . . . . . . . . . . . 47
6.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 47
6.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 47
6.2.2. Extension Fields . . . . . . . . . . . . . . . . . 49
6.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 50
6.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 52
6.4. Profile C: Base Color Fax Profile Summary . . . . . . . . 52
7. Profile L: Lossless Color Profile. . . . . . . . . . . . . . . 54
7.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 54
7.1.1. Color Encoding . . . . . . . . . . . . . . . . . . 54
7.1.2. JBIG Compression . . . . . . . . . . . . . . . . . 55
7.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 55
7.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 56
7.2.2. Extension Fields . . . . . . . . . . . . . . . . . 57
7.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 57
7.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 57
7.4. Profile L: Lossless Color Fax Profile Summary . . . . . . 58
8. Profile M: Mixed Raster Content Profile. . . . . . . . . . . . 60
8.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 60
8.1.1. MRC 3-layer model. . . . . . . . . . . . . . . . . 60
8.1.2. A TIFF Representation for the MRC 3-layer model. . 62
8.2. Required TIFF Fields. . . . . . . . . . . . . . . . . . . 64
8.2.1. Baseline Fields. . . . . . . . . . . . . . . . . . 64
8.2.2. Extension Fields . . . . . . . . . . . . . . . . . 66
8.2.3. New Fields . . . . . . . . . . . . . . . . . . . . 67
8.3. Recommended TIFF Fields . . . . . . . . . . . . . . . . . 69
8.4. Rules and Requirements for Images . . . . . . . . . . . . 69
8.5. Profile M: MRC Fax Profile Summary. . . . . . . . . . . . 71
9. MIME content-types image/tiff and image/tiff-fx. . . . . . . . 74
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 74
4.5. 実現警告. . . . . . . . . . . . . . . . . 38 4.5.1。 データを解凍しました。 . . . . . . . . . . . . . . . . 38 4.5.2. コード化と解決。 . . . . . . . . . . . . . 38 4.5.3. EOLは.394.5に.4をバイト並べました。 EOL。 . . . . . . . . . . . . . . . . . . . . . . . 40 4.5.5. RTC除外。 . . . . . . . . . . . . . . . . . . 40 4.5.6. EOFBのT.6の使用はイメージズを圧縮しました。 . . . . . . 40 4.6. いさかいF.404.7の例の使用。 プロフィールF: 拡張黒くて白いファックスは概要. 41 5の輪郭を描きます。 プロフィールJ: Lossless JBIGの白黒のファックスプロフィール. . . . . 43 5.1。 概観。 . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2. 必要ないさかい分野。 . . . . . . . . . . . . . . . . . . 44 5.2.1. 基線分野。 . . . . . . . . . . . . . . . . . 44 5.2.2. 拡大分野. . . . . . . . . . . . . . . . . 44 5.2.3。 新しい分野. . . . . . . . . . . . . . . . . . . . 44 5.3。 お勧めのいさかい分野. . . . . . . . . . . . . . . . . 45 5.4。 プロフィールJ: Lossless JBIGの白黒のプロフィール概要。 45 6. プロフィールC: カラーファックスプロフィールを基礎づけてください。 . . . . . . . . . . . . . . 47 6.1. 概観。 . . . . . . . . . . . . . . . . . . . . . . . . 47 6.2. 必要ないさかい分野。 . . . . . . . . . . . . . . . . . . 47 6.2.1. 基線分野。 . . . . . . . . . . . . . . . . . 47 6.2.2. 拡大分野. . . . . . . . . . . . . . . . . 49 6.2.3。 新しい分野. . . . . . . . . . . . . . . . . . . . 50 6.3。 お勧めのいさかい分野. . . . . . . . . . . . . . . . . 52 6.4。 プロフィールC: 色のファックスプロフィール概要. . . . . . . . 52 7を基礎づけてください。 プロフィールL: Losslessはプロフィールを着色します。 . . . . . . . . . . . . . . 54 7.1. 概観。 . . . . . . . . . . . . . . . . . . . . . . . . 54 7.1.1. コード化. . . . . . . . . . . . . . . . . . 54 7.1を.2に着色してください。 JBIG圧縮. . . . . . . . . . . . . . . . . 55 7.2。 必要ないさかい分野。 . . . . . . . . . . . . . . . . . . 55 7.2.1. 基線分野。 . . . . . . . . . . . . . . . . . 56 7.2.2. 拡大分野. . . . . . . . . . . . . . . . . 57 7.2.3。 新しい分野. . . . . . . . . . . . . . . . . . . . 57 7.3。 お勧めのいさかい分野. . . . . . . . . . . . . . . . . 57 7.4。 プロフィールL: Losslessはファックスプロフィール概要. . . . . . 58 8を着色します。 プロフィールM: Mixedラスタ内容プロフィール。 . . . . . . . . . . . 60 8.1. 概観。 . . . . . . . . . . . . . . . . . . . . . . . . 60 8.1.1. MRC、3階層モデル。 . . . . . . . . . . . . . . . . 60 8.1.2. MRCのための3階層モデルのTIFF Representation。 . 62 8.2. 必要ないさかい分野。 . . . . . . . . . . . . . . . . . . 64 8.2.1. 基線分野。 . . . . . . . . . . . . . . . . . 64 8.2.2. 拡大分野. . . . . . . . . . . . . . . . . 66 8.2.3。 新しい分野. . . . . . . . . . . . . . . . . . . . 67 8.3。 お勧めのいさかい分野. . . . . . . . . . . . . . . . . 69 8.4。 イメージズ. . . . . . . . . . . . 69 8.5のための規則と要件。 プロフィールM: MRCはファックスでプロフィール概要を送ります。 . . . . . . . . . . . 71 9. MIMEはイメージ/いさかいといさかいイメージ/fxを内容でタイプします。 . . . . . . . 74 10. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 74
Buckley, et al. Standards Track [Page 3] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[3ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
11.1. Normative References . . . . . . . . . . . . . . . . . . 74
11.2. Informative References . . . . . . . . . . . . . . . . . 76
Annex A: Summary of TIFF Fields for Internet Fax . . . . . . . . . 77
Annex B: List of technical edits to RFC 2301 . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 84
11. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 74 11.1。 引用規格. . . . . . . . . . . . . . . . . . 74 11.2。 有益な参照. . . . . . . . . . . . . . . . . 76別館A: インターネットファックス. . . . . . . . . 77別館Bへのいさかい分野の概要: RFC2301.81AuthorsのAddresses. . . . . . . . . . . . . . . . . . . . . . . . 82Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 84への技術的な編集のリスト
1. Introduction
1. 序論
This document describes the use of TIFF (Tag Image File Format) to represent the data content and structure generated by the current suite of ITU-T Recommendations for Group 3 facsimile. These recommendations and the TIFF fields described here support the following facsimile profiles:
このドキュメントは、Group3ファクシミリのためにITU-T Recommendationsの現在のスイートで発生するデータ内容と構造を表すためにTIFF(タグImage File Format)の使用について説明します。 ここで説明されたこれらの推薦とTIFF分野は以下のファクシミリプロフィールを支えます:
S: Minimal black-and-white profile, using binary MH compression
[T.4]
F: Extended black-and-white profile, using binary MH, MR, and MMR
compression [T.4, T.6]
J: Lossless JBIG black-and-white profile, with JBIG compression
[T.85, T.82]
C: Lossy color and grayscale profile, using JPEG compression [T.42,
T.81]
L: Lossless color and grayscale profile, using JBIG compression
[T.43, T.82]
M: Mixed raster content profile [T.44], using a combination of
existing compression methods
S: 2進のMH圧縮[T.4]Fを使用する最小量の白黒のプロフィール: 拡張白黒使用のプロフィール、2進のMH、MR、およびMMR圧縮[T.4、T.6]J: JBIG圧縮[T.85、T.82]CがあるLossless JBIGの白黒のプロフィール: JPEG圧縮[T.42、T.81]Lを使用する損失性色とグレースケールプロフィール: JBIG圧縮[T.43、T.82]Mを使用するLossless色とグレースケールプロフィール: 既存の圧縮方法の組み合わせを使用して、Mixedラスタ内容は[T.44]の輪郭を描きます。
Each profile corresponds to the content of ITU-T Recommendations shown and is a subset of the full TIFF for facsimile specification.
各プロフィールは、見せられたITU-T Recommendationsの内容に対応している、ファクシミリ仕様のための完全なTIFFの部分集合です。
Profile S describes a minimal interchange set of fields, which will guarantee that, at least, binary black-and-white images will be supported. Implementations are required to support this minimal interchange set of fields.
プロフィールSは最小量の置き換えセットの分野について説明します。(分野は、少なくとも2進の白黒のイメージが支持されるのを保証するでしょう)。 実現が、この最小量の置き換えセットの分野を支持するのに必要です。
With the intent of specifying a file format for Internet fax, this document
インターネットファックス、このドキュメントにファイル形式を指定する意図をもって
1. specifies the structure of TIFF files for facsimile data,
2. defines ITU fax-compatible values for existing TIFF fields, and
3. defines new TIFF fields and values required for compatibility with
ITU color fax.
1.、データを電送してください、ITUのファックスコンパチブル値を既存のTIFF分野と2を定義して、3を新しいTIFF分野を定義して、値がITUカラーファックスとの互換性に必要であるので、TIFFファイルの構造を指定します。
Buckley, et al. Standards Track [Page 4] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[4ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
This specification of TIFF for facsimile is known as TIFF-FX (TIFF for Fax eXtended). References to the format described by this specification should always use the term "TIFF-FX", and some profiles in this specification may not be interpreted correctly by other TIFF applications.
ファクシミリのためのTIFFのこの仕様はTIFF-FX(ファックスeXtendedのためのTIFF)として知られています。 この仕様で説明された形式の参照はいつも「いさかい-FX」という用語を使用するべきです、そして、この仕様によるいくつかのプロフィールは他のいさかいアプリケーションで正しく解釈されないかもしれません。
1.1. Scope
1.1. 範囲
This document defines a TIFF-based file format specification for enabling standardized messaging-based fax over the Internet. It specifies the TIFF fields and field values required for compatibility with the existing ITU-T Recommendations for Group 3 black-and-white, grayscale, and color facsimile. TIFF has historically been used for handling fax image files in applications such as store-and-forward messaging. Implementations that support this file format specification for import/export may elect to support it as a native format. This document recommends a TIFF file structure compatible with low-memory and page-level streaming implementations.
このドキュメントは、インターネットの上で標準化されたメッセージングベースのファックスを可能にするためにTIFFベースのファイル書式仕様を定義します。 それはTIFF分野を指定します、そして、分野値がGroup3白黒、グレースケール、および色のためのRecommendationsが電送する既存のITU-Tとの互換性に必要です。 TIFFは店とフォワードメッセージングなどのアプリケーションにおける取り扱いファックスイメージ・ファイルに歴史的に使用されました。 輸入/輸出のためにこのファイル書式仕様をサポートする実現は、ネイティブの形式としてそれを支持するのを選ぶかもしれません。 このドキュメントは少ない記憶とのコンパチブルTIFFファイル構造とページレベルのストリーミングの実現を推薦します。
Unless otherwise noted, the current TIFF specification [TIFF] and selected TIFF Technical Notes [TTN1, TTN2] are the primary references for describing TIFF and defining TIFF fields. This document is the primary reference for defining TIFF field values for fax applications.
別の方法で注意されない場合、現在のTIFF仕様[TIFF]と選択されたTIFF Technical Notes[TTN1、TTN2]はTIFFについて説明して、TIFF分野を定義する第一の参照です。 このドキュメントはファックスアプリケーションのためにTIFF分野値を定義する第一の参照です。
1.2. Approach
1.2. アプローチ
The basic approach to using TIFF for facsimile data is to insert the compressed fax image data into a TIFF file and use TIFF fields to encode the parameters that describe the image data. These fields will have values that comply with the ITU-T Recommendations.
ファクシミリデータにTIFFを使用することへの基本的なアプローチは、圧縮されたファックスイメージデータをTIFFファイルの中に挿入して、イメージデータについて説明するパラメタをコード化するのにTIFF分野を使用することです。 これらの分野には、ITU-T Recommendationsに従う値があるでしょう。
This approach takes advantage of TIFF features and structures that bridge the data formats and performance requirements of both legacy fax machines and host-based fax applications. TIFF constructs for pages, images, and strips allow a TIFF file to preserve the fax data stream structure and the performance advantages that come with it. A TIFF-based approach also builds on an established base of users and implementors and ensures backward compatibility with existing TIFF- based IETF proposals and work in progress for Internet fax.
このアプローチは遺産ファックス装置とホストベースのファックスアプリケーションの両方のデータ形式と性能要件に橋を架けるTIFFの特徴と構造を利用します。 ページ、イメージ、および片のためのTIFF構造物で、TIFFファイルはファックスデータ・ストリーム構造とそれと共に来る性能利点を保存できます。 TIFFベースのアプローチは、また、ユーザと作成者の確立したベースの上に建てて、既存のTIFFとの互換性がインターネットファックスのためのIETF提案と処理中の作業を基礎づけたのを後方に確実にします。
1.3. Overview of this Document
1.3. このDocumentの概観
Section 2 gives an overview of TIFF. Section 2.1 describes the structure of TIFF files, including general guidelines for structuring multi-page TIFF files. Section 2.2 lists the TIFF fields that are required or recommended for all fax profiles. The TIFF fields used
セクション2はTIFFの概観を与えます。 セクション2.1はマルチページTIFFファイルを構造化するための一般的ガイドラインを含むTIFFファイルの構造について説明します。 セクション2.2はすべてのファックスプロフィールのために必要である、または推薦されるTIFF分野を記載します。 分野が使用したTIFF
Buckley, et al. Standards Track [Page 5] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[5ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
only by specific fax profiles are described in Sections 3 - 8, which describe the individual fax profiles. These sections also specify the ITU-compatible field values (image parameters) for each profile.
特定のファックスだけで、プロフィールはセクション3で説明されます--8。(その8は個々のファックスプロフィールについて説明します)。 また、これらのセクションはITUコンパチブル分野値(映像パラメーター)を各プロフィールに指定します。
The full set of permitted fields of TIFF for facsimile are included in the current TIFF specification, Section 2 of this document, and the sections on specific profiles of facsimile operation. This document defines profiles of TIFF for facsimile, where a profile is a subset of the full set of permitted fields and field values of TIFF for facsimile.
ファクシミリのためのTIFFの受入れられた分野のフルセットは現在のTIFF仕様、このドキュメントのセクション2、およびファクシミリ操作の特定のプロフィールの上のセクションに含まれています。 このドキュメントはプロフィールが受入れられた分野のフルセットの部分集合であるファクシミリのためのTIFFのプロフィールとファクシミリのためのTIFFの分野値を定義します。
Section 3 defines the minimal black-and-white facsimile profile (Profile S), which is required in all implementations. Section 4 defines the extended black-and-white fax profile (Profile F), which provides a standard definition of TIFF-F. Section 5 describes the lossless black-and-white profile using JBIG compression (Profile J).
セクション3は最小量の白黒のファクシミリプロフィール(プロフィールS)を定義します。(それが、すべての実現で必要です)。 セクション4は拡張白黒のファックスプロフィール(プロフィールF)を定義します。(それは、TIFF-Fの標準定義を提供します)。 セクション5は、JBIG圧縮(プロフィールJ)を使用することでlosslessの白黒のプロフィールについて説明します。
Section 6 defines the base color profile, required in all color implementations, for the lossy JPEG representation of color and grayscale facsimile data (Profile C). Section 7 defines the lossless JBIG color and grayscale facsimile profile (Profile L), and Section 8 defines the Mixed Raster Content facsimile profile (Profile M). Each of these sections concludes with a table summarizing the required and recommended fields for each profile and the values they can have.
セクション6は色とグレースケールファクシミリデータ(プロフィールC)の損失性JPEG表現のためにすべての色の実現で必要である基調色プロフィールを定義します。 セクション7はlossless JBIG色とグレースケールファクシミリプロフィール(プロフィールL)を定義します、そして、セクション8はMixed Raster Contentファクシミリプロフィール(プロフィールM)を定義します。 それぞれのこれらのセクションはそれらが持つことができる各プロフィールと値のために必要でお勧めの分野をまとめるテーブルで締めくくります。
Section 9 refers to the MIME content types used in connection with TIFF for facsimile. Sections 10 and 11 give Security Considerations and References, followed by Authors' Addresses and the Copyright Notice. Annex A gives a summary of the TIFF fields used or defined in this document and provides a convenient reference for implementors.
セクション9はファクシミリにTIFFで使用されるMIME内容タイプについて言及します。 セクション10と11はAuthorsのAddressesとCopyright Noticeによって続かれたSecurity ConsiderationsとReferencesに与えます。 別館Aは、本書では使用されたか、または定義されたTIFF分野の概要をして、作成者の便利な参照を提供します。
To implement only the minimal interchange black-and-white set of fields and values (Profile S), one need read only Sections 1, 2, 3, 9, and 10.
白黒が設定した分野と値(プロフィールS)の最小量の置き換えだけを実行するために、人はセクション1、2、3、9、および10だけを読まなければなりません。
The following tree diagram shows the relationship among profiles and between profiles and coding methods.
以下の樹形図はプロフィールとプロフィールとコード化方法との関係を示しています。
Buckley, et al. Standards Track [Page 6] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[6ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
S (MH)
/ \
B&W / \ Color
------------ ----------
/ \ \
/ F (MH, MR, MMR) C (JPEG)
/ / \
J (JBIG) ---- \
/ \
L (JBIG) \
\
M (MRC)
S(MH)/\B&W/\色------------ ---------- /\\/F(MH、さん、MMR)C(JPEG)//\J(JBIG)---- \/\L(JBIG)\\M(MRC)
A profile is based on a collection of ITU-T facsimile coding methods. For example, Profile S, the minimal profile, is based on Modified Huffman (MH) compression, which is defined in ITU-T Rec. T.4. Profile F specifies Modified Huffman (MH), Modified READ (MR), and Modified Modified READ (MMR) compressions, which are defined in ITU-T Rec. T.4 and T.6.
プロフィールはITU-Tファクシミリコード化方法の収集に基づいています。 例えば、Profile S(最小量のプロフィール)はModifiedハフマン(MH)圧縮に基づいています。(それは、ITU-T Recで定義されます)。 T.4。 プロフィールFはModifiedハフマン(MH)、Modified READ(MR)、およびModified Modified READ(MMR)圧縮を指定します。(圧縮はITU-T Recで定義されます)。 T.4とT.6。
All implementations of TIFF for facsimile MUST implement Profile S, which is the root node of the tree. All color implementations of TIFF for facsimile MUST implement Profile C. The implementation of a particular profile MUST also implement those profiles on the path that connect it to the root node, and MAY optionally implement profiles not on the path connecting it to the root node. For example, an implementation of Profile M must also implement Profiles C and S and may optionally implement Profile F, J, or L. For another example, an implementation of Profile C must also implement Profile S and may optionally implement Profile F or J.
ファクシミリのためのTIFFのすべての実現がProfile Sを実行しなければなりません。(Profile Sは木の根の節です)。 ファクシミリがまた特定のプロフィールの実現がそうしなければならないProfile C.を実行しなければならないので、TIFFのすべての色の実現は、経路のそれを接続するそれらのプロフィールを根のノードに実行して、根のノードにそれを接続しながら、いずれの経路でも任意にプロフィールは実行しないかもしれません。 例えば、Profile Mの実現は、また、Profiles CとSを実行しなければならなくて、任意にProfile Fを実行するかもしれません、JかL.Forは別の例をJです、Profile Cの実現。また、Profile Sを実行しなければならなくて、任意にProfile FかJを実行するかもしれません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", " NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [REQ].
“SHALL"、「NOT」が「必須NOT」というキーワード“MUST"が、「必要でした」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[REQ]で説明されるように本書では解釈されることであるべきですか?
2. TIFF and Fax
2. いさかいとファックス
2.1. TIFF Overview
2.1. いさかい概観
TIFF provides a means for describing, storing, and interchanging raster image data. A primary goal of TIFF is to provide a rich environment within which applications can exchange image data. The current TIFF specification [TIFF] defines a commonly used core set of TIFF fields known as Baseline TIFF. The current specification, the set of Pagemaker TIFF Technical Notes [TTN1], and TIFF Technical Note 2 [TTN2] define several TIFF extensions. The TIFF-based specification for fax applications uses a subset of Baseline TIFF
TIFFはラスター・イメージデータを説明して、格納して、交換するための手段を提供します。 TIFFの第一の目標はアプリケーションがイメージデータを交換できる豊かな環境を提供することです。 現在のTIFF仕様[TIFF]はBaseline TIFFとして知られている一般的に使用された巻き癖のTIFF分野を定義します。 現在の仕様、Pagemaker TIFF Technical Notesのセット[TTN1]、およびTIFF Technical Note2[TTN2]はいくつかのTIFF拡張子を定義します。 ファックスアプリケーションのためのTIFFベースの仕様はBaseline TIFFの部分集合を使用します。
Buckley, et al. Standards Track [Page 7] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[7ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
fields, with selected extensions, as described in this document. In a few cases, this document defines new TIFF fields specifically for fax applications.
選択された拡大で、本書では説明されるように、さばきます。 いくつかの場合では、このドキュメントは特にファックスアプリケーションのために新しいTIFF分野を定義します。
2.1.1. File Structure
2.1.1. ファイル構造
TIFF is designed for raster images, which makes it a good match for facsimile documents, which are multi-page raster images. Each raster image consists of a number of rows or scanlines, each of which has the same number of pixels, the unit of sampling. Each pixel has at least one sample or component (exactly one for black-and-white images).
TIFFはラスター・イメージのために設計されています(それをマルチページラスター・イメージであるファクシミリドキュメントのための良いマッチにします)。 各ラスター・イメージは多くの列か走査線から成ります。それはそれぞれ、同じピクセル数(標本抽出のユニット)を持っています。 各画素には、少なくとも1つのサンプルかコンポーネント(白黒のイメージのためのちょうどもの)があります。
A TIFF file begins with an 8-byte image file header. The first two bytes describe the byte order used within the file. Legal values are "II" (0x4949) when bytes are ordered from least to most significant (little-endian), and "MM" (0x4D4D), when bytes are ordered from most to least significant (big-endian) within a 16- or 32-bit integer. Either byte order can be used, except in the case of the minimal black-and-white profile, which SHALL use value "II". The next two bytes contain the value 42, which identifies the file as a TIFF file and is ordered according to the value in the first two bytes of the header. The last four bytes give the offset that points to the first image file directory (IFD). This and all other offsets in a TIFF file are with respect to the beginning of the TIFF file. An IFD can be at any location in the file after the header but must begin on a word boundary.
TIFFファイルは8バイトのイメージ・ファイルヘッダーと共に始まります。 最初の2バイトはファイルの中で使用されたバイトオーダーについて説明します。 バイトが最少から最も重要な(リトルエンディアン)、および「mm」(0x4D4D)まで命令されるとき、法定価格は「II」(0×4949)です、バイトが16か32ビットの整数の中で大部分から最も重要でない(ビッグエンディアン)まで命令されるとき。 最小量の白黒のプロフィール、どのSHALL使用価値「II」に関するケースを除いて、どちらのバイトオーダーも使用できるか。 次の2バイトは値42を含んでいます。(それは、ファイルがTIFFファイルであると認識して、ヘッダーの最初の2バイトにおける値に従って、注文されます)。 最後の4バイトは最初のイメージ・ファイルディレクトリ(IFD)を示すオフセットを与えます。 TIFFファイルの始まりに関してTIFFファイルにおける他のこれとすべてのオフセットがあります。 IFDはヘッダーの後に、ファイルのどんな位置にもあることができますが、語境界で始まらなければなりません。
An IFD is a sequence of tagged fields, sorted in ascending order by tag value. An IFD consists of a 2-byte count of the number of fields, a sequence of field entries, and a 4-byte offset to the next IFD. The fields contain information about the image and pointers to the image data. Each separate raster image in the file is represented by an IFD.
IFDは昇順にタグ値によって分類されたタグ付けをされた分野の系列です。 IFDは次のIFDに分野の数、フィールド入力の系列、および4バイトのオフセットの2バイトのカウントから成ります。 分野はイメージとポインタの情報をイメージデータに含んでいます。 ファイルのそれぞれの別々のラスター・イメージはIFDによって表されます。
Each field entry in an IFD has 12 bytes and consists of a 2-byte Tag, 2 bytes identifying the field type (e.g., short, long, rational, ASCII), 4 bytes giving the count (number of values or offsets), and 4 bytes containing either the offset to a field value stored outside the IFD or, based on the type and count, the field value itself. Resolution and metadata such as dates, names, and descriptions are examples of "long" field values that do not fit in 4 bytes and therefore use offsets in the field entry. Details are given in the TIFF specification [TIFF].
IFDの各フィールド入力は、12バイトを持って、2バイトのTag、フィールド・タイプを特定する2バイト(例えば、短くて、長くて、合理的なASCII)、カウントを与える4バイト(値かオフセットの数)、およびIFDの外に格納された分野値へのオフセットかタイプとカウントに基づいた分野値自体のどちらかを含む4バイトから成ります。 解決、デートするようなメタデータ、名前、および記述は4バイトをうまくはめ込んで、したがってフィールド入力におけるオフセットを使用しない「長い」分野値に関する例です。 詳細はTIFF仕様[TIFF]に述べられます。
A TIFF file can contain more than one IFD, where each IFD is a subfile whose type is given in the NewSubfileType field. Multiple IFDs can be organized either as a linked list, with the last entry in
TIFFファイルは1IFDを入れてあることができます。そこでは、各IFDがタイプがNewSubfileType分野で与えられている「副-ファイル」です。 中に最後のエントリーがある状態で、繋がっているリストとして複数のIFDsを組織化できます。
Buckley, et al. Standards Track [Page 8] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[8ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
each IFD pointing to the next IFD (the pointer in the last IFD is 0), or as a tree, using the SubIFDs field in the primary IFD [TTN1]. The SubIFDs field contains an array of pointers to child IFDs of the primary IFD.
各IFDが次のIFD(最後のIFDのポインタは0である)か、木として指して、SubIFDsを使用して、第一のIFDで[TTN1]をさばいてください。 SubIFDs分野は第一のIFDの子供IFDsにポインタのアレイを含んでいます。
Child IFDs describe related images, such as reduced resolution versions of the primary IFD image. The same IFD can point both to a next IFD and to child IFDs, and child IFDs can themselves point to other IFDs.
子供IFDsは第一のIFDイメージの減少している解決バージョンなどの関連するイメージについて説明します。 同じIFDはa次IFDと、そして、子供IFDsと、子供IFDs缶自体に他のIFDsへのポイントを指すことができます。
All fax profiles represent a multi-page fax image as a linked list of IFDs, with a NewSubfileType field containing a bit that identifies the IFD as one page of a multi-page document. Each IFD has a PageNumber field, identifying the page number in ascending order, starting at 0 for the first page. Although a Baseline TIFF reader is not required to read any IFDs beyond the first, an implementation that reads the files that comply with this specification SHALL read multiple IFDs. Only the Mixed Raster Content fax profile, described in Section 8, requires the use of child IFDs.
すべてのファックスプロフィールがIFDsの繋がっているリストとしてマルチページファックスイメージを表して、NewSubfileType分野で、それを少し含むのは、IFDがマルチページドキュメントの1ページであると認識します。 各IFDには、0時に最初のページのために始まって、昇順にページ番号を特定して、PageNumber分野があります。 Baseline TIFF読者は1番目を超えてどんなIFDsも読むのに必要ではありませんでしたが、この仕様SHALLに従うファイルを読む実現は複数のIFDsを読みました。 セクション8で説明されたMixed Raster Contentファックスプロフィールだけが子供IFDsの使用を必要とします。
Buckley, et al. Standards Track [Page 9] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[9ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
The following figure illustrates the structure of a multi-page TIFF file.
以下の図はマルチページTIFFファイルの構造を例証します。
+-----------------------+
| Header |------------+
+-----------------------+ | First IFD
| IFD (page 0) |<-----------+ Offset
+---| |------------+
Value | +-----------------------+ |
Offset +-->| Long Values |--+ |
+-----------------------| | Strip |
| Image Data |<-+ Offset |
| strip 1 page 0 | | |
+-----------------------+ | |
| : | : |
|
+-----------------------+ | Next IFD
| IFD (page 1) |<-----------+ Offset
+---| |------------+
Value | +-----------------------+ |
Offset +-->| Long Values |--+ |
+-----------------------| | Strip |
| Image Data |<-+ Offset |
| strip 1 page 1 | | |
+-----------------------+ | |
| strip 2 page 1 |<-+ |
+-----------------------+ | |
| : | : |
|
+-----------------------+ | Next IFD
| IFD (page 2) |<-----------+ Offset
| : |
+-----------------------+ | ヘッダー|------------+ +-----------------------+ | 最初に、IFD| IFD(0ページ)| <、-、-、-、-、-、-、-、-、-、--+ オフセット+---| |------------+ 値| +-----------------------+ | オフセット+-->| 長い値|--+ | +-----------------------| | 片| | イメージデータ| <、-+ オフセット| | 1 0ページを剥取ってください。| | | +-----------------------+ | | | : | : | | +-----------------------+ | 次のIFD| IFD(1ページ)| <、-、-、-、-、-、-、-、-、-、--+ オフセット+---| |------------+ 値| +-----------------------+ | オフセット+-->| 長い値|--+ | +-----------------------| | 片| | イメージデータ| <、-+ オフセット| | 1つの1ページを剥取ってください。| | | +-----------------------+ | | | 2つの1ページを剥取ってください。| <、-+ | +-----------------------+ | | | : | : | | +-----------------------+ | 次のIFD| IFD(2ページ)| <、-、-、-、-、-、-、-、-、-、--+ オフセット| : |
2.1.2. Image Structure
2.1.2. 画像構造
An IFD stores an image as one or more strips, as shown in the preceding figure. A strip consists of 1 or more scanlines (rows) of raster image data in compressed form. An image may be stored in a single strip or may be divided into several strips, which would require less memory to buffer. (Baseline TIFF recommends about 8k bytes per strip, but existing fax usage is typically one strip per image.)
An IFD stores an image as one or more strips, as shown in the preceding figure. A strip consists of 1 or more scanlines (rows) of raster image data in compressed form. An image may be stored in a single strip or may be divided into several strips, which would require less memory to buffer. (Baseline TIFF recommends about 8k bytes per strip, but existing fax usage is typically one strip per image.)
Each IFD requires three strip-related fields: StripOffsets, RowsPerStrip, and StripByteCounts. The StripOffsets field is an array of pointers to the strip or strips that contain the actual image data. The StripByteCounts field gives the number of bytes in each strip after compression. TIFF requires that each strip, except
Each IFD requires three strip-related fields: StripOffsets, RowsPerStrip, and StripByteCounts. The StripOffsets field is an array of pointers to the strip or strips that contain the actual image data. The StripByteCounts field gives the number of bytes in each strip after compression. TIFF requires that each strip, except
Buckley, et al. Standards Track [Page 10] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 10] RFC 3949 File Format for Internet Fax February 2005
the last, contain the same number of scanlines, which is given in the RowsPerStrip field. This document introduces the new StripRowCounts field that allows a variable number of scanlines per strip, which is required by the Mixed Raster Content fax profile (Section 8).
the last, contain the same number of scanlines, which is given in the RowsPerStrip field. This document introduces the new StripRowCounts field that allows a variable number of scanlines per strip, which is required by the Mixed Raster Content fax profile (Section 8).
Image data is stored as uninterpreted, compressed image data streams within a strip. The formats of these streams follow the ITU-T Recommendations. The Compression field in the IFD indicates the type of compression, and other TIFF fields in the IFD describe image attributes such as color encoding and spatial resolution. Compression parameters are stored in the compressed data stream rather than in TIFF fields. This makes the TIFF representation and compressed data format specification independent of each another. This approach, modeled on [TTN2], allows TIFF to add new compression schemes gracefully as they become available.
Image data is stored as uninterpreted, compressed image data streams within a strip. The formats of these streams follow the ITU-T Recommendations. The Compression field in the IFD indicates the type of compression, and other TIFF fields in the IFD describe image attributes such as color encoding and spatial resolution. Compression parameters are stored in the compressed data stream rather than in TIFF fields. This makes the TIFF representation and compressed data format specification independent of each another. This approach, modeled on [TTN2], allows TIFF to add new compression schemes gracefully as they become available.
Some attributes can be specified both in the compressed data stream and within a TIFF field. It is possible that the two values will differ. When this happens for values required to interpret the data stream, the values in the data stream take precedence. For informational values that are not required to interpret the data stream, such as author name, then the TIFF field value takes precedence.
Some attributes can be specified both in the compressed data stream and within a TIFF field. It is possible that the two values will differ. When this happens for values required to interpret the data stream, the values in the data stream take precedence. For informational values that are not required to interpret the data stream, such as author name, then the TIFF field value takes precedence.
2.1.3. TIFF File Structure for Fax Applications
2.1.3. TIFF File Structure for Fax Applications
The TIFF specification has a very flexible file structure that does not specify the ordering of IFDs, field values, and image data in a file. Individual applications may require or recommend an ordering.
The TIFF specification has a very flexible file structure that does not specify the ordering of IFDs, field values, and image data in a file. Individual applications may require or recommend an ordering.
This specification recommends that when using a TIFF file for facsimile, a multi-page fax document SHOULD be represented as a linked list of IFDs. It also recommends that a TIFF file for facsimile SHOULD order pages in a TIFF file in the same way that they are ordered in a fax data stream. In a TIFF file, a page consists of several elements: one or more IFDs (including subIFDs), long field values that are stored outside the IFDs, and image data (in one or more strips).
This specification recommends that when using a TIFF file for facsimile, a multi-page fax document SHOULD be represented as a linked list of IFDs. It also recommends that a TIFF file for facsimile SHOULD order pages in a TIFF file in the same way that they are ordered in a fax data stream. In a TIFF file, a page consists of several elements: one or more IFDs (including subIFDs), long field values that are stored outside the IFDs, and image data (in one or more strips).
The minimal black-and-white profile (Profile S) specifies a required ordering of pages and elements within a page (Section 3.5). The extended black-and-white profile (Profile F) provides guidelines for ordering pages and page elements (Section 4.4.6). Other profiles SHOULD follow these guidelines. This recommendation is intended to simplify the implementation of TIFF writers and readers in fax applications and the conversion between TIFF file and fax data stream representations. However, for interchange robustness, readers SHOULD
The minimal black-and-white profile (Profile S) specifies a required ordering of pages and elements within a page (Section 3.5). The extended black-and-white profile (Profile F) provides guidelines for ordering pages and page elements (Section 4.4.6). Other profiles SHOULD follow these guidelines. This recommendation is intended to simplify the implementation of TIFF writers and readers in fax applications and the conversion between TIFF file and fax data stream representations. However, for interchange robustness, readers SHOULD
Buckley, et al. Standards Track [Page 11] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 11] RFC 3949 File Format for Internet Fax February 2005
be prepared to read TIFF files whose structure is consistent with [TIFF], which supports a more flexible file structure than is recommended here.
be prepared to read TIFF files whose structure is consistent with [TIFF], which supports a more flexible file structure than is recommended here.
This specification introduces an optional new GlobalParametersIFD field, defined in Section 2.2.4. This field has type IFD and indicates parameters describing the fax session. While it is often possible to obtain these parameters by scanning the file, it is convenient to make them available together in one place for fast and easy access. If the GlobalParametersIFD occurs in a TIFF file, it SHOULD be located in the first IFD, immediately following the 8-byte image file header.
This specification introduces an optional new GlobalParametersIFD field, defined in Section 2.2.4. This field has type IFD and indicates parameters describing the fax session. While it is often possible to obtain these parameters by scanning the file, it is convenient to make them available together in one place for fast and easy access. If the GlobalParametersIFD occurs in a TIFF file, it SHOULD be located in the first IFD, immediately following the 8-byte image file header.
2.2. TIFF Fields for All Fax Applications
2.2. TIFF Fields for All Fax Applications
The TIFF specification [TIFF] is organized as a baseline set and several extensions, including technical notes [TTN1, TTN2] that will be incorporated in the next release of TIFF. The baseline and extensions have required and optional fields.
The TIFF specification [TIFF] is organized as a baseline set and several extensions, including technical notes [TTN1, TTN2] that will be incorporated in the next release of TIFF. The baseline and extensions have required and optional fields.
Facsimile applications require (and recommend) a mixture of baseline and extensions fields, as well as some new fields that are not part of the TIFF specification and that are defined in this document. This sub-section lists the fields that are required or recommended for all profiles. In particular, Section 2.2.1 lists the fields that are required by all profiles and that have values that do not depend on the profile. Section 2.2.2 lists the fields that are required by all profiles and that have values that do depend on the profile. Section 2.2.3 lists the fields that are recommended for all profiles. Fields required or recommended by some but not all profiles are given in the section (Section 3 - 8) that describes that profile. The sections for each fax profile have subsections for required and recommended fields; each subsection organizes the fields according to whether they are baseline, extension or new.
Facsimile applications require (and recommend) a mixture of baseline and extensions fields, as well as some new fields that are not part of the TIFF specification and that are defined in this document. This sub-section lists the fields that are required or recommended for all profiles. In particular, Section 2.2.1 lists the fields that are required by all profiles and that have values that do not depend on the profile. Section 2.2.2 lists the fields that are required by all profiles and that have values that do depend on the profile. Section 2.2.3 lists the fields that are recommended for all profiles. Fields required or recommended by some but not all profiles are given in the section (Section 3 - 8) that describes that profile. The sections for each fax profile have subsections for required and recommended fields; each subsection organizes the fields according to whether they are baseline, extension or new.
The fields required for facsimile have only a few legal values, specified in the ITU-T Recommendations. Of these legal values, some are required and some are optional, just as they are required (mandatory) or optional in fax implementations that conform to the ITU-T Recommendations. The required and optional values are noted in the sections on the different fax profiles.
The fields required for facsimile have only a few legal values, specified in the ITU-T Recommendations. Of these legal values, some are required and some are optional, just as they are required (mandatory) or optional in fax implementations that conform to the ITU-T Recommendations. The required and optional values are noted in the sections on the different fax profiles.
Buckley, et al. Standards Track [Page 12] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 12] RFC 3949 File Format for Internet Fax February 2005
This section describes the fields required or recommended by all fax profiles. The pattern for the description of TIFF fields in this document is as follows:
This section describes the fields required or recommended by all fax profiles. The pattern for the description of TIFF fields in this document is as follows:
FieldName(TagValueInDecimal) = allowable values. TYPE
FieldName(TagValueInDecimal) = allowable values. TYPE
WhetherRequiredByTIFForTIFFforFAX
Count = (omitted if =1) = (if not in current spec but available)
Explanation of the field, how it's used, and the values it can
have. Default value, if any, as specified in [TIFF].
WhetherRequiredByTIFForTIFFforFAX Count = (omitted if =1) = (if not in current spec but available) Explanation of the field, how it's used, and the values it can have. Default value, if any, as specified in [TIFF].
When a field's default value is the desired value, that field may be omitted from the relevant IFD unless specifically required by the text of this specification.
When a field's default value is the desired value, that field may be omitted from the relevant IFD unless specifically required by the text of this specification.
2.2.1. TIFF fields required for all fax profiles
2.2.1. TIFF fields required for all fax profiles
The TIFF fields listed in this section SHALL be used by all fax profiles but have field values that are not specified by the ITU standards, i.e., the fields do not depend on the profile. The next subsection lists the fields that SHALL be used by all fax profiles, but which do have values specified by the ITU-specified or profile- specific values. Fields that SHALL be used by some but not all profiles are given in the Sections (3 - 8) that describe the profiles that use them.
The TIFF fields listed in this section SHALL be used by all fax profiles but have field values that are not specified by the ITU standards, i.e., the fields do not depend on the profile. The next subsection lists the fields that SHALL be used by all fax profiles, but which do have values specified by the ITU-specified or profile- specific values. Fields that SHALL be used by some but not all profiles are given in the Sections (3 - 8) that describe the profiles that use them.
ImageLength(257)
SHORT or LONG
RequiredByTIFFBaseline
Total number of scanlines in image.
No default, must be specified.
ImageLength(257) SHORT or LONG RequiredByTIFFBaseline Total number of scanlines in image. No default, must be specified.
PageNumber(297)
SHORT
RequiredByTIFFforFAX, TIFFExtension
Count = 2
The first number represents the page number (0 for the first
page); the second number is the total number of pages in the
document. If the second value is 0, then the total page count is
not available.
No default, must be specified
PageNumber(297) SHORT RequiredByTIFFforFAX, TIFFExtension Count = 2 The first number represents the page number (0 for the first page); the second number is the total number of pages in the document. If the second value is 0, then the total page count is not available. No default, must be specified
Buckley, et al. Standards Track [Page 13] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 13] RFC 3949 File Format for Internet Fax February 2005
RowsPerStrip(278)
SHORT or LONG
RequiredByTIFFBaseline
The number of scanlines per TIFF strip, except for the last strip.
For a single strip image, this is the same as the value of the
ImageLength field.
Default = 2**32 - 1 (meaning all scanlines in one strip).
RowsPerStrip(278) SHORT or LONG RequiredByTIFFBaseline The number of scanlines per TIFF strip, except for the last strip. For a single strip image, this is the same as the value of the ImageLength field. Default = 2**32 - 1 (meaning all scanlines in one strip).
StripByteCounts(279)
SHORT or LONG
RequiredByTIFFBaseline
Count = number of strips
For each strip, the number of bytes in that strip after
compression.
No default, must be specified.
StripByteCounts(279) SHORT or LONG RequiredByTIFFBaseline Count = number of strips For each strip, the number of bytes in that strip after compression. No default, must be specified.
StripOffsets(273)
SHORT or LONG
RequiredByTIFFBaseline
Count = number of strips
For each strip, the byte offset from the beginning of the file to
the start of that strip.
No default, must be specified.
StripOffsets(273) SHORT or LONG RequiredByTIFFBaseline Count = number of strips For each strip, the byte offset from the beginning of the file to the start of that strip. No default, must be specified.
2.2.2. Additional TIFF fields required for all fax profiles
2.2.2. Additional TIFF fields required for all fax profiles
The TIFF fields listed in this section SHALL be used by all fax profiles, but the values associated with them depend on the profile being described and the associated ITU Recommendations. Therefore, only the fields are defined here; the values applicable to a particular fax profile are described in Sections 3 - 8. Fields that SHALL be used by some but not all profiles are given in the section (3 - 8) describing the profile that uses them.
The TIFF fields listed in this section SHALL be used by all fax profiles, but the values associated with them depend on the profile being described and the associated ITU Recommendations. Therefore, only the fields are defined here; the values applicable to a particular fax profile are described in Sections 3 - 8. Fields that SHALL be used by some but not all profiles are given in the section (3 - 8) describing the profile that uses them.
BitsPerSample(258)
SHORT
RequiredByTIFFBaseline
Number of bits per image sample.
Default = 1 (field may be omitted if this is the value).
BitsPerSample(258) SHORT RequiredByTIFFBaseline Number of bits per image sample. Default = 1 (field may be omitted if this is the value).
Compression(259)
SHORT
RequiredByTIFFBaseline
Compression method used for image data.
Default = 1 (no compression, so may not be omitted for FAX).
Compression(259) SHORT RequiredByTIFFBaseline Compression method used for image data. Default = 1 (no compression, so may not be omitted for FAX).
Buckley, et al. Standards Track [Page 14] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 14] RFC 3949 File Format for Internet Fax February 2005
FillOrder(266)
SHORT
RequiredByTIFFforFax
The default bit order in Baseline TIFF per [TIFF] is indicated by
FillOrder=1, where bits are not reversed before being stored.
However, TIFF for Fax typically uses the setting of FillOrder=2,
where the bit order within bytes is reversed before storage (i.e.,
bits are stored with the Least Significant Bit first).
Default = 1 (field may be omitted if this is the value)
Facsimile data appears on the phone line in bit-reversed order
relative to its description in the relevant ITU compression
Recommendation. Therefore, a wide majority of facsimile
implementations choose this natural order for storage.
FillOrder(266) SHORT RequiredByTIFFforFax The default bit order in Baseline TIFF per [TIFF] is indicated by FillOrder=1, where bits are not reversed before being stored. However, TIFF for Fax typically uses the setting of FillOrder=2, where the bit order within bytes is reversed before storage (i.e., bits are stored with the Least Significant Bit first). Default = 1 (field may be omitted if this is the value) Facsimile data appears on the phone line in bit-reversed order relative to its description in the relevant ITU compression Recommendation. Therefore, a wide majority of facsimile implementations choose this natural order for storage.
Nevertheless, all readers conforming to this specification must be
able to read data in both bit orders, except in the case of
Profile S, which only requires support for FillOrder=2 (Least
Significant Bit first).
Nevertheless, all readers conforming to this specification must be able to read data in both bit orders, except in the case of Profile S, which only requires support for FillOrder=2 (Least Significant Bit first).
ImageWidth(256)
SHORT or LONG
RequiredByTIFFBaseline
The number of pixels (columns) per scanline (row) of the image
No default, must be specified.
ImageWidth(256) SHORT or LONG RequiredByTIFFBaseline The number of pixels (columns) per scanline (row) of the image No default, must be specified.
NewSubFileType(254)
LONG
RequiredByTIFFforFAX
A general indication of the kind of data contained in this IFD Bit
1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for FAX).
NewSubFileType(254) LONG RequiredByTIFFforFAX A general indication of the kind of data contained in this IFD Bit 1 is 1 if the image is a single page of a multi-page document. Default = 0 (no subfile bits on, so may not be omitted for FAX).
PhotometricInterpretation(262)
SHORT
RequiredByTIFFBaseline
The color space of the image data.
No default, must be specified.
PhotometricInterpretation(262) SHORT RequiredByTIFFBaseline The color space of the image data. No default, must be specified.
ResolutionUnit(296)
SHORT
RequiredByTIFFBaseline The unit of measure for resolution. 2 =
inch, 3 = centimeter; Default = 2 (field may be omitted if this is
the value)
ResolutionUnit(296) SHORT RequiredByTIFFBaseline The unit of measure for resolution. 2 = inch, 3 = centimeter; Default = 2 (field may be omitted if this is the value)
Buckley, et al. Standards Track [Page 15] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 15] RFC 3949 File Format for Internet Fax February 2005
SamplesPerPixel(277)
SHORT
RequiredByTIFFBaseline
The number of color components per pixel; SamplesPerPixel is 1 for
a black-and-white, grayscale or indexed (palette) image. Default
= 1 (field may be omitted if this is the value).
SamplesPerPixel(277) SHORT RequiredByTIFFBaseline The number of color components per pixel; SamplesPerPixel is 1 for a black-and-white, grayscale or indexed (palette) image. Default = 1 (field may be omitted if this is the value).
XResolution(282)
RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image in pixels per resolution
unit. The ITU-T Recommendations for facsimile specify a small
number of horizontal resolutions: 100, 200, 300, 400 pixels per
inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per
inch). The allowed XResolution values for each profile are given
in the section defining that profile. Per [T.4], it is
permissible for applications to treat the following XResolution
values as being equivalent: <204, 200> and <400,408> in
pixels/inch. These equivalencies were allowed by [T.4] to permit
conversions between inch and metric based facsimile terminals. To
ensure interoperability, if an application accepts any member of
the pairs then T.4 requires it to accept both (e.g., accept 204 if
200 pixels per inch is accepted). TIFF for Facsimile Writers
SHOULD express XResolution in inch-based units, for consistency
with historical practice and to maximize interoperability. See
the table below for information on how to convert from an ITU-T
metric value to its inch-based equivalent resolution.
No default, must be specified
XResolution(282) RATIONAL RequiredByTIFFBaseline The horizontal resolution of the image in pixels per resolution unit. The ITU-T Recommendations for facsimile specify a small number of horizontal resolutions: 100, 200, 300, 400 pixels per inch, and 80, 160 pixels per centimeter (or 204, 408 pixels per inch). The allowed XResolution values for each profile are given in the section defining that profile. Per [T.4], it is permissible for applications to treat the following XResolution values as being equivalent: <204, 200> and <400,408> in pixels/inch. These equivalencies were allowed by [T.4] to permit conversions between inch and metric based facsimile terminals. To ensure interoperability, if an application accepts any member of the pairs then T.4 requires it to accept both (e.g., accept 204 if 200 pixels per inch is accepted). TIFF for Facsimile Writers SHOULD express XResolution in inch-based units, for consistency with historical practice and to maximize interoperability. See the table below for information on how to convert from an ITU-T metric value to its inch-based equivalent resolution. No default, must be specified
YResolution(283)
RATIONAL
RequiredByTIFFBaseline
The vertical resolution of the image in pixels per resolution
unit. The ITU-T Recommendations for facsimile specify a small
number of vertical resolutions: 100, 200, 300, 400 pixels per
inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391
pixels per inch). The allowed YResolution values for each profile
are given in the section defining that profile. Per [T.4], it is
permissible for applications to treat the following YResolution
values as being equivalent: <98, 100>, <196, 200>, and <391, 400>
in pixels/inch. These equivalencies were allowed by [T.4] to
permit conversions between inch- and metric-based facsimile
terminals. To insure interoperability, if an application accepts
any member of the pairs, then T.4 requires it to accept both
(e.g., accept 98 if 100 pixels per inch is accepted). TIFF for
Facsimile Writers SHOULD express YResolution in inch-based units,
for consistency with historical practice and to maximize
YResolution(283) RATIONAL RequiredByTIFFBaseline The vertical resolution of the image in pixels per resolution unit. The ITU-T Recommendations for facsimile specify a small number of vertical resolutions: 100, 200, 300, 400 pixels per inch, and 38.5, 77, 154 pixels per centimeter (or 98, 196, 391 pixels per inch). The allowed YResolution values for each profile are given in the section defining that profile. Per [T.4], it is permissible for applications to treat the following YResolution values as being equivalent: <98, 100>, <196, 200>, and <391, 400> in pixels/inch. These equivalencies were allowed by [T.4] to permit conversions between inch- and metric-based facsimile terminals. To insure interoperability, if an application accepts any member of the pairs, then T.4 requires it to accept both (e.g., accept 98 if 100 pixels per inch is accepted). TIFF for Facsimile Writers SHOULD express YResolution in inch-based units, for consistency with historical practice and to maximize
Buckley, et al. Standards Track [Page 16] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 16] RFC 3949 File Format for Internet Fax February 2005
interoperability. See the table below for information on
converting from the metric value to its inch based equivalent
resolution.
No default, must be specified.
interoperability. See the table below for information on converting from the metric value to its inch based equivalent resolution. No default, must be specified.
+-----------------------------+-----------------------------+ | XResolution | YResolution | +--------------+--------------+--------------+--------------+ |ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit| | =2 (inch) | =3 (cm) | =2 (inch) | =3 (cm) | +--------------+--------------+--------------+--------------+ | 100 | | 100 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 98 | 38.5 | | 200 | | 100 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 196 | 77 | | 200 | | 200 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 391 | 154 | +--------------+--------------+--------------+--------------+ | 300 | | 300 | | +--------------+--------------+--------------+--------------+ | 408 | 160 | 391 | 154 | | 400 | | 400 | | +--------------+--------------+--------------+--------------+
+-----------------------------+-----------------------------+ | XResolution | YResolution | +--------------+--------------+--------------+--------------+ |ResolutionUnit|ResolutionUnit|ResolutionUnit|ResolutionUnit| | =2 (inch) | =3 (cm) | =2 (inch) | =3 (cm) | +--------------+--------------+--------------+--------------+ | 100 | | 100 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 98 | 38.5 | | 200 | | 100 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 196 | 77 | | 200 | | 200 | | +--------------+--------------+--------------+--------------+ | 204 | 80 | 391 | 154 | +--------------+--------------+--------------+--------------+ | 300 | | 300 | | +--------------+--------------+--------------+--------------+ | 408 | 160 | 391 | 154 | | 400 | | 400 | | +--------------+--------------+--------------+--------------+
2.2.3. TIFF fields recommended for all fax profiles
2.2.3. TIFF fields recommended for all fax profiles
The TIFF fields listed in this section MAY be used by all fax profiles. However, Profile S writers (the minimal fax profile described in Section 3) SHOULD NOT use these fields. Recommended fields that are profile-specific are described in Sections 3 - 8.
The TIFF fields listed in this section MAY be used by all fax profiles. However, Profile S writers (the minimal fax profile described in Section 3) SHOULD NOT use these fields. Recommended fields that are profile-specific are described in Sections 3 - 8.
DateTime(306)
ASCII
OptionalInTIFFBaseline
Date/time of image creation in 24-hour format
"YYYY:MM:DD HH:MM:SS". No default.
DateTime(306) ASCII OptionalInTIFFBaseline Date/time of image creation in 24-hour format "YYYY:MM:DD HH:MM:SS". No default.
DocumentName(269)
ASCII
OptionalInTIFFExtension(DocumentStorageAndRetrieval)
The name of the scanned document. This is a TIFF extension field,
not a Baseline TIFF field. No default.
DocumentName(269) ASCII OptionalInTIFFExtension(DocumentStorageAndRetrieval) The name of the scanned document. This is a TIFF extension field, not a Baseline TIFF field. No default.
Buckley, et al. Standards Track [Page 17] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 17] RFC 3949 File Format for Internet Fax February 2005
ImageDescription(270)
ASCII
OptionalInTIFFBaseline
A string describing the contents of the image.
No default.
ImageDescription(270) ASCII OptionalInTIFFBaseline A string describing the contents of the image. No default.
Orientation(274) = 1 - 8.
SHORT
OptionalinTIFFBaseline 1: 0th row represents the visual top of the
image; the 0th column represents the visual left side of the
image. See the current TIFF spec [TIFF] for further values;
Baseline TIFF only requires value=1. Default = 1.
Note: It is recommended that a writer that is aware of the
orientation include this field to give a positive indication of
the orientation, even if the value is the default. Writers should
not generate mirror images, because many readers will not properly
reverse the image before display or print.
Orientation(274) = 1 - 8. SHORT OptionalinTIFFBaseline 1: 0th row represents the visual top of the image; the 0th column represents the visual left side of the image. See the current TIFF spec [TIFF] for further values; Baseline TIFF only requires value=1. Default = 1. Note: It is recommended that a writer that is aware of the orientation include this field to give a positive indication of the orientation, even if the value is the default. Writers should not generate mirror images, because many readers will not properly reverse the image before display or print.
Software(305)
ASCII
OptionalInTIFFBaseline
The name and release number of the software package that
created the image.
No default.
Software(305) ASCII OptionalInTIFFBaseline The name and release number of the software package that created the image. No default.
2.2.4. New TIFF fields recommended for fax profiles
2.2.4. New TIFF fields recommended for fax profiles
The new TIFF fields listed in this section MAY be used by all fax profiles. However, Profile S writes (the minimal fax profile described in Section 3) SHOULD NOT use these fields. In addition, support for these new TIFF fields has not been included in historical TIFF-F readers described in Section 4 and [TIFF-F]. These fields describe "global" parameters of the fax session that created the image data. They are optional, not part of the current TIFF specification, and are defined in this document.
The new TIFF fields listed in this section MAY be used by all fax profiles. However, Profile S writes (the minimal fax profile described in Section 3) SHOULD NOT use these fields. In addition, support for these new TIFF fields has not been included in historical TIFF-F readers described in Section 4 and [TIFF-F]. These fields describe "global" parameters of the fax session that created the image data. They are optional, not part of the current TIFF specification, and are defined in this document.
The first new field, GlobalParametersIFD, is an IFD that contains global parameters and is located in a Primary IFD.
The first new field, GlobalParametersIFD, is an IFD that contains global parameters and is located in a Primary IFD.
GlobalParametersIFD (400) IFD or LONG
GlobalParametersIFD (400) IFD or LONG
An IFD containing global parameters. It is recommended that a
TIFF writer place this field in the first IFD, where a TIFF reader
would find it quickly.
An IFD containing global parameters. It is recommended that a TIFF writer place this field in the first IFD, where a TIFF reader would find it quickly.
Each field in the GlobalParametersIFD is a TIFF field that is
legal in any IFD. Required baseline fields should not be located
in the GlobalParametersIFD but should be in each image IFD. If a
Each field in the GlobalParametersIFD is a TIFF field that is legal in any IFD. Required baseline fields should not be located in the GlobalParametersIFD but should be in each image IFD. If a
Buckley, et al. Standards Track [Page 18] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 18] RFC 3949 File Format for Internet Fax February 2005
conflict exists between fields in the GlobalParametersIFD and in
the image IFDs, then the data in the image IFD shall prevail.
conflict exists between fields in the GlobalParametersIFD and in the image IFDs, then the data in the image IFD shall prevail.
Among the GlobalParametersIFD entries is a new ProfileType field
that generally describes information in this IFD and in the TIFF
file.
Among the GlobalParametersIFD entries is a new ProfileType field that generally describes information in this IFD and in the TIFF file.
ProfileType(401)
LONG
The type of image data stored in this IFD.
0 = Unspecified
1 = Group 3 fax
No default
ProfileType(401) LONG The type of image data stored in this IFD. 0 = Unspecified 1 = Group 3 fax No default
The following new global fields are defined in this document as IFD entries for use with fax applications.
The following new global fields are defined in this document as IFD entries for use with fax applications.
FaxProfile(402) = 0 - 6.
BYTE
The profile that applies to this file; a profile is subset of the
full set of permitted fields and field values of TIFF for
facsimile. The currently defined values are:
0: does not conform to a profile defined for TIFF for facsimile
1: minimal black & white lossless, Profile S
2: extended black & white lossless, Profile F
3: lossless JBIG black & white, Profile J
4: lossy color and grayscale, Profile C
5: lossless color and grayscale, Profile L
6: Mixed Raster Content, Profile M
FaxProfile(402) = 0 - 6. BYTE The profile that applies to this file; a profile is subset of the full set of permitted fields and field values of TIFF for facsimile. The currently defined values are: 0: does not conform to a profile defined for TIFF for facsimile 1: minimal black & white lossless, Profile S 2: extended black & white lossless, Profile F 3: lossless JBIG black & white, Profile J 4: lossy color and grayscale, Profile C 5: lossless color and grayscale, Profile L 6: Mixed Raster Content, Profile M
CodingMethods(403)
LONG
This field indicates which coding methods are used in the file. A
value of 1 in a bit location indicates the corresponding coding
method is used. More than one bit set to 1 means more than one
coding method is used in the file.
Bit 0: unspecified compression
Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman)
Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified READ)
Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR)
Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG)
Bit 5: ITU-T Rec. T.81 (Baseline JPEG)
Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color)
Bits 7 - 31: reserved for future use
CodingMethods(403) LONG This field indicates which coding methods are used in the file. A value of 1 in a bit location indicates the corresponding coding method is used. More than one bit set to 1 means more than one coding method is used in the file. Bit 0: unspecified compression Bit 1: 1-dimensional coding, ITU-T Rec. T.4 (MH - Modified Huffman) Bit 2: 2-dimensional coding, ITU-T Rec. T.4 (MR - Modified READ) Bit 3: 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified MR) Bit 4: ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (JBIG) Bit 5: ITU-T Rec. T.81 (Baseline JPEG) Bit 6: ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (JBIG color) Bits 7 - 31: reserved for future use
Buckley, et al. Standards Track [Page 19] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 19] RFC 3949 File Format for Internet Fax February 2005
Note: There is a limit of 32 compression types to identify standard compression methods.
Note: There is a limit of 32 compression types to identify standard compression methods.
VersionYear(404)
BYTE
Count: 4
The year of the standard specified by the FaxProfile field, given
as 4 characters, e.g., '1997'; used in lossy and lossless color
profiles.
VersionYear(404) BYTE Count: 4 The year of the standard specified by the FaxProfile field, given as 4 characters, e.g., '1997'; used in lossy and lossless color profiles.
ModeNumber (405)
BYTE
The mode of the standard specified by the FaxProfile field. A
value of 0 indicates Mode 1.0; used in Mixed Raster Content
profile.
ModeNumber (405) BYTE The mode of the standard specified by the FaxProfile field. A value of 0 indicates Mode 1.0; used in Mixed Raster Content profile.
3. Profile S: Minimal Black-and-White Fax Profile
3. Profile S: Minimal Black-and-White Fax Profile
This section defines the minimal black-and-white subset of TIFF for facsimile. This subset is designated Profile S. All implementations of TIFF for facsimile SHALL support the minimal subset.
This section defines the minimal black-and-white subset of TIFF for facsimile. This subset is designated Profile S. All implementations of TIFF for facsimile SHALL support the minimal subset.
Black-and-white mode is the binary fax application most users are familiar with today. This mode is appropriate for black-and-white text and line art. Black-and-white mode is divided into two levels of capability. This section describes the minimal interchange set of TIFF fields that must be supported by all implementations in order to assure that some form of image, albeit black-and-white, can be interchanged. This minimum interchange set is a strict subset of the fields and values defined for the extended black-and-white profile (TIFF-F or Profile F) in Section 4, which describes extensions to the minimal interchange set of fields that provide a richer set of black-and-white capabilities.
Black-and-white mode is the binary fax application most users are familiar with today. This mode is appropriate for black-and-white text and line art. Black-and-white mode is divided into two levels of capability. This section describes the minimal interchange set of TIFF fields that must be supported by all implementations in order to assure that some form of image, albeit black-and-white, can be interchanged. This minimum interchange set is a strict subset of the fields and values defined for the extended black-and-white profile (TIFF-F or Profile F) in Section 4, which describes extensions to the minimal interchange set of fields that provide a richer set of black-and-white capabilities.
3.1. Overview
3.1. Overview
The minimal interchange portion of the black-and-white facsimile mode supports 1-dimensional Modified Huffman (MH) compression, with the original Group 3 fax resolutions, commonly called "standard" and "fine."
The minimal interchange portion of the black-and-white facsimile mode supports 1-dimensional Modified Huffman (MH) compression, with the original Group 3 fax resolutions, commonly called "standard" and "fine."
To assure interchange, this profile uses the minimal set of fields with a minimal set of values. There are no recommended fields in this profile. Further, the TIFF file is required to be "little- endian", which means that the byte order value in the TIFF header is "II". This profile defines a required ordering for the pages in a fax document and for the IFDs and image data of a page. It also requires
To assure interchange, this profile uses the minimal set of fields with a minimal set of values. There are no recommended fields in this profile. Further, the TIFF file is required to be "little- endian", which means that the byte order value in the TIFF header is "II". This profile defines a required ordering for the pages in a fax document and for the IFDs and image data of a page. It also requires
Buckley, et al. Standards Track [Page 20] RFC 3949 File Format for Internet Fax February 2005
Buckley, et al. Standards Track [Page 20] RFC 3949 File Format for Internet Fax February 2005
that a single strip contain the image data for each page; see Section 3.5. The image data may contain RTC sequences, as specified in Section 3.4.
that a single strip contain the image data for each page; see Section 3.5. The image data may contain RTC sequences, as specified in Section 3.4.
3.2. Required TIFF Fields
3.2. Required TIFF Fields
Besides the fields listed in Section 2.2.1, the minimal black-and- white fax profile requires the following fields. The fields listed in Section 2.2.1 and the fields and fax-specific values specified in this subsection must be supported by all implementations.
Besides the fields listed in Section 2.2.1, the minimal black-and- white fax profile requires the following fields. The fields listed in Section 2.2.1 and the fields and fax-specific values specified in this subsection must be supported by all implementations.
3.2.1. Baseline fields
3.2.1. Baseline fields
BitsPerSample(258) = 1.
SHORT
RequiredByTIFFBaseline
Binary data only.
Default = 1 (field may be omitted if this is the value)
BitsPerSample(258) = 1. SHORT RequiredByTIFFBaseline Binary data only. Default = 1 (field may be omitted if this is the value)
Compression(259) = 3.
SHORT
RequiredByTIFFBaseline
3 = 1- or 2- dimensional coding.
The value 3 is a TIFF extension value [TIFF]. The T4Options field
must be specified, and its value specifies that the data is
encoded with the Modified Huffman (MH) compression of [T.4].
Compression(259) = 3. SHORT RequiredByTIFFBaseline 3 = 1- or 2- dimensional coding. The value 3 is a TIFF extension value [TIFF]. The T4Options field must be specified, and its value specifies that the data is encoded with the Modified Huffman (MH) compression of [T.4].
FillOrder(266) = 2.
SHORT
RequiredByTIFFBaseline
2 = Least Significant Bit first
FillOrder(266) = 2. SHORT RequiredByTIFFBaseline 2 = Least Significant Bit first
NOTE: Baseline TIFF readers are only required to support FillOrder
1, where the lowest numbered pixel is stored in the MSB of the
byte. However, because many devices, such as modems, transmit the
LSB first when converting the data to serial form, it is common
for black-and-white fax products to use the second FillOrder = 2,
where the lowest numbered pixel is stored in the LSB. Therefore,
this value is specified in the minimal black-and-white profile.
以下に注意してください。 基線TIFF読者はFillOrder1を支持するだけでよいです。そこでは、バイトのMSBに格納されます中で番号付の画素最も低い。 しかしながら、最初に、データを連続フォームに変換するとき、モデムなどの多くの装置がLSBを伝えるので、白黒のファックス製品が2番目のFillOrder=2を使用するのは、一般です。(そこでは、LSBに格納されます中で番号付の画素最も低い)。 したがって、この値は最小量の白黒のプロフィールで指定されます。
ImageWidth(256) = 1728.
SHORT or LONG
RequiredByTIFFBaseline
This profile only supports a page width of 1728 pixels. This
width corresponds to North American Letter and Legal and to ISO A4
size pages. No default, must be specified.
ImageWidth(256)=1728。 SHORTかLONG RequiredByTIFFBaseline Thisが1728画素のページ幅にサポートだけの輪郭を描きます。 この幅は北米のLetterとLegalと、そして、ISO A4サイズページに対応しています。 どんなデフォルトも指定されているはずがありません。
Buckley, et al. Standards Track [Page 21] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[21ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
NewSubFileType(254) = (Bit 1=1).
LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax).
NewSubFileType(254)は(ビット1=1)と等しいです。 イメージがマルチページドキュメントの1ページであるなら、LONG RequiredByTIFFforFAX Bit1は1歳です。 デフォルト=0、(いいえがビットを副ファイルするので省略されないかもしれない、ファックス)
PhotometricInterpretation(262) = 0.
SHORT
RequiredByTIFFBaseline
0 = pixel value 1 means black.
No default, must be specified.
PhotometricInterpretation(262)=0。 SHORT RequiredByTIFFBaseline0=ピクセル値1は黒いことを意味します。 どんなデフォルトも指定されているはずがありません。
ResolutionUnit(296) = 2.
SHORT
RequiredByTIFFBaseline
The unit of measure for resolution. 2 = inch.
Default = 2 (field may be omitted if this is the value).
ResolutionUnit(296)=2。 SHORT RequiredByTIFFBaseline、解決のための測定の単位。 2はインチと等しいです。 デフォルト=2(分野はこれが値であるなら省略されるかもしれません)。
SamplesPerPixel(277) = 1.
SHORT
RequiredByTIFFBaseline
The number of components per pixel; 1 for black-and-white.
Default = 1 (field may be omitted if this is the value).
SamplesPerPixel(277)=1。 SHORT RequiredByTIFFBaseline、1画素あたりのコンポーネントの数。 1 白黒のために。 デフォルト=1(分野はこれが値であるなら省略されるかもしれません)。
XResolution(282) = 200, 204.
RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are 200 and
204, which may be treated as equivalent. See Section 2.2.2 for
inch metric equivalency. No default, must be specified.
XResolution(282)=200、204。 RATIONAL RequiredByTIFFBaseline、イメージの水平な解像度は解決ユニットあたりの画素で言い表されます。 画素/インチでは、許容値は、200と204です。(その204は同等物として扱われるかもしれません)。 インチのメートル法の同等に関してセクション2.2.2を見てください。 どんなデフォルトも指定されているはずがありません。
YResolution(283) = 98, 100, 196, 200.
RATIONAL
RequiredByTIFFBaseline The vertical resolution of the image is
expressed in pixels per resolution unit. In pixels/inch, the
allowed values are 98, 100, 196, and 200; 98 and 100 may be
treated as equivalent, and 196 and 200 may be treated as
equivalent. See Section 2.2.2 for inch metric equivalency. No
default, must be specified.
YResolution(283)=98、100、196、200。 RATIONAL RequiredByTIFFBaseline、イメージの垂直解像度は解決ユニットあたりの画素で言い表されます。 画素/インチでは、許容値は、98と、100と、196と、200です。 同等物、196、および200が同等物として扱われるとき、98と100は扱われるかもしれません。 インチのメートル法の同等に関してセクション2.2.2を見てください。 どんなデフォルトも指定されているはずがありません。
Buckley, et al. Standards Track [Page 22] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[22ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
3.2.2. Extension fields
3.2.2. 拡大分野
T4Options(292) = (Bit 0 = 0, Bit 1 = 0, Bit 2 = 0, 1)
LONG
RequiredTIFFExtension (when Compression = 3)
Bit 0 = 0 indicates MH compression.
Bit 1 must be 0.
Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
aligned.
Default is all bits are 0 (applies when EOLs are not byte aligned)
(ビット0 = 0、Bit1 = 0、Bit2 = 0、1)LONG RequiredTIFFExtension(Compression=3であるときに)T4Options(292)=ビット0 = 0はMH圧縮を示します。 ビット1は0であるに違いありません。 = ビット2 = 1は、EOLsが並べられたバイトであることを示して、バイトではなく、0EOLsが並びました。 デフォルトはすべてのビットが0であるということです。(EOLsが並べられたバイトでないときに、適用します)
Note: The T4Options field is required when the Compression field has a value of 3. Bit 0 of this field specifies the compression used (MH only in this profile). MH coding requires the use of EOL (End of Line) codes: Bit 2 indicates whether the EOL codes are byte-aligned or not. See Section 3.4 for details.
以下に注意してください。 Compression分野に3の値があると、T4Options分野が必要です。 この分野のビット0は使用される圧縮(このプロフィールだけのMH)を指定します。 MHコード化はEOL(線の端)コードの使用を必要とします: ビット2は、EOLコードがバイトによって並べられるかどうかを示します。 詳細に関してセクション3.4を見てください。
3.2.3. New Fields
3.2.3. 新しい分野
None.
なし。
3.3. Recommended TIFF Fields
3.3. お勧めのいさかい分野
None.
なし。
3.4. End of Line (EOL) and Return to Control (RTC)
3.4. 行末(EOL)と制御するリターン(RTC)
TIFF extensions for fax, used in this specification, differ from Baseline TIFF in the following ways:
この仕様で使用されるファックスのためのTIFF拡張子は以下の方法でBaseline TIFFと異なっています:
- A 12-bit EOL sequence MUST precede each line of MH-compressed
image data. (Baseline TIFF does not use these EOL sequences.)
- The EOL sequence MAY be byte-aligned, in which case fill bits are
added so that the EOL sequence ends on a byte boundary, and any
subsequent image data begins on a byte boundary.
- If the EOL codes are not byte aligned, the image data MAY be
followed by an RTC (Return to Control) sequence, consisting of 6
consecutive EOLs.
- 12ビットのEOL系列はMH-圧縮画像データの各線に先行しなければなりません。 (基線TIFFはこれらのEOL系列を使用しません。) - EOL系列がバイトによって並べられるかもしれない、その場合、中詰めビットが加えられるので、EOL系列はバイト境界で終わります、そして、どんなその後のイメージデータもバイト境界で始まります。 - EOLコードが並べられたバイトでないなら、RTC(Controlに返す)系列はイメージデータのあとに続くかもしれません、6連続したEOLsから成って。
In conventional fax, an MH-compressed fax data stream for a page
consists of the following sequence:
EOL, compressed data (first line), EOL, compressed data, ... ,
EOL, compressed data (last line), RTC (6 consecutive EOL codes)
従来のファックスで、1ページのためのMHによって圧縮されたファックスデータ・ストリームは以下の系列から成ります: EOL(圧縮されたデータ(最初の線)、EOL)はデータを圧縮しました… , EOL、圧縮されたデータ(最終ライン)、RTC(6つの連続したEOLコード)
Baseline TIFF does not use EOL codes or Return to Control (RTC) sequences for MH-compressed data. However, the TIFF extension field T4Options used in this specification for MH compression (Compression = 3) requires EOLs.
基線TIFFはMHによって圧縮されたデータにControl(RTC)系列にEOLコードかReturnを使用しません。 しかしながら、MH圧縮(圧縮=3)にこの仕様で使用されるTIFF拡張子分野T4OptionsはEOLsを必要とします。
Buckley, et al. Standards Track [Page 23] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[23ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Furthermore, Bit 2 in the T4Options field indicates whether or not the EOL codes are byte aligned. If Bit 2 = 1, indicating the EOL codes are byte aligned, then fill bits have been added as necessary before EOL codes so that an EOL code always ends on a byte boundary, and the first bit of data following an EOL begins on a byte boundary. Without fill bits, an EOL code may end in the middle of a byte. Byte alignment relieves application software of the burden of bit-shifting every byte while parsing scanlines for line-oriented image manipulation (such as writing a TIFF file). Not all TIFF readers historically used for fax are able to deal with non byte aligned data.
その上、T4Options分野のBit2は、EOLコードがバイトであるかどうかが並んだのを示します。 次に、EOLコードが並べられたバイトであることを示して、Bit2 = 1がいっぱいになるならビットがEOLコードの前に必要に応じて加えられるので、EOLコードはバイト境界でいつも終わります、そして、EOLに続くデータの最初のビットはバイト境界で始まります。 中詰めビットがなければ、EOLコードは1バイトの中央に終わるかもしれません。 バイト整列はバイト毎に線指向の映像操作(TIFFファイルを書くことなどの)のために走査線を分析している間、ビット移行の負担をアプリケーション・ソフトに取り除きます。 ファックスに歴史的に使用されるというわけではないすべてのTIFF読者が非バイトの並べられたデータに対処できます。
While TIFF extension requires EOL codes, TIFF in fax applications has traditionally prohibited RTC sequences. Implementations that seek common processing and interfaces for fax data streams and Internet fax files would prefer that the TIFF data include RTC sequences.
TIFF拡張子はEOLコードを必要としますが、ファックスアプリケーションにおけるTIFFはRTC系列を伝統的に禁止しました。 ファックスデータ・ストリームとインターネットファックスファイルのために一般的な処理とインタフェースを求める実現は、TIFFデータがRTC系列を含んでいるのを好むでしょう。
To reconcile these differences, RTCs are allowed in cases where EOL codes are not byte aligned and no fill bits have been added to the data. This corresponds to situations where the fax data is simply inserted in a strip without being processed or interpreted. RTCs should not occur in the data when EOLs have been byte aligned. This is formally specified in the next subsection.
これらの違いを和解させるために、RTCはEOLコードが並べられたバイトでない場合で許容されています、そして、中詰めビットは全くデータに追加されていません。 これはファックスデータが単に処理されるか、または解釈されないで片に挿入される状況に対応しています。 EOLsが並べられたバイトであるときに、RTCはデータに起こるべきではありません。 これは次の小区分で正式に指定されます。
3.4.1. RTC Exclusion
3.4.1. RTC除外
Implementations that seek to maintain strict conformance with TIFF and compatibility with the historical use of TIFF for fax SHOULD NOT include the RTC sequence when writing TIFF files. However, implementations that need to support "transparency" of T.4-generated image data MAY include RTCs when writing TIFF files if the flag settings of the T4Options field are set for non byte aligned data, i.e., Bit 2 is 0. Implementors of TIFF readers should be aware that there are some existing TIFF implementations for fax that include the RTC sequence in MH image data. Therefore, minimal set readers MUST be able to process files that do not include RTCs and SHOULD be able to process files that do include RTCs.
TIFFにファイルを書くとき、ファックスSHOULD NOTのためにTIFFとの厳しい順応とTIFFの歴史的な使用との互換性を維持しようとする実現がRTC系列を含んでいます。 しかしながら、T4Options分野の旗の設定が非バイトの並べられたデータに設定されるならTIFFにファイルを書くとき、T.4が発生しているイメージデータの「透明」を支持する必要がある実現はRTCを含むかもしれません、すなわち、Bit2は0歳です。 TIFF読者の作成者はファックスのためのMHイメージデータにRTC系列を含んでいるいくつかの既存のTIFF実現があるのを意識しているべきです。 したがって、極小集合の読者はRTCとSHOULDを含んでいないファイルを処理できなければなりません。RTCを含んでいるファイルは処理できてください。
3.5. File Structure
3.5. ファイル構造
The TIFF header, described in Section 2.1.1, contains two bytes that describe the byte order used within the file. For the minimal black-and-white profile, these bytes SHALL have the value "II" (0x4949), denoting that the bytes in the TIFF file are in LSByte- first order (little-endian). The first or 0th IFD immediately follows the header, so offset to the first IFD is 8. The header values are shown in the following table:
セクション2.1.1で説明されたTIFFヘッダーはファイルの中で使用されたバイトオーダーについて説明する2バイトを含んでいます。 最小量の白黒のプロフィール、SHALLが持っているこれらのバイト、値いさかいファイルのバイトがLSByteにあるのを指示する「II」(0×4949)が最初に、(リトルエンディアン)を命令します。 1番目か第0IFDがすぐにヘッダーに続いて、そのように最初のIFDに相殺されているのは、8です。 ヘッダー値は以下のテーブルに示されます:
Buckley, et al. Standards Track [Page 24] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[24ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+--------+-------------------+--------+-----------+
| Offset | Description | Value |
+--------+-------------------+--------+-----------+
| 0 | Byte Order | 0x4949 (II) |
+--------+-------------------+--------+-----------+
| 2 | Identifier | 42 decimal |
+--------+-------------------+--------+-----------+
| 4 | Offset of 0th IFD | 0x 0000 0008 |
+--------+-------------------+--------+-----------+
+--------+-------------------+--------+-----------+ | 相殺されます。| 記述| 値| +--------+-------------------+--------+-----------+ | 0 | バイトオーダー| 0×4949 (II)| +--------+-------------------+--------+-----------+ | 2 | 識別子| 42小数| +--------+-------------------+--------+-----------+ | 4 | 第0IFDのオフセット| 0x0000 0008| +--------+-------------------+--------+-----------+
The minimal black-and-white profile SHALL order IFDs and image data within a file as follows: (1) There SHALL be an IFD for each page in a multi-page fax document; (2) the IFDs SHALL occur in the same order in the file as the pages occur in the document; (3) the IFD SHALL precede the image data to which it has offsets; (4) the image data SHALL occur in the same order in the file as the pages occur in the document; (5) the IFD, the value data, and the image data to which it has offsets SHALL precede the next image IFD; and (6) the image data for each page SHALL be contained within a single strip.
最小量の黒人と白は以下のファイルの中でSHALLオーダーIFDsとイメージデータの輪郭を描きます: (1) そこ、SHALL、マルチページファックスドキュメントの各ページIFDになってください。 (2) ページがドキュメントに起こるのに従って、IFDs SHALLはファイルの同次で起こります。 (3) IFD SHALLはそれがオフセットを持っているイメージデータに先行します。 (4) ページがドキュメントに起こるのに従って、イメージデータSHALLはファイルの同次で起こります。 (5) IFD、値のデータ、およびそれがオフセットSHALLを持っているイメージデータは次のイメージIFDに先行します。 (6) そして、含まれて、それぞれのためのイメージデータは1片の中にSHALLを呼び出します。
As a result of (6), the StripOffsets field will contain the pointer to the image data. With two exceptions, the field entries in the IFD contain the field values instead of offsets to field values located outside the IFD. The two exceptions are the values for the XResolution and YResolution fields, both of which are type RATIONAL and require 2 4-byte numbers. These "long" field values SHALL be placed immediately after the IFD which containing the offsets to them, and before the image data pointed to by that IFD.
(6)の結果、StripOffsets分野はイメージデータにポインタを含むでしょう。 2つの例外で、IFDのフィールド入力はIFDの外に位置する分野値にオフセットの代わりに分野値を含んでいます。 2つの例外が、XResolutionとYResolution分野への値であり、2の4バイトの番号を必要とします。その両方がタイプRATIONALです。 これらの「長い」分野はSHALLを評価します。それらと、イメージデータの前にオフセットを含んで、それでIFDを示したIFD直後、置かれてください。
The effect of these requirements is that the IFD for the first page SHALL come first in the file after the TIFF header, followed by the long field values for XResolution and YResolution, followed by the image data for the first page, then the IFD for second page, and so on. This is shown in the following figure. Each IFD is required to have a PageNumber field, which has value 0 for the first page, 1 for the second page, and so on.
これらの要件の効果はロング・フィールド値がXResolutionとYResolutionのためにあとに続いたTIFFヘッダーが次に、最初のページ単位でイメージデータ、第2ページなどのためのIFDで続いた後に最初のページSHALL IFDがファイルで一番になるということです。 これは以下の図に示されます。 各IFDが、PageNumber分野を持つのに必要です。(分野には、最初のページ単位で値0、第2ページ単位で1などがあります)。
Buckley, et al. Standards Track [Page 25] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[25ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+-----------------------+
| Header |------------+
+-----------------------+ | First IFD
| IFD (page 0) | <----------+ Offset
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 0) |<-+ Offset |
+-----------------------+ | Next IFD
| IFD (page 1) | <----------+ Offset
+---| |------------+
| | |--+ |
Value | +-----------------------+ | |
Offset +-->| Long Values | | |
+-----------------------| | Strip |
| Image Data (page 1) |<-+ Offset |
+-----------------------+ | Next IFD
| IFD (page 2) | <----------+ Offset
+-----------------------+
| : |
+-----------------------+ | ヘッダー|------------+ +-----------------------+ | 最初に、IFD| IFD(0ページ)| <、-、-、-、-、-、-、-、-、--+ オフセット+---| |------------+ | | |--+ | 値| +-----------------------+ | | オフセット+-->| 長い値| | | +-----------------------| | 片| | イメージデータ(0ページ)| <、-+ オフセット| +-----------------------+ | 次のIFD| IFD(1ページ)| <、-、-、-、-、-、-、-、-、--+ オフセット+---| |------------+ | | |--+ | 値| +-----------------------+ | | オフセット+-->| 長い値| | | +-----------------------| | 片| | イメージデータ(1ページ)| <、-+ オフセット| +-----------------------+ | 次のIFD| IFD(2ページ)| <、-、-、-、-、-、-、-、-、--+ オフセット+-----------------------+ | : |
Using this file structure may reduce the memory requirements in implementations. It also provides some support for streaming, in which a file can be processed as it is received and before the entire file is received.
このファイル構造を使用すると、実現におけるメモリ要件は減らされるかもしれません。 また、それはストリーミングの何らかのサポートを提供します。(そこでは、それが受け取られていて、ファイル全体が受信されている前にファイルを処理できます)。
3.6. Profile S: Minimal Black-and-White Profile Summary
3.6. プロフィールS: 最小量の白黒のプロフィール概要
The table below summarizes the TIFF fields that compose the minimal interchange set for black-and-white facsimile. The Baseline and Extension fields and field values MUST be supported by all implementations. For convenience, certain fields that have a value that is a sequence of flag bits are shown with integer values corresponding to the flags that are set. An implementation should test the setting of the relevant flag bits individually, however, to allow extensions to the sequence of flag bits to be appropriately ignored. (See, for example, T4Options below.)
以下のテーブルは白黒のファクシミリのために最小量の置き換えセットを構成するTIFF分野をまとめます。 すべての実現でBaseline、Extension分野、および分野値を支持しなければなりません。 便利において、フラグビットの系列である値を持っているある一定の分野が設定される旗に対応する整数値で示されます。 しかしながら、実現は、フラグビットの系列への拡大が適切に無視されるのを許容するために個別に関連フラグビットの設定をテストするべきです。 (例えば以下のT4Optionsを見てください。)
+---------------------------+--------------------------------+ | Baseline Fields | Values | +---------------------------+--------------------------------+ | BitsPerSample | 1 | +---------------------------+--------------------------------+ | Compression | 3: 1D Modified Huffman coding | | | set T4Options = 0 or 4 | +------------------------------------------------------------+
+---------------------------+--------------------------------+ | 基線分野| 値| +---------------------------+--------------------------------+ | BitsPerSample| 1 | +---------------------------+--------------------------------+ | 圧縮| 3: 1Dはハフマンコード化を変更しました。| | | T4Options=0か4を設定してください。| +------------------------------------------------------------+
Buckley, et al. Standards Track [Page 26] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[26ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+---------------------------+--------------------------------+ | FillOrder | 2: least significant bit first | +---------------------------+--------------------------------+ | ImageWidth | 1728 | +---------------------------+--------------------------------+ | ImageLength | n: total number of scanlines | | | in image | +---------------------------+--------------------------------+ | NewSubFileType | 2: Bit 1 identifies single | | | page of a multi-page document | +---------------------------+--------------------------------+ | PageNumber | n,m: page number n followed by | | | total page count m | +---------------------------+--------------------------------+ | PhotometricInterpretation | 0: pixel value 1 means black | +---------------------------+--------------------------------+ | ResolutionUnit | 2: inch | +---------------------------+--------------------------------+ | RowsPerStrip | number of scanlines per strip | | | = ImageLength, with one strip | +---------------------------+--------------------------------+ | SamplesPerPixel | 1 | +---------------------------+--------------------------------+ | StripByteCounts | number of bytes in TIFF strip | +---------------------------+--------------------------------+ | StripOffsets | offset from beginning of | | | file to single TIFF strip | +---------------------------+--------------------------------+ | XResolution | 204, 200 (pixels/inch) | +---------------------------+--------------------------------+ | YResolution | 98, 196, 100, 200 (pixels/inch)| +---------------------------+--------------------------------+ | Extension Fields | +---------------------------+--------------------------------+ | T4Options | 0: MH coding, EOLs not byte | | | aligned | | | 4: MH coding, EOLs byte aligned| +---------------------------+--------------------------------+
+---------------------------+--------------------------------+ | FillOrder| 2: 最下位ビット、最初に。| +---------------------------+--------------------------------+ | ImageWidth| 1728 | +---------------------------+--------------------------------+ | ImageLength| n: 総数の走査線| | | イメージで| +---------------------------+--------------------------------+ | NewSubFileType| 2: ビット1はシングルを特定します。| | | マルチページドキュメントのページ| +---------------------------+--------------------------------+ | PageNumber| n、m: nが続いたページ番号| | | 総ページ数m| +---------------------------+--------------------------------+ | PhotometricInterpretation| 0: ピクセル値1は黒いことを意味します。| +---------------------------+--------------------------------+ | ResolutionUnit| 2: インチ| +---------------------------+--------------------------------+ | RowsPerStrip| 1片あたりの走査線の数| | | = 1片があるImageLength| +---------------------------+--------------------------------+ | SamplesPerPixel| 1 | +---------------------------+--------------------------------+ | StripByteCounts| TIFF片の中のバイト数| +---------------------------+--------------------------------+ | StripOffsets| 始めから、相殺します。| | | ただ一つのTIFF片にファイルしてください。| +---------------------------+--------------------------------+ | XResolution| 204、200(画素/インチ)| +---------------------------+--------------------------------+ | YResolution| 98、196、100、200(画素/インチ)| +---------------------------+--------------------------------+ | 拡大分野| +---------------------------+--------------------------------+ | T4Options| 0: バイトではなく、MHコード化、EOLs| | | 並べられます。| | | 4: MHコード化、バイトが並べたEOLs| +---------------------------+--------------------------------+
4. Profile F: Extended Black-and-White fax profile
4. プロフィールF: 拡張Blackとホワイトファックスプロフィール
This section defines the extended black-and-white profile or Profile F of TIFF for facsimile. It provides a standard definition of what has historically been known as TIFF Class F and now as TIFF-F. In doing so, it aligns this profile with current ITU-T Recommendations for black-and-white fax and with existing industry practice. Implementations of this profile include implementations of Profile S.
このセクションはファクシミリのためにTIFFの拡張白黒のプロフィールかProfile Fを定義します。 それはTIFF Class Fとして現在、TIFF-Fとして歴史的に知られていることに関する標準定義を提供します。 そうする際に、それは白黒のファックスと既存の産業習慣で現在のITU-T Recommendationsにこのプロフィールを一直線にします。 このプロフィールの実現はProfile Sの実現を含んでいます。
Buckley, et al. Standards Track [Page 27] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[27ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
This section describes extensions to the minimal interchange set of fields (Profile S) that provide a richer set of black-and-white capabilities. The fields and values described in this section are a superset of the fields and values defined for the minimal interchange set in Section 3. In addition to the MH compression, Modified READ (MR) and Modified Modified READ (MMR) compression, as described in [T.4] and [T.6] are supported.
このセクションは、より豊かな白黒の能力を提供する最小量の置き換えセットの分野(プロフィールS)に拡大について説明します。 このセクションで説明された分野と値は分野のスーパーセットです、そして、最小量の置き換えのために定義された値はセクション3にセットしました。 MH圧縮、Modified READ(MR)、およびModified Modified READ(MMR)圧縮に加えて、中で説明されるように、[T.4]と[T.6]は支持されます。
Section 4.1 gives an overview of TIFF-F. Section 4.2 describes the TIFF fields that SHALL be used in this profile. Section 4.3 describes the fields that MAY be used in this profile. In the spirit of the original TIFF-F specification, Sections 4.4 and 4.5 discuss technical implementation issues and warnings. Section 4.6 gives an example of TIFF-F use. Section 4.7 gives a summary of the required and recommended fields and their values.
セクション4.1はTIFF-Fの概観を与えます。 セクション4.2はこのプロフィールで使用されていた状態でSHALLがあるTIFF分野について説明します。 セクション4.3はこのプロフィールで使用されるかもしれない分野について説明します。 当初のTIFF-F仕様の精神では、セクション4.4と4.5は技術的な導入問題と警告について議論します。 セクション4.6はTIFF-F使用に関する例を出します。 セクション4.7は必要でお勧めの分野とそれらの値の概要をします。
4.1. TIFF-F Overview
4.1. いさかいF概観
Though it has been in common use for many years, TIFF-F has previously never been documented in the form of a standard. An informal TIFF-F document was originally created by a small group of fax experts led by Joe Campbell. The existence of TIFF-F is noted in [TIFF], but it is not defined. This document serves as the formal definition of the F application of [TIFF] for Internet applications. For ease of reference, the term TIFF-F will be used throughout this document as a shorthand for the extended black-and-white profile of TIFF for facsimile.
それは何年間も共用ですが、TIFF-Fは以前に、規格の形に一度も記録されたことがありません。 非公式のTIFF-Fドキュメントは元々、ジョー・キャンベルによって導かれたファックスの専門家の小さいグループによって作成されました。 TIFF-Fの存在は[TIFF]に述べられますが、それは定義されません。 このドキュメントはインターネットアプリケーションのための[TIFF]のFアプリケーションの公式の定義として機能します。 参照する場合に便利なようにTIFF-FがファクシミリのためのTIFFの拡張白黒のプロフィールに速記としてこのドキュメント中で使用される用語。
Up until the TIFF 6.0 specification, TIFF supported various "Classes" that defined the use of TIFF for various applications. Classes were used to support specific applications. In this spirit, TIFF-F has been known historically as "TIFF Class F". Previous informal TIFF-F documents [TIFF-F0] used the "Class F" terminology. As of TIFF 6.0 [TIFF], the TIFF Class concept has been eliminated in favor of the concept of Baseline TIFF. Therefore, this document updates the definition of TIFF-F as the F profile of TIFF for facsimile, by using Baseline TIFF as defined in [TIFF] as the starting point and then adding the TIFF extensions to Baseline TIFF that apply for TIFF-F. In almost all cases, the resulting definition of TIFF-F fields and values remains consistent with those used historically in earlier definitions of TIFF Class F. Where some of the values for fields have been updated to provide more precise conformance with the ITU-T [T.4] and [T.30] fax recommendations, these differences are noted.
TIFF6.0仕様まで、TIFFはTIFFの様々なアプリケーションの使用を定義した様々な「クラス」を支持しました。 クラスは、特定のアプリケーションを支持するのに使用されました。 この精神では、TIFF-Fは「いさかいのクラスF」として歴史的に知られています。 前の非公式のTIFF-Fドキュメント[TIFF-F0]は「クラスF」用語を使用しました。 TIFF6.0[TIFF]現在、TIFF Class概念はBaseline TIFFの概念を支持して排除されました。 したがって、このドキュメントはファクシミリのためにTIFFのFプロフィールとしてTIFF-Fの定義をアップデートします、[TIFF]で出発点と定義されて、次に、TIFF-Fに申し込むBaseline TIFFにTIFF拡張子を加えるとしてBaseline TIFFを使用することによって。 ほとんどすべてのケース、TIFF-F分野とそれらと一致した残りがTIFF Class F.Whereの以前の定義に歴史的に使用した値の結果として起こる定義では、ITU-T[T.4]と[T.30]ファックス推薦をより正確な順応に提供するために分野への値のいくつかをアップデートして、これらの違いに注意します。
Buckley, et al. Standards Track [Page 28] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[28ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
4.2. Required TIFF Fields
4.2. 必要ないさかい分野
This section lists the required fields and the values they must have to be ITU-compatible. Besides the fields listed in Section 2.2.1, the extended black-and-white fax profile SHALL use the following fields.
このセクションはそれらがITU互換性があるように持たなければならない必須項目と値を記載します。 セクション2.2.1で記載された分野以外に、拡張白黒のファックスプロフィールSHALLは以下の分野を使用します。
4.2.1. Baseline fields
4.2.1. 基線分野
BitsPerSample(258) = 1.
SHORT
RequiredByTIFFBaseline
Binary data only.
Default = 1 (field may be omitted if this is the value)
BitsPerSample(258)=1。 SHORT RequiredByTIFFBaseline Binaryデータ専用。 デフォルト=1(分野はこれが値であるなら省略されるかもしれません)
Compression(259) = 3, 4.
SHORT
RequiredByTIFFBaseline
3 = 1- or 2- dimensional coding, must have T4Options field This is
a TIFF Extension value [TIFF].
4 = 2-dimensional coding, ITU-T Rec. T.6 (MMR - Modified Modified
READ, must have T6Options field)) This is a TIFF Extension value.
Default = 1 (and is not applicable; field must be specified)
圧縮(259)=3、4。 SHORT RequiredByTIFFBaseline3 = 1か2の次元コード化、必須はそうしました。T4Options分野ThisはTIFF Extension値[TIFF]です。 4 = 2次元のコード化、ITU-T Rec。 T.6(MMR--Modified READを変更して、T6Options分野を持たなければなりません) これはTIFF Extension値です。 デフォルト=1(適切でない、;、分野を指定しなければならない )
NOTE: Baseline TIFF permits use of value 2 for Modified Huffman compression, but data is presented in a form that does not use EOLs, and so TIFF for facsimile uses Compression=3 instead. See Sections 4.4.4, 4.5.1, and 4.5.2 for more information on compression and encoding.
以下に注意してください。 基線TIFFが値2のModifiedハフマン圧縮の使用を可能にしますが、データがEOLsを使用しないフォームに提示されるので、ファクシミリのためのTIFFは代わりにCompression=3を使用します。 そして、見る、セクション4.4 .4 4.5 .1、4.5 .2 圧縮とコード化に関する詳しい情報のために。
FillOrder(266) = 1 , 2.
SHORT
RequiredByTIFFBaseline
Profile F readers must be able to read data in both bit orders,
but the vast majority of facsimile products store data LSB first,
exactly as it appears on the telephone line.
1 = Most Significant Bit first.
2 = Least Significant Bit first.
FillOrder(266)=1、2。 SHORT RequiredByTIFFBaseline Profile F読者は両方の噛み付いている命令でデータを読むことができなければなりませんが、かなりの大多数のファクシミリ製品は最初にデータLSBを格納します、ちょうど電話回線の上に現れるように。 1は最初に、ほとんどのSignificant Bitと等しいです。 2は最初に、最少のSignificant Bitと等しいです。
ImageWidth(256)
SHORT or LONG
RequiredByTIFFBaseline
This profile supports the following fixed page widths: 1728, 2592,
3456 (corresponding to North American Letter and Legal and ISO A4
paper sizes), 2048, 3072, 4096 (corresponding to ISO B4 paper
size), and 2432, 3648, 4864 (corresponding to ISO A3 paper size).
No default; must be specified.
ImageWidth(256) SHORTかLONG RequiredByTIFFBaseline Thisプロフィールが以下の固定ページ幅を支持します: 1728、2592、3456(北米のLetter、Legal、およびISO A4紙サイズに対応する)、2048 3072 4096 (ISO B4紙サイズに対応します)、2432、3648、4864(ISO A3紙サイズに対応する)。 デフォルトがありません。 指定しなければならなくなってください。
Buckley, et al. Standards Track [Page 29] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[29ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
NOTE: Historical TIFF-F did not include support for the following widths related to higher resolutions: 2592, 3072, 3648, 3456, 4096, and 4864. Historical TIFF-F documents also included the following values related to A5 and A6 widths: 816 and 1216. Per the most recent version of [T.4], A5 and A6 documents are no longer supported in Group 3 facsimile, so the related width values are now obsolete. See section 4.5.2 for more information on inch/metric equivalencies and other implementation details.
以下に注意してください。 歴史的なTIFF-Fは、より高い解像度に関連する以下の幅のサポートを含んでいませんでした: 2592、3072、3648、3456、4096、および4864。 また、歴史的なTIFF-FドキュメントはA5に関連する以下の値とA6幅を含んでいました: 816と1216。 A5とA6ドキュメントが[T.4]の最新のバージョンに従ってもうGroup3ファクシミリで支えられないので、関連する幅の値は現在、時代遅れです。 インチ/のメートル法のequivalenciesと他の実現の詳細の詳しい情報に関してセクション4.5.2を見てください。
NewSubFileType(254) = (Bit 1=1).
LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax).
NewSubFileType(254)は(ビット1=1)と等しいです。 イメージがマルチページドキュメントの1ページであるなら、LONG RequiredByTIFFforFAX Bit1は1歳です。 デフォルト=0、(いいえがビットを副ファイルするので省略されないかもしれない、ファックス)
NOTE: Bit 1 is always set to 1 for TIFF-F, indicating a single page of a multi-page image. The same bit settings are used when TIFF-F is used for a one-page fax image. See Section 4.4.3 for details on multi-page files.
以下に注意してください。 マルチページイメージの1ページを示して、ビット1はTIFF-Fのためにいつも1に設定されます。 TIFF-Fが1ページのファックスイメージに使用されるとき、同じ噛み付いている設定は使用されています。 マルチページファイルに関する詳細に関してセクション4.4.3を見てください。
PhotometricInterpretation(262) = 0, 1.
SHORT
RequiredByTIFFBaseline
0 = pixel value 1 means black, 1 = pixel value 1 means white.
This field allows notation of an inverted or negative image.
No default, must be specified.
PhotometricInterpretation(262)=0、1。 1つの=ピクセル値1手段は、SHORT RequiredByTIFFBaseline0=ピクセル値1が黒いことを意味するのを空白にします。 この分野は逆さの、または、否定的なイメージの記法を許容します。 どんなデフォルトも指定されているはずがありません。
ResolutionUnit(296) = 2, 3.
SHORT
RequiredByTIFFBaseline
The unit of measure for resolution. 2 = inch, 3 = centimeter; =
TIFF-F has traditionally used inch-based measurement.
Default = 2 (field may be omitted if this is the value).
ResolutionUnit(296)=2、3。 SHORT RequiredByTIFFBaseline、解決のための測定の単位。 2 = 少しずつ動いてください、そして、3はセンチメートルと等しいです。 = TIFF-Fはインチベースの測定を伝統的に使用しました。 デフォルト=2(分野はこれが値であるなら省略されるかもしれません)。
SamplesPerPixel(277) = 1.
SHORT
RequiredByTIFFBaseline
1 = monochrome, bi-level in this case (see BitsPerSample).
Default = 1 (field may be omitted if this is the value).
SamplesPerPixel(277)=1。 SHORT RequiredByTIFFBaseline1はこの場合白黒、両性愛者のレベルと等しいです(BitsPerSampleを見てください)。 デフォルト=1(分野はこれが値であるなら省略されるかもしれません)。
XResolution(282) = 200, 204, 300, 400, 408
RATIONAL
RequiredByTIFFBaseline
The horizontal resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are 200, 204,
300, 400, and 408. See Section 2.2.2 for inch metric equivalency.
No default, must be specified.
XResolution(282)は200、204、300、400と等しいです、408RATIONAL RequiredByTIFFBaseline。イメージの水平な解像度は解決ユニットあたりの画素で言い表されます。 画素/インチでは、許容値は、200と、204と、300と、400と、408です。 インチのメートル法の同等に関してセクション2.2.2を見てください。 どんなデフォルトも指定されているはずがありません。
Buckley, et al. Standards Track [Page 30] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[30ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
NOTE: The values of 200 and 408 have been added to the historical TIFF-F values, for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 80 pixels/cm, which is equivalent to 204 pixels per inch. See section 4.5.2 for information on implementation details.
以下に注意してください。 200と408の値は一貫性のために[T.30]と共に歴史的なTIFF-F値に加えられます。 また、いくつかの既存のTIFF-F実現が同等な80画素/cmから204ピクセル・パー・インチの値を支持するかもしれません。 実現の詳細の情報に関してセクション4.5.2を見てください。
YResolution(283) = 98, 100, 196, 200, 300, 391, and 400
RATIONAL
RequiredByTIFFBaseline
The vertical resolution of the image is expressed in pixels per
resolution unit. In pixels/inch, the allowed values are 98, 100,
196, 200, 300, 391, and 400 pixels/inch. See Section 2.2.2 for
inch metric equivalency.
No default, must be specified
YResolution(283)は98、100、196、200、300、391、および400RATIONAL RequiredByTIFFBaselineと等しいです。イメージの垂直解像度は解決ユニットあたりの画素で言い表されます。 画素/インチでは、許容値は98、100、196、200、300、391、および400画素/インチです。 インチのメートル法の同等に関してセクション2.2.2を見てください。 どんなデフォルトも指定されているはずがありません。
NOTE: The values of 100, 200, and 391 have been added to the historical TIFF-F values, for consistency with [T.30]. Some existing TIFF-F implementations may also support values of 77 and 38.5 (cm), which are equivalent to 196 and 98 pixels per inch, respectively. See section 4.5.2 for more information on implementation details.
以下に注意してください。 100の値であり、200、および391は一貫性のために[T.30]と共に歴史的なTIFF-F値に加えられます。 また、いくつかの既存のTIFF-F実現がそれぞれ77と38.5(cm)の値を支持するかもしれません。(38.5は196と98ピクセル・パー・インチに同等です)。 実現の詳細の詳しい情報に関してセクション4.5.2を見てください。
NOTE: Not all combinations of XResolution, YResolution, and ImageWidth are legal. The following table gives the legal combinations and corresponding paper sizes [T.30].
以下に注意してください。 XResolution、YResolution、およびImageWidthのすべての組み合わせがどんな法的であるというわけではありません。 以下のテーブルは法的な組み合わせと対応する紙サイズ[T.30]を与えます。
+--------------+-----------------+---------------------------+
| XResolution x YResolution | ImageWidth |
+--------------+-----------------+---------+--------+--------+
| 200x100, 204x98 | | | |
| 200x200, 204x196 | 1728 | 2048 | 2432 |
| 204x391 | | | |
+--------------+-----------------+---------+--------+--------+
| 300 x 300 | 2592 | 3072 | 3648 |
+--------------+-----------------+---------+--------+--------+
| 408 x 391, 400 x 400 | 3456 | 4096 | 4864 |
+--------------+-----------------+---------+--------+--------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------+--------+--------+
| Paper Size |
+---------------------------+
+--------------+-----------------+---------------------------+ | XResolution x YResolution| ImageWidth| +--------------+-----------------+---------+--------+--------+ | 200×100、204×98| | | | | 200×200、204×196| 1728 | 2048 | 2432 | | 204×391| | | | +--------------+-----------------+---------+--------+--------+ | 300x300| 2592 | 3072 | 3648 | +--------------+-----------------+---------+--------+--------+ | 408x391、400x400| 3456 | 4096 | 4864 | +--------------+-----------------+---------+--------+--------+ |手紙、A4| B4| A3| | 法的| | | +---------+--------+--------+ | 紙サイズ| +---------------------------+
Buckley, et al. Standards Track [Page 31] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[31ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
4.2.2. Extension fields
4.2.2. 拡大分野
T4Options(292) = (Bit 0 = 0 or 1, Bit 1 = 0, Bit 2 = 0 or 1)
LONG
RequiredTIFFExtension (when Compression = 3)
T4Options was also known as Group3Options in a prior version of
[TIFF].
Bit 0 = 1 indicates MR compression, = 0 indicates MH compression.
Bit 1 must be 0.
Bit 2 = 1 indicates that EOLs are byte aligned, = 0 EOLs not byte
aligned.
Default is all bits are 0 (applies when MH compression is used and
EOLs are not byte aligned) (See Section 3.2.2.) The T4Options
field is required when the Compression field has a value of 3.
This field specifies the compression used (MH or MR) and whether
the EOL codes are byte aligned or not. If they are byte aligned,
then fill bits have been added as necessary so that the End of
Line (EOL) codes always end on byte boundaries. See Sections 3.4,
4.5.3, and 4.5.4 for details.
また、T4Options(292)=(ビット0 = 0か1、Bit1 = 0、Bit2 = 0か1)LONG RequiredTIFFExtension(Compression=3であるときに)T4OptionsはGroup3Optionsとして[TIFF]の先のバージョンで知られていました。 ビット0 = 1はMR圧縮を示して、=0はMH圧縮を示します。 ビット1は0であるに違いありません。 = ビット2 = 1は、EOLsが並べられたバイトであることを示して、バイトではなく、0EOLsが並びました。 デフォルトはすべてのビットが0(MH圧縮が使用されていて、EOLsが並べられたバイトでないときに、適用します)(.2にセクション3.2を見る)であるということです。 Compression分野に3の値があると、T4Options分野が必要です。 この分野は使用されて(MHかMR)、EOLコードが並べられたバイトであるか否かに関係なく、圧縮を指定します。 中詰めビットがそれらが並べられたバイトであるなら必要に応じて加えられるので、線(EOL)コードのEndはバイト境界でいつも終わります。 セクション3.4、4.5.3、および4.5を見てください。.4 詳細のために。
T6Options(293) = (Bit 0 = 0, Bit 1 = 0).
LONG
RequiredTIFFExtension (when Compression = 4)
Used to indicate parameterization of 2D Modified Modified READ
(MMR) compression. T6Options was also known as Group4Options in a
prior version of [TIFF]. Bit 0 must be 0.
Bit 1 = 0 indicates uncompressed data mode is not allowed; = 1
indicates that uncompressed data is allowed (see [TIFF]). Default
is all bits 0. For FAX, the field must be present and have the
value 0. The use of uncompressed data where compression would
expand the data size is not allowed for FAX.
T6Options(293)=(ビット0 = 0、ビット1 = 0)。 LONG RequiredTIFFExtension(Compression=4であるときに)は以前はよく2D Modified Modified READ(MMR)圧縮のパラメタリゼーションを示していました。 また、T6OptionsはGroup4Optionsとして[TIFF]の先のバージョンで知られていました。 ビット0は0であるに違いありません。 ビット1 = 0は、解凍されたデータモードが許容されていないのを示します。 = 1は、解凍されたデータが許容されているのを示します([TIFF]を見てください)。 デフォルトはすべてビット0です。 FAXに関しては、分野は、存在していて、値0を持たなければなりません。 圧縮がデータサイズを広くする解凍されたデータの使用はFAXのために許されていません。
NOTE: MMR compressed data is two-dimensional and does not use EOLs. Each MMR encoded image MUST include an "end-of-facsimile-block" (EOFB) code at the end of each coded strip; see Section 4.5.6.
以下に注意してください。 MMRはデータを圧縮しました。二次元であり、EOLsを使用しません。 各MMR、コード化されたイメージはそれぞれのコード化された片の端ときに「ファクシミリブロックの端」(EOFB)コードを含まなければなりません。 セクション4.5.6を見てください。
4.2.3. New fields
4.2.3. 新しい分野
None.
なし。
4.3. Recommended TIFF fields
4.3. お勧めのTIFF分野
4.3.1. Baseline fields
4.3.1. 基線分野
See Section 2.2.3.
セクション2.2.3を見てください。
Buckley, et al. Standards Track [Page 32] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[32ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
4.3.2. Extension fields
4.3.2. 拡大分野
See Section 2.2.3.
セクション2.2.3を見てください。
4.3.3. New fields
4.3.3. 新しい分野
See Section 2.2.4 and optional fields below.
セクション2.2.4と下の任意の分野を見てください。
Three new, optional fields, used in the original TIFF-F description to describe page quality, are defined in this specification. The information contained in these fields is usually obtained from receiving facsimile hardware (if applicable). They SHOULD NOT be used in writing TIFF-F files for facsimile image data that is error corrected or otherwise guaranteed not to have coding errors. Some applications need to understand exactly the error content of the data. For example, a CAD program might wish to verify that a file has a low error level before importing it into a high-accuracy document. Because Group 3 facsimile devices do not necessarily perform error correction on the image data, the quality of a received page must be inferred from the pixel count of decoded scanlines. A "good" scan line is defined as a line that, when decoded, contains the correct number of pixels. Conversely, a "bad" scanline is defined as a line that, when decoded, contains an incorrect number of pixels.
ページ品質について説明するのにオリジナルのTIFF-F記述に使用される3つの新しくて、任意の分野がこの仕様に基づき定義されます。 これらの分野に保管されていた情報は、通常、ファクシミリハードウェアを受け止めるのから得て(適切。)です。 SHOULD NOTは、修正された誤りであるファクシミリイメージデータにTIFF-Fファイルを書く際に使用されたか、または別の方法で使用されないのを保証しました。それら、誤りをコード化して。 いくつかのアプリケーションが、まさにデータの誤り内容を理解する必要があります。 例えば、CADプログラムは、高精度ドキュメントにそれをインポートする前に、ファイルには低誤りレベルがあることを確かめたがっているかもしれません。 Group3ファクシミリデバイスが必ずイメージデータにエラー修正を実行するというわけではないので、解読された走査線の画素数から容認されたページの品質を推論しなければなりません。 「良い」スキャン系列は解読されると画素の適度の数を含む系列と定義されます。 逆に、「悪い」走査線は解読されると不正確な数の画素を含む系列と定義されます。
BadFaxLines(326)
SHORT or LONG
The number of "bad" scanlines encountered by the facsimile device
during reception. A "bad" scanline is defined as a scanline that,
when decoded, comprises an incorrect number of pixels. Note that
PercentBad = (BadFaxLines/ImageLength) * 100.
No default.
BadFaxLines(326) SHORTかレセプションの間にファクシミリデバイスで遭遇するLONG数の「悪さ」の走査線。 「悪い」走査線は解読されると不正確な数の画素を包括する走査線と定義されます。 PercentBadが(BadFaxLines/ImageLength)*100と等しいことに注意してください。 デフォルトがありません。
CleanFaxData(327) = 0, 1, 2.
SHORT
Indicates whether "bad" lines encountered during reception are
stored in the data, or whether "bad" lines have been replaced by
the receiver.
0 = No "bad" lines
1 = "bad" lines exist but were regenerated by the receiver,
2 = "bad" lines exist but have not been regenerated.
No default.
CleanFaxData(327)=0、1、2。 データか、「悪い」系列を受信機に取り替えたことにかかわらずレセプションの間に遭遇する「悪い」系列は保存されます。「悪い」「悪い」0=系列がない1=系列が存在しましたが、作り直されたか否かに関係なく、SHORT Indicatesは「悪い」受信機、2=系列で存在しますが、作り直されていません。 デフォルトがありません。
NOTE: Many facsimile devices do not actually output bad lines. Instead, the previous good line is repeated in place of a bad line. Although this substitution, known as line regeneration, results in a visual improvement to the image, the data is nevertheless corrupted. The CleanFaxData field describes the error content of the data. That
以下に注意してください。 多くのファクシミリデバイスは実際に悪い系列を出力しません。 代わりに、前の良い系列は悪い系列に代わって繰り返されます。 系列再生として知られているこの代替はイメージへの視覚改良をもたらしますが、それにもかかわらず、データは崩壊します。 CleanFaxData分野はデータの誤り内容について説明します。 それ
Buckley, et al. Standards Track [Page 33] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[33ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
is, when the BadFaxLines and ImageLength fields indicate that the facsimile device encountered lines with an incorrect number of pixels during reception, the CleanFaxData field indicates whether these bad lines are actually still in the data or whether the receiving facsimile device replaced them with regenerated lines.
BadFaxLinesとImageLength分野が、ファクシミリデバイスがレセプションの間不正確な数の画素で系列に遭遇したのを示すときのこれらの悪い系列がまだ実際にデータにあったか、または受信ファクシミリデバイスがそれらを作り直された系列に取り替えたことにかかわらず分野が示すCleanFaxDataはそうですか?
ConsecutiveBadFaxLines(328)
LONG or SHORT
Maximum number of consecutive "bad" scanlines received. The
BadFaxLines field indicates only the quantity of bad lines.
No Default.
受け取られた連続した「悪い」走査線のConsecutiveBadFaxLines(328) LONGかSHORT Maximum番号。 BadFaxLines分野は悪い系列の量だけを示します。 デフォルトがありません。
NOTE: The BadFaxLines and ImageLength data indicate only the quantity of bad lines. The ConsecutiveBadFaxLines field is an indicator of the distribution of bad lines and may therefore be a better general indicator of perceived image quality. See Section 4.4.5 for examples of the use of these fields.
以下に注意してください。 BadFaxLinesとImageLengthデータは悪い系列の量だけを示します。 ConsecutiveBadFaxLines分野は、悪い系列の分配のインディケータであり、したがって、知覚された画質の、より良い一般的なインディケータであるかもしれません。 これらの分野の使用の例に関してセクション4.4.5を見てください。
4.4. Technical Implementation Issues
4.4. 技術的実装問題
4.4.1. Strips
4.4.1. 片
In general, TIFF files divide an image into "strips", also known as "bands". Each strip contains a few scanlines of the image. By using strips, a TIFF reader need not load the entire image into memory, enabling it to fetch and decompress small random portions of the image as necessary.
一般に、TIFFファイルはイメージをまた、「バンド」として知られている「片」に分割します。 各片はイメージのいくつかの走査線を含んでいます。 片を使用することによって、TIFF読者は全体のイメージをメモリにロードする必要はありません、必要に応じてイメージの小さい無作為の部分をとって来て、減圧するのを可能にして。
The number of scanlines in a strip is described by the RowsPerStrip value and the number of bytes in the strip after compression by the StripByteCount value. The location in the TIFF file of each strip is given by the StripOffsets values.
片の中の走査線の数はStripByteCount値による圧縮の後に片の中のRowsPerStrip値とバイト数によって説明されます。 StripOffsets値でそれぞれの片のTIFFファイルの位置を与えます。
Strip size is application dependent. The recommended approach for multi-page TIFF-F images is to represent each page as a single strip. Existing TIFF-F usage is typically one strip per page in multi-page TIFF-F files. See Sections 2.1.2 and 2.1.3.
片サイズはアプリケーションに依存しています。 マルチページTIFF-Fイメージのためのお勧めのアプローチは各ページ単位で1片を表すことです。 通常、マルチページTIFF-Fファイルのページあたり既存のTIFF-F用法は1片です。 .3にセクション2.1 .2と2.1を見てください。
4.4.2. Bit Order
4.4.2. 噛み付いているオーダー
The current TIFF specification [TIFF] does not require a Baseline TIFF reader to support FillOrder=2, i.e., lowest numbered 1-bit pixel in the least significant bit of a byte. It further recommends that FillOrder=2 be used only in special purpose applications.
現在のTIFF仕様[TIFF]は、Baseline TIFF読者がFillOrder=2(すなわち、1バイトの最下位ビットで最も低い番号付の1ビットの画素)をサポートするのを必要としません。 それは、FillOrder=2が専用アプリケーションだけで使用されることをさらに勧めます。
Buckley, et al. Standards Track [Page 34] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[34ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Facsimile data appears on the phone line in bit-reversed order relative to its description in ITU-T Recommendation T.4. Therefore, most facsimile applications choose this natural order for data in a file. Nevertheless, TIFF-F readers must be able to read data in both bit orders and support FillOrder values of 1 and 2.
ファクシミリデータはビットで逆にされたオーダーにおける電話回線の上にITU-T Recommendation T.4の記述に比例して現れます。 したがって、ほとんどのファクシミリアプリケーションがファイルのデータのためのこの自然界の秩序を選びます。 それにもかかわらず、TIFF-F読者は噛み付いている注文と1と2のサポートFillOrder値の両方でデータを読むことができなければなりません。
4.4.3. Multi-Page
4.4.3. マルチページ
Many existing applications already read TIFF-F-like files but do not support the multi-page field. Since a multi-page format greatly simplifies file management in fax application software, TIFF-F specifies multi-page documents (NewSubfileType = 2) as the standard case.
多くの既存のアプリケーションは、既にTIFF Fのようなファイルを読みますが、マルチページ分野をサポートしません。 マルチページ形式がファックスアプリケーション・ソフトでファイル管理を大いに簡素化するので、TIFF-Fは一般的なケースとしてマルチページドキュメント(NewSubfileType=2)を指定します。
It is recommended that applications export multiple-page TIFF-F files without manipulating fields and values. Historically, some TIFF-F writers have attempted to produce individual single-page TIFF-F files with modified NewSubFileType and PageNumber (page one-of-one) values for export purposes. However, there is no easy way to link such multiple single-page files together into a logical multiple-page document, so this practice is not recommended.
アプリケーションが、分野と値を操らないで複数のページTIFF-Fがファイルであるとエクスポートするのは、お勧めです。 歴史的に、何人かのTIFF-F作家が、輸出目的のために変更されたNewSubFileTypeとPageNumber(1の1つを呼び出す)値で個々の1ページTIFF-Fファイルを作り出すのを試みました。 しかしながら、そのような複数の1ページファイルを論理的な複数のページドキュメントに結びつけるどんな簡単な方法もないので、この習慣は推薦されません。
4.4.4. Compression
4.4.4. 圧縮
In Group 3 facsimile, there are three compression methods which had been standardized as of 1994 and are in common use. The ITU-T T.4 Recommendation [T.4] defines a one-dimensional compression method known as Modified Huffman (MH) and a two-dimensional method known as Modified READ (MR) (READ is short for Relative Element Address Designate). In 1984, a somewhat more efficient compression method known as Modified Modified READ (MMR) was defined in the ITU-T T.6 Recommendation [T.6]. MMR was originally defined for use with Group 4 facsimile, so that this compression method has been commonly called Group 4 compression. In 1991, the MMR method was approved for use in Group 3 facsimile and has since been widely utilized.
Group3ファクシミリには、3つの1994年の時点で、標準化された、共用の圧縮方法があります。 ITU-T T.4 Recommendation[T.4]はModifiedハフマンとして知られている一次元圧縮方法(MH)とModified READとして知られている二次元メソッド(さん)を定義します(Relative Element Address Designateに、READは短いです)。 1984年に、Modified Modified READ(MMR)として知られているいくらか効率的な圧縮方法はITU-T T.6 Recommendation[T.6]で定義されました。 MMRは元々使用のためにGroup4ファクシミリで定義されました、この圧縮方法が一般的にGroup4圧縮と呼ばれたように。 1991年に、MMRメソッドは、Group3ファクシミリにおける使用のために承認されて、以来、広く利用されています。
TIFF-F supports these three compression methods. The most commonly used is the one-dimensional Modified Huffman (MH) compression method. This is specified by setting the Compression field value to 3 and then setting bit 0 of the T4Options field to 0. Alternatively, the two dimensional Modified READ (MR) method, which is much less frequently used in historical TIFF-F implementations, may be selected by setting bit 0 of the T4Options field to 1. The value of Bit 2 in this field is determined by the use of fill bits.
TIFF-Fはこれらの3つの圧縮方法をサポートします。 最も一般的に使用されているのは、一次元Modifiedハフマン(MH)圧縮方法です。 これは、Compression分野価値を3に設定して、次に、T4Options分野のビット0を0に設定することによって、指定されます。 あるいはまた、二次元Modified READ(MR)メソッド(まして歴史的なTIFF-F実装に頻繁に使用される)は、T4Options分野のビット0を1に設定することによって、選択されるかもしれません。 この分野のBit2の値は中詰めビットの使用目的で決定します。
Depending upon the application, the more efficient two-dimensional Modified Modified READ (MMR)compression method from T.6 may be selected by setting the Compression field value to 4 and then setting
アプリケーションによって、T.6からの、より効率的な二次元Modified Modified READ(MMR)圧縮方法は、Compression分野価値を設定することによって、4と次に、設定に選択されるかもしれません。
Buckley, et al. Standards Track [Page 35] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[35ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
the first two bits (and all unused bits) of the T6Options field to 0. More information to aid the implementor in making a compression selection is contained in Section 4.5.2.
0へのT6Options分野の最初の2ビット(すべての未使用のビット)。 圧縮選択をする際に作成者を支援する詳しい情報はセクション4.5.2に含まれています。
Baseline TIFF also permits use of Compression=2 to specify Modified Huffman compression, but the data does not use EOLs. As a result, TIFF-F uses Compression=3 instead of Compression=2 to specify Modified Huffman compression.
また、基線TIFFは、Compression=2の使用がModifiedハフマン圧縮を指定するのを可能にしますが、データはEOLsを使用しません。 その結果、TIFF-Fは、Modifiedハフマン圧縮を指定するのにCompression=2の代わりにCompression=3を使用します。
4.4.5. Example Use of Page-quality Fields
4.4.5. ページ品質分野の例の使用
Here are examples for writing the CleanFaxData, BadFaxLines, and ConsecutiveBadFaxLines fields:
ここに、CleanFaxData、BadFaxLines、およびConsecutiveBadFaxLinesに分野を書くための例があります:
1. Facsimile hardware does not provide page-quality information: MUST
NOT write page-quality fields.
1. ファクシミリハードウェアはページ品質情報を提供しません: ページ品質分野を書いてはいけません。
2. Facsimile hardware provides page-quality information, but reports
no bad lines. Write only BadFaxLines = 0.
2. ファクシミリハードウェアは、ページ品質情報を提供しますが、どんな悪い系列も報告しません。 BadFaxLines=0だけ、を書いてください。
3. Facsimile hardware provides page-quality information and reports
bad lines. Write both BadFaxLines and ConsecutiveBadFaxLines.
Also write CleanFaxData = 1 or 2 if the hardware's regeneration
capability is known.
3. ファクシミリハードウェアは、ページ品質情報を提供して、悪い系列を報告します。 BadFaxLinesとConsecutiveBadFaxLinesの両方を書いてください。 また、ハードウェアの再生能力が知られているなら、CleanFaxData=1か2を書いてください。
4. Source image data stream is error corrected or otherwise
guaranteed to be error free such as for a computer-generated file:
SHOULD NOT write page-quality fields.
4. 修正されるか、またはコンピュータで発生しているファイルなどのようにエラーのなくなるように別の方法で保証されて、ソースイメージデータ・ストリームは誤りです: SHOULD NOTはページ品質分野を書きます。
TIFF Writers SHOULD only generate these fields when the image has been generated from a fax image data stream where error correction, e.g., Group 3 Error Correction Mode, was not used.
イメージがファックスイメージデータ・ストリームのためにエラー修正(例えば、Group3Error Correction Mode)が使用されなかったところで発生しているときだけ、TIFF Writers SHOULDはこれらの分野を生成します。
4.4.6. Practical Guidelines for Writing and Reading Multi-Page TIFF-F
Files
4.4.6. マルチページいさかいFファイルを書いて、読むための実際的なガイドライン
Traditionally, TIFF-F has required readers and writers to be able to handle multi-page TIFF-F files. The experience of various TIFF-F implementors has shown that implementing TIFF-F can be greatly simplified if certain practical guidelines are followed when writing multi-page TIFF-F files.
伝統的に、TIFF-Fは、読者と作家がマルチページTIFF-Fファイルを扱うことができるのを必要としました。 様々なTIFF-F作成者の経験は、マルチページTIFF-Fファイルを書くとき、ある実際的なガイドラインが従われているならTIFF-Fを実装するのを大いに簡素化できるのを示しました。
The structure for a multi-page TIFF-F file will include one IFD per document page. In this case, this IFD will define the attributes for a single page. A second simplifying guideline is that the writer of TIFF-F files SHOULD present IFDs in the same order as the actual sequence of pages. (The pages are numbered within TIFF-F beginning with page 0 as the first page and then ascending (i.e., 0, 1,
マルチページTIFF-Fファイルのための構造はドキュメントページあたり1IFDを含むでしょう。 この場合、このIFDは1ページのために属性を定義するでしょう。 ガイドラインを簡素化する1秒はTIFF-Fの作家がページの実際の系列として同次でSHOULDの現在のIFDsをファイルするということです。 (ページが0ページで始まりながら最初のページとしてTIFF-Fの中で付番されて、次に、昇っている、(すなわち、0、1
Buckley, et al. Standards Track [Page 36] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[36ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
2, ...). However, any field values over 4 bytes will be stored separately from the IFD. TIFF-F readers SHOULD expect IFDs to be presented in page order but be able to handle exceptions.
2, ...). しかしながら、4バイト以上のどんな分野値も別々にIFDから保存されるでしょう。 TIFF-F読者SHOULDは、IFDsがページオーダーに示されますが、例外を扱うことができると予想します。
Per [TIFF], the exact placement of image data is not specified. However, the offsets for each image strip are defined from within each IFD. Where possible, another guideline for TIFF-F writers is that the image data for each page of a multi-page document SHOULD be contained within a single strip (i.e., one image strip per fax page). A single image strip per page further simplifies TIFF-F file writing for applications such as store and forward messaging, where the file is usually prepared in advance of the transmission, but other assumptions may apply for the size of the image strip for applications that require "streaming" techniques (see section 4.4.7). If a different image strip size guideline has been used (e.g., constant size for image strips that may be less than the page size), this will immediately be evident from the values/offsets of the fields related to strips.
[TIFF]に従って、イメージデータの正確なプレースメントは指定されません。 しかしながら、それぞれのイメージ片のためのオフセットは各IFDから定義されます。 可能であるところでは、TIFF-F作家への別のガイドラインはマルチページドキュメントSHOULDの各ページイメージデータが1片(すなわち、ファックスページあたり1イメージ片)の中に含まれているということです。 1ページあたり1イメージ片はさらにファイルがトランスミッションの前に通常準備されますが、他の仮定が「ストリーミング」のテクニックを必要とするアプリケーションのためのイメージ片のサイズに申し込むかもしれない(セクション4.4.7を見てください)店や前進のメッセージングなどのアプリケーションのためのTIFF-Fファイル書くことを簡素化します。 異なったイメージ片サイズガイドラインが使用されたなら(例えば、イメージ片のためのページ・サイズより少ないかもしれない一定のサイズ)、これはすぐに、片に関連する分野の値/オフセットで明白になるでしょう。
Another simplifying guideline is that each IFD SHOULD be placed in the TIFF-F file structure at a point preceding the image that the IFD describes.
別の簡素化ガイドラインは各IFD SHOULDがIFDが説明するイメージに先行しながらポイントにTIFF-Fファイル構造に置かれるということです。
In addition, placing the image data in a physical order within the TIFF file structure which is consistent with the logical page order simplifies TIFF-F file writing and reading. In practice, TIFF-F readers will need to use the strip offsets to find the exact physical location of the image data, whether or not it is presented in logical page order.
さらに、論理的なページと一致したTIFFファイル構造の中に物理的なオーダーにおけるイメージデータを置いて、オーダーはTIFF-Fファイル書くことと読書を簡素化します。 実際には、TIFF-F読者は、イメージデータの正確な物理的な位置を見つけるのにストリップオフセットを使用する必要があるでしょう、それが論理的なページ順番に提示されるか否かに関係なく。
If the image data is stored in multiple strips, then the strips SHOULD occur in the file in the same order that the data they contain occurs in the facsimile transmission, starting from the top of the page.
イメージデータが複数の片の中に保存されるなら、SHOULDがファイルに同じように起こる片は、それらが含むデータがファクシミリ伝送で現れるよう命令します、ページの先頭から始めて。
TIFF-F writers MAY follow another simplifying guideline, in which the IFD, the value data and the image data to which the IFD has offsets precede the next image IFD. However, this guideline has been relaxed compared to the others given here.
ガイドライン((次のイメージIFDに先行します)IFDがオフセットを持っているIFD、値のデータ、およびイメージデータ)を簡素化して、TIFF-F作家は別のものについて来るかもしれません。 しかしながら、ここに与えられた他のものと比べて、このガイドラインはリラックスしました。
In the case of the minimal profile, which is also the minimal subset of Profile F, the SHOULDs and MAYs of these guidelines become SHALLs (see Section 3.5).
最小量のプロフィールの場合では、どれがこれらのガイドラインのProfile Fの最小量の部分集合とも、SHOULDsと5月であるかはSHALLsになります(セクション3.5を見てください)。
A TIFF-F file structured using the guidelines of this section will essentially consist of a linked list of IFDs, presented in ascending page order, each pointing to a single page of image data
このセクションのガイドラインを使用することで構造化されたTIFF-Fファイルはそれぞれ1ページのイメージデータを示すページオーダーを昇る際に寄贈されたIFDsの繋がっているリストから本質的には成るでしょう。
Buckley, et al. Standards Track [Page 37] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[37ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
(one strip per page), where the pages of image data are also placed in a logical page order sequence within the TIFF-F file structure. (The pages of image data may themselves be stored in a contiguous manner, at the option of the implementor).
(1ページあたり1片。)(また、イメージデータのページはTIFF-Fファイル構造の中にそこに論理的なページオーダー系列に置かれます)。 (イメージデータのページがそうするかもしれない、自分たち、作成者の選択のときに隣接の方法で保存されてください、)
4.4.7. Use of TIFF-F for Streaming Applications
4.4.7. いさかいFのストリーミング・アプリケーションの使用
TIFF-F has historically been used for handling fax image files in applications such as store and forward messaging, where the entire size of the file is known in advance. Although TIFF-F may also be used as a file format for cases such as streaming applications, assumptions differing from those provided in this section (e.g., the entire size and number of pages within the image are not known in advance) may be required. As a result, a definition for the streaming application of TIFF-F is beyond the scope of this document.
TIFF-Fはファイルの全体のサイズがあらかじめ知られている店や前進のメッセージングなどのアプリケーションにおける取り扱いファックスイメージ・ファイルに歴史的に使用されました。 また、TIFF-Fはストリーミング・アプリケーションなどのケースにファイル形式として使用されるかもしれませんが、このセクション(例えばイメージの中の全体のサイズとページ数はあらかじめ、知られていない)に提供されたものと異なっている仮定が必要であるかもしれません。 その結果、TIFF-Fのストリーミング・アプリケーションのための定義はこのドキュメントの範囲を超えています。
4.5. Implementation Warnings
4.5. 実装警告
4.5.1. Uncompressed data
4.5.1. 解凍されたデータ
TIFF-F requires the ability to read and write at least one-
dimensional T.4 Huffman ("compressed") data. Uncompressed data is
not allowed. The "Uncompressed" bit in T4Options or T6Options must
be set to 0.
TIFF-Fは少なくとも1つの次元T.4ハフマン(「圧縮される」)データを読み書きする能力を必要とします。 解凍されたデータは許容されていません。 T4OptionsかT6Optionsの「解凍された」ビットを0に設定しなければなりません。
4.5.2. Encoding and Resolution
4.5.2. コード化と解決
Since two-dimensional encoding is not required for Group 3 compatibility, some historic TIFF-F readers have not been able to read such files. The minimum subset of TIFF-F REQUIRES support for one-dimensional (Modified Huffman) files, so this choice maximizes portability. However, implementors seeking greater efficiency SHOULD use T.6 MMR compression when writing TIFF-F files. Some TIFF-F readers will also support two-dimensional Modified READ files. Implementors who wish to have the maximum flexibility in reading TIFF-F files should support all three of these compression methods (MH, MR, and MMR).
以来、二次元コード化はGroup3の互換性に必要でなく、何人かの歴史的なTIFF-F読者はそのようなファイルを読むことができませんでした。 一次元(ハフマンを変更する)のファイルのTIFF-F REQUIRESサポートの最小の部分集合であり、したがって、この選択は移植性を最大にします。 しかしながら、TIFF-Fファイルを書くとき、より大きい効率SHOULDを探している作成者がT.6 MMR圧縮を使用します。 また、何人かのTIFF-F読者が二次元Modified READファイルをサポートするでしょう。 TIFF-Fファイルを読む際に最大の柔軟性を持ちたがっている作成者はこれらのすべての3つの圧縮方法(MH、MR、およびMMR)をサポートするべきです。
Almost all facsimile products support both standard (98 dpi) vertical resolution and "fine" (196 dpi) resolution. Therefore, fine- resolution files are quite portable in the real world.
ほとんどすべてのファクシミリ製品が、両方が標準(98dpi)の垂直解像度と「すばらしい」(196dpi)解決であるとサポートします。 したがって、詳しい解決ファイルは本当の世界でかなり携帯用です。
In 1993, the ITU-T added support for higher resolutions in the T.30 recommendation, including 200 x 200, 300 x 300, and 400 x 400 in dots per inch-based units. At the same time, support was added for metric dimensions equivalent to the following inch-based resolutions: 391v x 204h and 391v x 408h. Therefore, the full set of inch-based equivalents of the new resolutions are supported in the TIFF-F
1993年に、ITU-TはT.30推薦における、より高い解像度のサポートを加えました、インチベースのユニットあたりのドットに200x200、300x300、および400x400を含んでいて。 同時に、サポートは以下のインチベースの解決に同等なメートル法の寸法のために加えられました: 391v x204hと391v x408h。 したがって、新しい解決のインチベースの同等物のフルセットはTIFF-Fでサポートされます。
Buckley, et al. Standards Track [Page 38] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[38ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
writer, as they may appear in some image-data streams received from Group 3 facsimile devices. However, many facsimile terminals and older versions of TIFF-F readers are likely not to support these higher resolutions.
彼らがGroup3から受けられたイメージデータ・ストリームに現れるかもしれないように作家はデバイスを電送してください。 しかしながら、TIFF-F読者の多くのファクシミリ端末と旧式のバージョンは、これらが、より高い解像度であるとサポートしないようにありそうです。
Per [T.4], it is permissible for applications to treat the following XResolution values as equivalent: <204,200> and <400,408>. Similarly, the following YResolution values may also be treated as equivalent: <98, 100>, <196, 200>, and <391, 400>. These equivalencies were allowed by [T.4] to permit conversions between inch- and metric-based facsimile terminals.
[T.4]に従って、アプリケーションが同等な以下のXResolution同じくらい値を扱うのは、許されています: <20万4200>と<40万408>。 また、同様に、以下のYResolution値は同等物として扱われるかもしれません: <98、100の>、<196、200>、および<391、400>。 [T.4]はこれらのequivalenciesをインチとメートル法ベースのファクシミリ端末の間の変換を可能にさせられました。
The optional support of metric-based resolutions in the TIFF-F reader (i.e., 77 x 38.5 cm) is included for completeness, as they are used in some legacy TIFF-F applications, but this use is not recommended for the creation of TIFF-F files by a writer.
それらがいくつかのレガシーTIFF-Fアプリケーションで使用されますが、この使用がTIFF-Fファイルの作成のために作家によって推薦されないようにTIFF-F読者(すなわち、77x38.5cm)でのメートル法ベースの解決の任意のサポートは完全性のために含まれています。
4.5.3. EOL byte-aligned
4.5.3. EOLはバイト並びました。
The historical convention for TIFF-F has been that all EOLs in Modified Huffman or Modified READ data must be byte-aligned. However, Baseline TIFF has permitted use of non byte-aligned EOLs by default, so that a large percentage of TIFF-F reader implementations support both conventions. Therefore, the minimum subset of TIFF-F, or Profile S, as defined in Section 3, includes support for both byte-aligned and non-byte-aligned EOLs; see Section 3.2.2.
TIFF-F歴史的なコンベンションはModifiedハフマンかModified READデータのすべてのEOLsがバイトで並べなければならないということです。 しかしながら、Baseline TIFFはデフォルトで非バイトが並んでいるEOLsの使用を可能にしました、大きい百分率のTIFF-F読者実装が両方のコンベンションをサポートするように。 したがって、セクション3で定義されるTIFF-F、またはProfile Sの最小の部分集合はバイトで並べられて、かつ非バイトが並んでいるEOLsのサポートを含んでいます。 セクション3.2.2を見てください。
An EOL is said to be byte-aligned when Fill bits have been added as necessary before EOL codes so that EOL always ends on a byte boundary, thus ensuring an EOL sequence of a one byte preceded by a zero nibble: xxxx0000 00000001.
EOLはFillビットがEOLコードの前に必要に応じて加えられたとき、EOLがバイト境界でいつも終わるようにバイトによって並べられると言われています、その結果、ゼロで先行された1バイトのEOL系列が少量であるのを確実にします: xxxx0000 00000001。
Modified Huffman compression encodes bits, not bytes. This means that the end-of-line token may end in the middle of a byte. In byte alignment, extra zero bits (Fill) are added so that the first bit of data following an EOL begins on a byte boundary. In effect, byte alignment relieves application software of the burden of bit-shifting every byte while parsing scan-lines for line-oriented image manipulation (such as writing a TIFF file).
変更されたハフマン圧縮はバイトではなく、ビットをコード化します。 これは、行末トークンが1バイトの中央に終わるかもしれないことを意味します。 バイト整列では、付加的なゼロ・ビット(いっぱいにしている)が加えられるので、EOLに続くデータの最初のビットはバイト境界で始まります。 事実上、バイト整列はバイト毎に系列指向の映像操作(TIFFファイルを書くことなどの)のために走査線を分析している間、ビット移行の負担をアプリケーション・ソフトに取り除きます。
For Modified READ compression, each line is terminated by an EOL and a one-bit tag bit. Per [T.4], the value of the tag bit is 0 if the next line contains two-dimensional data and 1 if the next line is a reference line. To maintain byte alignment, fill bits are added before the EOL/tag bit sequence so that the first bit of data following an MR tag bit begins on a byte boundary.
Modified READ圧縮において、各系列はEOLと1ビットのタグビットによって終えられます。 次の系列が次の系列が基準線であるなら二次元データと1を含んでいるなら、[T.4]あたりタグビットの価値は0です。 EOL/タグが系列に噛み付く前にバイト整列を維持するために、中詰めビットが加えられるので、MRタグビットに続くデータの最初のビットはバイト境界で始まります。
Buckley, et al. Standards Track [Page 39] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[39ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
4.5.4. EOL
4.5.4. EOL
As illustrated in FIGURE 1/T.4 in [T.4], MH-encoded facsimile documents begin with an EOL, which in TIFF-F may be byte-aligned. The last line of the image is not terminated by an EOL. Similarly, respect, images encoded with Modified READ two-dimensional compression begin with an EOL, followed by a tag bit.
[T.4]の図1/T.4で例証されるように、MHによってコード化されたファクシミリドキュメントはEOLと共に始まります。(TIFF-Fでは、バイトで、EOLは並べられるかもしれません)。 イメージの最終ラインはEOLによって終えられません。 同様に、敬意、イメージはModified READ二次元で圧縮をコード化しました、タグビットをEOLと共に始めて、続いてコード化します。
4.5.5. RTC Exclusion
4.5.5. RTC除外
Aside from EOLs, TIFF-F files have historically only contained image data. This means that applications seeking to maintain strict conformance with the rules in [TIFF] and compatibility with historical TIFF-F SHOULD NOT include the Return To Control sequence (RTC) (consisting of 6 consecutive EOLs) when writing TIFF-F files. However, applications intended to support "transparency" of [T.4] image data MAY include RTCs if the flag settings of the T4Options field are set for non byte aligned MH or MR image data. Implementors of TIFF readers should also be aware that there are some existing TIFF-F implementations that include the RTC sequence in MH/MR image data. Therefore, TIFF-F readers MUST be able to process files that do not include RTCs and SHOULD be able to process files that do include RTCs.
EOLsは別として、TIFF-Fファイルはイメージデータを歴史的に含むだけでした。 これは、TIFF-Fファイルを書くとき、歴史的なTIFF-F SHOULD NOTとの規則が[TIFF]にある状態で厳しい順応を維持しようとするアプリケーションと互換性がReturn To Control系列(RTC)(6連続したEOLsから成る)を含んでいることを意味します。 しかしながら、T4Options分野の旗の設定が非バイトの並べられたMHかMRイメージデータに設定されるなら、[T.4]イメージデータの「透明」をサポートすることを意図するアプリケーションはRTCを含むかもしれません。 また、TIFF読者の作成者もMH/MRイメージデータにRTC系列を含んでいるいくつかの既存のTIFF-F実装があるのを意識しているべきです。 したがって、TIFF-F読者はRTCとSHOULDを含んでいないファイルを処理できなければなりません。RTCを含んでいるファイルは処理できてください。
4.5.6. Use of EOFB for T.6 Compressed Images
4.5.6. EOFBのT.6圧縮画像の使用
TIFF-F pages encoded with the T.6 Modified Modified READ compression method MUST include an "end-of-facsimile-block" (EOFB) code at the end of each coded strip. Per [TIFF], the EOFB code is followed by pad bits as needed to align on a byte boundary. TIFF readers SHOULD ignore any bits other than pad bits beyond the EOFB.
T.6 Modified Modified READ圧縮方法でコード化されたTIFF-Fページはそれぞれのコード化された片の端ときに「ファクシミリブロックの端」(EOFB)コードを含まなければなりません。 パッドビットは[TIFF]に従って必要に応じてEOFBコードを支えて、バイト境界に並びます。 TIFF読者SHOULDはEOFBを超えたパッドビット以外のどんなビットも無視します。
4.6. Example Use of TIFF-F
4.6. いさかいFの例の使用
The Profile F of TIFF (i.e., TIFF-F content) is a secondary component of the VPIM Message, as defined in [VPIM 2]. Voice messaging systems can often handle fax store-and-forward capabilities in addition to traditional voice message store-and-forward functions. As a result, TIFF-F fax messages can optionally be sent between compliant VPIM systems and may be rejected if the recipient system cannot deal with fax.
TIFF(すなわち、TIFF-F内容)のProfile FはVPIM Messageの伴星です、[VPIM2]で定義されるように。 声のメッセージシステムはしばしば伝統的な音声メール店とフォワード機能に加えたファックス店とフォワード能力を扱うことができます。 その結果、TIFF-Fファックス通信は、任意に対応するVPIMシステムの間に送ることができて、受取人システムがファックスに対処できないなら、拒絶されるかもしれません。
Refer to the VPIM Specification for proper usage of this content.
この内容の適切な用法についてVPIM Specificationを参照してください。
Buckley, et al. Standards Track [Page 40] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[40ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
4.7. Profile F: Extended Black-and-white Fax Profile Summary
4.7. プロフィールF: 拡張白黒のファックスプロフィール概要
Recommended fields are shown with an asterisk (*).
お勧めの分野はアスタリスク(*)で示されます。
Required fields or values are shown with a double asterisk (**). If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisks are in the Values column, then only the values suffixed with a double asterisk are required of implementations.
必須項目か値が二重アスタリスク(**)で示されます。 二重アスタリスクがフィールド名にあるなら、実装はすべての記載された値に要求されます。 二重アスタリスクがValuesコラムにあるなら、実装は二重アスタリスクでsuffixedされた値だけに要求されます。
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 3**: 1D Modified Huffman and |
| | 2D Modified READ coding |
| | 4: 2D Modified Modified READ |
| | coding |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time in 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+---------------------------+--------------------------------+
| FillOrder** | 1: most significant bit first |
| | 2: least significant bit first |
+------------------------------------------------------------+
| ImageDescription* | {ASCII}: A string describing |
| | the contents of the image. |
+---------------------------+--------------------------------+
| ImageWidth | 1728**, 2048, 2432, 2592, |
| | 3072, 3456, 3648, 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines |
| | in image |
+---------------------------+--------------------------------+
| NewSubFileType | 2**: Bit 1 identifies single |
| | page of a multi-page document |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| ** | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
| | 3: centimeter |
+------------------------------------------------------------+
+---------------------------+--------------------------------+ | 基線分野| 値| +---------------------------+--------------------------------+ | BitsPerSample| 1** | +---------------------------+--------------------------------+ | 圧縮| 3**: そして1Dがハフマンを変更した。| | | 2D Modified READコード化| | | 4: 変更されていた状態で変更された2Dは読みました。| | | コード化| +---------------------------+--------------------------------+ | DateTime*| ASCII: 24時間で日付/時間| | | 形式「YYYY:mm:DD HH:mm:SS」| +---------------------------+--------------------------------+ | FillOrder**| 1: 最上位ビット、最初に。| | | 2: 最下位ビット、最初に。| +------------------------------------------------------------+ | ImageDescription*| ASCII: 五弦説明| | | イメージのコンテンツ。 | +---------------------------+--------------------------------+ | ImageWidth| 1728**, 2048, 2432, 2592, | | | 3072, 3456, 3648, 4096, 4864 | +---------------------------+--------------------------------+ | ImageLength**| n: 総数の走査線| | | イメージで| +---------------------------+--------------------------------+ | NewSubFileType| 2**: ビット1はシングルを特定します。| | | マルチページドキュメントのページ| +---------------------------+--------------------------------+ | オリエンテーション| 1**-8、デフォルト1| +---------------------------+--------------------------------+ | PhotometricInterpretation| 0: ピクセル値1は黒いことを意味します。| | ** | 1: ピクセル値1は白いことを意味します。| +---------------------------+--------------------------------+ | ResolutionUnit**| 2: インチ| | | 3: センチメートル| +------------------------------------------------------------+
Buckley, et al. Standards Track [Page 41] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[41ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1** |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release |
| | number of creator software |
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number or bytes in TIFF |
| | strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning of |
| | file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 200, 204**, 300, 400, 408 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98**, 196**, 100, |
| | 200, 300, 391, 400 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| T4Options | 0**: required if Compression |
| | is Modified Huffman, EOLs are |
| | not byte aligned |
| | 1: required if Compression is |
| | 2D Modified READ, EOLs are |
| | not byte aligned |
| | 4**: required if Compression |
| | is Modified Huffman, EOLs are |
| | byte aligned |
+---------------------------+--------------------------------+
| T4Options (continued) | 5: required if Compression |
| | is 2D Modified READ, EOLs are |
| | byte aligned |
+---------------------------+--------------------------------+
| T6Options | 0: required if Compression is |
| | 2D Modified Modified READ |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of scanned |
| | document |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
+---------------------------+--------------------------------+ | RowsPerStrip**| n: 走査線の数| | | TIFF片| +---------------------------+--------------------------------+ | SamplesPerPixel| 1** | +---------------------------+--------------------------------+ | ソフトウェア*| ASCII: 名前とリリース| | | 創造者ソフトウェアの数| +---------------------------+--------------------------------+ | StripByteCounts**| <n>: TIFFの数かバイト| | | 片| +---------------------------+--------------------------------+ | StripOffsets**| <n>: 始めから、相殺します。| | | それぞれのTIFF片にファイルしてください。| +---------------------------+--------------------------------+ | XResolution| 200, 204**, 300, 400, 408 | | | (画素/インチに書かれています) | +---------------------------+--------------------------------+ | YResolution| 98**, 196**, 100, | | | 200, 300, 391, 400 | | | (画素/インチに書かれています) | +---------------------------+--------------------------------+ | 拡大分野| +---------------------------+--------------------------------+ | T4Options| 0**: Compressionであるなら、必要です。| | | Modifiedハフマン、EOLsがあるということです。| | | どんなバイトも並びませんでした。| | | 1: Compressionが必要であるなら、必要です。| | | 2D Modified READ、EOLsはそうです。| | | どんなバイトも並びませんでした。| | | 4**: Compressionであるなら、必要です。| | | Modifiedハフマン、EOLsがあるということです。| | | バイトは並びました。| +---------------------------+--------------------------------+ | T4Options(続けられています)| 5: Compressionであるなら、必要です。| | | 2D Modified READ、EOLsがあるということです。| | | バイトは並びました。| +---------------------------+--------------------------------+ | T6Options| 0: Compressionが必要であるなら、必要です。| | | 変更されていた状態で変更された2Dは読みました。| +---------------------------+--------------------------------+ | DocumentName*| ASCII: スキャンされることの名前| | | ドキュメント| +---------------------------+--------------------------------+ | PageNumber**| n、m: 従われたページ番号| | | 総ページ数| +---------------------------+--------------------------------+
Buckley, et al. Standards Track [Page 42] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[42ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+---------------------------+--------------------------------+ | New Fields | +---------------------------+--------------------------------+ | BadFaxLines* | number of "bad" scanlines | | | encountered during reception | +---------------------------+--------------------------------+ | CleanFaxData* | 0: no "bad" lines | | | 1: "bad" lines exist, but were | | | regenerated by receiver | | | 2: "bad" lines exist, but have | | | not been regenerated | +---------------------------+--------------------------------+ | ConsecutiveBadFaxLines* | Max number of consecutive | | | "bad" lines received | +---------------------------+--------------------------------+ | GlobalParametersIFD* | IFD: global parameters IFD | +---------------------------+--------------------------------+ | ProfileType* | n: type of data stored in file | +---------------------------+--------------------------------+ | FaxProfile* | n: ITU-compatible fax profile | +---------------------------+--------------------------------+ | CodingMethods* | n: compression algorithms used | | | in file | +---------------------------+--------------------------------+
+---------------------------+--------------------------------+ | 新しい分野| +---------------------------+--------------------------------+ | BadFaxLines*| 「悪い」走査線の数| | | レセプションの間、遭遇します。| +---------------------------+--------------------------------+ | CleanFaxData*| 0: 「悪い」線がありません。| | | 1: 「悪い」線は、存在しましたが、ありました。| | | 受信機で、作り直されます。| | | 2: しかし、「悪い」線は存在しています。| | | 作り直されません。| +---------------------------+--------------------------------+ | ConsecutiveBadFaxLines*| 連続することのマックス番号| | | 受け取られた「悪い」台詞| +---------------------------+--------------------------------+ | GlobalParametersIFD*| IFD: グローバルなパラメタIFD| +---------------------------+--------------------------------+ | ProfileType*| n: ファイルに格納されたデータのタイプ| +---------------------------+--------------------------------+ | FaxProfile*| n: ITUコンパチブルファックスプロフィール| +---------------------------+--------------------------------+ | CodingMethods*| n: アルゴリズムが使用した圧縮| | | ファイルで| +---------------------------+--------------------------------+
5. Profile J: Lossless JBIG Black-and-White Fax profile
5. プロフィールJ: Lossless JBIG Blackとホワイトファックスプロフィール
This section defines the lossless JBIG black-and-white profile of TIFF for facsimile, designated Profile J. Implementations of this profile are required to implement Profile S as well.
このセクションはファクシミリのためにTIFFのlossless JBIGの白黒のプロフィールを定義して、このプロフィールの指定されたProfile J.Implementationsはまた、Profile Sを実行しなければなりません。
The previous section described the extended interchange set of TIFF fields for black-and-white fax, which provided support for the MH, MR, and MMR compression of black-and-white images. This section adds a profile with JBIG compression capability.
前項は白黒のファックスのために拡張置き換えセットのTIFF分野について説明しました。(それは、白黒のイメージのMH、MR、およびMMR要約のサポートを提供しました)。 このセクションはJBIG圧縮能力でプロフィールを加えます。
5.1. Overview
5.1. 概観
This section describes a black-and-white profile that uses JBIG compression. The ITU-T has approved the single-progression sequential mode of JBIG [T.82] for Group 3 facsimile. JBIG coding offers improved compression for halftoned originals. JBIG compression is used in accordance with the application rules given in ITU-T Rec. T.85 [T.85].
このセクションはJBIG圧縮を使用する白黒のプロフィールについて説明します。 ITU-TはGroup3ファクシミリのためにJBIG[T.82]のただ一つの進行順序配列モデルを承認しました。 JBIGコード化申し出はhalftonedオリジナルのための圧縮を改良しました。 ITU-T Recで与えられたアプリケーション規則に従って、JBIG圧縮は使用されます。 T.85[T.85]。
This profile is essentially the extended black-and-white profile with JBIG compression used instead of MH, MR, or MMR.
このプロフィールは本質的にはMH、MR、またはMMRの代わりに中古のJBIG圧縮がある拡張白黒のプロフィールです。
Buckley, et al. Standards Track [Page 43] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[43ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
5.2. Required TIFF Fields
5.2. 必要ないさかい分野
This section lists the required fields and the values they must have to be ITU-compatible. Besides the fields listed in Section 2.2.1, the extended black-and-white fax profile requires the following fields.
このセクションはそれらがITU互換性があるように持たなければならない必須項目と値を記載します。 セクション2.2.1で記載された分野以外に、拡張白黒のファックスプロフィールは以下の分野を必要とします。
5.2.1. Baseline fields
5.2.1. 基線分野
The TIFF fields that SHALL be used in this profile are the same as those described in Section 4.2.1 for the extended black-and-white profile, with two exceptions: the following text replaces the text in Section 4.2.1 for the Compression and FillOrder fields.
TIFFはこのプロフィールが同じである中古のコネが拡張白黒のプロフィールのためにセクション4.2.1で説明されたものであったならそのSHALLをさばきます、2つの例外で: 以下のテキストはセクション4.2.1におけるテキストをCompressionとFillOrder分野に置き換えます。
Compression(259) = 9.
SHORT
RequiredByTIFFBaseline
9 = JBIG coding. This is a TIFF extension value.
Default = 1 (and is not applicable; field must be specified).
Profile J uses ITU-T T.85 profile of T.82; see T82Options field.
圧縮(259)=9。 SHORT RequiredByTIFFBaseline9はJBIGコード化と等しいです。 これはTIFF拡大価値です。 デフォルト=1、(適切でない、;、分野を指定しなければならない ) ITU-T T.85が輪郭を描くT.82のJ用途の輪郭を描いてください。 T82Options分野を見てください。
FillOrder(266) = 1, 2.
SHORT
RequiredByTIFFBaseline
1 = Pixels are arranged within a byte such that pixels with lower
values are stored in the higher-order bits of the byte, i.e., most
significant bit first (MSB).
2 = Pixels are arranged within a byte such that pixels with lower
column values are stored in the lower-order bits of the bytes,
i.e., least significant bit first (LSB).
Profile J readers must be able to read data in both bit orders.
FillOrder(266)=1、2。 SHORT RequiredByTIFFBaseline1=画素が1バイト以内でアレンジされるので、下側の値に従った画素はバイト最初に、すなわち、最上位ビット(MSB)の高次なビットに格納されます。 2 = 画素が1バイト以内でアレンジされるので、下側のコラム値に従った画素はバイト最初に、すなわち、最下位ビット(LSB)の下層階級ビットに格納されます。 プロフィールJ読者は両方の噛み付いている命令でデータを読むことができなければなりません。
5.2.2. Extension fields
5.2.2. 拡大分野
Same fields as those in Section 2.2.1.
セクション2.2.1におけるそれらと同じ分野。
5.2.3. New fields
5.2.3. 新しい分野
T82Options(435) = 0
LONG
Required when Compression = 9
Individual bits are set to indicate the applicable profile of JBIG
coding; all bits set to 0 indicates ITU-T T.85 profile of T.82;
Other values are for further study.
Default is all bits 0, and field may be omitted if this is the
value. (Field may be omitted in Profile J files.)
9Individual Compression=ビットがJBIGコード化の適切なプロフィールを示すように設定されるとき、T82Options(435)は0LONG Requiredと等しいです。 0に設定されたすべてのビットがT.82のITU-T T.85プロフィールを示します。 さらなる研究には他の値があります。 デフォルトはすべてビット0です、そして、分野はこれが値であるなら省略されるかもしれません。 (分野はProfile Jファイルで省略されるかもしれません。)
Buckley, et al. Standards Track [Page 44] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[44ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Note: A T.82 decoder can decode a T.85-encoded image when it handles the NEWLE marker code as described Corrigendum 1 in [T.85].
以下に注意してください。 説明されたCorrigendum1として[T.85]でNEWLEマーカーコードを扱うとき、T.82デコーダはT.85によってコード化されたイメージを解読できます。
5.3. Recommended TIFF Fields
5.3. お勧めのいさかい分野
See Sections 2.2.3 and 2.2.4.
.4にセクション2.2 .3と2.2を見てください。
5.4. Profile J: Lossless JBIG Black-and-white Fax Profile Summary
5.4. プロフィールJ: Lossless JBIGの白黒のファックスプロフィール概要
Recommended fields are shown with an asterisk (*).
お勧めの分野はアスタリスク(*)で示されます。
Required fields or values are shown with a double asterisk (**). If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisks are in the Values column, then only the values suffixed with a double asterisk are required of implementations.
必須項目か値が二重アスタリスク(**)で示されます。 二重アスタリスクがフィールド名にあるなら、実現はすべての記載された値に要求されます。 二重アスタリスクがValuesコラムにあるなら、実現は二重アスタリスクでsuffixedされた値だけに要求されます。
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 1** |
+---------------------------+--------------------------------+
| Compression | 9**: JBIG coding |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time in 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+---------------------------+--------------------------------+
| FillOrder** | 1: most significant bit first |
| | 2: least significant bit first |
+---------------------------+--------------------------------+
| ImageDescription* | {ASCII}: A string describing |
| | the contents of the image |
+---------------------------+--------------------------------+
| ImageWidth | 1728**, 2048, 2432, 2592, |
| | 3072, 3456, 3648, 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines |
| | in image |
+---------------------------+--------------------------------+
| NewSubFileType** | 2: Bit 1 identifies single |
| | page of a multi-page document |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
| PhotometricInterpretation | 0: pixel value 1 means black |
| ** | 1: pixel value 1 means white |
+---------------------------+--------------------------------+
+---------------------------+--------------------------------+ | 基線分野| 値| +---------------------------+--------------------------------+ | BitsPerSample| 1** | +---------------------------+--------------------------------+ | 圧縮| 9**: JBIGコード化| +---------------------------+--------------------------------+ | DateTime*| ASCII: 24時間で日付/時間| | | 形式「YYYY:mm:DD HH:mm:SS」| +---------------------------+--------------------------------+ | FillOrder**| 1: 最上位ビット、最初に。| | | 2: 最下位ビット、最初に。| +---------------------------+--------------------------------+ | ImageDescription*| ASCII: 五弦説明| | | イメージのコンテンツ| +---------------------------+--------------------------------+ | ImageWidth| 1728**, 2048, 2432, 2592, | | | 3072, 3456, 3648, 4096, 4864 | +---------------------------+--------------------------------+ | ImageLength**| n: 総数の走査線| | | イメージで| +---------------------------+--------------------------------+ | NewSubFileType**| 2: ビット1はシングルを特定します。| | | マルチページドキュメントのページ| +---------------------------+--------------------------------+ | オリエンテーション| 1**-8、デフォルト1| +---------------------------+--------------------------------+ | PhotometricInterpretation| 0: ピクセル値1は黒いことを意味します。| | ** | 1: ピクセル値1は白いことを意味します。| +---------------------------+--------------------------------+
Buckley, et al. Standards Track [Page 45] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[45ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
| | 3: centimeter |
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel** | 1 |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release |
| | number of creator software |
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number of bytes in TIFF |
| | strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning of |
| | file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 200, 204**, 300, 400, 408 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 98**, 196**, 100, |
| | 200, 300, 391, 400 |
| | (written in pixels/inch) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of document |
| | scanned |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
| New Fields |
+---------------------------+--------------------------------+
| GlobalParametersIFD* | IFD: global parameters IFD |
+---------------------------+--------------------------------+
| T82Options** | 0: T.85 profile of T.82 |
+---------------------------+--------------------------------+
| ProfileType* | n: type of data stored in file |
+---------------------------+--------------------------------+
| FaxProfile* | n: ITU-compatible fax profile |
+---------------------------+--------------------------------+
| CodingMethods* | n: compression algorithms used |
| | in file |
+---------------------------+--------------------------------+
+---------------------------+--------------------------------+ | ResolutionUnit**| 2: インチ| | | 3: センチメートル| +---------------------------+--------------------------------+ | RowsPerStrip**| n: 走査線の数| | | TIFF片| +---------------------------+--------------------------------+ | SamplesPerPixel**| 1 | +---------------------------+--------------------------------+ | ソフトウェア*| ASCII: 名前とリリース| | | 創造者ソフトウェアの数| +---------------------------+--------------------------------+ | StripByteCounts**| <n>: TIFFのバイト数| | | 片| +---------------------------+--------------------------------+ | StripOffsets**| <n>: 始めから、相殺します。| | | それぞれのTIFF片にファイルしてください。| +---------------------------+--------------------------------+ | XResolution| 200, 204**, 300, 400, 408 | | | (画素/インチに書かれています) | +---------------------------+--------------------------------+ | YResolution| 98**, 196**, 100, | | | 200, 300, 391, 400 | | | (画素/インチに書かれています) | +---------------------------+--------------------------------+ | 拡大分野| +---------------------------+--------------------------------+ | DocumentName*| ASCII: ドキュメントの名前| | | スキャンされます。| +---------------------------+--------------------------------+ | PageNumber**| n、m: 従われたページ番号| | | 総ページ数| +---------------------------+--------------------------------+ | 新しい分野| +---------------------------+--------------------------------+ | GlobalParametersIFD*| IFD: グローバルなパラメタIFD| +---------------------------+--------------------------------+ | T82Options**| 0: T.82のT.85プロフィール| +---------------------------+--------------------------------+ | ProfileType*| n: ファイルに格納されたデータのタイプ| +---------------------------+--------------------------------+ | FaxProfile*| n: ITUコンパチブルファックスプロフィール| +---------------------------+--------------------------------+ | CodingMethods*| n: アルゴリズムが使用した圧縮| | | ファイルで| +---------------------------+--------------------------------+
Buckley, et al. Standards Track [Page 46] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[46ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
6. Profile C: Base Color Fax profile
6. プロフィールC: 基地のColorファックスプロフィール
6.1. Overview
6.1. 概観
This section defines the lossy color profile of TIFF for facsimile, designated Profile C. Implementations of this profile are required to also implement Profile S as well.
このセクションはファクシミリのためにTIFFの損失性カラープロフィールを定義します、また、このプロフィールの指定されたProfile C.Implementationsがまた、Profile Sを実行しなければなりません。
This is the base profile for color and grayscale facsimile, which means that all applications that support color fax must support this profile. The basic approach is the lossy JPEG compression [T.4, Annex E; T.81] of L*a*b* color data [T.42]. Grayscale applications use the L* lightness component; color applications use the L*, a* and b* components.
これは色とグレースケールファクシミリのためのベースプロフィールです。(そのプロフィールは、カラーファックスを支えるすべてのアプリケーションがこのプロフィールを支えなければならないことを意味します)。 基本的なアプローチが損失性JPEG圧縮である、[T.4、Annex E; T.81] L*a*b*では、[T.42]にデータを着色してください。 グレースケールアプリケーションはL*軽さコンポーネントを使用します。 色のアプリケーションはL*、*、およびb*コンポーネントを使用します。
This profile uses a new PhotometricInterpretation field value to describe the L*a*b* encoding specified in [T.42]. This encoding differs in two ways from the other L*a*b* encodings used in TIFF [TIFF, TTN1]: it specifies a different default range for the a* and b* components, based on a comprehensive evaluation of existing hardcopy output, and it optionally allows selectable range for the L*, a* and b* components.
このプロフィールは、*b*コード化が[T.42]で指定したL*について説明するのに新しいPhotometricInterpretation分野価値を使用します。 このコード化は*b*encodingsがTIFF[TIFF、TTN1]で使用したもう片方のL*と2つの方法において異なります: それは既存のハードコピー出力の総合評価に基づくa*とb*コンポーネントに異なったデフォルト範囲を指定します、そして、任意に、L*、*、およびb*コンポーネントのための選択可能な範囲を許容します。
6.2. Required TIFF Fields
6.2. 必要ないさかい分野
This section lists the required fields, in addition to those given in Section 2.2.1, and the values they must support to be compatible with ITU-T Rec. T.42 and Annex E in ITU-T Rec. T.4.
このセクションは必須項目を記載します、それらがITU-T Recと互換性があるように支持しなければならないセクション2.2.1、および値で与えられたものに加えて。 ITU-T RecのT.42と別館E。 T.4。
6.2.1. Baseline Fields
6.2.1. 基線分野
ImageWidth(256).
SHORT or LONG
This profile supports the following fixed page widths: 864, 1024,
1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864.
ImageWidth(256)。 SHORTかLONG Thisプロフィールが以下の固定ページ幅を支持します: 864, 1024, 1216, 1728, 2048, 2432, 2592, 3072, 3456, 3648, 4096, 4864.
NewSubFileType(254) = (Bit 1=1).
LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax).
NewSubFileType(254)は(ビット1=1)と等しいです。 イメージがマルチページドキュメントの1ページであるなら、LONG RequiredByTIFFforFAX Bit1は1歳です。 デフォルト=0、(いいえがビットを副ファイルするので省略されないかもしれない、ファックス)
BitsPerSample(258) = 8.
SHORT
Count = SamplesPerPixel
The base color fax profile requires 8 bits per sample.
BitsPerSample(258)=8。 SHORT Countはベースがプロフィールが必要とするファックスに着色するSamplesPerPixelと1サンプルあたり8ビット等しいです。
Buckley, et al. Standards Track [Page 47] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[47ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Compression(259) = 7.
SHORT
Base color fax profile uses Baseline JPEG compression. Value 7
represents JPEG compression as specified in [TTN2].
圧縮(259)=7。 SHORT基地のカラーファックスプロフィールはBaseline JPEG圧縮を使用します。 値7は[TTN2]で指定されているとしてJPEG圧縮を表します。
FillOrder(266) = 1 , 2.
SHORT
RequiredByTIFFBaseline
Profile C readers must be able to read data in both bit orders,
but the vast majority of facsimile products store data LSB first,
exactly as it appears on the telephone line.
1 = Most Significant Bit first.
2 = Least Significant Bit first.
FillOrder(266)=1、2。 SHORT RequiredByTIFFBaseline Profile C読者は両方の噛み付いている命令でデータを読むことができなければなりませんが、かなりの大多数のファクシミリ製品は最初にデータLSBを格納します、ちょうど電話回線の上に現れるように。 1は最初に、ほとんどのSignificant Bitと等しいです。 2は最初に、最少のSignificant Bitと等しいです。
PhotometricInterpretation(262) = 10.
SHORT
Base color fax profile requires pixel values to be stored with the
CIE L*a*b* encoding defined in ITU-T Rec. T.42. This encoding is
indicated by the PhotometricInterpretation value 10, referred to
as ITULAB. With this encoding, the minimum sample value is
mapped to 0, and the maximum sample value is mapped to (2^n - 1),
i.e., the maximum value, where n is the BitsPerSample value. The
conversion from unsigned ITULAB-encoded samples values to signed
CIE L*a*b* values is determined by the Decode field; see Section
6.2.3.
PhotometricInterpretation(262)=10。 SHORT基地のカラーファックスプロフィールは、ピクセル値が*b*コード化がITU-T Recで定義したCIE L*と共に格納されるのを必要とします。 T.42。 ITULABと呼ばれて、このコード化はPhotometricInterpretation値10によって示されます。 このコード化で、最小の標本値は0に写像されます、そして、最大の標本値はすなわち、(2^n--1)、最大の値に写像されます。そこでは、nがBitsPerSample値です。 無記名のITULABによってコード化されたサンプル値からサインされた*b*が評価するCIE L*までの変換はDecode分野のそばで決定しています。 セクション6.2.3を見てください。
NOTE: PhotometricInterpretation values 8 and 9 specify encodings for use with 8-bit-per-sample CIE L*a*b* [TIFF] and ICC L*a*b* [TTN1] data, but they are fixed encodings, which use different minimum and maximum samples than the T.42 default encoding. As currently defined, they are not able to represent fax-encoded L*a*b* data.
以下に注意してください。 8と9がencodingsを指定するPhotometricInterpretation値は1サンプルあたり8ビットCIE L**b*[TIFF]とICC L*と共に*を使用します。b*[TTN1]データ、encodingsはT.42デフォルトコード化よりそれらだけに固定されています。(encodingsは異なった最小の、そして、最大のサンプルを使用します)。 現在定義されるように、彼らはファックスでコード化されたL*a*b*データを表すことができません。
ResolutionUnit(296) = 2.
SHORT
The unit of measure for resolution. 2 = inch.
ITU-T standards only specify inch-based resolutions for color fax.
Default = 2 (field may be omitted if this is the value).
ResolutionUnit(296)=2。 SHORT、解決のための測定の単位。 2はインチと等しいです。 ITU-T規格はカラーファックスのためのインチベースの解決を指定するだけです。 デフォルト=2(分野はこれが値であるなら省略されるかもしれません)。
SamplesPerPixel(277) = 1, 3.
SHORT
1: L* component only, required in base color profile
3: L*, a*, b* components
Encoded according to PhotometricInterpretation field
SamplesPerPixel(277)=1、3。 短い1: 基調色プロフィール3で唯一の、そして、必要なL*コンポーネント: L*、*、PhotometricInterpretation分野に従ったb*コンポーネントEncoded
Buckley, et al. Standards Track [Page 48] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[48ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
XResolution(282) = 100, 200, 300, 400.
RATIONAL
YResolution(283) = 100, 200, 300, 400.
RATIONAL
The resolution of the image is expressed in pixels per resolution
unit. In pixels per inch, allowed XResolution values are 100,
200, 300, and 400. The base color fax profile requires the pixels
to be square, hence YResolution must equal XResolution. Base
resolution is 200 pixels per inch and SHALL be supported by all
implementations of this profile.
XResolution(282)=100、200、300、400。 合理的なYResolution(283)=100、200、300、400。 RATIONAL、イメージの解像度は解決ユニットあたりの画素で言い表されます。 ピクセル・パー・インチでは、XResolution値が許容されているのは、100と、200と、300と、400です。 基調色ファックスプロフィールは、画素が正方形であることを必要とします、したがって、YResolutionがXResolutionと等しくなければなりません。 基地の解決は、200ピクセル・パー・インチとSHALLです。このプロフィールのすべての実現で、支持されます。
NOTE: The functional equivalence of inch-based and metric-based resolutions is maintained, per Annex E.6.5 in [T.4]. See table in Section 2.2.2.
以下に注意してください。 インチベースの、そして、メートル法ベースの解決の機能的な等価性は[T.4]でAnnex E.6.5単位で維持されます。 セクション2.2.2でテーブルを見てください。
NOTE: Not all combinations of XResolution, YResolution and ImageWidth are legal. The following table gives the legal combinations for inch-based resolutions and the corresponding paper sizes [T.30].
以下に注意してください。 XResolution、YResolution、およびImageWidthのすべての組み合わせがどんな法的であるというわけではありません。 以下のテーブルはインチベースの解決のための法的な組み合わせと対応する紙サイズ[T.30]を与えます。
+--------------------------------+---------------------------+
| XResolution x YResolution | ImageWidth |
+--------------------------------+---------------------------+
| 100 x 100 | 864 | 1024 | 1216 |
+--------------------------------+---------------------------+
| 200 x 200 | 1728 | 2048 | 2432 |
+--------------------------------+---------------------------+
| 300 x 300 | 2592 | 3072 | 3648 |
+--------------------------------+---------------------------+
| 400 x 400 | 3456 | 4096 | 4864 |
+--------------------------------+---------------------------+
|Letter,A4| B4 | A3 |
| Legal | | |
+---------------------------+
| Paper Size |
+---------------------------+
+--------------------------------+---------------------------+ | XResolution x YResolution| ImageWidth| +--------------------------------+---------------------------+ | 100x100| 864 | 1024 | 1216 | +--------------------------------+---------------------------+ | 200x200| 1728 | 2048 | 2432 | +--------------------------------+---------------------------+ | 300x300| 2592 | 3072 | 3648 | +--------------------------------+---------------------------+ | 400x400| 3456 | 4096 | 4864 | +--------------------------------+---------------------------+ |手紙、A4| B4| A3| | 法的| | | +---------------------------+ | 紙サイズ| +---------------------------+
6.2.2. Extension Fields
6.2.2. 拡大分野
The JPEG compression standard allows for the a*b* chroma components of an image to be subsampled relative to the L* lightness component. The extension fields ChromaSubSampling and ChromaPositioning define the subsampling. They are the same as YCbCrSubSampling and YCbCrPositioning in [TIFF] but have been renamed to reflect their applicability to other color spaces.
JPEG圧縮規格は、イメージのa*b*彩度成分がL*軽さコンポーネントに比例して「副-標本抽出」であることを許容します。 拡大分野のChromaSubSamplingとChromaPositioningは「副-標本抽出」を定義します。 それらは、[TIFF]でYCbCrSubSamplingとYCbCrPositioningと同じですが、他の色の空間への彼らの適用性を反映するために改名されました。
Buckley, et al. Standards Track [Page 49] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[49ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
ChromaSubSampling(530).
SHORT
Count = 2
Specifies the subsampling factors for the chroma components of a
L*a*b* image. The two subfields of this field,
ChromaSubsampleHoriz and ChromaSubsampleVert, specify the
horizontal and vertical subsampling factors respectively.
ChromaSubSampling(530)。 SHORT CountはL*a*b*の彩度成分のための「副-標本抽出」要素が像を描く2Specifiesと等しいです。 この分野の2つの部分体(ChromaSubsampleHorizとChromaSubsampleVert)が、それぞれ水平で垂直な「副-標本抽出」要素を指定します。
SHORT 0: ChromaSubsampleHoriz = 1, 2.
1: equal numbers of lightness and chroma samples horizontally,
2: twice as many lightness samples as chroma samples horizontally,
短い0: ChromaSubsampleHoriz=1、2。 1: 軽さと彩度の数が水平に抽出する2歳の同輩: 彩度が水平に抽出するより2倍の軽さのサンプル
SHORT 1: ChromaSubsampleVert = 1, 2.
1: equal numbers of lightness and chroma samples vertically,
2: twice as many lightness samples as chroma samples vertically,
短い1: ChromaSubsampleVert=1、2。 1: 軽さと彩度の数が垂直に抽出する2歳の同輩: 彩度が垂直に抽出するより2倍の軽さのサンプル
The default value for ChromaSubSampling is (2,2), which is the
default for chroma subsampling in color fax [T.4, Annex E]. No
chroma subsampling, i.e., ChromaSubSampling = (1,1), is an option
for color fax.
ChromaSubSamplingのためのデフォルト値は(2、2)です。(その)はカラーファックス[T.4、Annex E]で彩度「副-標本抽出」のためのデフォルトです)。 彩度「副-標本抽出」でないこと(すなわち、ChromaSubSampling=(1、1))はカラーファックスのためのオプションです。
ChromaPositioning(531) = 1.
SHORT
Specifies the spatial positioning of chroma components relative to
the lightness component.
1: centered, value of 1 means chrominance samples are spatially
offset and centered with respect to luminance samples. See the
current TIFF specification under YcbCr positioning for further
information.
Default = 1, which is what ITU-T T.4, Annex E specifies.
ChromaPositioning(531)=1。 軽さコンポーネントに比例して彩度成分を置く空間的なSHORT Specifies。 1: 中心に置かれて、1の値は、色差のサンプルが空間的に相殺されて、輝度のサンプルに関して中心に置かれることを意味します。 詳細のためのYcbCr位置決めで現在のTIFF仕様を見てください。 デフォルト=1。(その=はどんなITU-T T.4であり、Annex Eが指定するかということです)。
6.2.3. New Fields
6.2.3. 新しい分野
Decode(433).
SRATIONAL
Count = 2 * SamplesPerPixel
Describes how to map image sample values into the range of values
appropriate for the current color space. In general, the values
are taken in pairs and specify the minimum and maximum output
value for each color component. For the base color fax profile,
Decode has a count of 6 values and maps the unsigned ITULAB-
encoded sample values (Lsample, asample, bsample) to signed L*a*b*
values, as follows:
L* = Decode[0] + Lsample x (Decode[1]-Decode[0])/(2^n -1)
a* = Decode[2] + asample x (Decode[3]-Decode[2])/(2^n -1)
b* = Decode[4] + bsample x (Decode[5]-Decode[4])/(2^n -1)
where Decode[0], Decode[2] and Decode[4] are the minimum values
for L*, a*, and b*; Decode[1], Decode[3] and Decode[5] are the
(433)を解読してください。 SRATIONAL Countはイメージを写像するのが現在の色のスペースに、適切な値の範囲に値を抽出する2*SamplesPerPixel Describesと等しいです。 一般に、値は、それぞれのカラー成分に組で取られて、最小の、そして、最大の出力値を指定します。 基調色ファックスプロフィールに関しては、Decodeには、6つの値のカウントがあります、そして、無記名のITULABがコード化した地図は*b*が評価するサインされたL*に値(Lsample、asample、bsample)を抽出します、以下の通りです: 解読してください。L*=が[0]+Lsample xを解読する、(解読、[1] -解読してください、[0]) /(2^n-1)a*=が[2]+asample xを解読する、(解読、[3] -解読してください、[2]) /(2^n-1)b*=が[4]+bsample xを解読する、([5] -L*、*、およびb*のために、Decode[0]、Decode[2]、およびDecode[4]が最小の値であるところで[4]) /(2^n-1)を解読してください。 Decode[3]、[1]を解読してください。そうすれば、Decode[5]は解読します。
Buckley, et al. Standards Track [Page 50] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[50ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
maximum values for L*, a*, and b*; and n is the BitsPerSample.
When n=8,=20 L*=Decode[0] when Lsample=0 and L*=Decode[1] when
Lsample=255.
L*、*、およびb*のための最大の値。 そして、nはBitsPerSampleです。 n=8であるときに、[0] [1] Lsample=255であるときに、Lsample=0とL*=が解読するとき、=20L*=は解読します。
ITU-T Rec. T.42 specifies the ITULAB encoding in terms of a range and offset for each component, which are related to the minimum and maximum values as follows:
ITU-T Rec。 T.42は各コンポーネントのために範囲に関してコード化して、相殺するITULABを指定します:(ITULABは以下の最小の、そして、最大の値に関連します)。
minimum = - (range x offset) / 2^n - 1
maximum = minimum + range
最小限=--(範囲xは相殺されました)/2^n--1最大の=最小限+範囲
The Decode field default values depend on the color space. For the ITULAB color space encoding, the default values correspond to the base range and offset, as specified in ITU-T Rec. T.42 [T.42]. The following table gives the base range and offset values for BitsPerSample=8, and the corresponding default minimum and maximum default values for the Decode field, calculated using the equations above when PhotometricInterpetation=10.
Decode分野デフォルト値は色のスペースに依存します。 ITULAB色のスペースコード化のために、デフォルト値は、ベースの範囲に対応している、相殺されます、ITU-T Recで指定されるように。 T.42[T.42]。 以下のテーブルはBitsPerSample=8、およびPhotometricInterpetation=10であるときに最小の、そして、最大のデフォルトが上で方程式を使用することで計算されたDecode分野に評価する対応するデフォルトのためにベースの範囲とオフセット値を与えます。
Refer to ITU-T Rec. T.42 [T.42] to calculate the range and offset, and hence the minimum and maximum values, for other BitsPerSample values.
ITU-T Recを参照してください。 範囲について計算して、相殺するT.42[T.42]、およびしたがって、他のBitsPerSample値のための最小の、そして、最大の値。
+-----------------------------------------------+
| ITU-T Rec. T.42 | Decode |
+---------+-----------| base values | default values |
| BitsPer + Component +------------------+----------------------------+
| -Sample | | Range | Offset | Min | Max |
+---------+-----------+--------+---------+--------------+-------------+
| 8 | L* | 100 | 0 | 0 | 100 |
| +-----------+--------+---------+--------------+-------------+
| | a* | 170 | 128 | -21760/255 | 21590/255 |
| +-----------+--------+---------+--------------+-------------+
| | b* | 200 | 96 | -19200/255 | 31800/255 |
+---------+-----------+--------+---------+--------------+-------------+
+-----------------------------------------------+ | ITU-T Rec。 T.42| 解読してください。| +---------+-----------| 基礎点| デフォルト値| | BitsPer+コンポーネント+------------------+----------------------------+ | -サンプル| | 範囲| 相殺されます。| 分| マックス| +---------+-----------+--------+---------+--------------+-------------+ | 8 | L*| 100 | 0 | 0 | 100 | | +-----------+--------+---------+--------------+-------------+ | | *| 170 | 128 | -21760/255 | 21590/255 | | +-----------+--------+---------+--------------+-------------+ | | b*| 200 | 96 | -19200/255 | 31800/255 | +---------+-----------+--------+---------+--------------+-------------+
For example, when PhotometricInterpretation=10 and BitsPerSample=8, the default value for Decode is (0, 100, -21760/255, 21590/255, -19200/255, 31800/255). For guidelines on the use of the Decode field, see section 5.2.2 of [GUIDE].
PhotometricInterpretation=10とBitsPerSample=8であるときに、例えば、Decodeのためのデフォルト値は(0、100、-21760/255、21590/255、-19200/255、31800/255)です。 Decode分野の使用に関するガイドラインに関しては、[ガイド]についてセクション5.2.2を見てください。
Buckley, et al. Standards Track [Page 51] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[51ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
6.3. Recommended TIFF Fields
6.3. お勧めのいさかい分野
See Sections 2.2.3. and 2.2.4.
セクション2.2.3 2.2.4を見てください。
6.4. Profile C: Base Color Fax Profile Summary
6.4. プロフィールC: 基調色ファックスプロフィール概要
Recommended fields are shown with an asterisk (*).
お勧めの分野はアスタリスク(*)で示されます。
Required fields or values are shown with a double asterisk (**). If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisk is in the Values column, then only the values suffixed with a double asterisk are required of implementations.
必須項目か値が二重アスタリスク(**)で示されます。 二重アスタリスクがフィールド名にあるなら、実現はすべての記載された値に要求されます。 二重アスタリスクがValuesコラムにあるなら、実現は二重アスタリスクでsuffixedされた値だけに要求されます。
+---------------------------+--------------------------------+
| Baseline Fields | Values |
+---------------------------+--------------------------------+
| BitsPerSample | 8**: 8 bits per color sample |
+---------------------------+--------------------------------+
| Compression** | 7: JPEG |
+---------------------------+--------------------------------+
| DateTime* | {ASCII}: date/time in 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+---------------------------+--------------------------------+
| FillOrder** | 1: most significant bit first |
| | 2: least significant bit first |
+---------------------------+--------------------------------+
| ImageDescription* | {ASCII}: A string describing |
| | the contents of the image |
+---------------------------+--------------------------------+
| ImageWidth | 864, 1024, 1216, 1728**, 2048 |
| | 2432, 2592, 3072, 3456, 3648 |
| | 4096, 4864 |
+---------------------------+--------------------------------+
| ImageLength** | n: total number of scanlines |
| | in image |
+---------------------------+--------------------------------+
| NewSubFileType** | 2: Bit 1 identifies single page|
| | of a multi-page document |
+---------------------------+--------------------------------+
| Orientation | 1**-8, Default 1 |
+---------------------------+--------------------------------+
+---------------------------+--------------------------------+ | 基線分野| 値| +---------------------------+--------------------------------+ | BitsPerSample| 8**: 1色見本あたり8ビット| +---------------------------+--------------------------------+ | 圧縮**| 7: JPEG| +---------------------------+--------------------------------+ | DateTime*| ASCII: 24時間で日付/時間| | | 形式「YYYY:mm:DD HH:mm:SS」| +---------------------------+--------------------------------+ | FillOrder**| 1: 最上位ビット、最初に。| | | 2: 最下位ビット、最初に。| +---------------------------+--------------------------------+ | ImageDescription*| ASCII: 五弦説明| | | イメージのコンテンツ| +---------------------------+--------------------------------+ | ImageWidth| 864, 1024, 1216, 1728**, 2048 | | | 2432, 2592, 3072, 3456, 3648 | | | 4096, 4864 | +---------------------------+--------------------------------+ | ImageLength**| n: 総数の走査線| | | イメージで| +---------------------------+--------------------------------+ | NewSubFileType**| 2: ビット1は1ページを特定します。| | | マルチページドキュメントについて| +---------------------------+--------------------------------+ | オリエンテーション| 1**-8、デフォルト1| +---------------------------+--------------------------------+
Buckley, et al. Standards Track [Page 52] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[52ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+------------------------------------------------------------+
| PhotometricInterpretation | 10**: ITULAB |
+---------------------------+--------------------------------+
| ResolutionUnit** | 2: inch |
+---------------------------+--------------------------------+
| RowsPerStrip** | n: number of scanlines per |
| | TIFF strip |
+---------------------------+--------------------------------+
| SamplesPerPixel | 1**: L* (lightness) |
| | 3: LAB |
+---------------------------+--------------------------------+
| Software* | {ASCII}: name & release number |
| | of creator software |
+---------------------------+--------------------------------+
| StripByteCounts** | <n>: number or bytes in |
| | TIFF strip |
+---------------------------+--------------------------------+
| StripOffsets** | <n>: offset from beginning |
| | of file to each TIFF strip |
+---------------------------+--------------------------------+
| XResolution | 100, 200**, 300, 400 (written |
| | in pixels/inch) |
+---------------------------+--------------------------------+
| YResolution | 100, 200**, 300, 400 |
| | (must equal XResolution) |
+---------------------------+--------------------------------+
| Extension Fields |
+---------------------------+--------------------------------+
| DocumentName* | {ASCII}: name of scanned |
| | document |
+---------------------------+--------------------------------+
| PageNumber** | n,m: page number followed by |
| | total page count |
+---------------------------+--------------------------------+
| ChromaSubSampling | (1,1), (2, 2)** |
| | (1, 1): equal numbers of |
| | lightness and chroma samples |
| | horizontally and vertically |
| | (2, 2): twice as many lightness|
| | samples as chroma samples |
| | horizontally and vertically |
+---------------------------+--------------------------------+
| ChromaPositioning | 1**: centered |
+------------------------------------------------------------+
+------------------------------------------------------------+ | PhotometricInterpretation| 10**: ITULAB| +---------------------------+--------------------------------+ | ResolutionUnit**| 2: インチ| +---------------------------+--------------------------------+ | RowsPerStrip**| n: 走査線の数| | | TIFF片| +---------------------------+--------------------------------+ | SamplesPerPixel| 1**: L*(軽さ)| | | 3: 研究室| +---------------------------+--------------------------------+ | ソフトウェア*| ASCII: 数を命名して、リリースしてください。| | | 創造者ソフトウェアについて| +---------------------------+--------------------------------+ | StripByteCounts**| <n>: 数か中のバイト| | | TIFF片| +---------------------------+--------------------------------+ | StripOffsets**| <n>: 始めから、相殺されます。| | | それぞれのTIFF片へのファイルについて| +---------------------------+--------------------------------+ | XResolution| 100、200**、300、400(| | | コネに画素/インチを書きます)| +---------------------------+--------------------------------+ | YResolution| 100, 200**, 300, 400 | | | (XResolutionと等しくなければなりません) | +---------------------------+--------------------------------+ | 拡大分野| +---------------------------+--------------------------------+ | DocumentName*| ASCII: スキャンされることの名前| | | ドキュメント| +---------------------------+--------------------------------+ | PageNumber**| n、m: 従われたページ番号| | | 総ページ数| +---------------------------+--------------------------------+ | ChromaSubSampling| (1,1), (2, 2)** | | | (1, 1): 数と等しいです。| | | 軽さと彩度のサンプル| | | 水平で垂直に| | | (2, 2): 2倍の軽さ| | | 彩度のサンプルとしてのサンプル| | | 水平で垂直に| +---------------------------+--------------------------------+ | ChromaPositioning| 1**: 中心に置かれます。| +------------------------------------------------------------+
Buckley, et al. Standards Track [Page 53] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[53ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+---------------------------+--------------------------------+ | New Fields | +---------------------------+--------------------------------+ | Decode** | minL, maxL, mina, maxa, minb, | | | maxb: minimum and maximum | | | values for L*a*b* | +---------------------------+--------------------------------+ | GlobalParametersIFD* | IFD: IFD containing | | | global parameters | +---------------------------+--------------------------------+ | ProfileType* | n: type of data stored in | | | TIFF file | +---------------------------+--------------------------------+ | FaxProfile* | n: ITU-compatible fax profile | +---------------------------+--------------------------------+ | CodingMethods* | n: compression algorithms | | | used in file | +---------------------------+--------------------------------+ | VersionYear* | byte sequence: year of ITU std | +---------------------------+--------------------------------+
+---------------------------+--------------------------------+ | 新しい分野| +---------------------------+--------------------------------+ | **を解読してください。| minL、maxL、mina、maxa、minb| | | maxb: 最小であって、最大です。| | | L*のために、*b*を評価します。| +---------------------------+--------------------------------+ | GlobalParametersIFD*| IFD: IFD含有| | | グローバルなパラメタ| +---------------------------+--------------------------------+ | ProfileType*| n: 中に格納されたデータのタイプ| | | TIFFファイル| +---------------------------+--------------------------------+ | FaxProfile*| n: ITUコンパチブルファックスプロフィール| +---------------------------+--------------------------------+ | CodingMethods*| n: 圧縮アルゴリズム| | | ファイルでは、使用されます。| +---------------------------+--------------------------------+ | VersionYear*| バイト列: ITU stdの年| +---------------------------+--------------------------------+
7. Profile L: Lossless Color Profile
7. プロフィールL: Losslessカラープロフィール
This section defines the lossless color profile of TIFF for facsimile, designated Profile L. Implementations of this profile are required to also implement Profiles S and C as well.
このセクションはファクシミリのためにTIFFのlosslessカラープロフィールを定義します、また、このプロフィールの指定されたProfile L.ImplementationsがProfiles Sとまた、Cを実行しなければなりません。
7.1. Overview
7.1. 概観
This profile, specified in [T.43] and [T.4] Annex G, uses JBIG to code three types of color and grayscale images losslessly: one bit per color CMY, CMYK, and RGB images; a palettized (i.e., mapped) color image; and continuous tone color and grayscale images. The last two are multi-level and use the L*a*b* encoding specified in [T.42].
この[T.43]と[T.4]別館Gで指定されたプロフィールはlosslesslyに3つのタイプの色とグレースケールイメージをコード化するのにJBIGを使用します: カラーCMYあたり1ビット、CMYK、およびRGBイメージ。 palettizedされた(すなわち、写像される)カラーイメージ。 連続した音色とグレースケールイメージ。 最後の2は、マルチレベルであり、*b*コード化が[T.42]で指定したL*を使用します。
7.1.1. Color Encoding
7.1.1. カラー符号化
While under development, ITU-T Rec. T.43 was called T.Palette, as one of its major additions was palettized color images. Baseline TIFF only allows RGB color maps, but ITU-T Rec. T.43 requires L*a*b* color maps, using the encoding specified in ITU-T Rec. T.42. Palette color images are expressed with indices (bits per sample) of 12 bits or less, or optionally 13 to 16 bits, per [T.43] and Annex G in [T.4]. Profile L files use the color table in the T.43 data stream rather than the TIFF ColorMap field.
開発中である間、ITU-T Recです。 T.43は、主要な追加の1つがpalettizedカラーイメージであったので、T.Paletteと呼ばれました。 基線TIFFはRGBカラー地図、しかし、ITU-T Recを許容するだけです。 ITU-T Recで指定されたコード化を使用して、T.43は*b*色が写像するL*を必要とします。 T.42。 パレットカラーイメージは12ビット以下のインデックスリスト(1サンプルあたりのビット)で任意に13〜16ビット言い表されます、[T.4]の[T.43]とAnnex G単位で。 プロフィールLファイルはTIFF ColorMap分野よりむしろT.43データ・ストリームにカラーテーブルを使用します。
Buckley, et al. Standards Track [Page 54] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[54ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Enabling T.43 color maps in TIFF requires the extension field Indexed, as defined in [TTN1], and the PhotometricInterpretation field value 10, as defined in Section 6.2.1. The following table shows the corresponding PhotometricInterpretation, SamplesPerPixel, BitsPerSample, and Indexed field values for the different T.43 image types.
TIFFのT.43カラー地図を可能にするのは拡大分野Indexedを必要とします、[TTN1]、およびPhotometricInterpretation分野価値10で定義されるように、セクション6.2.1で定義されるように。 以下のテーブルは異なったT.43イメージタイプのために対応するPhotometricInterpretation、SamplesPerPixel、BitsPerSample、およびIndexedに分野値を示しています。
+----------------------------------------------------------+ | Image Type |PhotometricIn| Samples | Bits Per | Indexed | | |-terpretation| Per Pixel| Sample | | |------------+-------------+----------+----------+---------| | RGB | 2=RGB | 3 | 1 | 0 | +----------------------------------------------------------+ | CMY | 5=CMYK | 3 | 1 | 0 | +------------+-------------+----------+----------+---------+ | CMYK | 5=CMYK | 4 | 1 | 0 | +------------+-------------+----------+----------+---------+ | Palette | 10=ITULAB | 1 | n | 1 | +------------+-------------+----------+----------+---------+ | Grayscale | 10=ITULAB | 1 |2-8, 9-12 | 0 | +------------+-------------+----------+----------+---------+ | Color | 10=ITULAB | 3 |2-8, 9-12 | 0 | +------------+-------------+----------+----------+---------+
+----------------------------------------------------------+ | イメージタイプ|PhotometricIn| サンプル| ビット| 索引をつけられます。| | |-terpretation| 1画素単位で| サンプル| | |------------+-------------+----------+----------+---------| | RGB| 2=RGB| 3 | 1 | 0 | +----------------------------------------------------------+ | CMY| 5=CMYK| 3 | 1 | 0 | +------------+-------------+----------+----------+---------+ | CMYK| 5=CMYK| 4 | 1 | 0 | +------------+-------------+----------+----------+---------+ | パレット| 10=ITULAB| 1 | n| 1 | +------------+-------------+----------+----------+---------+ | グレースケール| 10=ITULAB| 1 |2-8, 9-12 | 0 | +------------+-------------+----------+----------+---------+ | 色| 10=ITULAB| 3 |2-8, 9-12 | 0 | +------------+-------------+----------+----------+---------+
7.1.2. JBIG Compression
7.1.2. JBIG圧縮
T.43 uses the single-progression sequential mode of JBIG, defined in ITU-T Rec. T.82. (Other compression methods are for further study.) To code multi-level images using JBIG, which is a bi-level compression method, an image is resolved into a set of bit-planes, and each bit-plane is then JBIG compressed. For continuous-tone color and grayscale images, Gray code conversion is used. The Gray code conversion is part of the data-stream encoding and is therefore invisible to TIFF.
T.43はITU-T Recで定義されたJBIGのただ一つの進行順序配列モデルを使用します。 T.82。 (さらなる研究には他の圧縮方法があります。) JBIGを使用することでマルチレベルイメージをコード化するために、イメージは1セットのビット飛行機に変えられます、そして、そして、それぞれのビット飛行機は圧縮されたJBIGです。JBIGは両性愛者のレベル圧縮方法です。 連続した音色とグレースケールイメージに関しては、グレーコード変換は使用されています。 グレーコード変換は、データ・ストリームコード化の一部であり、したがって、TIFFに目に見えません。
7.2. Required TIFF Fields
7.2. 必要ないさかい分野
This section lists the required fields, in addition to those in Section 2.2.1, and the values they must have to be compatible with ITU-T Rec. T.43.
このセクションは必須項目を記載します、セクション2.2.1におけるそれら、およびそれらがITU-T Recと互換性があるように持たなければならない値に加えて。 T.43。
Buckley, et al. Standards Track [Page 55] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[55ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
7.2.1. Baseline Fields
7.2.1. 基線分野
ImageWidth(256).
SHORT or LONG
Same page widths as the base color profile; see Section 6.2.1.
NewSubFileType(254) = (Bit 1=1).
LONG
RequiredByTIFFforFAX
Bit 1 is 1 if the image is a single page of a multi-page document.
Default = 0 (no subfile bits on, so may not be omitted for fax).
ImageWidth(256)。 基調色としての幅が輪郭を描くSHORTかLONG Sameページ。 セクション6.2.1を見てください。 NewSubFileType(254)は(ビット1=1)と等しいです。 イメージがマルチページドキュメントの1ページであるなら、LONG RequiredByTIFFforFAX Bit1は1歳です。 デフォルト=0、(いいえがビットを副ファイルするので省略されないかもしれない、ファックス)
BitsPerSample(258) = 1, 2 - 8, 9 - 12.
SHORT
Count = SamplesPerPixel
RGB, CMY, CMYK: 1 bit per sample
Continuous tone (L*a*b*): 2 - 8 bits per sample, 9 - 12 bits
optional. Palette color: 12 or fewer bits per sample.
Note: More than 8 bits per sample is not baseline TIFF.
BitsPerSample(258)=1、2--8、9--12。 短いカウントはSamplesPerPixel RGB、CMY、CMYKと等しいです: サンプルContinuousあたり1ビット、調子を変えてください(L*a*b*): サンプル、9--12ビットあたり任意の2--8ビット。 パレット色: 1サンプルあたりの12か、より少ないビット。 以下に注意してください。 1サンプルあたり8ビット以上は基線TIFFではありません。
Compression(259) = 10.
SHORT
10: ITU-T Rec. T.43 representation, using ITU-T Rec. T.82 (JBIG)
coding
圧縮(259)=10。 短い10: ITU-T Rec。 ITU-T Recを使用するT.43表現。 T.82(JBIG)コード化
FillOrder(266) = 1 , 2.
SHORT
RequiredByTIFFBaseline
Profile L readers must be able to read data in both bit orders,
but the vast majority of facsimile products store data LSB
first, exactly as it appears on the telephone line.
1 = Most Significant Bit first.
2 = Least Significant Bit first.
FillOrder(266)=1、2。 SHORT RequiredByTIFFBaseline Profile L読者は両方の噛み付いている命令でデータを読むことができなければなりませんが、かなりの大多数のファクシミリ製品は最初にデータLSBを格納します、ちょうど電話回線の上に現れるように。 1は最初に、ほとんどのSignificant Bitと等しいです。 2は最初に、最少のSignificant Bitと等しいです。
PhotometricInterpretation(262) = 2, 5, 10.
SHORT
2: RGB
5: CMYK, including CMY
10: ITULAB
Image data may also be stored as palette-color images, where pixel
values are represented by a single component that is an index into
a color map using the ITULAB encoding. This color map is
specified by the color palette table embedded in the image data
stream. To use palette-color images, set the
PhotometricInterpretation to 10, SamplesPerPixel to 1, Indexed to
1, and use the color map in the data stream. See Section 7.1.1
for discussion of the color encoding.
PhotometricInterpretation(262)=2、5、10。 短い2: RGB5: CMY10を含んでいるCMYK また、ITULAB Imageデータはパレットカラーイメージとして格納されるかもしれません。そこでは、ピクセル値が、カラー地図へのインデックスであるただ一つのコンポーネントによってITULABコード化を使用することで表されます。 このカラー地図はイメージデータ・ストリームに埋め込まれたカラーパレットテーブルによって指定されます。 パレットカラーイメージを使用するために、10へのPhotometricInterpretation、1へのSamplesPerPixel、1へのIndexedを設定してください、そして、データ・ストリームにカラー地図を使用してください。 カラー符号化の議論に関してセクション7.1.1を見てください。
Buckley, et al. Standards Track [Page 56] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[56ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
ResolutionUnit(296) = 2.
SHORT
The unit of measure for resolution. 2 = inch.
ITU-T standards only specify inch-based resolutions for color fax.
Default = 2 (field may be omitted if this is the value).
ResolutionUnit(296)=2。 SHORT、解決のための測定の単位。 2はインチと等しいです。 ITU-T規格はカラーファックスのためのインチベースの解決を指定するだけです。 デフォルト=2(分野はこれが値であるなら省略されるかもしれません)。
SamplesPerPixel(277) = 1, 3, 4.
SHORT
1: Palette-color image, or L*-only if Indexed = 0 and
PhotometricInterpretation is 10 (ITULAB).
3: RGB, or L*a*b*, or CMY if PhotometricInterpretation is 5
(CMYK).
4: CMYK.
SamplesPerPixel(277)=1、3、4。 短い1: イメージをパレットで着色してください。さもないと、Indexedが0とPhotometricInterpretationと等しいなら、唯一のL*は10(ITULAB)です。 3: L*のRGB、*b*、またはCMY、PhotometricInterpretationが5歳(CMYK)であるなら。 4: CMYK。
XResolution(282) = 100, 200, 300, 400.
RATIONAL
YResolution(283) = 100, 200, 300, 400.
RATIONAL
The resolution of the image is expressed in pixels per resolution
unit. In pixels per inch, allowed XResolution values are 100,
200, 300, and 400. The lossless color fax profile requires the
pixels to be square, hence YResolution must equal XResolution.
Base resolution is 200 pixels per inch.
XResolution(282)=100、200、300、400。 合理的なYResolution(283)=100、200、300、400。 RATIONAL、イメージの解像度は解決ユニットあたりの画素で言い表されます。 ピクセル・パー・インチでは、XResolution値が許容されているのは、100と、200と、300と、400です。 losslessカラーファックスプロフィールは、画素が正方形であることを必要とします、したがって、YResolutionがXResolutionと等しくなければなりません。 基地の解決は200ピクセル・パー・インチです。
7.2.2. Extension Fields
7.2.2. 拡大分野
Indexed(346) = 0, 1.
SHORT
0: not a palette-color image.
1: palette-color image.
This field is used to indicate that each sample value is an index
into an array of color values specified in the image data stream.
Because the color map is embedded in the image data stream, the
ColorMap field is not used in Profile L. Lossless color fax
profile supports palette-color images with the ITULAB encoding.
The SamplesPerPixel value must be 1.
(346) =0、1に索引をつけました。 短い0: パレットカラーイメージでない。 1: パレットカラーイメージ。 この分野は、各標本値がイメージデータ・ストリームで指定された色の値の勢ぞろいへのインデックスであることを示すのに使用されます。 カラー地図がイメージデータ・ストリームに埋め込まれているので、ColorMap分野はProfile L.で使用されません。LosslessはITULABコード化でファックスプロフィールサポートをパレットカラーイメージに着色します。 SamplesPerPixel値は1でなければなりません。
7.2.3. New Fields
7.2.3. 新しい分野
Decode(433)
SRATIONAL
Decode is used in connection with the ITULAB encoding of image
data; see Section 6.2.3.
イメージデータのITULABコード化に関して(433) 使用されるSRATIONAL Decodeを解読してください。 セクション6.2.3を見てください。
7.3. Recommended TIFF Fields
7.3. お勧めのいさかい分野
See Sections 2.2.3. and 2.2.4.
セクション2.2.3 2.2.4を見てください。
Buckley, et al. Standards Track [Page 57] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[57ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
7.4. Profile L: Lossless Color Fax Profile Summary
7.4. プロフィールL: Lossless色のファックスプロフィール概要
Recommended fields are shown with an asterisk (*).
お勧めの分野はアスタリスク(*)で示されます。
Required fields or values are shown with a double asterisk (**). If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisks are in the Values column, then only the values suffixed with a double asterisk are required of implementations.
必須項目か値が二重アスタリスク(**)で示されます。 二重アスタリスクがフィールド名にあるなら、実現はすべての記載された値に要求されます。 二重アスタリスクがValuesコラムにあるなら、実現は二重アスタリスクでsuffixedされた値だけに要求されます。
+--------------------+--------------------------------------+
| Baseline Fields | Values |
+--------------------+--------------------------------------+
| BitsPerSample | 1: Binary RGB, CMY(K) |
| | 8**: 8 bits per color sample |
| | 9 - 12: optional |
+--------------------+--------------------------------------+
| Compression | 10**: JBIG, per T.43 |
+--------------------+--------------------------------------+
| DateTime* | {ASCII}: date/time in the 24-hour |
| | format "YYYY:MM:DD HH:MM:SS" |
+--------------------+--------------------------------------+
| FillOrder** | 1: Most significant bit first |
| | 2: Least significant bit first |
+--------------------+--------------------------------------+
| ImageDescription* | {ASCII}: A string describing the |
| | contents of the image |
+--------------------+--------------------------------------+
| ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, |
| | 2592, 3072, 3456, 3648, 4096, 4864 |
+--------------------+--------------------------------------+
| ImageLength** | n: total number of scanlines in image|
+--------------------+--------------------------------------+
| NewSubFileType | 2**: Bit 1 identifies single page of |
| | a multi-page document |
+--------------------+--------------------------------------+
+--------------------+--------------------------------------+ | 基線分野| 値| +--------------------+--------------------------------------+ | BitsPerSample| 1: 2進のRGB、CMY(K)| | | 8**: 1色見本あたり8ビット| | | 9 - 12: 任意| +--------------------+--------------------------------------+ | 圧縮| 10**: 1T.43あたりのJBIG| +--------------------+--------------------------------------+ | DateTime*| ASCII: 24時間で日付/時間| | | 形式「YYYY:mm:DD HH:mm:SS」| +--------------------+--------------------------------------+ | FillOrder**| 1: 最上位ビット、最初に。| | | 2: 最下位ビット、最初に。| +--------------------+--------------------------------------+ | ImageDescription*| ASCII: 五弦説明| | | イメージのコンテンツ| +--------------------+--------------------------------------+ | ImageWidth| 864, 1024, 1216, 1728**, 2048, 2432, | | | 2592, 3072, 3456, 3648, 4096, 4864 | +--------------------+--------------------------------------+ | ImageLength**| n: イメージによる総数の走査線| +--------------------+--------------------------------------+ | NewSubFileType| 2**: 1が1ページを特定するビット| | | マルチページドキュメント| +--------------------+--------------------------------------+
Buckley, et al. Standards Track [Page 58] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[58ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+--------------------+--------------------------------------+
| Orientation | 1**-8, Default 1 |
+--------------------+--------------------------------------+
| PhotometricInter- | 2: RGB |
| pretation | 5: CMYK |
| | 10**: ITULAB |
+--------------------+--------------------------------------+
| ResolutionUnit** | 2: inch |
+--------------------+--------------------------------------+
| RowsPerStrip** | n: number of scanlines per TIFF strip|
+--------------------+--------------------------------------+
| SamplesPerPixel | 1**: L* (lightness) |
| | 3: LAB, RGB, CMY |
| | 4: CMYK |
+--------------------+--------------------------------------+
| Software* | {ASCII}: name & release number of |
| | creator software |
+--------------------+--------------------------------------+
| StripByteCounts** | <n>: number or bytes in TIFF strip |
+--------------------+--------------------------------------+
| StripOffsets** | <n>: offset from beginning of file to|
| | each TIFF strip |
+--------------------+--------------------------------------+
| XResolution | 100, 200**, 300, 400 (pixels/inch) |
+--------------------+--------------------------------------+
| YResolution | equal to XResolution (pixels must be |
| | square) |
+--------------------+--------------------------------------+
| Extension Fields |
+--------------------+--------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+--------------------+--------------------------------------+
| PageNumber** | n,m: page number followed by total |
| | page count |
+--------------------+--------------------------------------+
| Indexed | 0: not a palette-color image |
| | 1: palette-color image |
+--------------------+--------------------------------------+
| New Fields |
+--------------------+--------------------------------------|
| Decode | minL, maxL, mina, maxa, minb, maxb: |
| | minimum and maximum values for L*a*b*|
+--------------------+--------------------------------------+
| GlobalParameters | IFD: global parameters IFD |
| IFD* | |
+-----------------------------------------------------------+
+--------------------+--------------------------------------+ | オリエンテーション| 1**-8、デフォルト1| +--------------------+--------------------------------------+ | PhotometricInter| 2: RGB| | pretation| 5: CMYK| | | 10**: ITULAB| +--------------------+--------------------------------------+ | ResolutionUnit**| 2: インチ| +--------------------+--------------------------------------+ | RowsPerStrip**| n: TIFF片あたりの走査線の数| +--------------------+--------------------------------------+ | SamplesPerPixel| 1**: L*(軽さ)| | | 3: 研究室、RGB、CMY| | | 4: CMYK| +--------------------+--------------------------------------+ | ソフトウェア*| ASCII: 数を命名して、リリースします。| | | 創造者ソフトウェア| +--------------------+--------------------------------------+ | StripByteCounts**| <n>: TIFF片の中の数かバイト| +--------------------+--------------------------------------+ | StripOffsets**| <n>: ファイルの始まりから、相殺します。| | | それぞれのTIFF片| +--------------------+--------------------------------------+ | XResolution| 100、200**、300、400(画素/インチ)| +--------------------+--------------------------------------+ | YResolution| XResolutionと等しさ、(画素、| | | 正方形でなければならない、)| +--------------------+--------------------------------------+ | 拡大分野| +--------------------+--------------------------------------+ | DocumentName*| ASCII: スキャンした文書の名前| +--------------------+--------------------------------------+ | PageNumber**| n、m: 合計があとに続いたページ番号| | | ページ数| +--------------------+--------------------------------------+ | 索引をつけられます。| 0: パレットカラーイメージでない| | | 1: パレットカラーイメージ| +--------------------+--------------------------------------+ | 新しい分野| +--------------------+--------------------------------------| | 解読してください。| minL、maxL、mina、maxa、minb、maxb: | | | 最小限と最大はL*のために*b*を評価します。| +--------------------+--------------------------------------+ | GlobalParameters| IFD: グローバルなパラメタIFD| | IFD*| | +-----------------------------------------------------------+
Buckley, et al. Standards Track [Page 59] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[59ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+--------------------+--------------------------------------+ | ProfileType* | n: type of data stored in TIFF file | +--------------------+--------------------------------------+ | FaxProfile* | n: ITU-compatible fax profile | +--------------------+--------------------------------------+ | CodingMethods* | n: compression algorithms used in | | | file | +--------------------+--------------------------------------+ | VersionYear* | byte sequence: year of ITU fax std | +--------------------+--------------------------------------+
+--------------------+--------------------------------------+ | ProfileType*| n: TIFFに格納されたデータのタイプはファイルします。| +--------------------+--------------------------------------+ | FaxProfile*| n: ITUコンパチブルファックスプロフィール| +--------------------+--------------------------------------+ | CodingMethods*| n: 中で使用された圧縮アルゴリズム| | | ファイル| +--------------------+--------------------------------------+ | VersionYear*| バイト列: ITUファックスstdの年| +--------------------+--------------------------------------+
8. Profile M: Mixed Raster Content Profile
8. プロフィールM: Mixedラスタ内容プロフィール
This section defines the Mixed Raster Content profile of TIFF for facsimile, designated Profile M. Implementations of this profile are required to implement Profiles S and C and may optionally implement Profiles F, J and L.
このセクションがファクシミリのためにTIFFのMixed Raster Contentプロフィールを定義して、このプロフィールの指定されたProfile M.ImplementationsはProfiles SとCを実行するのが必要であり、任意にProfiles F、J、およびLを実行するかもしれません。
8.1. Overview
8.1. 概観
Unlike previous fax profiles, which use a single coding method and resolution for an entire fax page, Mixed Raster Content [T.44] enables different coding methods and resolutions within a single page. For example, consider a page that contains black-and-white text, which is best coded with MMR or JBIG; a color bar chart, best coded with JBIG; and a scanned color image, best coded with JPEG. Similarly, although spatial resolution of 400 pixels per inch may be best for the black-and-white text, 200 pixels per inch is usually sufficient for a color image.
前のファックスプロフィールと異なって、Mixed Raster Content[T.44]は1ページ以内で異なったコード化方法と解決を可能にします。プロフィールは全体のファックスページにただ一つのコード化方法と解決を使用します。 例えば、MMRかJBIGと共に最も良いコード化する白黒のテキストを含む1ページを考えてください。 JBIGと共に最もよくコード化された白人と有色人との差別図。 そして、JPEGと共に最もよくコード化されたスキャンされたカラーイメージ。 同様に、白黒のテキストに、400ピクセル・パー・インチの空間分解能は最も良いかもしれませんが、通常、200個のピクセル・パー・インチがカラーイメージに十分です。
Rather than applying one coding method and resolution to all elements, MRC allows multiple coders and resolutions within a page. By itself, MRC does not define any new coding methods or resolutions. Instead it defines a 3-layer image model for structuring and combining the scanned image data. The MRC 3-layer model has been applied here with the TIFF format to yield a data structure that differs from [T.44], though it applies the same coding methods, uses the same compressed image data streams, and is consistent with the TIFF principle of a single IFD per image.
すべての要素への1つのコード化方法と解決を適用するよりむしろ、MRCは1ページ以内で複数の符号化器と解決を許します。 MRC自身はどんな新しいコード化方法や解決も定義しません。 代わりに、それは、スキャンされたイメージデータを構造化して、結合するために3層のイメージモデルを定義します。 MRC、3階層モデル、TIFF形式でここに適用されて、それが同じコード化方法を適用して、同じ圧縮画像データ・ストリームを使用して、1イメージあたり1独身のIFDのTIFF本質と一致していますが、[T.44]と異なっているデータ構造をもたらしました。
8.1.1. MRC 3-layer model
8.1.1. MRC、3階層モデル
The 3 layers of the MRC model are Foreground and Background, which are both multi-level, and Mask, which is bi-level. Each layer may appear only once on a page and is coded independently of the other two layers. The final image is obtained by using the Mask layer to determine whether output pixels come from the Foreground layer or the Background layer. When the Mask layer pixel value is 1, the
MRCモデルの3つの層が、ForegroundとBackgroundです。(そのBackgroundはマルチレベルとMaskの両方です)。(Maskは両性愛者のレベルです)。 各層は、1ページに一度だけ現れるかもしれなくて、他の2つの層の如何にかかわらずコード化されます。 出力画素がForeground層かBackground層から来るかどうか決定するのにMask層を使用することによって、最終的なイメージを得ます。 Maskが層にするとき、ピクセル値は1です。
Buckley, et al. Standards Track [Page 60] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[60ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
corresponding pixel from the Foreground layer is selected; when it is 0, the corresponding pixel from the Background layer is selected. Details are given in the Introduction of [T.44].
Foreground層からの対応する画素は選択されます。 それが0であるときに、Background層からの対応する画素は選択されます。 Introductionで[T.44]を詳細に与えます。
In our earlier example, the shape of the black-and-white text and the mask for the color chart could be in the Mask layer, the color of the chart and text in the Foreground layer, and the color image in the Background layer. If a Mask layer pixel has a value of 1, the final image pixel will be, depending on the pixel location, from either the color chart or text color in the Foreground layer. If a Mask layer pixel has a value of 0, the final image pixel will be from the color image in the Background layer.
私たちの以前の例には、Background層の中に白黒のテキストの形とカラーチャートのためのマスクがMask層と図の色とForeground層、およびカラーイメージにおけるテキストにあるかもしれません。 最終的なイメージ画素はそうになるでしょう、画素位置によって、Mask層の画素に1の値があるなら、Foreground層のカラーチャートかテキスト色から、持っています。 Mask層の画素に0の値があると、最終的なイメージ画素はBackground層の中でカラーイメージから来ているでしょう。
Each layer is an image and, when present, is represented by at least one IFD in a TIFF file. This is consistent with TIFF, which provides fields to define the attributes, such as resolution, image size, bits per sample, etc., of a single image or layer. The distribution of content among layers is determined by the writer, as is the choice of coding method, color encoding, and spatial resolution for a layer.
各層は、イメージであり、存在しているとき、TIFFファイルの少なくとも1IFDによって表されます。 これはTIFFと一致しています、解決、画像寸法、ただ一つのイメージか層の1サンプルあたりのビットなどのように。(TIFFは、属性を定義するために野原を供給します)。 層の中の内容の分配は作家によって決定されます、層のための方法、カラー符号化、および空間分解能をコード化することの選択のように。
Not all pages, and not all parts of a page, require 3 layers. If a page has of only one layer, then that layer is the primary image whether it is a Background, Mask, or Foreground layer. If there is more than one layer, then the Mask must be one of the layers, in which case it is the primary image. In all cases, the primary image must be page size.
1ページのすべての部分ではなく、すべてのページが3つの層を必要とするというわけではありません。 1ページが1つの層だけについてそうしたなら、その層はそれがBackground、Mask、またはForeground層であることにかかわらず第一のイメージです。 1つ以上の層があればMaskが層の1つであるに違いない、その場合、それは第一のイメージです。 すべての場合では、第一のイメージはページ・サイズであるに違いありません。
MRC [T.44] allows a page to be transmitted as a series of stripes, each consisting of 1, 2 or 3 layers. The number of scanlines in each stripe can vary over the page. Although [T.44] does not allow overlap between images of a single layer, the MRC profile permits overlapping IFDs when one of the IFDs is used only to define a default image color. According to [T.4] Annex H, stripes having more than 1 layer SHOULD NOT be more than 256 lines in length unless the capability to receive longer stripes has been negotiated.
MRC[T.44]は一連のしまとして1ページを伝えさせます、1、2または3つの層からそれぞれ成って。 各しまの走査線の数はページの上で異なることができます。 [T.44]は単一層のイメージの間のオーバラップを許容しませんが、MRCプロフィールは、IFDsの1つが使用されるとき、デフォルトイメージ色を定義するIFDsを重ね合わせるのを可能にします。 [T.4]に従って、H(より長いしまを受ける能力が交渉されていない場合長さで1層のSHOULD NOTが256以上の線であることを持っているしま)を付加してください。
Furthermore, color fax also requires the spatial resolutions of Background and Foreground images to be legal fax values that are also integer factors of the Mask image resolution. For example, if the Mask-Layer resolution is 400 pixels per inch, then allowable resolutions for the Foreground and Background layers are 100, 200, or 400 pixels per inch; if the Mask is at 300 pixels per inch, then allowable values are 100 and 300. The Foreground and Background layer resolutions can be set independently of each other.
その上、また、カラーファックスは、BackgroundとForegroundイメージの空間分解能がまたMaskイメージ解決の整数要素である法的なファックス値であることを必要とします。 例えば、Mask-層の解決が400ピクセル・パー・インチであるなら、ForegroundとBackground層のための許容できる解決は100、200、または400ピクセル・パー・インチです。 Maskが300ピクセル・パー・インチであるなら、許容量は、100と300です。 ForegroundとBackground層の解決は互いの如何にかかわらず用意ができることができます。
Buckley, et al. Standards Track [Page 61] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[61ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
8.1.2. A TIFF Representation for the MRC 3-layer model
8.1.2. MRCのための3階層モデルのTIFF Representation
In the TIFF representation of the 3-layer MRC model, each page is represented by a single IFD, called the Primary IFD. The nextIFD offset associated with a Primary IFD will point to the Primary IFD of the next page. If the page consists of a single layer, then the Primary IFD represents that layer. If more than one layer is present, the Primary IFD represents the Mask layer and the other layers are represented by a set of child IFDs that are referenced through the SubIFD extension field [TTN1] of the Primary IFD. To distinguish MRC-specific SubIFDs from other SubIFDs, the NewSubFileType field MUST have Bit 4 ON, indicating an MRC-related IFD. A new ImageLayer field is also introduced that consists of two values that identify the layer (Foreground, Background, or Mask) and the order within the layer (first, second, ... image of the layer); see Section 8.2.3.
Primary IFDは、3層のMRCモデルのTIFF表現で、各ページが独身のIFDによって表されると呼びました。 Primary IFDに関連しているnextIFDオフセットは次のページのPrimary IFDを示すでしょう。 ページが単一層から成るなら、Primary IFDはその層を表します。 1つ以上の層が存在しているなら、Primary IFDはMask層を表します、そして、他の層はPrimary IFDのSubIFD拡大分野[TTN1]を通って参照をつけられる子供IFDsの1セットによって表されます。 他のSubIFDsとMRC特有のSubIFDsを区別するために、MRC関連のIFDを示して、NewSubFileType分野にはBit4ONがなければなりません。 また、層(最初に、2番目… 層のイメージ)の中で層(フォアグランド、Background、またはMask)と注文を特定する2つの値から成る新しいImageLayer野原を挿入します。 セクション8.2.3を見てください。
In Profile M, the Primary IFD represents a complete layer and corresponds to the primary image described in Section 8.1.1. There must be no other MRC-related IFDs or SubIFDs that contain image data corresponding to the layer represented by the Primary IFD.
Profile Mでは、Primary IFDは完全な層を表して、セクション8.1.1で説明された第一のイメージに対応しています。 Primary IFDによって表された層に対応するイメージデータを含むいくつかの他のMRC関連のIFDsもSubIFDsもあるはずがありません。
MRC [T.44] allows a page to be transmitted as a series of stripes. A strip within an IFD in a Profile M file represents a stripe in a [T.44] data stream. The [T.44] stripes of the Primary image are represented by a single, multiple-strip IFD; the [T.44] stripes of other layers are represented as multiple, single-strip IFDs.
MRC[T.44]は一連のしまとして1ページを伝えさせます。 MがファイルするProfileのIFDの中の片は[T.44]データ・ストリームでしまを表します。 Primaryイメージの[T.44]しまは単一の、そして、複数の片のIFDによって表されます。 他の層の[T.44]しまは複数の、そして、ただ一つの片のIFDsとして表されます。
The layer represented by the Primary IFD may consist of strips of image data, but all the strips must be part of the single Primary IFD. For example, if the page consisted of only the Background layer, then all strips associated with the Background layer must be treated as a single image. Because MRC allows stripes with variable numbers of scanlines, a reader MUST support StripRowCounts field, as a writer may use it in place of the RowsPerStrip field to support a variable number of scanlines in each strip of the Primary IFD. In accordance with [TTN2], each strip shall be independently encoded, but coding parameters may not change between strips.
Primary IFDによって表された層はイメージデータの片から成るかもしれませんが、すべての片が独身のPrimary IFDの一部であるに違いありません。 例えば、ページがBackground層だけから成ったなら、Background層に関連しているすべての片をただ一つのイメージとして扱わなければなりません。 MRCが可変数の走査線があるしまを許容するので、読者はStripRowCounts分野を支持しなければなりません、作家がPrimary IFDの各片の中の可変数の走査線を支持するのにRowsPerStrip分野に代わってそれを使用するとき。 [TTN2]に従って、各片は独自にコード化されるものとしますが、コード化パラメタは片の間で変化しないかもしれません。
Layers other than the layer represented by the Primary IFD store each strip as a separate IFD, allowing the coding parameters to change from strip to strip as described by the MRC standard [T.44]. In all cases, if the Mask layer exists, it shall be represented by a single IFD and a single set of coding parameters.
Primary IFDによって表された層以外の層は別々のIFDとして各片を格納します、コード化パラメタがMRC規格[T.44]によって説明されるように剥取る片から変化するのを許容して。 すべての場合では、Mask層が存在しているなら、それは独身のIFDとコード化パラメタの1セットによって表されるものとします。
The use of SubIFDs to store child IFDs is described in [TTN1]. When the Mask is the primary image, the Background and Foreground layer images are represented with child IFDs referenced by the SubIFDs
子供IFDsを格納するSubIFDsの使用は[TTN1]で説明されます。 Maskが第一のイメージであるときに、子供IFDsがSubIFDsによって参照をつけられている状態で、BackgroundとForeground層のイメージは表されます。
Buckley, et al. Standards Track [Page 62] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[62ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
field in the Primary IFD. There are multiple ways to organize the images of the Background and Foreground layer images: (1) the SubIFD field of the Primary IFD is an array of pointers to all child image IFDs, one entry per child image; (2) the SubIFD field is a single pointer to a linked list of all child image IFDs; (3) the SubIFD field is an array of two pointers, where the first pointer is to a linked list of all Background layer image IFDs, and the second pointer is to a linked list of all Foreground layer image IFDs. A Profile M writer SHOULD structure the Background and Foreground layer images by using (3), as shown in the example below. Furthermore, the child IFDs representing the images of the Background and Foreground layers SHOULD be ordered in the file in the same order as they occur on the page. However, a Profile M reader must scan all available child IFDs to locate and identify IFDs associated with MRC layers.
Primary IFDでは、さばきます。 Backgroundのイメージを組織化する複数の方法とForeground層のイメージがあります: (1) Primary IFDのSubIFD分野はすべての子供イメージIFDsへのポインタのアレイです、子供イメージあたり1つのエントリー。 (2) SubIFD分野はすべての子供イメージIFDsの繋がっているリストへの単一のポインタです。 (3) SubIFD分野は2個のポインタのアレイです、そして、すべてのForeground層のイメージIFDsの繋がっているリストには秒針があります。(そこに、すべてのBackground層のイメージIFDsの繋がっているリストには最初のポインタがあります)。 Profile Mの作家SHOULD構造のBackgroundとForegroundは(3)を使用することによって、イメージを層にします、以下の例に示されるように。 その上、ページに起こるとき、命令されて、SHOULDのBackgroundとForeground層のイメージを表す子供IFDsが同じくらいのファイルで注文します。 しかしながら、Profile M、読者は、MRC層に関連しているIFDsを場所を見つけて、特定するためにすべての利用可能な子供IFDsをスキャンしなければなりません。
(nextIFD)
PRIMARY IFD PAGE 0 -----------------------> PRIMARY IFD PAGE 1--> ...
ImageLayer = [2,1]
NewSubFileType = 18
SubIFD[0] ---------------------- SubIFD[1]
| |
V V
Child IFD Child IFD
ImageLayer = [1,1] ImageLayer [3,1]
NewSubFileType = 16 NewSubFileType 16
| |
|(nextIFD) |(nextIFD)
V V
Child IFD Child IFD
ImageLayer = [1,2] ImageLayer [3,2]
NewSubFileType = 16 NewSubFileType 16
| |
|(nextIFD) |(nextIFD)
V V
Child IFD Child IFD
ImageLayer = [1,3] ImageLayer [3,3]
NewSubFileType = 16 NewSubFileType 16
| |
|(nextIFD) |(nextIFD)
V V
0 0
(nextIFD)第一のIFD0ページ----------------------->の第一のIFD1ページ-->… ImageLayer=[2、1]NewSubFileTypeは18SubIFD[0]と等しいです。---------------------- SubIFD[1]| | V V子供IFD子供IFD ImageLayer=[1、1]ImageLayer[3、1]NewSubFileTypeは16NewSubFileType16と等しいです。| | |(nextIFD) |(nextIFD) V V子供IFD子供IFD ImageLayer=[1、2]ImageLayer[3、2]NewSubFileTypeは16NewSubFileType16と等しいです。| | |(nextIFD) |(nextIFD) V V子供IFD子供IFD ImageLayer=[1、3]ImageLayer[3、3]NewSubFileTypeは16NewSubFileType16と等しいです。| | |(nextIFD) |(nextIFD) V V0 0
The XPosition and YPosition TIFF fields specify the offset to the upper left corner of the IFD in resolution units, which are inches in Profile M; see Section 8.2.2. The Primary IFD must not use XPosition or YPosition fields.
XPositionとYPosition TIFF分野は解決ユニットでオフセットをIFDの左上隅まで指定します。(ユニットはProfile Mのインチです)。 セクション8.2.2を見てください。 Primary IFDはXPositionかYPosition分野を使用してはいけません。
Buckley, et al. Standards Track [Page 63] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[63ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
MRC [T.44] allows the specification of a default image color that is to be applied in the event no image data is transmitted for a given stripe and layer. The new field ImageBaseColor is used to store default image color specifications in Profile M, see 8.2.3. By setting the StripByteCounts array to zero values, an IFD defining a default color but containing no encoded image data can be specified. ImageBaseColor can also be used in IFDs that contain encoded image data. In that case, the fields of the IFD must accurately reflect the encoding of the image data. If the StripByteCount entry for a given strip is 0, then the ImageBaseColor is used for that strip. If the encoded image data is ITU L*a*b, the ImageBaseColor is interpreted with the encoding parameters of the image data. If the image data is not ITU L*a*b*, the ImageBaseColor is interpreted as 8-bit ITU L*a*b*; see Section 8.2.3.
MRC[T.44]はデフォルトイメージ色の仕様を許容します、すなわち、出来事で適用されるために、イメージデータが全く与えられたしまと層のために送られません。 8.2は、新しい分野ImageBaseColorがProfile Mにデフォルトイメージ色の表示を格納するのに使用されるのを.3に見ます。 StripByteCountsアレイに値のゼロを合わせるように設定することによって、デフォルト色を定義しますが、コード化されたイメージデータを全く含まないIFDは指定できます。 また、コード化されたイメージデータを含むIFDsでImageBaseColorを使用できます。 その場合、IFDの分野は正確にイメージデータのコード化を反映しなければなりません。 与えられた片のためのStripByteCountエントリーが0であるなら、ImageBaseColorはその片に使用されます。 *コード化されたイメージデータがITU Lであるなら、*bであり、ImageBaseColorはイメージデータのコード化パラメタで解釈されます。 イメージデータがITU L*a*b*でないなら、ImageBaseColorは8ビットのITU L*a*b*として解釈されます。 セクション8.2.3を見てください。
8.2. Required TIFF Fields
8.2. 必要ないさかい分野
This section describes the TIFF fields required, in addition to those in Section 2.2.1, to represent MRC fax images. Since MRC stores fax data as a collection of images corresponding to layers or parts of layers, the coding methods, color encodings, and spatial resolutions used by previous profiles apply to Profile M. Therefore, the descriptions here will typically reference the appropriate earlier sections. Fields and values specific to Profile M are pointed out.
このセクションは分野がセクション2.2.1におけるそれらに加えてMRCファックスイメージを表すのを必要としたTIFFについて説明します。 前のプロフィールによって使用される層に対応するイメージの収集か層、コード化方法、カラーencodings、および空間分解能の部品がProfile M.Thereforeに当てはまるときMRCがファックスデータを格納するので、ここでの記述は適切な以前のセクションに通常参照をつけるでしょう。 Profile Mに特定の分野と値は指摘されます。
8.2.1. Baseline Fields
8.2.1. 基線分野
ImageWidth(256).
SHORT or LONG
Same page widths as Profile C, the base color profile; see Section
6.2.1. In Profile M, the width of a Foreground or Background
image in the coded data stream may be less than the page width,
unless the Background or Foreground is the primary image, in which
case the width of the coded data stream is the page width. The
ImageWidth field will always store the actual width of the coded
data.
ImageWidth(256)。 Profile CとしてのSHORTかLONG Sameページ幅、基調色プロフィール。 セクション6.2.1を見てください。 Profile Mでは、コード化されたデータ・ストリームにおける、ForegroundかBackgroundイメージの幅がページ幅より少ないかもしれない、BackgroundかForegroundが第一のイメージでないなら、その場合、コード化されたデータ・ストリームの幅はページ幅です。 ImageWidth分野はいつもコード化されたデータの実際の幅を格納するでしょう。
NewSubFileType(254) = 16, 18.
LONG
For Profile M, the NewSubFileType field has two bits that are
required. Bit 1 indicates a single page of a multi-page document
and must be set for the Primary IFD; Bit 4 indicates the MRC
imaging model as described in ITU-T Recommendation T.44 [T.44] and
must be set for Primary IFDs and all MRC-specific child IFDs.
NewSubFileType(254)=16、18。 LONG For Profile M、NewSubFileType分野には、必要である2ビットがあります。 ビット1をマルチページドキュメントの1ページを示して、Primary IFDに設定しなければなりません。 ビット4をITU-T Recommendation T.44[T.44]で説明されるようにMRCイメージモデルを示して、Primary IFDsとすべてのMRC特有の子供IFDsに設定しなければなりません。
Buckley, et al. Standards Track [Page 64] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[64ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
BitsPerSample(258) = 1, 2-8, 9-12
SHORT
SamplesPerPixel(277) = 1, 3, 4.
SHORT
Compression(259) = 1, 3, 4, 7, 9, 10.
SHORT
For Mask layer, see Sections 4.2.1 and 5.2.1. For Foreground and
Background layers, see Sections 6.2.1 and 7.2.1 Compression=1 is
not used by previous profiles. An IFD used only to specify the
default image color for a layer and strip will not have any
encoded image data associated with it, i.e., the StripByteCounts
field will contain a 0. Since no image data exists in the IFD,
the Compression field shall be set to 1, indicating no
compression. A Compression field value of 1 is not allowed for
any other IFDs.
BitsPerSample(258)は1、2-8、9-12の短いSamplesPerPixel(277)=1、3、4と等しいです。 短い圧縮(259)=1、3、4、7、9、10。 セクション4.2 .1と5.2は、SHORT For Maskが層にするのを.1に見ます。 ForegroundとBackground層に関しては、セクション6.2.1を見てください。そうすれば、7.2に、.1Compression=1は前のプロフィールによって使用されません。 使用されるデフォルトイメージ色を層と片に指定するIFDはそれに関連している少しのコード化されたイメージデータも持たないでしょう、すなわち、StripByteCounts分野が0を含むでしょう。 イメージデータが全くIFDに存在していないので、圧縮を全く示さないで、Compression分野は1に設定されるものとします。 1のCompression分野価値はいかなる他のIFDsのためにも許容されていません。
FillOrder(266) = 1 , 2.
SHORT
RequiredByTIFFBaseline
Profile M readers must be able to read data in both bit orders,
but the vast majority of facsimile products store data LSB first,
exactly as it appears on the telephone line
1 = Most Significant Bit first.
2 = Least Significant Bit first.
FillOrder(266)=1、2。 読者が両方でデータを読み込むことができなければならないSHORT RequiredByTIFFBaseline Profile Mは命令に噛み付きましたが、かなりの大多数のファクシミリ製品は最初にデータLSBを格納します、ちょうど電話回線の上に1が最初にほとんどのSignificant Bitと等しいように見えるように。 2は最初に、最少のSignificant Bitと等しいです。
PhotometricInterpretation(262) = 0, 2, 10.
SHORT
For Mask layer, 0. For Foreground and Background layers, see
Sections 6.2.1 and 7.2.1.
PhotometricInterpretation(262)=0、2、10。 SHORT For Mask層、0。 ForegroundとBackground層に関しては、.1にセクション6.2 .1と7.2を見てください。
ResolutionUnit(296) = 2.
SHORT
The unit of measure for resolution. 2 = inch.
ITU-T standards only specify inch-based resolutions for color fax
Default = 2 (field may be omitted if this is the value).
ResolutionUnit(296)=2。 SHORT、解決のための測定の単位。 2はインチと等しいです。 ITU-T規格は色のファックスDefault=2のためのインチベースの解決を指定するだけです(分野はこれが値であるなら省略されるかもしれません)。
StripByteCounts(279)
SHORT or LONG
In Profile M, it is permissible for the StripByteCounts value for
a given strip to have a zero entry. This means there is no
encoded image data corresponding to that strip. Instead, the
current default image color should be used for the strip. The
standard default image colors are black for the Foreground layer
and White for the Background layer. The ImageBaseColor field can
be used to specify other default colors; see Section 8.2.3.
StripByteCounts(279) SHORTかLONG In Profile M、StripByteCounts値において、aが当然のことの片でエントリーのゼロに合っているのは、許されています。 これは、その片に対応するイメージデータがコード化されないことを意味します。 代わりに、現在のデフォルトイメージ色は片に使用されるべきです。 Foreground層とホワイトにとって、標準省略時解釈イメージ色はBackground層のために黒いです。 他のデフォルト色を指定するのにImageBaseColor分野を使用できます。 セクション8.2.3を見てください。
Buckley, et al. Standards Track [Page 65] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[65ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
XResolution(282) = 100, 200, 300, 400.
RATIONAL
YResolution(283) = 100, 200, 300, 400.
RATIONAL
The resolution of the image is expressed in pixels per resolution
unit. In pixels per inch, allowed XResolution values for all
layers are 100, 200, 300, and 400. Color fax requires the pixels
to be square, hence YResolution must equal XResolution for all
layers. The resolution of Background and Foreground layers must
each be an integer factor of the Primary image, which is the Mask
layer, when it is present; see Section 8.4.
XResolution(282)=100、200、300、400。 合理的なYResolution(283)=100、200、300、400。 RATIONAL、イメージの解像度は解決ユニットあたりの画素で言い表されます。 ピクセル・パー・インチでは、すべての層のためのXResolution値が許容されているのは、100と、200と、300と、400です。 カラーファックスは、画素が正方形であることを必要とします、したがって、YResolutionがすべての層のためにXResolutionと等しくなければなりません。 BackgroundとForeground層の解決はそれぞれMask層であるPrimaryイメージの整数要素であるに違いありません、それが存在しているとき。 セクション8.4を見てください。
8.2.2. Extension Fields
8.2.2. 拡大分野
ChromaSubSampling(530).
SHORT
ChromaPositioning(531).
SHORT
For Foreground and Background layers, see Section 6.2.2.
ChromaSubSampling(530)。 短いChromaPositioning(531)。 セクション6.2.2は、SHORT For ForegroundとBackgroundが層にするのを見ます。
Indexed(346) = 0, 1.
SHORT
For Foreground and Background layers: 1 indicates a palette-color
image; see Section 7.2.2.
(346) =0、1に索引をつけました。 SHORT For ForegroundとBackground層: 1はパレットカラーイメージを示します。 セクション7.2.2を見てください。
T4Options(292) = 0, 1, 4, 5.
SHORT
T6Options(293) = 0.
SHORT
For Mask layer, see Section 4.2.2.
T4Options(292)=0、1、4、5。 短いT6Options(293)=0。 セクション4.2.2は、SHORT For Maskが層にするのを見ます。
SubIFDs(330).
IFD
Count = number of child IFDs. Each value is an offset from the
beginning of the TIFF file to a child IFD [TTN1].
SubIFDs(330)。 IFD Countは子供IFDsの数と等しいです。 各値は子供IFDへのTIFFファイル[TTN1]の始まりからのオフセットです。
XPosition(286).
RATIONAL
YPosition(287).
RATIONAL
Specifies the horizontal and vertical offsets of the top left of
the IFD from the top left of the Primary IFD in resolution units.
For example, if the Primary IFD is at 400 pixels per inch, and a
foreground layer IFD is at 200 pixels per inch and located at
pixel coordinate (345, 678) with respect to the Primary IFD, the
XPosition value is 345/400 and the YPosition value is 678/400 in
inches.
XPosition(286)。 合理的なYPosition(287)。 先端の水平で垂直なオフセットが残した解決ユニットのPrimary IFDの左上からのIFDのRATIONAL Specifies。 例えば、Primary IFDが400ピクセル・パー・インチであって、フォアグランドIFD層が200ピクセル・パー・インチであって、Primary IFDに関して画素座標(345、678)で位置しているなら、XPosition値は345/400です、そして、YPosition値はインチで表現される678/400です。
Buckley, et al. Standards Track [Page 66] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[66ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
The Primary IFD does not use the XPosition or YPosition fields.
The XPosition and YPosition values must be specified for MRC child
IFDs; there is no default value.
Primary IFDはXPositionかYPosition分野を使用しません。 MRC子供IFDsにXPositionとYPosition値を指定しなければなりません。 デフォルト値が全くありません。
8.2.3. New Fields
8.2.3. 新しい分野
Decode(433).
SRATIONAL
For Foreground and Background layers, see Section 6.2.3.
(433)を解読してください。 セクション6.2.3は、SRATIONAL For ForegroundとBackgroundが層にするのを見ます。
T82Options(435)
LONG
For Mask layer, see Section 5.2.3.
セクション5.2.3は、T82Options(435) LONG For Maskが層にするのを見ます。
ImageBaseColor(434).
SHORT
Count = SamplesPerPixel
ImageBaseColor(434)。 短いカウント=SamplesPerPixel
In areas of an image layer where no image data is available (i.e., where no strips are defined, or where the StripByteCounts entry for a given strip is 0), the color specified by ImageBaseColor will be used.
イメージデータがないのが利用可能である(すなわち、片は全くどこで定義されないか、そして、与えられた片のためのStripByteCountsエントリーはどこの0ですか)イメージ層の領域では、ImageBaseColorによって指定された色が使用されるでしょう。
If the ImageBaseColor field is used in an IFD that contains image data encoded in ITU L*a*b*, then the ImageBaseColor will be interpreted with the color-encoding parameters of the image data (i.e., color gamut, illuminant, bit/sample, and decode). If the ImageBaseColor field is used in an IFD that contains image data that is not encoded in ITU L*a*b, then the ImageBaseColor SHALL be interpreted as 8 bits/sample, 3 samples/pixel ITU L*a*b*. If the ImageBaseColor field is used in an IFD that contains no encoded image data, then the ImageBaseColor SHALL be interpreted as 8 bits/sample, 3 samples/pixel ITU L*a*b*. If the fax data stream requires a different encoding, then transferring the default color value between a TIFF file and fax data stream requires a color conversion.
ImageBaseColor分野がイメージを含むIFDで使用されるなら、データはITU L*で*b*をコード化して、次に、ImageBaseColorはイメージデータのカラー符号化パラメタで解釈されるでしょう(すなわち、ビット/サンプルに全域、発光体を着色してください、そして、解読してください)。 ImageBaseColor分野が使用されているなら、次に、*b、ITU L*ImageBaseColor SHALLでコード化されないイメージデータを含むIFDでは8個のビット/サンプルとして解釈されてください、3サンプル/画素ITU L*a*b*。ImageBaseColor分野がIFDで使用されるなら、それはコード化されたイメージデータを全く含んでいません; 次に、ImageBaseColor SHALLは間にデフォルト色の価値を移して、ファックスデータ・ストリームがa異なったコード化を必要とするならa TIFFが8個のビット/サンプル(3サンプル/画素ITU L*a*b*)ファイルするので解釈されて、ファックスで流れが必要とするデータに色の変換を送ります。
A [T.44] stripe may contain a Foreground or Background image less than full stripe size, with the rest of the stripe assuming a default image color. In this case, the default image color is imaged first, followed by the image data. In Profile M, this is represented as a child IFD containing no encoded image data but specifying the default image color in the ImageBaseColor field. A second child IFD contains the image data. To ensure the default image color is imaged first, the order value in the ImageLayer field of the IFD defining the ImageBaseColor field MUST have a lower value than the order value in the ImageLayer field of the IFD defining the image data.
[T.44]しまは完全なしまのサイズほどForegroundかBackgroundイメージを含まないかもしれません、しまの残りが、デフォルトイメージが色であると仮定していて。 この場合、イメージデータがあとに続いていて、デフォルトイメージ色は最初に、像を描かれます。 Profile Mでは、これは、いいえを含む子供IFDがイメージデータをコード化したので表されますが、ImageBaseColor分野でデフォルトイメージ色を指定しています。 第二子IFDはイメージデータを含んでいます。 デフォルトイメージ色が最初に像を描かれるのを保証するために、ImageBaseColor分野を定義するIFDのImageLayer分野のオーダー値はイメージデータを定義するIFDのImageLayer分野にオーダー値より低値を持たなければなりません。
Buckley, et al. Standards Track [Page 67] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[67ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
To define a child IFD specifying a ImageBaseColor but containing no encoded image data, create an IFD with the following settings.
ImageBaseColorを指定しますが、コード化されたイメージデータを全く含まない子供IFDを定義するには、以下の設定があるIFDを作成してください。
ImageLayer[0]: specified layer
ImageLayer[1]: less than any other IFDs corresponding
to the same layer and strip.
RowsPerStrip: strip height
ImageLength: strip height
ImageWidth: full image width
BitsPerSample: 8
PhotometricInterpretation: 10 (ITULAB)
SamplesPerPixel: 3
Compression: 1 (none)
X/YResolution: that of the Primary IFD
XPosition: 0
YPosition: the offset from the top of the page to
the beginning of the strip in the
resolution units of inches
StripByteCounts: single 0 value
StripOffsets: single 0 entry
NewSubFileType: bit 4 O (MRC)
ImageBaseColor: desired color in 8 bit ITULAB
ImageLayer[0]: 層のImageLayer[1]は指定しました: 同じ層に対応するいかなる他のIFDsと片よりもそれほど。 RowsPerStrip: 高さのImageLengthを剥取ってください: 高さのImageWidthを剥取ってください: 完全なイメージ幅のBitsPerSample: 8PhotometricInterpretation: 10 (ITULAB)SamplesPerPixel: 3圧縮: 1(なにも)X/YResolution: Primary IFD XPositionのもの: 0YPosition: ページの先頭からユニットの解決インチStripByteCountsにおける片の始まりまでのオフセット: 0値のStripOffsetsを選抜してください: 0エントリーNewSubFileTypeを選抜してください: ビット4O(MRC)ImageBaseColor: 8ビットのITULABの必要な色
For the Foreground layer image, the default value for the ImageBaseColor field is black. For other cases, including the Background layer image, the default value is white.
Foreground層のイメージに関しては、ImageBaseColor分野へのデフォルト値は黒いです。 他のケースにおいて、Background層のイメージを含んでいて、デフォルト値は白いです。
StripRowCounts(559).
LONG
Count = number of strips.
The number of scanlines stored in a strip. Profile M allows each
fax strip to store a different number of scanlines. For strips
with more than one layer, the maximum strip size is either 256
scanlines or full page size. The 256 maximum SHOULD be used
unless the capability to receive longer strips has been
negotiated. This field replaces RowsPerStrip for IFDs with
variable-size strips. Only one of the two fields, StripRowCounts
and RowsPerStrip, may be used in an IFD.
StripRowCounts(559)。 LONG Countは片の数と等しいです。 片の中に格納された走査線の数。 プロフィールMで、それぞれのファックス片は異なった数の走査線を格納できます。 1つ以上の層がある片のために、最大の片サイズは、256の走査線か全ページサイズのどちらかです。 256の最大のSHOULD、 より長い片を受け取る能力が交渉されていない場合、使用されてください。 この分野はIFDsのためのRowsPerStripを可変サイズ片に取り替えます。 IFDで2つの分野の1つ(StripRowCountsとRowsPerStrip)だけを使用してもよいです。
ImageLayer (34732).
LONG
Count = 2.
Image layers are defined such that layer 1 is the Background
layer, layer 3 is the Foreground layer, and layer 2 is the Mask
layer, which selects pixels from the Background and Foreground
layers. The ImageLayer tag contains two values, which describe
the layer to which the image belongs and the order in which it is
imaged.
ImageLayer(34732)。 長い間、=2を数えてください。 イメージ層が定義されるので、層1はBackground層です、そして、層3はForeground層です、そして、層2はMask層です。(その層はBackgroundとForeground層からの画素を選択します)。 ImageLayerタグは2つの値を含んでいます。(値はイメージが属する層とそれが像を描かれる注文について説明します)。
Buckley, et al. Standards Track [Page 68] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[68ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
ImageLayer[0] = 1, 2, 3.
1: Image is a Background image, i.e., the image that will appear
whenever the Mask contains a value of 0. Background images
typically contain low-resolution, continuous-tone imagery.
2: Image is the Mask layer. In MRC, if the Mask layer is present,
it must be the Primary IFD and be full page in extent.
3: Image is a Foreground image, i.e., the image that will appear
whenever the Mask contains a value of 1. The Foreground image
generally defines the color of text or lines but may also
contain high-resolution imagery.
ImageLayer[0]=1、2、3。 1: イメージはBackgroundイメージ、すなわち、Maskが0の値を含んでいるときはいつも、現れるイメージです。 背景画像は低い解像度の、そして、連続したトーンのイメージを通常含んでいます。 2: イメージはMask層です。 MRCでは、Mask層が存在しているなら、それは、Primary IFDであり、範囲の全ページであるに違いありません。 3: イメージはForegroundイメージ、すなわち、Maskが1の値を含んでいるときはいつも、現れるイメージです。 Foregroundイメージは、一般にテキストか線の色を定義しますが、また、高画質イメージを含むかもしれません。
ImageLayer[1]:
1: first image to be imaged in this layer
2: second image to be imaged in this layer
3: ...
ImageLayer[1]: 1: この層2の中に像を描かれるべき最初のイメージ: 2番目のこの層3の中に像を描かれるべきイメージ: ...
In Profile M, more than one image can exist in a single layer.
ImageLayer[1] specifies the order in which images within a single
layer are to be imaged. This insures that overlapping images
within a single layer are imaged correctly.
Profile Mでは、1つ以上のイメージが単一層の中に存在できます。 ImageLayer[1]は像を描かれる単一層の中のイメージがことであるオーダーを指定します。 これは、重なっているイメージが単一層の中に正しく像を描かれるのを保障します。
If an IFD contains no encoded image data and is used only to
specify the ImageBaseColor field, the value of ImageLayer[1] must
be less than that of any other IFD corresponding to the same layer
and strip to ensure the image data is interpreted as on top of the
default color.
IFDがコード化されたイメージデータを全く含んでいなくて、いかなる他のもの以下も同じ層と確実にする片に対応するIFDであったに違いないなら単にImageBaseColor分野、ImageLayer[1]の値を指定するのにおいて使用されているなら、イメージデータはデフォルト色の上で解釈されます。
In Profile M, it is possible to have only a single layer. For
example, if a page contains only a single continuous-tone
photograph, then only the Background layer would occur. In this
case, the Background layer will be stored as the Primary IFD.
ImageLayer[0] will be 1, indicating Background; ImageLayer[1] will
be 1, as there can be no other IFDs associated with that layer.
No Mask layer will exist.
Profile Mでは、単一層しか持っていないのは可能です。 例えば、1ページがただ一つの連続したトーン写真だけを含んでいるなら、Background層だけが現れるでしょう。 この場合、Background層はPrimary IFDとして格納されるでしょう。 Backgroundを示して、ImageLayer[0]は1歳になるでしょう。 その層に関連している他のいくつかのIFDsがあるはずがないので、ImageLayer[1]は1歳になるでしょう。 Mask層は全く存在しないでしょう。
8.3. Recommended TIFF Fields
8.3. お勧めのいさかい分野
See Sections 2.2.3. and 2.2.4.
セクション2.2.3 2.2.4を見てください。
8.4. Rules and Requirements for Images
8.4. イメージズのための規則と要件
Profile M defines a fundamental set of rules for images in the 3 layer representation.
プロフィールMはイメージのために3層の表現で基本的なセットの規則を定義します。
Buckley, et al. Standards Track [Page 69] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[69ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
1. If more than one layer exists, then the binary Mask layer SHALL be
present and be the primary image. The Mask layer SHALL support
the binary data representations defined in Section 3 and MAY
support those defined in Sections 4 and 5, with the exception that
PhotometricInterpretation MUST be 0. If only one layer exists,
then the image corresponding to that layer is the primary image.
1. 1つの層が存在しているよりさらに、次に、SHALLの2進のMask層であるなら、存在してください、そして、第一のイメージになってください。 2進のデータ表現がものがセクション4と5で定義したセクション3と5月のサポートで定義したMask層のSHALLサポート、例外で、そのPhotometricInterpretationは0歳であるに違いありません。 1つの層だけが存在しているなら、その層に対応するイメージは第一のイメージです。
2. The Primary IFD defines and extends to the entire page boundary;
all attached model images cannot extend beyond the Primary image.
Resolution differences may cause some pixels to "hang over" the
page boundary, but no new pixels should exist completely beyond
the page extent.
2. Primary IFDは全体のページ・バウンダリを定義して、達します。 すべての添付のモデルイメージがPrimaryイメージを超えて敷衍されることができるというわけではありません。 解決差は「垂れ下がってください」にページ・バウンダリをいくつかの画素引き起こすかもしれませんが、どんな新しい画素も完全ページ範囲を超えて存在するはずがありません。
3. The Background and Foreground images SHALL support the color
representations defined in Section 6 and MAY support those defined
in Section 7. These images MAY optionally cover only a portion of
the strip or page.
3. BackgroundとForegroundイメージSHALLはセクション6で定義された色の表現をサポートして、セクション7で定義されたものを支持するかもしれません。 これらのイメージは任意に片かページの一部だけをカバーするかもしれません。
4. Each Primary IFD and each MRC-specific SubIFD must have an
ImageLayer field to specify which layer the IFD belongs to, and
the imaging order of that IFD within the layer.
4. 各Primary IFDとそれぞれのMRC特有のSubIFDは層の中にIFDがどの層に属すかを指定するImageLayer分野、およびそのIFDに関するイメージ命令を持たなければなりません。
5. Each Primary IFD must have a NewSubFileType field value set to 18,
indicating a single page of a multi-page document (bit 1) and MRC
(bit 4).
5. 各Primary IFDはNewSubFileType分野価値を18に設定させなければなりません、マルチページドキュメント(ビット1)とMRC(ビット4)の1ページを示して。
6. Each MRC-specific child IFD must have a NewSubFileType field value
set to 16, indicating MRC (bit 4).
6. MRC(ビット4)を示して、それぞれのMRC特有の子供IFDはNewSubFileType分野価値を16に設定させなければなりません。
7. In MRC fax, each layer is transmitted as a sequence of strips. If
the page consists of a single layer, then all strips shall be
stored in the single Primary IFD. In this case, coding parameters
cannot change between strips. If the page consists of more than
one layer, then all strips of the Mask layer shall be stored in
the single Primary IFD. All strips of the Foreground/Background
layers SHALL be stored in separate IFDs, referenced by the Primary
IFD's SubIFD field, containing an ImageLayer field with
ImageLayer[0] identifying either Background (layer 1) or
Foreground (layer 3), and Imagelayer[1] identifying order in which
images within a single layer are to be imaged. The TIFF XPosition
and YPosition fields are used to indicate the placement of these
images with respect to the primary image.
7. MRCファックスで、各層は片の系列として伝えられます。 ページが単一層から成るなら、すべての片が独身のPrimary IFDに格納されるものとします。 この場合、コード化パラメタは片の間で変化できません。 ページが1つ以上の層から成るなら、Mask層のすべての片が独身のPrimary IFDに格納されるものとします。 Primary IFDのSubIFD分野によって参照をつけられます、Foreground/バックグラウンドSHALL層のすべての片が別々のIFDsに格納されて、単一層の中にImageLayer[0]がBackground(層1)かForeground(層3)のどちらかを特定していて、Imagelayer[1]がどのイメージでオーダーを特定しているかImageLayer分野を含んで、像を描かれることになっていてください。 TIFF XPositionとYPosition分野は、第一のイメージに関してこれらのイメージのプレースメントを示すのに使用されます。
8. When the Mask image is present, the resolution of Background and
Foreground images must each be an integer factor of the Mask
image. For example, if the Mask image is 400 pixels/inch, then
the Background or Foreground image may be at 400 pixels/inch
(400/1), 200 pixels/inch (400/2), or 100 pixels/inch (400/4).
8. Maskイメージが存在しているとき、BackgroundとForegroundイメージの解像度はそれぞれMaskイメージの整数要素であるに違いありません。 例えば、Maskイメージが400画素/インチであるなら、BackgroundかForegroundイメージが400画素/インチ(400/1)、200画素/インチ(400/2)、または100画素/インチ(400/4)にあるかもしれません。
Buckley, et al. Standards Track [Page 70] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[70ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
8.5. Profile M: MRC Fax Profile Summary
8.5. プロフィールM: MRCファックスプロフィール概要
Recommended fields are shown with an asterisk (*).
お勧めの分野はアスタリスク(*)で示されます。
Required fields or values are shown with a double asterisk (**). If the double asterisk is on the field name, then all the listed values are required of implementations; if the double asterisk is in the Values column, then only the values suffixed with a double asterisk are required of implementations.
必須項目か値が二重アスタリスク(**)で示されます。 二重アスタリスクがフィールド名にあるなら、実現はすべての記載された値に要求されます。 二重アスタリスクがValuesコラムにあるなら、実現は二重アスタリスクでsuffixedされた値だけに要求されます。
+------------------+-----------------------------------------+
| Baseline Fields | Values |
+------------------+-----------------------------------------+
| BitsPerSample | 1**: binary mask, RGB, CMY(K) |
| | 2 - 8**: bits per color sample |
| | 9 - 12: optional 12 bits/sample |
+------------------+-----------------------------------------+
| Compression | 1: None (ImageBaseColor IFD only) |
| | 3**: Modified Huffman and Modified READ |
| | 4: Modified Modified READ |
| | 7**: JPEG |
| | 9: JBIG, per T.85 |
| | 10: JBIG, per T.43 |
+------------------+-----------------------------------------+
| DateTime* | {ASCII): date/time in the 24-hour format|
| | "YYYY:MM:DD HH:MM:SS" |
+------------------+-----------------------------------------+
| FillOrder** | 1: Most significant bit first |
| | 2: Least significant bit first |
+------------------+-----------------------------------------+
| ImageDescription*| {ASCII}: A string describing the |
| | contents of the image. |
+------------------+-----------------------------------------+
| ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, |
| | 2592, 3072, 3456, 3648, 4096, 4864 |
| | Note: legal widths for the Primary IFD. |
+------------------+-----------------------------------------+
| ImageLength** | n: total number of scanlines in image |
+------------------+-----------------------------------------+
| NewSubFileType** | 16, 18: |
| | Bit 1 indicates single page of a multi- |
| | page document on Primary IFD |
| | Bit 4 indicates MRC model |
+------------------+-----------------------------------------+
+------------------+-----------------------------------------+ | 基線分野| 値| +------------------+-----------------------------------------+ | BitsPerSample| 1**: 2進のマスク、RGB、CMY(K)| | | 2 - 8**: 1色見本あたりのビット| | | 9 - 12: 任意の12個のビット/サンプル| +------------------+-----------------------------------------+ | 圧縮| 1: なし(ImageBaseColor IFD専用)| | | 3**: ハフマンを変更して、読まれて、変更されます。| | | 4: 変更されていた状態で、読まれて、変更されます。| | | 7**: JPEG| | | 9: 1T.85あたりのJBIG| | | 10: 1T.43あたりのJBIG| +------------------+-----------------------------------------+ | DateTime*| {ASCII): date/time in the 24-hour format| | | "YYYY:MM:DD HH:MM:SS" | +------------------+-----------------------------------------+ | FillOrder** | 1: Most significant bit first | | | 2: Least significant bit first | +------------------+-----------------------------------------+ | ImageDescription*| {ASCII}: A string describing the | | | contents of the image. | +------------------+-----------------------------------------+ | ImageWidth | 864, 1024, 1216, 1728**, 2048, 2432, | | | 2592, 3072, 3456, 3648, 4096, 4864 | | | Note: legal widths for the Primary IFD. | +------------------+-----------------------------------------+ | ImageLength** | n: total number of scanlines in image | +------------------+-----------------------------------------+ | NewSubFileType** | 16, 18: | | | Bit 1 indicates single page of a multi- | | | page document on Primary IFD | | | Bit 4 indicates MRC model | +------------------+-----------------------------------------+
Buckley, et al. Standards Track [Page 71] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[71ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+------------------+-----------------------------------------+
| Orientation | 1**-8, Default 1 |
+------------------+-----------------------------------------+
| PhotometricInter | 0**: WhiteIsZero (Mask Layer) |
| pretation | 2: RGB |
| | 10**: ITULAB |
+------------------+-----------------------------------------+
| ResolutionUnit** | 2: inch |
+------------------+-----------------------------------------+
| RowsPerStrip | n: number or scanlines per strip |
+------------------+-----------------------------------------+
| SamplesPerPixel | 1**: L* (lightness) |
| | 3: RGB, LAB, CMY |
| | 4: CMYK |
+------------------+-----------------------------------------+
| Software* | {ASCII}: name & release number of |
| | creator software |
+------------------+-----------------------------------------+
| StripByteCounts**| <n>: number or bytes in each strip |
+------------------+-----------------------------------------+
| StripOffsets** | <n>: offset from beginning of file to |
| | each TIFF strip |
+------------------+-----------------------------------------+
| XResolution | 100, 200**, 300, 400 (written in |
| | pixels/inch) |
+------------------+-----------------------------------------+
| YResolution | equal to XResolution (pixels must be |
| | square) |
+------------------+-----------------------------------------+
| Extension Fields |
+------------------+-----------------------------------------+
| T4Options | 0**: required if Compression is Modified|
| | Huffman, EOLs not byte aligned |
| | 1: required if Compression 2D Modified |
| | READ, EOLs are not byte aligned |
| | 4**: required if Compression Modified |
| | Huffman, EOLs byte aligned |
| | 5: required if Compression 2D Modified |
| | READ, EOLs are byte aligned |
+------------------+-----------------------------------------+
| T6Options | 0: required if Compression is 2D |
| | Modified Modified READ |
+------------------+-----------------------------------------+
| DocumentName* | {ASCII}: name of scanned document |
+------------------+-----------------------------------------+
| PageNumber** | n,m: page number followed by total page |
| | count |
+------------------+-----------------------------------------+
+------------------+-----------------------------------------+ | オリエンテーション| 1**-8、デフォルト1| +------------------+-----------------------------------------+ | PhotometricInter| 0**: WhiteIsZero(マスク層)| | pretation| 2: RGB| | | 10**: ITULAB| +------------------+-----------------------------------------+ | ResolutionUnit**| 2: インチ| +------------------+-----------------------------------------+ | RowsPerStrip| n: 1片あたりの数か走査線| +------------------+-----------------------------------------+ | SamplesPerPixel| 1**: L*(軽さ)| | | 3: RGB、研究室、CMY| | | 4: CMYK| +------------------+-----------------------------------------+ | ソフトウェア*| ASCII: 数を命名して、リリースします。| | | 創造者ソフトウェア| +------------------+-----------------------------------------+ | StripByteCounts**| <n>: 各片の中の数かバイト| +------------------+-----------------------------------------+ | StripOffsets**| <n>: ファイルの始まりから、相殺します。| | | それぞれのTIFF片| +------------------+-----------------------------------------+ | XResolution| 100、200**、300、400(| | | 画素/インチに書かれています)| +------------------+-----------------------------------------+ | YResolution| XResolutionと等しさ、(画素、| | | 正方形でなければならない、)| +------------------+-----------------------------------------+ | 拡大分野| +------------------+-----------------------------------------+ | T4Options| 0**: CompressionがModifiedであるなら、必要です。| | | ハフマン、どんなバイトも並べなかったEOLs| | | 1: Compressionの2D Modifiedであるなら、必要です。| | | READ、EOLsは並べられたバイトではありません。| | | 4**: Compression Modifiedであるなら、必要です。| | | ハフマン、バイトが並べたEOLs| | | 5: Compressionの2D Modifiedであるなら、必要です。| | | READ、EOLsは並べられたバイトです。| +------------------+-----------------------------------------+ | T6Options| 0: Compressionが2Dであるなら、必要です。| | | 変更されていた状態で、読まれて、変更されます。| +------------------+-----------------------------------------+ | DocumentName*| ASCII: スキャンした文書の名前| +------------------+-----------------------------------------+ | PageNumber**| n、m: 総ページがあとに続いたページ番号| | | カウント| +------------------+-----------------------------------------+
Buckley, et al. Standards Track [Page 72] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[72ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+------------------+-----------------------------------------+ | ChromaSubSampling| (1,1), (2, 2)** | | | (1, 1): equal numbers of lightness and | | | chroma samples horizontally & vertically| | | (2, 2): twice as many lightness samples | | | as chroma horizontally and vertically | +------------------+-----------------------------------------+ | ChromaPositioning| 1: centered | +------------------+-----------------------------------------+ | Indexed | 0: not a palette-color image | | | 1: palette-color image | +------------------+-----------------------------------------+ | SubIFDs | <IFD>: byte offset to FG/BG IFDs | +------------------+-----------------------------------------+ | XPosition | horizontal offset in primary IFD | | | resolution units | +------------------+-----------------------------------------+ | YPosition | vertical offset in primary IFD | | | resolution units | +------------------+-----------------------------------------+ | New Fields | +------------------+-----------------------------------------+ | Decode | minL, maxL, mina, maxa, minb, maxb: | | | minimum and maximum values for L*a*b* | +------------------+-----------------------------------------+ | ImageBaseColor | a,b,c: background color in ITULAB | +------------------+-----------------------------------------+ | StripRowCounts | <n>: number of scanlines in each strip | +------------------+-----------------------------------------+ | ImageLayer | n, m: layer number, imaging sequence | | | (e.g., strip number) | +------------------+-----------------------------------------+ | T82Options | 0: T.85 profile of T.82 coding | +------------------+-----------------------------------------+ | GlobalParameters | IFD: global parameters IFD | | IFD* | | +------------------+-----------------------------------------+ | ProfileType* | n: type of data stored in TIFF file | +------------------+-----------------------------------------+ | FaxProfile* | n: ITU-compatible fax profile | +------------------+-----------------------------------------+ | CodingMethods* | n: compression algorithms used in file | +------------------+-----------------------------------------+ | ModeNumber* | n: version of T.44 standard | +------------------+-----------------------------------------+ | VersionYear* | byte sequence: year of ITU fax standard | +------------------+-----------------------------------------+
+------------------+-----------------------------------------+ | ChromaSubSampling| (1,1), (2, 2)** | | | (1, 1): そして等しい数の軽さ。| | | 彩度は水平に垂直に抽出します。| | | (2, 2): 2倍の軽さのサンプル| | | 彩度、水平で垂直に。| +------------------+-----------------------------------------+ | ChromaPositioning| 1: 中心に置かれます。| +------------------+-----------------------------------------+ | 索引をつけられます。| 0: パレットカラーイメージでない| | | 1: パレットカラーイメージ| +------------------+-----------------------------------------+ | SubIFDs| <IFD>: FG/BG IFDsに相殺されたバイト| +------------------+-----------------------------------------+ | XPosition| 第一のIFDでの水平なオフセット| | | 解決ユニット| +------------------+-----------------------------------------+ | YPosition| 第一のIFDでの垂直なオフセット| | | 解決ユニット| +------------------+-----------------------------------------+ | 新しい分野| +------------------+-----------------------------------------+ | 解読してください。| minL、maxL、mina、maxa、minb、maxb: | | | 最小限と最大はL*のために*b*を評価します。| +------------------+-----------------------------------------+ | ImageBaseColor| a、b、c: ITULABの背景色| +------------------+-----------------------------------------+ | StripRowCounts| <n>: 各片の中の走査線の数| +------------------+-----------------------------------------+ | ImageLayer| n、m: 系列に像を描いて、数を層にしてください。| | | (例えば、片番号) | +------------------+-----------------------------------------+ | T82Options| 0: T.82コード化のT.85プロフィール| +------------------+-----------------------------------------+ | GlobalParameters| IFD: グローバルなパラメタIFD| | IFD*| | +------------------+-----------------------------------------+ | ProfileType*| n: TIFFに格納されたデータのタイプはファイルします。| +------------------+-----------------------------------------+ | FaxProfile*| n: ITUコンパチブルファックスプロフィール| +------------------+-----------------------------------------+ | CodingMethods*| n: ファイルで使用される圧縮アルゴリズム| +------------------+-----------------------------------------+ | ModeNumber*| n: T.44規格のバージョン| +------------------+-----------------------------------------+ | VersionYear*| バイト列: ITUファックス規格の年| +------------------+-----------------------------------------+
Buckley, et al. Standards Track [Page 73] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[73ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
9. MIME content-types image/tiff and image/tiff-fx
9. MIME満足しているタイプイメージ/いさかいといさかいイメージ/fx
The MIME content-types image/tiff and image/tiff-fx are used for TIFF-FX encoded image data, as defined in this document. [TIFF-REG] and [TIFF-FX-REG] describe the registration of these MIME content- types.
イメージ/いさかいといさかいイメージ/fxが使用されるMIMEの満足しているタイプTIFF-FXは本書では定義されるようにイメージデータをコード化しました。 [TIFF-REG]と[TIFF-FX-REG]はこれらのMIME内容タイプの登録について説明します。
10. Security Considerations
10. セキュリティ問題
This document describes a file format for Internet fax, which is a series of profiles of TIFF for facsimile. As such, it does not create any security issues not already identified in [TIFF-REG], in its use of fields as defined in [TIFF]. There are also new TIFF fields defined within this specification, but they are of a purely descriptive nature, so no new security risks are incurred.
このドキュメントはインターネットファックスのためにファイル形式について説明します。(それは、ファクシミリのためのTIFFの一連のプロフィールです)。 そういうものとして、それは問題が[TIFF]で定義されるように既に分野を[TIFF-REG]、使用で特定しなかった少しのセキュリティも作成しません。 また、この仕様の中で定義された新しいTIFF分野がありますが、それらが純粋に描写的に自然であるので、どんな新しいセキュリティ危険も被られません。
Further, the encoding specified in this document does not in any way preclude the use of any Internet security protocol to encrypt, authenticate, or non-repudiate TIFF-encoded facsimile messages.
さらに、本書では指定されたコード化が何らかの方法でコード化するどんなインターネットセキュリティプロトコルの使用も排除しない、認証、非、否認、TIFFによってコード化されたファクシミリメッセージ。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[T.4] ITU-T Recommendation T.4, Standardization of group 3
facsimile apparatus for document transmission, October
1997.
[T.4]ITU-T Recommendation T.4、ドキュメントトランスミッション、1997年10月のためのグループ3ファクシミリ装置のStandardization。
[T.6] ITU-T Recommendation T.6, Facsimile coding schemes and
coding control functions for group 4 facsimile
apparatus, November 1988
[T.6]ITU-T Recommendation T.6とFacsimileコード構成とグループ4ファクシミリ装置のためにコントロール機能をコード化する1988年11月
[T.30] ITU-T Recommendation T.30 - Procedures for Document
Facsimile Transmission in the General Switched
Telephone Network, June 1996
[T.30]ITU-T推薦T.30--一般切り換えられた電話網、1996年6月のドキュメントファクシミリ伝送のための手順
[T.42] ITU-T Recommendation T.42, Continuous-tone colour
representation method for facsimile, February 1996
[T.42]ITU-T Recommendation T.42、ファクシミリ、1996年2月のためのContinuous-トーン色の表現方法
[T.43] ITU-T Recommendation T.43, Colour and gray-scale image
representations using lossless coding scheme for
facsimile, February 1997
[T.43]ITU-T Recommendation T.43とColourとファクシミリ、1997年2月にlosslessコード構成を使用する階調画像表現
[T.44] ITU-T Recommendation T.44, Mixed Raster Content (MRC),
April 1999.
[T.44]ITU-T推薦T.44、Mixedラスタ内容(MRC)、1999年4月。
Buckley, et al. Standards Track [Page 74] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[74ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
[T.81] ITU-T Recommendation T.81, Information technology -
Digital compression and coding of continuous-tone still
images - Requirements and guidelines, September 1992
情報技術--連続したトーン静止画像の指圧とコード化--[T.81]ITU-T Recommendation T.81と要件とガイドライン、1992年9月
[T.85] ITU-T Recommendation T.85, Application profile for
Recommendation T.82 - Progressive bi-level image
compression (JBIG coding scheme) for facsimile
apparatus, August 1995
[T.85]ITU-T Recommendation T.85、Recommendation T.82のためのApplicationプロフィール--ファクシミリ装置、1995年8月のための進歩的な両性愛者のレベル画像圧縮(JBIGコード構成)
[T.82] ITU-T Recommendation T.82, Information technology -
Coded representation of picture and audio information -
Progressive bi-level image compression, March 1995
[T.82]ITU-T Recommendation T.82、情報技術--絵とオーディオ情報のコード値--進歩的な両性愛者のレベル画像圧縮、1995年3月
[TIFF] Tag Image File Format, Revision 6.0, Adobe Developers
Association, June 3, 1992,
http://partners.adobe.com/public/developers/en/tiff/
TIFF6.pdf
[いさかい]タグ画像ファイル形式、改正6.0、Adobe開発者協会、1992年6月3日、 http://partners.adobe.com/public/developers/en/tiff/ TIFF6.pdf
The TIFF 6.0 specification dated June 3, 1992
specification (c) 1986-1988, 1992 Adobe Systems
Incorporated. All Rights Reserved.
1992アドビ・システムズIncorporated、TIFF6.0仕様は1992年6月3日に(c)1986-1988と仕様の日付を入れました。 All rights reserved。
[TIFF-F0] TIFF Class F specification, Apr 28, 1990,
ftp://ftp.faximum.com/pub/documents/tiff_f.txt
[TIFF-F0]TIFF Class F仕様、1990年4月28日、 ftp://ftp.faximum.com/pub/documents/tiff_f.txt
[TIFF-REG] Parsons, G. and J. Rafferty, "Tag Image File Format
(TIFF) - image/tiff MIME Sub-type Registration", RFC
3302, September 2002.
[TIFF-REG] パーソンズとG.とJ.Rafferty、「Image File Format(TIFF)にタグ付けをしてください--イメージ/いさかいMIMEはRegistrationをSubタイプする」RFC3302、2002年9月。
[TTN1] Adobe PageMaker 6.0 TIFF Technical Notes, Sept. 14,
1995,
http://partners.adobe.com/public/developers/en/tiff/
TIFFPM6.pdf
[TTN1]Adobe PageMaker6.0いさかいテクニカルノート、1995年9月14日、 http://partners.adobe.com/public/developers/en/tiff/ TIFFPM6.pdf
[TTN2] Draft TIFF Technical Note 2, Replacement TIFF/JPEG
specification, March 17, 1995,
ftp://ftp.uu.net/graphics/jpeg/
[TTN2] 草稿TIFF Technical Note2、Replacement TIFF/JPEG仕様、1995年3月17日、 ftp://ftp.uu.net/graphics/jpeg/
[TIFF-FX-REG] McIntyre, L., Parsons, G., and J. Rafferty, "Tag Image
File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME
Sub-type Registration", RFC 3250, September 2002.
[TIFF-FX-REG] マッキンタイヤ、L.、パーソンズ、G.、およびJ.Rafferty、「Image File FormatファックスeXtended(TIFF-FX)にタグ付けをしてください--いさかいイメージ/fx MIME Sub-タイプRegistration」、RFC3250、2002年9月。
Buckley, et al. Standards Track [Page 75] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[75ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
11.2. Informative References
11.2. 有益な参照
[GUIDE] Cancio, V., Moldovan, M., Tamura, H., and D. Wing,
"Implementers Guide for Facsimile Using Internet Mail",
RFC 3249, September 2002.
[誘導します] Cancio、V.、Moldovan、M.、田村、H.、およびD.は飛んで行きます、「ファクシミリのためのImplementersガイドはインターネットメールを使用し」て、RFC3249、2002年9月。
[TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format
(TIFF) - F Profile for Facsimile", RFC 2306, March
1998.
[いさかいF]のパーソンズ、G.、およびJ.Rafferty、「画像ファイル形式(いさかい)にタグ付けをしてください--ファクシミリのためのFプロフィール」、RFC2306、3月1998日
[VPIM 2] Vaudreuil G. and G. Parsons, "Voice Profile for
Internet Mail - version 2 (VPIMv2)", RFC 3801, June
2004.
[VPIM2] ボードルイG.とG.パーソンズ、「インターネットメールのためにProfileを声に出してください--バージョン2(VPIMv2)」、RFC3801、6月2004日
Buckley, et al. Standards Track [Page 76] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[76ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Annex A: Summary of TIFF Fields for Internet Fax
別館A: インターネットファックスのためのいさかい分野の概要
This annex includes tables which list by profile the TIFF fields used in the proposed fax file format. The fields are organized into 3 categories:
この別館はプロフィールで提案されたファックスファイル形式に使用されるTIFF分野を記載するテーブルを含んでいます。 分野は3つのカテゴリに組織化されます:
1) TIFF Baseline Fields
2) TIFF Extension Fields
3) New Fields.
1) いさかい基線分野2) いさかい拡大分野3) 新しい分野。
The tables include the allowed values for each fax profile. Entries other than explicit numbers are described by:
テーブルはそれぞれのファックスプロフィールのための許容値を含んでいます。 明白な数以外のエントリーは以下によって説明されます。
n - single number
n, m - 2 numbers
a, b, c - 3 numbers
r - rational number
<n> - array of numbers
<b> - byte sequence
{ASCII} - string
IFD - IFD byte offset
<IFD> - array of IFD byte offsets
n--ただ一つのNo.n、m--2つの番号a、b、c--3つの番号r--有理数<n>-->--バイト列ASCII--IFDバイトが<IFD>を相殺したというストリングIFDが整列させるIFDバイトの数の<bのアレイは相殺されます。
A blank entry in the table indicates that the field is not used by that particular fax profile.
テーブルの空白のエントリーは、分野がその特定のファックスプロフィールによって使用されないのを示します。
Table A.1 TIFF Baseline Fields
テーブルA.1いさかい基線分野
+---------------------------------------------------------+
| Fax Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| BitsPer | 1 | 1 | 1 | 8 | 1, 2-8 | 1, 2-8 |
| Sample | | | | | 9-12 | 9-12 |
+----------+---------+----------+--------+---------+--------+--------+
| Compres- | 3 | 3, 4 | 9 | 7 | 10 | 3, 4, 7|
| sion | | | | | | 9,10 |
+----------+---------+----------+--------+---------+--------+--------+
| DateTime | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| FillOrder| 2 | 1, 2 | 1, 2 | 1, 2 | 1, 2 | 1,2 |
+----------+---------+----------+--------+---------+--------+--------+
+---------------------------------------------------------+ | ファックスプロフィール| +---------------------------------------------------------| | 最小量| 広がっています。| JBIG| 損失性|Lossless| Mixed| +----------| B&W| B&W| B&W| 色| 色| ラスタ| | いさかい| | | | | | 内容| | 分野| S| F| J| C| L| M| +----------+---------+----------+--------+---------+--------+--------+ | BitsPer| 1 | 1 | 1 | 8 | 1, 2-8 | 1, 2-8 | | サンプル| | | | | 9-12 | 9-12 | +----------+---------+----------+--------+---------+--------+--------+ | Compres| 3 | 3, 4 | 9 | 7 | 10 | 3, 4, 7| | sion| | | | | | 9,10 | +----------+---------+----------+--------+---------+--------+--------+ | DateTime| | ASCII| ASCII| ASCII| ASCII| ASCII| +----------+---------+----------+--------+---------+--------+--------+ | FillOrder| 2 | 1, 2 | 1, 2 | 1, 2 | 1, 2 | 1,2 | +----------+---------+----------+--------+---------+--------+--------+
Buckley, et al. Standards Track [Page 77] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[77ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+----------+---------+----------+--------+---------+--------+--------+
| ImageDes-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| cription | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | n | n | n | n | n | n |
| Length | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, |
| Width | | 2592, 3072, 3456 | 2048, 2432, 2592, 3072, |
| | | 3648, 4096, 4864 | 3456, 3648, 4096, 4864 |
| | | Note, for the Mixed Raster Content M profile |
| | | these widths apply to the Primary IFD. |
+----------+---------+----------+--------+---------+--------+--------+
| NewSub- | 2 | 2 | 2 | 2 | 2 | 16, 18 |
| FileType | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Orien- | 1 | 1-8 | 1-8 | 1-8 | 1-8 | 1-8 |
| tation | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Photo- | 0 | 0, 1 | 0, 1 | 10 | 2, 5, | 0, |
| metric- | | | | | 10 | 2, |
| Interp- | | | | | | 10 |
| retation | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Resolu- | 2 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 2, 3 |
| tionUnit | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| RowsPer- | n | n | n | n | n | n |
| Strip | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Samples- | 1 | 1 | 1 | 1, 3 | 1, 3, 4| 1, 3, 4|
| PerPixel | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Software | | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | n | <n> | <n> | <n> | <n> | <n> |
| Byte- | | | | | | |
| Counts | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Strip- | n | <n> | <n> | <n> | <n> | <n> |
| Offsets | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| XResolu- | 204 | 200, 204, 300 | 100, 200, 300, 400 |
| tion | 200 | 400, 408 | |
+----------+---------+----------+--------+---------+--------+--------+
| YResolu- | 98, 196 | 98, 196, 100, 200 | 100, 200, 300, 400 |
| tion | 100,200 | 300, 391, 400 | |
+----------+---------+----------+--------+---------+--------+--------+
+----------+---------+----------+--------+---------+--------+--------+ | ImageDes| | ASCII| ASCII| ASCII| ASCII| ASCII| | cription| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | イメージ| n| n| n| n| n| n| | 長さ| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | イメージ| 1728 | 1728, 2048, 2432 | 864, 1024, 1216, 1728, | | 幅| | 2592, 3072, 3456 | 2048, 2432, 2592, 3072, | | | | 3648, 4096, 4864 | 3456, 3648, 4096, 4864 | | | | Raster Content Mが輪郭を描くMixedのための注意| | | | これらの幅はPrimary IFDに適用されます。 | +----------+---------+----------+--------+---------+--------+--------+ | NewSub| 2 | 2 | 2 | 2 | 2 | 16, 18 | | FileType| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | Orien| 1 | 1-8 | 1-8 | 1-8 | 1-8 | 1-8 | | tation| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | 写真| 0 | 0, 1 | 0, 1 | 10 | 2, 5, | 0, | | メートル法| | | | | 10 | 2, | | Interp| | | | | | 10 | | retation| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | Resolu| 2 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | 2, 3 | | tionUnit| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | RowsPer| n| n| n| n| n| n| | 片| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | サンプル| 1 | 1 | 1 | 1, 3 | 1, 3, 4| 1, 3, 4| | PerPixel| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | ソフトウェア| | ASCII| ASCII| ASCII| ASCII| ASCII| +----------+---------+----------+--------+---------+--------+--------+ | 片| n| <n>。| <n>。| <n>。| <n>。| <n>。| | バイト| | | | | | | | カウント| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | 片| n| <n>。| <n>。| <n>。| <n>。| <n>。| | オフセット| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | XResolu| 204 | 200, 204, 300 | 100, 200, 300, 400 | | tion| 200 | 400, 408 | | +----------+---------+----------+--------+---------+--------+--------+ | YResolu| 98, 196 | 98, 196, 100, 200 | 100, 200, 300, 400 | | tion| 100,200 | 300, 391, 400 | | +----------+---------+----------+--------+---------+--------+--------+
Buckley, et al. Standards Track [Page 78] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[78ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Table A.2 TIFF Extension Fields
テーブルA.2いさかい拡大分野
+---------------------------------------------------------+
| Fax Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma- | | | | 1 | | 1 |
| Position-| | | | | | |
| ing | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Chroma- | | | | <1, 1> | | <1, 1> |
| SubSampl-| | | | <2, 2> | | <2, 2> |
| ing | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Document-| | {ASCII} | {ASCII}| {ASCII} | {ASCII}| {ASCII}|
| Name | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Indexed | | | | | 0,1 | 0,1 |
+----------+---------+----------+--------+---------+--------+--------+
| Page- | n, m | n, m | n, m | n, m | n, m | n, m |
| Number | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| SubIFDs | | | | | | <IFD> |
+----------+---------+----------+--------+---------+--------+--------+
| T4Options| 0, 4 | 0, 1, | | | | 0, 1, |
| | | 4, 5 | | | | 4, 5 |
+----------+---------+----------+--------+---------+--------+--------+
| T6Options| | 0 | | | | 0 |
+----------+---------+----------+--------+---------+--------+--------+
| XPosition| | | | | | r |
+----------+---------+----------+--------+---------+--------+--------+
| YPosition| | | | | | r |
+----------+---------+----------+--------+---------+--------+--------+
+---------------------------------------------------------+ | ファックスプロフィール| +---------------------------------------------------------| | 最小量| 広がっています。| JBIG| 損失性|Lossless| Mixed| +----------| B&W| B&W| B&W| 色| 色| ラスタ| | いさかい| | | | | | 内容| | 分野| S| F| J| C| L| M| +----------+---------+----------+--------+---------+--------+--------+ | 彩度| | | | 1 | | 1 | | 位置| | | | | | | | ing| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | 彩度| | | | <1、1>。| | <1、1>。| | SubSampl| | | | <2、2>。| | <2、2>。| | ing| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | ドキュメント| | ASCII| ASCII| ASCII| ASCII| ASCII| | 名前| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | 索引をつけられます。| | | | | 0,1 | 0,1 | +----------+---------+----------+--------+---------+--------+--------+ | ページ| n、m| n、m| n、m| n、m| n、m| n、m| | 数| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | SubIFDs| | | | | | <IFD>。| +----------+---------+----------+--------+---------+--------+--------+ | T4Options| 0, 4 | 0, 1, | | | | 0, 1, | | | | 4, 5 | | | | 4, 5 | +----------+---------+----------+--------+---------+--------+--------+ | T6Options| | 0 | | | | 0 | +----------+---------+----------+--------+---------+--------+--------+ | XPosition| | | | | | r| +----------+---------+----------+--------+---------+--------+--------+ | YPosition| | | | | | r| +----------+---------+----------+--------+---------+--------+--------+
Buckley, et al. Standards Track [Page 79] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[79ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Table A.3 New Fields
A.3の新しい分野を見送ってください。
+---------------------------------------------------------+
| Fax Profile |
+---------------------------------------------------------|
| Minimal | Extended | JBIG | Lossy |Lossless| Mixed |
+----------| B&W | B&W | B&W | Color | Color | Raster |
| TIFF | | | | | | Content|
| Field | S | F | J | C | L | M |
+----------+---------+----------+--------+---------+--------+--------+
| BadFax- | | n | | | | |
| Lines | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| CleanFax-| | 0, 1, 2 | | | | |
| Data | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Coding- | | | n | n | n | n |
| Method | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Consecu- | | n | | | | |
| tiveBad- | | | | | | |
| FaxLines | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Decode | | | | <r> | <r> | <r> |
+----------+---------+----------+--------+---------+--------+--------+
| Fax- | | | n | n | n | n |
| Profile | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Global- | | IFD | IFD | IFD | IFD | IFD |
| Parame- | | | | | | |
| tersIFD | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | | | | | | n, m |
| Layer | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| T82- | | | n | | | n |
| Options | | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Image- | | | | | | <n> |
| BaseColor| | | | | | |
+----------+---------+----------+--------+---------+--------+--------+
| Mode- | | | | | | n |
| Number | | | | | | |
+----------+---------+----------+--------+---------+--------+--------|
| Profile- | | | n | n | n | n |
| Type | | | | | | |
+--------------------------------------------------------------------+
+---------------------------------------------------------+ | ファックスプロフィール| +---------------------------------------------------------| | 最小量| 広がっています。| JBIG| 損失性|Lossless| Mixed| +----------| B&W| B&W| B&W| 色| 色| ラスタ| | いさかい| | | | | | 内容| | 分野| S| F| J| C| L| M| +----------+---------+----------+--------+---------+--------+--------+ | BadFax| | n| | | | | | 線| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | CleanFax| | 0, 1, 2 | | | | | | データ| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | コード化| | | n| n| n| n| | 方法| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | Consecu| | n| | | | | | tiveBad| | | | | | | | FaxLines| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | 解読してください。| | | | <r>。| <r>。| <r>。| +----------+---------+----------+--------+---------+--------+--------+ | ファックス| | | n| n| n| n| | プロフィール| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | グローバル| | IFD| IFD| IFD| IFD| IFD| | パラメ| | | | | | | | tersIFD| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | イメージ| | | | | | n、m| | 層| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | T82| | | n| | | n| | オプション| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | イメージ| | | | | | <n>。| | BaseColor| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | モード| | | | | | n| | 数| | | | | | | +----------+---------+----------+--------+---------+--------+--------| | プロフィール| | | n| n| n| n| | タイプ| | | | | | | +--------------------------------------------------------------------+
Buckley, et al. Standards Track [Page 80] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[80ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+----------+---------+----------+--------+---------+--------+--------+ | Strip- | | | | | | <n> | | RowCounts| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | Version- | | | | <b> |<b> | | | Year | | | | | | | +----------+---------+----------+--------+---------+--------+--------+
+----------+---------+----------+--------+---------+--------+--------+ | 片| | | | | | <n>。| | RowCounts| | | | | | | +----------+---------+----------+--------+---------+--------+--------+ | バージョン| | | | <b>。|<b>。| | | 年| | | | | | | +----------+---------+----------+--------+---------+--------+--------+
Annex B: List of technical edits to RFC2301
別館B: RFC2301への技術的な編集のリスト
This Annex lists technical differences between this document and RFC 2301, the Proposed Standard File Format for Internet Fax.
このAnnexはインターネットファックスのためにこのドキュメントとRFC2301、Proposed Standard File Formatの技術的な違いを記載します。
+----+---------+-------------------------------------------------+ | No.| Section | Technical Edit | +----+---------+-------------------------------------------------+ | 1. | 5.2.1 | Added FillOrder=1 to Profile J | +----+---------+-------------------------------------------------+ | 2. | 6.2.1 | Constrained ResolutionUnit to 2 (i.e., inch) for| | | 7.2.1 | all color profiles, per ITU-T Recommendations | | | 8.2.1 | | +----+---------+-------------------------------------------------+ | 3. | 7.2.1 | Deleted ColorMap field; it re-encoded the color | | | 7.4 | palette already in the T.43 data stream | +----+---------+-------------------------------------------------+ | 4. | 7.2.2 | Changed TAG value of Indexed field from 364 to | | | | 346 to agree with Section 8.2.2 and Ref. [TTN1] | +----+---------+-------------------------------------------------+ | 5. | 8.2.1 | Added text clarifying the use of ImageWidth | | | | when Background or Foreground layer is Primary | | | | IFD | +----+---------+-------------------------------------------------+ | 6. | 8.2.3 | Changed field name from DefaultImageColor to | | | | ImageBaseColor; | +----+---------+-------------------------------------------------+ | 7. | 8.2.1 | Added Compression=1 for ImageBaseColor IFDs | +----+---------+-------------------------------------------------+ | 8. | 5.2.1 | Redefined compression = 9 to be T.82 (JBIG); | | | 5.2.3 | added T82Options field, with a default value (0)| | | | corresponding to the T.85 application profile | +----+---------+-------------------------------------------------+ | 9. | 4.3.3 | Added GlobalParametersIFD, ProfileType, | | | 4.7 | FaxProfile and CodingMethod to the New Fields | | | | portion of Profile F, per Sec. 2.2.4 | +----+---------+-------------------------------------------------+
+----+---------+-------------------------------------------------+ | いいえ| セクション| 技術的な編集| +----+---------+-------------------------------------------------+ | 1. | 5.2.1 | Jの輪郭を描く加えられたFillOrder=1| +----+---------+-------------------------------------------------+ | 2. | 6.2.1 | 2へのResolutionUnitを抑制します(すなわち、少しずつ動きます)。| | | 7.2.1 | すべてのITU-T Recommendationsあたりのカラープロフィール| | | 8.2.1 | | +----+---------+-------------------------------------------------+ | 3. | 7.2.1 | 削除されたColorMap分野。 それは色を再コード化しました。| | | 7.4 | 既にT.43データ・ストリームのパレット| +----+---------+-------------------------------------------------+ | 4. | 7.2.2 | 364からのIndexed分野のTAG値を変えます。| | | | 346 セクション8.2の.2とRefに同意するために。 [TTN1]| +----+---------+-------------------------------------------------+ | 5. | 8.2.1 | ImageWidthの使用をはっきりさせる加えられたテキスト| | | | BackgroundかForeground層がPrimaryであるときに| | | | IFD| +----+---------+-------------------------------------------------+ | 6. | 8.2.3 | DefaultImageColorからのフィールド名を変えます。| | | | ImageBaseColor。 | +----+---------+-------------------------------------------------+ | 7. | 8.2.1 | ImageBaseColor IFDsのための加えられた圧縮=1| +----+---------+-------------------------------------------------+ | 8. | 5.2.1 | T.82(JBIG)になるように圧縮=9を再定義します。 | | | 5.2.3 | デフォルト値(0)がある加えられたT82Options分野| | | | T.85アプリケーションプロフィールに対応しています。| +----+---------+-------------------------------------------------+ | 9. | 4.3.3 | GlobalParametersIFD、ProfileTypeを加えました。| | | 4.7 | 新しい分野へのFaxProfileとCodingMethod| | | | 1SecあたりのProfile Fの一部。 2.2.4 | +----+---------+-------------------------------------------------+
Buckley, et al. Standards Track [Page 81] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[81ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
+----+---------+-------------------------------------------------+ | 10.| 6.2.1 | Deleted BitsPerSample=12 as an option when | | |6.2.3,6.4| Compression=7 due to lack of interop testing. | | |Table A.1| | +----+---------+-------------------------------------------------+ | 11.|8.2.1,8.4| Deleted PhotometricInterpretation=5 in Profile M| | |Table A.1| due to insufficient interop testing. | +----+---------+-------------------------------------------------+ | 12.|7.2.1,7.4| Deleted BitsPerSample=13-16 for Palette-color | | |8.2.1,8.5| due to lack of interop testing. | | |Table A.1| | +----+---------+-------------------------------------------------+ | 13.| Annex B | Deleted Annex B due to discontinued use of | | | | application parameter; Annex C renamed Annex B | +----+---------+-------------------------------------------------+
+----+---------+-------------------------------------------------+ | 10.| 6.2.1 | オプションとしてBitsPerSample=12を削除する、いつ| | |6.2.3,6.4| 圧縮は欠いているinteropテストの7支払われるべきものと等しいです。 | | |テーブルA.1| | +----+---------+-------------------------------------------------+ | 11.|8.2.1,8.4| プロフィールMの削除されたPhotometricInterpretation=5| | |テーブルA.1| 不十分なinteropテストのため。 | +----+---------+-------------------------------------------------+ | 12.|7.2.1,7.4| パレット色のための削除されたBitsPerSample=13-16| | |8.2.1,8.5| interopテストの不足のため。 | | |テーブルA.1| | +----+---------+-------------------------------------------------+ | 13. | 別館B| 中止された使用によるAnnex Bを削除します。| | | | アプリケーションパラメタ。 Annex Bに改名された別館C| +----+---------+-------------------------------------------------+
Authors' Addresses
作者のアドレス
Robert Buckley Xerox Corporation Mailstop 0128-30E 800 Phillips Road Webster, NY 14580, USA
ニューヨーク 14580、800Eのロバートバックリーゼロックス社のMailstop0128-30フィリップスのRoadウェブスター(米国)
Phone: +1-585-422-1282 Fax: +1-585-422-2636 EMail: rbuckley@crt.xerox.com
以下に電話をしてください。 +1-585-422-1282 Fax: +1-585-422-2636 メールしてください: rbuckley@crt.xerox.com
Dennis Venable Xerox Corporation Mailstop 0128-27E 800 Phillips Road Webster, NY 14580, USA
ニューヨーク 14580、800Eのデニスヴェナブルゼロックス社のMailstop0128-27フィリップスのRoadウェブスター(米国)
Phone: +1-585-422-3138 Fax: +1-585-422-6117 EMail: dvenable@crt.xerox.com
以下に電話をしてください。 +1-585-422-3138 Fax: +1-585-422-6117 メールしてください: dvenable@crt.xerox.com
Buckley, et al. Standards Track [Page 82] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[82ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Lloyd McIntyre 10328 S. Stelling Road Cupertino, CA 95014 USA
ロイドマッキンタイヤ10328秒間Stelling Roadカルパチーノ、カリフォルニア95014米国
Phone: +1-408-725-1624
EMail: lloyd10328@pacbell.net or
Lloyd_McIntyre@Dell.com
以下に電話をしてください。 +1-408-725-1624 メールしてください: lloyd10328@pacbell.net かロイド_マッキンタイヤ@Dell.com
Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7, Canada
グレンW.ノーテル教区牧師は私書箱3511、駅のCオタワをK1Y 4H7、カナダにネットワークでつなぎます。
Phone: +1-613-763-7582 Fax: +1-613-967-5060 EMail: gparsons@nortel.com
以下に電話をしてください。 +1-613-763-7582 Fax: +1-613-967-5060 メールしてください: gparsons@nortel.com
James Rafferty Brooktrout Technology 410 First Avenue Needham, MA 02494 USA
ジェームスRafferty Brooktrout Technology410First Avenue・MA02494ニーダム(米国)
Phone: +1-781-433-9462 Fax: +1-781-433-9268 EMail: jraff@brooktrout.com
以下に電話をしてください。 +1-781-433-9462 Fax: +1-781-433-9268 メールしてください: jraff@brooktrout.com
Buckley, et al. Standards Track [Page 83] RFC 3949 File Format for Internet Fax February 2005
バックリー、他 標準化過程[83ページ]RFC3949はファックス2005年2月にインターネットに形式をファイルします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Buckley, et al. Standards Track [Page 84]
バックリー、他 標準化過程[84ページ]
一覧
スポンサーリンク
