RFC1314 日本語訳
1314 A File Format for the Exchange of Images in the Internet. A.Katz, D. Cohen. April 1992. (Format: TXT=54072 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Katz
Request for Comments: 1314 D. Cohen
ISI
April 1992
コメントを求めるワーキンググループA.キャッツ要求をネットワークでつないでください: 1314 D.コーエンISI1992年4月
A File Format for the Exchange of Images in the Internet
インターネットのイメージズの交換のためのファイル形式
Status of This Memo
このメモの状態
This document specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、IAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document defines a standard file format for the exchange of fax-like black and white images within the Internet. It is a product of the Network Fax Working Group of the Internet Engineering Task Force (IETF).
このドキュメントはファックスのような白黒のイメージの交換のためにインターネットの中で標準ファイル書式を定義します。 それはNetworkファックスインターネット・エンジニアリング・タスク・フォース(IETF)作業部会の製品です。
The standard is:
規格は以下の通りです。
** The file format should be TIFF-B with multi-page files
supported. Images should be encoded as one TIFF strip
per page.
** ファイル形式はサポートされたマルチページファイルがあるTIFF-Bであるべきです。 イメージズは1ページあたり1TIFF片としてコード化されるべきです。
** Images should be compressed using MMR when possible. Images
may also be MH or MR compressed or uncompressed. If MH or MR
compression is used, scan lines should be "byte-aligned".
** イメージズは、可能であるときに、MMRを使用することで圧縮されるべきです。 また、イメージズは、圧縮されたか、または解凍されたMHかMRであるかもしれません。 MHかMR圧縮が使用されているなら、スキャン系列は「バイトで、並べられるべきです」。
** For maximum interoperability, image resolutions should
either be 600, 400, or 300 dpi; or else be one of the
standard Group 3 fax resolutions (98 or 196 dpi
vertically and 204 dpi horizontally).
** 最大限のインターオペラビリティのために、イメージ解決は600、400、または300dpiであるべきです。 または、標準のGroup3ファックス解決の1つになってください、(98か196dpi、垂直である、204dpi、水平に)
Note that this specification is self contained and an implementation should be possible without recourse to the TIFF references, and that only the specific TIFF documents cited are relevant to this specification. Updates to the TIFF documents do not change this specification.
この仕様が独立であって、実装が償還請求なしでTIFF参照に可能であるべきであり、ドキュメントが引用した特定のTIFFだけがこの仕様に関連していることに注意してください。 TIFFドキュメントへのアップデートはこの仕様を変えません。
Experimentation with this file format specified here is encouraged.
このファイル形式がここで指定されている実験は奨励されます。
Katz & Cohen [Page 1] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[1ページ]RFC1314イメージは1992年4月に形式を交換します。
1. Introduction
1. 序論
The purpose of this document is to define a standard file format for exchange of black and white images using the Internet. Since many organizations have already started to accumulate and exchange scanned documents it is important to reach agreement about an interchange file format in order to promote and facilitate the exchange and distribution of such documents. These images may originate from scanners, software, or facsimile (fax) machines. They may be manipulated by software, communicated, shared, duplicated, displayed, printed by laser printers, or faxed.
このドキュメントの目的は白黒のイメージの交換のためにインターネットを使用することで標準ファイル書式を定義することです。 多くの団体が既に蓄積し始めて、交換がドキュメントをスキャンしたので、置き換えファイル形式に関する合意に達するのはそのようなドキュメントの交換と分配を促進して、容易にするために重要です。 これらのイメージはスキャナ、ソフトウェア、またはファクシミリ(ファックス)マシンから発するかもしれません。 それらをソフトウェアで操るか、コミュニケートするか、共有するか、コピーするか、表示するか、レーザープリンタで印刷するか、またはファックスで送るかもしれません。
This file format provides for the uniform transfer of high quality images at a reasonable cost and with reasonable speed whether these files are generated by scanners, totally by software (e.g., text-to- fax, bitmap-to-fax, OCR, etc), or by fax. Also the intent of this document is to remain compatible with future moves to multi-level (i.e., gray-scale), higher resolution, or color images. The format proposed here is supported by both commercially available hardware and commercial and public domain software for most popular platforms in current use.
これらのファイルがスキャナ、完全にソフトウェア(例えば、テキストからファックス、ビットマップからファックス、OCRなど)、またはファックスによって生成されるか否かに関係なく、手頃な費用において妥当な速度でこのファイル形式は高い品質イメージの一定の転送に備えます。 また、このドキュメントの意図はマルチレベル(すなわち、グレー・スケール)、より高い解像度、またはカラーイメージに今後の動きと互換性があったままで残ることになっています。 ここで提案された形式は商業的に利用可能なハードウェアとコマーシャルとパブリックドメインソフトの両方によって現在の使用でのほとんどのポピュラーなプラットホームにサポートされます。
The file format for images is a totally separate issue from how such files are to be communicated. For example, FTP or SMTP could be used to move an image file from one host to another, although there are complications in the use of SMTP as currently implemented due to file size and the need to move binary data. (There is currently a proposal for removing these limitations from SMTP and in particular extending it to allow binary data. See reference [1].)
イメージのためのファイル形式はどうコミュニケートするかからのそのようなファイルがことである完全に別々の問題です。 例えば、1人のホストから別のものへイメージ・ファイルを移すのにFTPかSMTPを使用できました、ファイルサイズによる現在実装されるとしてのSMTPの使用とバイナリ・データを動かす必要には複雑さがありますが。 (現在、SMTPからこれらの制限を取り除いて、バイナリ・データを許容するためにそれを特に広げるための提案があります。 参照[1]を見てください。)
One major potential application of the communications format defined here is to allow images to be sent to fax machines using the Internet. It is intended that one or more separate companion documents will be formulated to address the issues of standardization in the areas of protocols for transmitting images through the Internet and the issues of addressing fax machines and routing faxes. Just as the exchange format is separate from the transmission mechanism, it is also separate from how hosts store images.
ここで定義されたコミュニケーション書式の1つの主要な潜在的適用はイメージがファックスでインターネットを使用することでマシンを送るために送られるのを許容することです。 1通以上の別々の仲間ドキュメントがインターネットを通してイメージを送るためのプロトコルの領域の標準化の問題とファックス装置とルーティングがファックスであると扱う問題を扱うために定式化されることを意図します。 また、ちょうど交換形式が効果波及経路から別々であるように、ホストがどうイメージを保存するかからそれも別々です。
This document specifies a common exchange format; it does not require a host to store images in the format specified here, only to convert between the host's local image storage formats and the exchange format defined here for the purpose of exchanging images with other hosts across the network.
このドキュメントは一般的な交換形式を指定します。 ここで指定された形式でイメージを保存して、ネットワークの向こう側に他のホストとイメージを交換する目的のためにここで定義されたホストの地方の画像蓄積書式と交換書式の間で単に変換するのがホストを必要としません。
This standard specifies the use of TIFF (Tagged Image File Format, see below) as a format for exchange of image files. This is not a specific image encoding, but a framework for many encoding
この規格はイメージ・ファイルの交換のための形式としてTIFF(タグ付けをされたImage File Format、以下を見る)の使用を指定します。 これは特定のイメージコード化ではありませんが、多くのためのフレームワークはコード化です。
Katz & Cohen [Page 2] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[2ページ]RFC1314イメージは1992年4月に形式を交換します。
techniques, that can be used within the TIFF framework. For example, within TIFF it is possible to use MMR (the data encoding of CCITT Group 4 fax, see below), MH or MR (the data encodings of CCITT Group 3 fax), or other encoding methods.
テクニックであり、TIFFフレームワークの中でそれを使用できます。 例えば、TIFFの中では、MMR(データが4がファックスするCCITT Groupをコード化して、以下を見る)、MHまたはMR(CCITT Group3ファックスのデータencodings)を使用するのは可能です、メソッドをコード化しながら何らかの。
Which encoding technique to use is not specified here. Instead, with time the encoding schemes used by most document providers will emerge as the de-facto standard. Therefore, we do not declare any as "the standard data encoding scheme," just as we do not declare that English is the standard publication language. (However, we expect that most document providers will use MMR in the immediate future because it offers much better compression ratios than MH or MR.)
使用するテクニックをコード化するのが、どれでないかがここで指定しました。 代わりに、時間で、体系がほとんどのドキュメントプロバイダーで使用したコード化はデファクト規格として現れるでしょう。 したがって、私たちは「標準のzデータの符号化体系」としていずれも宣言しません、私たちが、英語が標準の公表言語であると宣言するだけではないように。 (しかしながら、私たちは、もっとも近い将来においてMHかMRよりはるかに良い圧縮比を提供するのでほとんどのドキュメントプロバイダーがMMRを使用すると予想します。)
Similarly, TIFF does not require that an image be communicated at a specific resolution. Resolution is a parameter in the TIFF descriptive header. We do suggest that images now be sent using one of a set of common resolutions in the interests of interoperability, but the format accommodates other resolutions that may be required by specialized applications or changing technologies.
同様に、TIFFは、イメージが特定の解決のときに伝えられるのを必要としません。 解決はTIFFの描写的であるヘッダーのパラメタです。 私たちは、イメージは現在相互運用性のために1セットの一般的な解決の1つを使用させられることを提案しますが、形式は専門化しているアプリケーションで必要である、または技術を変えているかもしれない他の決議を収容します。
Occasionally, image files will have to be converted, such as in the case where a document that was scanned at 400 dpi is to be printed on a 300 dpi printer. This conversion could be performed by the document provider, by the consumer, or by a third party. This document specifies neither who performs the conversion, nor which algorithms should be used to accomplish it.
時折、イメージ・ファイルは変換されなければならないでしょう、ケースなどのように中300dpiプリンタに印刷される400dpiでスキャンされたドキュメントがことである。 ドキュメントプロバイダー、消費者、または第三者がこの変換を実行できました。 このドキュメントは、だれが変換を実行するか、そして、どのアルゴリズムがそれを達成するのに使用されるべきであるかをどちらも指定しません。
Note that this standard does not attempt to define an exchange format for all image types that may be transmitted in the Internet. Nothing in this standard precludes it from being used for other image type such as gray-scale (e.g., JPEG) or color images but, for the purposes of standardization, the scope of this document is restricted to monochromatic bitmapped images.
この規格が、インターネットで伝えられるかもしれないすべてのイメージタイプのために交換書式を定義するのを試みないことに注意してください。 この規格における何もグレー・スケール(例えば、JPEG)かカラーイメージなどの他のイメージタイプに使用されるので、それを排除しませんが、標準化の目的のために、このドキュメントの範囲はモノクロのビットマップ画像に制限されます。
The developers of this standard recognize that it may have a limited lifespan as Office Document Architecture (ODA) matures and comes into use in the Internet; ultimately the class of images covered by this standard will likely be subsumed by the more general class of images supported by the ODA standards. However, at present, there does not appear to be a sufficient installed base of ODA compliant software and the ODA standards are not fully mature. This standard is intended to fill the need for a common image transfer format until ODA is ready. Finally, we believe that it should be possible to automatically map images encoded in the format specified here into a future ODA-based image interchange format, thus providing a reasonable transition path to these future standards.
この規格の開発者は、オフィスDocument Architecture(ODA)がインターネットで使用に熟して、入るときそれには限られた寿命があるかもしれないと認めます。 結局、この規格でカバーされたイメージのクラスはODA規格によってサポートされたより一般的なクラスのイメージによっておそらく包括されるでしょう。 しかしながら、ODA対応することのソフトウェアの十分なインストールされたベースは現在のところあるように見えません、そして、ODA規格は完全に熟しているというわけではありません。 ODAが準備ができるまでこの規格が一般的な画像転送形式の必要性をいっぱいにすることを意図します。 最終的に、私たちは、自動的にここで将来のODAベースのイメージ置き換え形式に指定された形式でコード化されたイメージを写像するのが可能であるべきであると信じています、その結果、妥当な変遷経路をこれらの将来の規格に提供します。
Katz & Cohen [Page 3] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[3ページ]RFC1314イメージは1992年4月に形式を交換します。
2. Relationship to Fax
2. ファックスで送る関係
Transmission of facsimile (fax) images over phone lines is becoming increasingly widespread. The standard of most fax machines in the U.S. is CCITT Group 3 (G3), specified in Recommendations T.4 and T.30 [2] and in EIA Standards EIA-465 and EIA-466. G3 faxes are 204 dots per inch (dpi) horizontally and 98 dpi (196 dpi optionally, in fine-detail mode) vertically. Since G3 neither assumes error free transmission nor retransmits when errors occur, the encoding scheme used is differential only over small segments never exceeding 2 lines at standard resolution or 4 lines for fine-detail. (The incremental G3 encoding scheme is called two-dimensional and the number of lines so encoded is specified by a parameter called k.)
電話回線でのファクシミリ(ファックス)イメージの伝達はますます広範囲になっています。 米国のほとんどのファックス装置の規格はRecommendations T.4とT.30[2]とEIA Standards EIA-465とEIA-466で指定されたCCITT Group3です(G3)。 G3ファックスは水平にインチ(dpi)あたり204のドットであり、98はdpi(196dpiは任意に、そして、中でモードを罰金で詳しく述べる)です。垂直に。 G3が誤りが無料のトランスミッションであると仮定しないで、また誤りが発生する場合再送しないので、使用されるコード化体系は詳しい詳細のために標準の解決か4つの系列で2つの系列を決して超えないことで小さいセグメントだけの上で特異です。 (体系をコード化する増加のG3は二次元であると呼ばれます、そして、そのようにコード化された系列の数はk.と呼ばれるパラメタによって指定されます)
CCITT Group 4 fax (G4) is defined by the T.400 and T.500 series of Recommendations as well as Recommendation T.6 [2]. It provides for 400 dpi (both vertical and horizontal) and is a fully two-dimensional encoding scheme (k is infinite) called MMR (Modified Modified READ, where READ stands for: Relative Element Address Designate). G4 assumes an error free transmission medium (generally an X.25 Public Data Network, or PDN). Because of this, G4 is not in widespread use in the U.S. today.
Group4がファックスするCCITT(G4)はRecommendation T.6[2]と同様にRecommendationsのT.400とT.500シリーズによって定義されます。 それは、400dpiに備えて(垂直なものと同様に水平な)、MMR(READが立つ変更されたModified READ: 親類Element Address Designate)と呼ばれる完全に二次元のコード化体系(kは無限である)です。 G4は、エラーのないトランスミッション媒体が(一般にX.25 Public Data Network、またはPDN)であると仮定します。 これのために、G4は今日、普及使用米国で中ではありません。
The traditional fax bundles together four independent issues:
伝統的なファックスは独立している4冊を一緒に添付します:
(1) Data presentation and compression;
(2) Data transmission;
(3) Image input from paper ("scanning"); and
(4) Image output to paper ("printing").
(1) データの表現と圧縮。 (2) データ伝送。 (3) 紙(「スキャンする」)からの画像入力。 (4) そして、紙(「印刷」)へのイメージ出力。
This bundling supports, for example, the high quality CCITT Group 4 (G4) images (400x400 dpi) but only over X.25 public data networks with error correction, and similarly it supports the mid-quality CCITT Group 3 (204x98 and 204x196 dpi) but only over phone voice circuits (the Switched Telephone Network, or STN) without error correction. This bundling does not support the use of any other data transmission capabilities (e.g., FTP over LANs and WANs), nor asynchrony between the scanning and the printing, nor image storage, nor the use of the popular laser printers for output (even though they are perfectly capable of doing so).
これがサポートを添付して、例えば、高品質のCCITT Group4(G4)イメージ(400×400dpi)にもかかわらず、単にエラー修正があるX.25公衆データネットワークの上、そして、同様に、中間の品質CCITT Group3(204×98と204×196dpi)をサポートしますが、電話だけで、エラー修正なしで回路(Switched Telephone Network、またはSTN)を声に出してください。 このバンドリングはいかなる他のデータ伝送能力(例えば、LANとWANの上のFTP)の使用、およびスキャンと、印刷と、画像蓄積と、ポピュラーなレーザープリンタの出力の使用の間の非同期もサポートしません(そう完全にすることができますが)。
In conventional fax, images are never stored. In today's computer network environment, a better model is:
従来のファックスで、イメージは決して保存されません。 今日のコンピュータネットワーク環境で、より良いモデルは以下の通りです。
(1) Images are scanned into files or created by software;
(2) These image files are stored, manipulated, or communicated;
(3) Images in a file are printed or displayed.
(1) イメージズは、ファイルの中にスキャンされるか、またはソフトウェアによって作成されます。 (2) これらのイメージ・ファイルは、保存されるか、操作されるか、または伝えられます。 (3) ファイルのイメージズを印刷するか、または表示します。
Katz & Cohen [Page 4] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[4ページ]RFC1314イメージは1992年4月に形式を交換します。
The only feature of the CCITT fax that should be used is the encoding technique (preferably MMR, but with MR or MH allowed) which may be implemented with a variety of fax-oriented chips at low cost due to the popularity of fax.
使用されるべきであるCCITTファックスの唯一の特徴がわずかの費用でファックスの人気のためさまざまなファックス指向のチップで実装されるかもしれない(望ましくはMMRにもかかわらず、許容されるMRかMHと共に)のコード化のテクニックです。
"Sending a fax" means both encoding (and decoding) the fax images as well as transmitting the data. Since the Internet ALREADY provides several mechanisms for data transmission (in particular, FTP for general file transmission), it is unnecessary to use the data transmission methods specified in the CCITT standard. Within the Internet, each fax image should be stored in a file and these files could be transferred (e.g., using FTP, SMTP, RPC-based methods, etc.).
「ファックスを送信します」は、ファックスイメージをコード化して(そして、解読します)、データを送ることを意味します。 インターネットALREADYがデータ伝送(一般的なファイルトランスミッションのための特にFTP)に数個のメカニズムを提供するので、CCITT規格で指定されたデータ伝送メソッドを使用するのは不要です。 インターネットの中では、ファイルにそれぞれのファックスイメージを保存するべきでした、そして、これらのファイルを移すことができました(例えば、FTP、SMTP、RPCベースのメソッドなどを使用します)。
Fax machines should be considered just as scanners and printers are, as I/O devices between paper and files; but not as a transmission means. Higher quality Group 4 images are thus supported at low cost, while enjoying the freedom to use any computerized file transfer and duplication mechanism, standard laser printers, multiple printing (possibly at multiple remote sites) of the same image without having to rescan it physically, and a variety of software for various processing of these images, such as OCR and various drawing programs. We should be able to interoperate with files created by fax machines, scanners, or software and to be able to print all of them on fax machines or on laser printers.
ファックス装置はちょうどスキャナと考えられるべきです、そして、紙とファイルの間には、入出力デバイスとしてプリンタがあります。 しかし、トランスミッションが意味しないように。 より高い上質のGroup4イメージはこのようにしてわずかの費用でサポートされます; どんなコンピューター化しているファイル転送と複製メカニズムも使用する自由を楽しんでいる間、標準のレーザープリンタ、同じイメージの物理的にそれを再スキャンする必要はなくて複数の印刷(ことによると複数のリモートサイトの)、およびプログラムOCRの、そして、様々な描いている私たちなどのこれらのイメージの様々な処理のためのさまざまなソフトウェアが、ファックス装置、スキャナ、またはソフトウェアによって作成されたファイルで共同利用して、ファックス装置の上、または、レーザープリンタの上でそれらを皆、印刷するはずであることができます。
The CCITT Recommendations assume realtime communications between fax machines and do not therefore specify any kind of fax file format. We propose using TIFF [3] which seems to be emerging as a standard, for encapsulation of encoded images. Because they assume realtime communications, the CCITT fax protocols require negotiations to take place between the sender and receiver. For example, they negotiate whether to use two-dimensional coding (and with what k parameter) and what (if any) padding there is between scan lines.
CCITT Recommendationsはファックス装置のリアルタイムでコミュニケーションを仮定して、したがって、どんな種類のファックスファイル形式も指定しません。 私たちは、コード化されたイメージのカプセル化の規格として現れているように思えるTIFF[3]を使用するよう提案します。 彼らがリアルタイムでコミュニケーションを仮定するので、CCITTファックスプロトコルは送付者と受信機の間の場所を取るために交渉を必要とします。例えば、それらは二次元コード化(そしてどんなkパラメタで)を使用するか、そして、そこでそっと歩くのが(もしあれば)、スキャン系列の間のものであることを交渉します。
In our approach, the image in the file is already compressed in a particular manner. If it is to be sent to an ordinary fax machine using a fax board/modem, that board will perform the negotiations with the receiving fax machine. In the cases where the receiver cannot handle the type of compression used in the file, it will be necessary to convert the image to another compression scheme before transmission. (Most fax cards seem to either store images using the default values of the parameters which are negotiated or in a format which can quickly be converted to this. With currently available hardware and software, any necessary format conversion should be easy to accomplish.)
私たちのアプローチでは、ファイルのイメージは既に特定の方法で圧縮されます。 ファックスボード/モデムを使用することで普通のファックス装置にそれを送るつもりであると、そのボードは受信ファックス装置との交渉を実行するでしょう。 受信機がファイルで使用される圧縮のタイプを扱うことができない場合では、トランスミッションの前に別の圧縮技術にイメージを変換するのが必要でしょう。 (ほとんどのファックスカードが交渉されるパラメタのデフォルト値を使用するストアイメージかすぐにこれに変換できる形式で見えます。 現在利用可能なハードウェアとソフトウェアでは、どんな必要なフォーマット変換も達成するのが簡単であるはずです。)
In conventional fax, if the compression used for a particular image
特定のイメージに、中古の圧縮であることでのコネ従来のファックス
Katz & Cohen [Page 5] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[5ページ]RFC1314イメージは1992年4月に形式を交換します。
is "negative" (i.e., the compressed form is larger than the uncompressed form, something that happens quite frequently with dithered photographic images), the larger compressed form of the image is still sent. If the images are first scanned into files, this problem could be recognized and the smaller, uncompressed file sent instead. (Also, Recommendations T.4 and T.6 [2] allow for an "uncompressed mode." Thus, lines which have negative compression may each be sent uncompressed. However, very few G3 fax machines support this mode.)
「否定的(すなわち、圧縮形は解凍されたフォームより大きいです、かなり頻繁にうろたえた画像で起こる何か)で」、より大きいイメージの圧縮されたフォームがまだ送られることはそうですか? イメージが最初にファイルの中にスキャンされるなら、この問題は認識されたかもしれません、そして、より小さくて、解凍されたファイルは代わりに発信しました。 (また、Recommendations T.4とT.6[2]は「解凍されたモード」を考慮します。 したがって、それぞれ解凍されていた状態で否定的圧縮を持っている系列を送るかもしれません。 しかしながら、ほんのわずかなG3ファックス装置はこのモードをサポートします。)
3. Image File Format
3. 画像ファイル形式
Image files should be in the TIFF-B format which is the bi-level subclass of TIFF. TIFF and TIFF-B are described in reference [3], cited at the end of this document. Images should be compressed using MMR (the G4 compression scheme) because it offers superior compression ratios. However, images may also be compressed using MH or MR (the G3 methods). MMR offers much better compression ratios than these (which are used in G3 fax because of the lack of an error-free communications path).
TIFFの両性愛者のレベルサブクラスであるTIFF-B形式にはイメージ・ファイルがあるはずです。 TIFFとTIFF-Bはこのドキュメントの端で引用された参照[3]で説明されます。 イメージズは、優れた圧縮比を提供するので、MMR(G4圧縮技術)を使用することで圧縮されるべきです。 しかしながら、また、イメージは、MHかMR(G3メソッド)を使用することで圧縮されるかもしれません。 MMRはこれら(エラーのないコミュニケーション経路の不足のためにG3ファックスで使用される)よりはるかに良い圧縮比を提供します。
TIFF-F, described in [4], is the proposed subclass of TIFF-B for fax images. However, since TIFF-F was intended for use with G3, it recommends against certain features we recommend. Specifically, it suggests not using MMR or MR compression (we recommend MMR and allow MR) and prohibits uncompressed mode (which we allow and suggest for some photographic images). Apart from these, the TIFF-F restrictions should be followed. (Complete compatibility between the format specified here and TIFF-F can only be guaranteed for MH compressed images.)
[4]で説明されたTIFF-FはファックスイメージのためのTIFF-Bの提案されたサブクラスです。 しかしながら、TIFF-FがG3との使用のために意図したので、それはあるに対して私たちが推薦する特徴を推薦します。 明確に、それは、MMRかMR圧縮(私たちは、MMRを推薦して、MRを許す)を使用するのを示さないで、解凍されたモード(私たちがいくつかの画像のために許容して、勧める)を禁止します。 これらは別として、TIFF-F制限は続かれるべきです。 (MH圧縮画像のためにここで指定された形式とTIFF-Fとの完全な両立性を保証できるだけです。)
[NOTE: Aldus Corp., the TIFF Developer, considers fax
applications to be outside the scope of mainstream TIFF
since it is not a part of general publishing which is
what TIFF was originally designed for. They specify the
LZW [5] compression scheme rather than MMR. We, however,
are concerned with the transmission and storage of images
rather than publishing. Therefore, we are more concerned
with compression ratios and compatibility with CCITT fax
than Aldus is.]
[以下に注意してください。 アルダス社(TIFF Developer)は、主流のTIFFの範囲の外にファックス利用がそれがTIFFが元々何において設計されたかということである一般的な出版の一部でないのであると考えます。 彼らはMMRよりむしろLZW[5]圧縮技術を指定します。しかしながら、私たちは出版よりむしろイメージのトランスミッションとストレージに関係があります。 したがって、私たちはアルダスよりCCITTファックスとの圧縮比と互換性に関係があります。]
TIFF itself allows for gray-scale and color images. Image files should be restricted to TIFF-B for now because most of the currently available hardware is bi-level (1 bit per pixel). In the future, when gray-scale or color scanners, printers, and fax becomes available, the file format suggested here can already accommodate it. (For example, though JPEG is not currently a TIFF defined compression type, work is currently underway for including it as such.)
TIFF自身はグレー・スケールとカラーイメージを考慮します。 現在利用可能なハードウェアの大部分が両性愛者のレベル(1画素あたり1ビット)であるので、イメージ・ファイルは当分TIFF-Bに制限されるべきです。 未来に、ここに示されたファイル形式は既にそれを収容できます。(その時、グレー・スケールかカラースキャナと、プリンタと、ファックスが利用可能になります)。 (現在、JPEGはそうではありませんが、例えば、TIFFは圧縮タイプを定義して、そういうものとしてそれを含んでいるのにおいて、仕事は現在、進行中です。)
Katz & Cohen [Page 6] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[6ページ]RFC1314イメージは1992年4月に形式を交換します。
[NOTE: In this document, we will use the term "reader"
or "TIFF reader" to refer to the process or device
which reads and parses a TIFF file.]
[注意: 本書では、私たちはTIFFファイルを読んで、分析するプロセスかデバイスについて言及するのに「読者」か「TIFF読者」という用語を使用するつもりです。]
3.A. TIFF File Format
3. A.いさかいファイル形式
Figure 1 below (reproduced here from Figure 1 of reference [3]) depicts the structure of a TIFF file.
以下の図1、(ここで参照の図1から再生して、[3])はTIFFファイルの構造について表現します。
TIFF files start with a file header which specifies the byte order used in the file (i.e., Big or Little Endian), the TIFF version number, and points to the first "Image File Directory" (IFD). If the first two bytes are hex 4D4D, the byte order is from most to least significant for both 16 and 32 bit integers (Big Endian). If the first two bytes are hex 4949, the byte order is from least to most significant (Little Endian). In both formats, character strings are stored into sequential bytes and are null terminated.
TIFFファイルはファイル(すなわち、BigかリトルEndian)で使用されるバイトオーダー、TIFFバージョン番号を指定して、最初の「イメージ・ファイルディレクトリ」(IFD)を示すファイルヘッダーから始まります。 最初の2バイトが十六進法4D4Dであるなら、バイトオーダーは大部分から両方の16と32ビットの整数(大きいEndian)に最も重要に来ていません。 最初の2バイトが十六進法4949であるなら、最少から最も重要(小さいEndian)になりまでバイトオーダーがあります。 両方の形式では、文字列は、連続したバイトとして保存されて、終えられた状態でヌルです。
The next two bytes (called the TIFF Version) must be 42 (hex 002A). This does not refer to the current TIFF revision number. The following 4 bytes contain the offset (in bytes from the beginning of the file) to the first IFD.
次の2バイト(TIFFバージョンと呼ばれる)は42であるに違いありません(002Aに魔法をかけてください)。 これは現在のTIFF改訂番号を示しません。 以下の4バイトはオフセット(ファイルの始まりからのバイトによる)を最初のIFDに含んでいます。
An IFD contains a 2 byte count of the number of entries in the IFD, a sequence of 12 byte directory entries, and a 4 byte pointer to the next IFD. One of these fields (StripOffsets) points to (parts of) an image in the file. There may be more than one image in the file (e.g., a "multi-page" TIFF file) and therefore more then one IFD. IFD field entries may appear in any order.
IFDはIFDのエントリーの数、12バイトのディレクトリエントリーの系列、および次のIFDへの4バイトの指針の2バイト・カウントを含んでいます。 これらの分野(StripOffsets)のひとりが示す、(離れている、)、ファイルのイメージ。 そこでは、次に、ファイル(例えば、「マルチページ」TIFFファイル)の1つ以上のイメージとしたがって、その他が1IFDであったならそうするかもしれません。 IFDフィールド入力は順不同に現れるかもしれません。
Each directory entry is 12 bytes and consists of a tag, its type, a length, and an offset to its value. If the value can fit into 4 bytes (i.e., if the type is BYTE, SHORT, or LONG), the actual value rather than an offset is given. If the value is less than 4 bytes (i.e., if the type is BYTE or SHORT), it is left-justified within the 4 byte value offset. More details about directory entries and the possible tags will be given in Section 3.C.
各ディレクトリエントリは、12バイトであり、値にタグ、タイプ、長さ、およびオフセットから成ります。 値が4バイトに収まることができるなら(すなわち、タイプがBYTE、SHORT、またはLONGであるなら)、オフセットよりむしろ実価を与えます。 値が4バイト(すなわち、タイプがBYTEかSHORTであるなら)未満であるなら、4バイトの値のオフセットの中で左で正当です。 セクション3.Cでディレクトリエントリーと可能なタグに関するその他の詳細を与えるでしょう。
All pointers (called offsets in the TIFF reference [3]) are the number of bytes from the beginning of the file and are 4 bytes long. The first byte of the file has an offset of 0. In the case of only one image per file, there should therefore be only one IFD. The last IFD's pointer to the next IFD is set to hex 00000000 (32 bits).
すべての指針、(TIFF参照[3])における呼ばれたオフセットは、ファイルの始まりからのバイト数であり、長さ4バイトです。 ファイルの最初のバイトには、0のオフセットがあります。 したがって、1ファイルあたり1つのイメージだけの場合には、1IFDしかあるはずがありません。 次のIFDへの最後のIFDの指針が00000000(32ビット)人に魔法をかけるように設定されます。
The entries in an IFD must be sorted in ascending order by Tag.
昇順にTagはIFDのエントリーを分類しなければなりません。
Katz & Cohen [Page 7] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[7ページ]RFC1314イメージは1992年4月に形式を交換します。
Header
+--------+--------+ Directory Entry
0 | | | Byte Order +--------+--------+
+--------+--------| X | | | Tag
2 | | | Version(42) +--------+--------|
+--------+--------| X+2 | | | Type
4 | | | Offset of +--------+--------|
+- - A - -+ 0th IFD X+4 | | |
6 | | | +- -+ Length
+--------+--------+ | | |
| +--------+--------+
| X+8 | | | Value
| +- - Y - -+ or
V | | | Value
+--------+--------+ Offset
IFD
+--------+--------+ |
A | - B - | Entry Count |
+--------+--------| |
| | | V
A+2 Entry 0
| | | +--------+--------+
+--------+--------+ | | |
| | | Y Value
A+14 Entry 1 | | |
| | | +--------+--------|
+--------+--------+
| | |
A+26 Entry 2
| | |
+--------+--------+
| | | .
.
| | | .
+--------+--------+
| | |
Entry B-1
| | |
+--------+--------+
| | | Offset of
A+2+B*12 - C - + Next IFD
| | |
+--------+--------+
|
V
(next IFD)
ヘッダー+--------+--------+ ディレクトリエントリ0| | | バイトオーダー+--------+--------+ +--------+--------| X| | | タグ2| | | バージョン(42)+--------+--------| +--------+--------| X+2| | | 4をタイプしてください。| | | +のオフセット--------+--------| +--A---+第0IFD X+4| | | 6 | | | +-+長さ+--------+--------+ | | | | +--------+--------+ | X+8| | | 値| +--Y---+かV| | | 値+--------+--------+ オフセットIFD+--------+--------+ | A| - B、-| エントリーカウント| +--------+--------| | | | | +2エントリー0に対して| | | +--------+--------+ +--------+--------+ | | | | | | Yは+14エントリー1を評価します。| | | | | | +--------+--------| +--------+--------+ | | | +26エントリー2| | | +--------+--------+ | | | . . | | | . +--------+--------+ | | | エントリーB-1| | | +--------+--------+ | | | +2+B*12のオフセット--C--+ 次のIFD| | | +--------+--------+ | V(次のIFD)
Figure 1: The Structure of a TIFF File
図1: いさかいファイルの構造
Katz & Cohen [Page 8] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[8ページ]RFC1314イメージは1992年4月に形式を交換します。
3.B. Image Format and Encoding Issues
3. B.画像形式と問題をコード化すること。
Images in TIFF files are organized as horizontal strips for fast access to individual rows. One can specify how many rows there are in each strip and all of the strips are the same size (except possibly the last one). Each strip must begin on a byte boundary but successive rows are not so required. For two-dimensional G3 compression (MR), each strip must begin with an "absolute" one- dimensional line. For MMR (G4) compression, each strip must be encoded as if it were a separate image.
TIFFファイルのイメージズは個々の行への速いアクセスのための水平板としてまとめられます。 1つは、片の各片とすべてにある行がいくつであるか同じサイズ(ことによると最後のものを除いた)に指定できます。 各片はバイト境界で始まらなければなりませんが、連続した行はそう必要ではありません。 二次元G3圧縮(MR)のために、各片は1つの次元「絶対」の系列で始まらなければなりません。 MMR(G4)圧縮において、まるでそれが別々のイメージであるかのように各片をコード化しなければなりません。
For a variety of reasons, each page must be a single strip (e.g., not broken up into multiple strips).
さまざまな理由で、各ページは1片であるに違いありません(例えば、複数の片に壊れません)。
One problem with multiple strips per page is that images which come from G4 fax machines as well as most scanned images will be generated as a single strip per page. These would have to be decoded and re- encoded as multiple strips (remember that for MMR compression, each strip must be start with a one-dimensionally encoded line).
複数の1ページあたりの片に関する1つの問題はほとんどのスキャンされたイメージと同様にG4ファックス装置から来るイメージが1ページあたり1片として生成されるということです。 これらは、解読されて、複数の片として再コード化されなければならないでしょう(各片がMMR圧縮のための、次元的1つのコード化された系列がある始めでなければならないことを覚えていてください)。
Another problem with multiple strips per page arises in MR compression. Here, there MAY be at most k-1 two-dimensionally encoded lines following a one-dimensionally encoded line, but this is not required. It is possible to have one-dimensional lines more frequently than every k lines. However, since each strip (except possibly the last one) is required to be the same size, it may be necessary to re-encode the image to insure that each strip starts with a one-dimensional line. This is not a problem if each page is a single strip.
複数の1ページあたりの片に関する別の問題はMR圧縮で起こります。 ここに、次元的1つのコード化された系列に続く次元的2のコード化された系列がほとんどのk-1にあるかもしれませんが、これは必要ではありません。 あらゆるkが立ち並んでいるより頻繁に一次元系列を持っているのは可能です。 しかしながら、各片(ことによると最後のものを除いた)が同じサイズになるのに必要であるので、各片が一次元系列から始まるのを保障するためにイメージを再コード化するのが必要であるかもしれません。 各ページが1片であるなら、これは問題ではありません。
[NOTE: The TIFF document [3] suggests using strips which
are about 8K bytes long. However, TIFF-F [4] recommends
that each page be a single strip regardless of its size.
The format specified in this document follows the TIFF-F
recommendation.]
[以下に注意してください。 TIFFドキュメント[3]は、およそ8Kのバイト長である片を使用するのを示します。 しかしながら、TIFF-F[4]は、各ページがサイズにかかわらず1片であることを推薦します。 本書では指定された形式はTIFF-F推薦に続きます。]
Also, as TIFF-F recommends, all G3 encoded images (MH and MR) should be "byte-aligned." This means that extra zero bits (fill bits) are added before each EOL (end-of-line) so that every line starts on a byte boundary.
また、TIFF-Fが、すべてのG3がイメージをコード化したことを勧めるとき、(MHとMR)も「バイトで、並べられるべきです」。 これが、付加的なゼロ・ビット(ビットをいっぱいにしている)が各EOL(行末)の前で加えられることを意味するので、あらゆる系列がバイト境界を始めます。
In addition, as in the TIFF-F specification, the RTC (Return to Control signal which consists of 6 continuous EOL's) of G3 shall not be included at the end of G3 encoded documents. RTC is to be considered part of the G3 transmission protocol and not part of the encoding. Most, if not all, G3 fax modems attach RTC to outgoing images and remove it from incoming ones.
さらに、TIFF-F仕様のようにG3の端にG3のRTC(連続したEOLの6ものから成るControl信号に返す)を含んでいないものとします。ドキュメントをコード化しました。 RTCはコード化の一部ではなく、G3トランスミッションプロトコルの一部であると考えられることになっています。 すべてでないなら、G3ファックスモデムは、送信するイメージにRTCを付けて、入って来るものからそれを最も移します。
Katz & Cohen [Page 9] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[9ページ]RFC1314イメージは1992年4月に形式を交換します。
For MMR (G4) encoded files, readers should be able to read images with only one EOFB (End Of Facsimile Block) at the end of the page and should not assume that Facsimile Blocks are of any particular size. (It has been reported that some MMR readers assume that all Facsimile Blocks are the maximum size.)
MMR(G4)のコード化されたファイルに関しては、読者は、ページの端の1EOFB(終わりのOf Facsimile Block)だけと共にイメージを読むことができるべきであって、Facsimile Blocksがどんな特定のサイズのものであるとも仮定するべきではありません。 (何人かのMMR読者が、すべてのFacsimile Blocksが最大サイズであると仮定すると報告されました。)
Systems may optionally choose to store the entire image uncompressed if the compression increases the size of the image file. Also, uncompressed mode (specified in Group3Options or Group4Options, see below) allows portions of the image to be uncompressed.
システムは、圧縮がイメージ・ファイルのサイズを増強するなら解凍された全体のイメージを保存するのを任意に選ぶかもしれません。 また、解凍されたモード(Group3OptionsかGroup4Optionsで指定されていて、以下を見る)で、イメージの部分は解凍します。
The multi-page capability of TIFF is supported and should be used for multi-page documents. TIFF files which have multiple pages have an IFD for each page of the document each of which describes and points to a single page image. (Note: though the current TIFF specification does not specifically prohibit having a single IFD point to an image which is actually multiple pages, with one strip for each page, most if not all TIFF readers would probably not be able to read such a file. Therefore, this should not be done.)
TIFFのマルチページ能力は、支持されて、マルチページドキュメントに使用されるべきです。 複数のページを持っているTIFFファイルがそれのそれぞれが1ページイメージを説明して、示すドキュメントの各ページIFDを持っています。 (以下に注意してください。 現在のTIFF仕様は、各ページ単位の1片で独身のIFDに実際に複数のページであるイメージを示させるのを明確に禁止しませんが、大部分かすべてのTIFF読者がたぶんそのようなファイルを読むことができるというわけではないでしょう。 したがって、これをするべきではありません。)
[A NOTE ON TIFF AND MULTI-PAGE DOCUMENTS:
[いさかいとマルチページドキュメントの上の注意:
Since most publications (e.g., reports, books, and
magazine articles) are composed of more than a single
page, multi-page TIFF files should be used where
appropriate. However, many current TIFF implementations
now only handle single-page files.
ほとんどの刊行物(例えば、レポート、本、および雑誌の記事)が単一の1ページ以上で構成されるので、マルチページTIFFファイルは適切であるところで使用されるべきです。 しかしながら、多くの現在のTIFF実現が現在、1ページファイルを扱うだけです。
It is hoped that in the future, more TIFF implementations
will handle multi-page files correctly. In the meantime,
it would be useful to develop a utility program which
could join several single-page TIFF files into a single
multi-page file and also separate a multi-page TIFF file
into several single page files.
将来より多くのTIFF実現が正しくマルチページファイルを扱うことが望まれています。 差し当たり、ただ一つのマルチページファイルにいくつかの1ページTIFFファイルを接合できたユティリティプログラムを開発して、また、マルチページTIFFファイルをいくつかの1ページファイルに切り離すのは役に立つでしょう。
For example, the utility could take a single TIFF file
with N pages, called doc.tif, and create the files
doc.000, doc.001, doc.002, ..., doc.N. doc.000 would be
an ASCII listing of the files created. This naming
scheme is compatible with that used by the image systems
we have seen which only handle single page files.
例えば、ユーティリティは、doc.tifと呼ばれるNページがあるただ一つのTIFFファイルを取って、ファイルdoc.000を作成するかもしれません、doc.001、doc.002…, doc.N. doc.000は作成されたファイルのASCIIリストでしょう。 この命名計画はハンドル1ページだけがファイルする私たちが見たイメージシステムによって使用されるそれと互換性があります。
In going the other way, the N+1 single page files could
be combined into a single multi-page TIFF file. In this
case, if the file doc.000 exists but contains information
contrary to what is found in looking for the files
doc.001, doc.002, ..., the program would notify the user.]
もう片方の方向に行く際に、ただ一つのマルチページTIFFファイルの中にN+1 1ページファイルを結合できました。 この場合、doc.000はファイルであるならファイルdoc.001を探す際に見つけられるものとは逆に存在していますが、情報を含みます、doc.002…, プログラムはユーザに通知するでしょう。]
Katz & Cohen [Page 10] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[10ページ]RFC1314イメージは1992年4月に形式を交換します。
3.C. TIFF Fields
3. C.いさかい分野
TIFF is tag or field based. The various fields and their format are listed in [3]. There are Basic Fields (common to all TIFF files), Informational Fields (which provide useful information to a user), Facsimile Fields (used here), and Private Fields.
TIFFはタグか分野に基づいています。 多岐とそれらの書式は[3]に記載されています。 Basicフィールズ(すべてのTIFFファイルに共通の)、Informationalフィールズ(役に立つ情報をユーザに提供する)がいて、Facsimileフィールズは(ここで中古)と兵士のフィールズです。
Each directory entry contains:
各ディレクトリエントリは以下を含んでいます。
The Tag for the field (2 bytes)
分野へのTag(2バイト)
The field Type (2 bytes)
分野Type(2バイト)
The field Length (4 bytes)
(This is in terms of the data type, not in bytes. For
example, a single 16-bit word or SHORT has a Length
of 1, not 2)
分野Length(4バイト)(データ型に関してこれはバイトに関してあるのではなく、あります。 例えば、ただ一つの16ビットの単語かSHORTには、2ではなく1のLengthがあります。)
The Value Offset (4 bytes)
(Pointer to the actual value, which must begin on a
word boundary. Therefore, this offset will always
be an even number. If the Value fits into 4 bytes, the
Value Offset contains the Value instead. If the Value
takes less than 4 bytes, it is left justified)
Value Offset(4バイト)(実価へのポインタ。(それは、語境界で始まらなければなりません)。 したがって、このオフセットはいつも偶数になるでしょう。 Valueが4バイトに収まるなら、Value Offsetは代わりにValueを含んでいます。 Valueが4バイト未満取るなら、それは正当化されるように残されます。)
The allowed types and their codes are:
許容タイプと彼らのコードは以下の通りです。
1 = BYTE 8-bit unsigned integer (1 byte)
1がBYTEと8ビットで等しい、符号のない整数(1バイト)
2 = ASCII 8-bit ASCII terminated with a null (variable
length)
2 = ASCIIの8ビットのASCIIはヌルで終わりました。(可変長)
3 = SHORT 16-bit unsigned integer (2 bytes)
3がSHORTと16ビットで等しい、符号のない整数(2バイト)
4 = LONG 32-bit unsigned integer (4 bytes)
4がLONGと32ビットで等しい、符号のない整数(4バイト)
5 = RATIONAL Two LONGs (64 bits) representing the
numerator and denominator of a fraction.
In this document, RATIONAL's will be written
as numerator/denominator. (8 bytes)
5は、断片の分子と分母を表しながら、RATIONAL Two LONGs(64ビット)と等しいです。 本書では、RATIONALのものは分子/分母として書かれるでしょう。 (8バイト)
For ASCII, the Length specifies the number of characters and includes the null. It does not, however, include padding if such is necessary.
ASCIIのために、Lengthはキャラクタの数を指定して、ヌルを含んでいます。 しかしながら、それは、そのようなものが必要であるならそっと歩くのを含んでいません。
(Note that ASCII strings of length 3 or less may be stored in the Value Offset field instead of being pointed to.)
(より長さ3のASCIIストリングが示されることの代わりにValue Offset分野に格納されるかもしれないことに注意してください。)
Katz & Cohen [Page 11] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[11ページ]RFC1314イメージは1992年4月に形式を交換します。
The following fields should be used in a TIFF image file. Only the Basic Fields are mandatory; the others are optional (except that for MH and MR encoded files, the Group3Options Facsimile Field is mandatory). The optional fields have default values which are given in the TIFF specification. (Note that the TIFF reference [3] recommends not relying on the default values.)
以下の分野はTIFFイメージ・ファイルで使用されるべきです。 Basicフィールズだけが義務的です。 他のものは任意です(Group3Options Facsimile FieldがMHとMRのコード化されたファイルに義務的であるのを除いて)。 任意の分野には、TIFF仕様で与えられているデフォルト値があります。 (TIFF参照[3]が、デフォルト値を当てにすることを勧めないことに注意してください。)
Some fields contain one or more flag bits all stored as one value. In these cases, the bit labeled 0 is the least significant bit (i.e., Little Endian order). Where there is more than one suggested value for a tag, the possible values are separated by |.
いくつかの分野が1つの値としてすべて格納された1フラグビット以上を含んでいます。 これらの場合では、0とラベルされたビットは最下位ビット(すなわち、リトルEndian注文)です。 タグのための1つ以上の提案された値があるところに、可能な値によって切り離されます。|.
Note that some fields (such as ImageLength or ImageWidth) can be of more than one type.
1つ以上のタイプにはいくつかの分野(ImageLengthかImageWidthなどの)があることができることに注意してください。
It would be useful to develop a TIFF viewer and editor which would allow one to read, add, and edit the fields in a TIFF file. Such an editor would display fields in sorted order and force the inclusion of all mandatory fields. Also, resolution and position should always be displayed or specified together with their units.
1つにTIFFファイルの分野を読んで、加えて、編集させるTIFFビューアーとエディタを開発するのは役に立つでしょう。 そのようなエディタは、分類されたオーダーにおける野原を表示して、すべての義務的な分野の包含を強制するでしょう。 また、それらのユニットと共に解決と位置をいつも表示するべきであるか、または指定するべきです。
3.C.1. Basic Fields (Mandatory)
3. C.1。 基礎体(義務的)です。
Basic Fields are those which are fundamental to the pixel
architecture or visual characteristics of an image. The following
Basic Fields should be included in a TIFF image file:
基本的なフィールズはイメージの画素構造か視覚特性に基本的なものです。 以下のBasicフィールズはTIFFイメージ・ファイルに含まれるべきです:
FIELD NAME
(TAG in hex, TYPE) VALUE DESCRIPTION
------------------ ----- -----------
FIELD NAME(十六進法におけるTAG、TYPE)VALUE DESCRIPTION------------------ ----- -----------
BitsPerSample 1 Number of bits
(0102, SHORT) per pixel (bi-level for
now, but may allow
more later)
1画素あたりのビット(0102、SHORT)のBitsPerSample1Number(当分間の後で以上を許容するかもしれないのを除いた両性愛者のレベル
Compression 4 Type of Compression
(0103, SHORT) (could also be 1 = Uncompressed
1 or 3) 3 = G3 (MH or MR)
4 = G4 (MMR)
Use 4 if possible
圧縮、できれば、Compression(0103、SHORT)(また、解凍された1か1=3であるかもしれない)3の4TypeはG3(MHかMR)4=G4(MMR)使用4と等しいです。
ImageLength <image's length> Length of the Image
(0101, SHORT in scan lines
or LONG)
ImageのImageLength<イメージの長さの>Length(0101、スキャン線かLONGのSHORT)
ImageWidth <image's width> Width of the Image
(0100, SHORT in pixels
ImageのImageWidth<イメージの幅の>Width、(0100、画素のSHORT
Katz & Cohen [Page 12] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[12ページ]RFC1314イメージは1992年4月に形式を交換します。
or LONG)
長さ)
NewSubFileType 0 usually Flag bits indicating
(00FE, LONG) bit 0: 1 if the kind of image.
reduced (see the TIFF
resolution of reference [3])
another image
bit 1: 1 if
single page of a
multi-page image
bit 2: 1 if
image defines a
transparency
mask
NewSubFileType、0 通常ビット0を示す(00FE、LONG)Flagビット: 1 イメージの種類であるなら減少、(別のものが像を描く参照[3])のTIFF決議が1に噛み付いたのを確実にしてください: 1 マルチページイメージビット2の1ページであるなら: 1はイメージであるなら透明マスクを定義します。
Photometric- 0 for positive
Interpretation image (0 imaged
(0106, SHORT) as white, 1 as
black)
1 means reverse
black and white
積極的なInterpretationイメージ(0は白、黒としての1として(0106、SHORT)に像を描いた)1つの手段のための光度測定の0は白黒を逆にします。
RowsPerStrip <Number of Rows> Number of Rows in
(0116, SHORT Each Strip. Each
or LONG) page should be a
single strip.
>が付番する中の通りの通りのRowsPerStrip<番号(0116 各片をショートしてください。 それぞれか長さ) ページは1片であるべきです。
SamplesPerPixel 1 (since are Bi-level
(0115, SHORT) images)
SamplesPerPixel1(以来、Bi-レベル(0115、SHORT)イメージです)
StripByteCounts count1, count2... Number of Bytes in
(0117, SHORTs each strip of the
or LONGs) images. (The Value
is an offset which
points to a series
of counts, each of
which is the same
Type, LONG or SHORT.
The Length is the
same as the number
of strips.)
StripByteCounts count1、count2… 中のBytesの数、(0117、それぞれが剥取るSHORTs、LONGs) または、イメージ。 (Valueはそれのそれぞれが同じType、LONGまたはSHORTである一連のカウントを示すオフセットです。 Lengthは片の数と同じです。)
StripOffsets off1, off2,... Pointers to the strips
(0111, SHORTs of the image (remember,
or LONGs) one strip per page).
(The Value is an offset
which points to a
series of offsets,
StripOffsets off1、off2… 片へのポインタ、(0111、イメージのSHORTs、(覚えている、LONGs) 1ページあたり1片、) (Valueは一連のオフセットを示すオフセットです。
Katz & Cohen [Page 13] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[13ページ]RFC1314イメージは1992年4月に形式を交換します。
each of which points
to the actual image
data for the strip.)
それのそれぞれが片のための実画像データを示す。)
ResolutionUnit 2 | 3 Units of Resolution
(0128, SHORT) See Below, 3.C.6 2: Inches
3: Centimeters
ResolutionUnit2| 3.C.6 2、3つの決議(急0128)が以下を見ます: インチ3: センチメートル
XResolution See Below, 3.C.6 Resolution in the X
(011A, RATIONAL) direction in pixels
per ResolutionUnit
(we suggest 400 dots
per inch when possible)
XResolution See Below、1ResolutionUnitあたりの画素のX(011A、RATIONAL)方向への3.C.6 Resolution(可能であるときに、私たちは1インチあたり400のドットを勧めます)
YResolution See Below, 3.C.6 Resolution in the Y
(011B, RATIONAL) direction in pixels
per ResolutionUnit
(we suggest 400 dots
per inch when possible)
YResolution See Below、1ResolutionUnitあたりの画素のY(011B、RATIONAL)方向への3.C.6 Resolution(可能であるときに、私たちは1インチあたり400のドットを勧めます)
3.C.2. Informational Fields (Optional)
3. C.2。 情報の分野(任意)です。
The following Informational Fields are optional. They provide
useful information to a user. All Field values are ASCII strings.
以下のInformationalフィールズは任意です。 彼らは役に立つ情報をユーザに提供します。 すべてのField値がASCIIストリングです。
NAME (TAG in hex) DESCRIPTION
---------------- -----------
NAME(十六進法におけるTAG)記述---------------- -----------
Artist (013B) Person Who Created the Image
イメージを作成した芸術家(013B)の人
DateTime (0132) Date and Time of Image Creation
イメージ創造のDateTime(0132)日時
HostComputer (013C) Name of Computer Image was Created On
HostComputer(013C)名(コンピュータImage)はCreated Onでした。
ImageDescription A Short Text Description
(010E)
ImageDescriptionは短いテキスト記述です。(010E)
Make (010F) Manufacturer of Hardware (Scanner) Used
ハードウェア(スキャナ)の(010F)のメーカーを使用させてください。
Model (0110) Model Number of Hardware (Scanner) Used
ハードウェア(スキャナ)の型番が使用したモデル(0110)
Software (0131) Software Package that Created the Image
ソフトウェア(0131)ソフトウェアパッケージはそのCreated Imageです。
3.C.3. Facsimile Fields (Optional, Mandatory for G3 Compression)
3. C.3。 ファクシミリ分野(任意で、G3圧縮に義務的)です。
In addition to the above, the Facsimile Fields below should be
used. The TIFF document recommends that they not be used for
interchange between applications, but they are now in wide enough
上記に加えて、以下のFacsimileフィールズは使用されるべきです。 TIFFドキュメントは、それらがアプリケーションの間の置き換えに使用されないことを勧めますが、それらは現在、十分広いところにあります。
Katz & Cohen [Page 14] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[14ページ]RFC1314イメージは1992年4月に形式を交換します。
use for just that. These fields are optional and default to 0
(all bits off).
まさしくそれのために、使用します。 これらの分野は、任意であり、0をデフォルトとします(すべてのビットが下にある状態で)。
FIELD NAME
(TAG in hex, TYPE) VALUE DESCRIPTION
------------------ ----- -----------
FIELD NAME(十六進法におけるTAG、TYPE)VALUE DESCRIPTION------------------ ----- -----------
Group3Options bit 0: 1 for Flag bits indicating
(0124, LONG) 2-dimensional Options for G3
coding
(i.e., MR with
k > 1)
bit 1: 1 if
uncompressed
mode MAY be used,
0 if uncompressed
mode IS NOT used.
bit 2: 1 if fill (As allowed by the G3
bits have been protocol, fill bits
added may be added between
each line of data
and the EOL. Since
fill bits are used to
"byte-align" G3 image
files, bit 2 should be
set to 1 for these
images.)
Group3Optionsは0に噛み付きました: G3コード化(すなわち、k>1とMR)のために2次元のOptionsを示す(0124、LONG)Flagビット1は1に噛み付きました: 1 解凍されたモードが使用されるかもしれないなら、解凍されたモードがあるなら、0は. ビット2を使用しませんでした: 1、中詰めです。(G3ビットによって許容されているように、プロトコルであり、データの各線とEOLの間で加えられるかもしれません中詰めビットが、言い足した。 中詰めビットがG3イメージ・ファイルを「バイト並べること」に使用されるので、ビット2はこれらのイメージのために1に設定されるべきです。)
Group4Options bit 0: unused Flag bits indicating
(0125, LONG) bit 1: 1 if Options for G4
uncompressed
mode MAY be used,
if this bit is 0
it means that
uncompressed mode
IS NOT used.
Group4Optionsは0に噛み付きました: ビット1を示す(0125、LONG)未使用のFlagビット: 1 G4がモードを解凍したのでOptionsが使用されるかもしれないなら、モードはこのビットがそれが意味する解凍した0であるなら使用されていません。
3.C.4. Storage and Retrieval Fields (Optional)
3. C.4。 格納と検索分野(任意)です。
The following fields are optional and may be useful for document
storage and retrieval.
以下の分野は、任意であり、書類保存と検索の役に立つかもしれません。
Katz & Cohen [Page 15] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[15ページ]RFC1314イメージは1992年4月に形式を交換します。
FIELD NAME
(TAG in hex, TYPE) DESCRIPTION
------------------ -----------
FIELD NAME(十六進法におけるTAG、TYPE)記述------------------ -----------
DocumentName Name of the Document
(010D, ASCII)
ドキュメントのDocumentName名(010D、ASCII)
PageName Name of the Page
(011D, ASCII)
ページのPageName名(011D、ASCII)
PageNumber Page Number in a Multi-Page Document
(0129, SHORTs) Two SHORT Values are specified, the
first is the page number and the
second is the total number of pages
in the document. The first page
is page 0. (NOTE: This does not
necessarily correspond to page
numbers which may be printed
in the image.)
Multi-ページDocument(0129、SHORTs)2SHORT ValuesのPageNumberページNumberは指定されます、そして、1番目はページ番号です、そして、2番目はドキュメントのページの総数です。 最初のページは0ページです。 (注意: これは必ずイメージで印刷されるかもしれないページ番号に対応するというわけではありません。)
XPosition X Offset of the Left Side of
(011E, RATIONAL) the Image, in ResolutionUnits
Xが相殺したResolutionUnitsの(011E的、そして、合理的な)イメージの左側のXPosition
YPosition Y Offset of the Top of
(011F, RATIONAL) the Image, in ResolutionUnits
Yが相殺したResolutionUnitsの(011F的、そして、合理的な)イメージの先端のYPosition
3.C.5. TIFF-F Fields (NOT Recommended)
3. C.5。 いさかいF分野(お勧めでない)です。
TIFF-F defines the following new fields for G3 (MH) encoded
images. Since these fields are not defined in TIFF-B itself,
their use is not recommended. However, since TIFF-F files may
include these tags for image data which came from a G3 fax
machine, readers should be prepared for them.
TIFF-FはG3(MH)のコード化されたイメージのために以下の新しい分野を定義します。 これらの分野がTIFF-B自身で定義されないので、彼らの使用は推薦されません。 しかしながら、TIFF-FファイルがG3ファックス装置から来たイメージデータのためのこれらのタグを含むかもしれないので、読者は彼らのために用意ができているべきです。
These three fields deal with corrupted image data which is due to
the fact that G3 devices may not perform error correction on bad
data.
これらの3つの分野がG3装置が悪いデータにエラー修正を実行しないかもしれないという事実のためである崩壊したイメージデータに対処します。
FIELD NAME
(TAG in hex, TYPE) DESCRIPTION
------------------ -----------
FIELD NAME(十六進法におけるTAG、TYPE)記述------------------ -----------
BadFaxLines Number of Bad fax scan lines
(0146, SHORT or LONG) encountered during fax reception
(but not necessarily in the file)
ファックスレセプションの間に遭遇するBadファックススキャン線(0146、SHORTまたはLONG)のBadFaxLines Number(しかし、必ずいずれのファイルでもそうするというわけではありません)
CleanFaxData 0 means no bad lines received
(0147, SHORT) 1 means bad lines were regenerated
CleanFaxData0は、どんな(0147、SHORT)容認された1の悪い線も、悪い線が作り直されたことを意味しないことを意味します。
Katz & Cohen [Page 16] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[16ページ]RFC1314イメージは1992年4月に形式を交換します。
by the receiving device
2 means bad lines were detected
but not regenerated
受信で、装置2は、悪い線が検出されましたが、作り直されなかったことを意味します。
ConsecutiveBadFaxLines The maximum number of consecutive
(0148, SHORT or LONG) bad fax lines (but not necessarily
in the file)
連続した(0148、SHORTまたはLONG)悪いファックスの最大数が裏打ちするConsecutiveBadFaxLines(しかし、必ずいずれのファイルでもそうするというわけではありません)
3.C.6. More on Representing Resolutions
3. C.6。 解決を表すときの以上
The tags XResolution and YResolution are both RATIONALs, i.e., the
ratio of two LONGS. G3 fax resolutions are actually specified in
dots (or lines) per mm while G4 is in dots per inch (actually,
dots per 25.4 mm).
タグのXResolutionとYResolutionはRATIONALs、すなわち、2LONGSの両方の比率です。 インチ(実際に25.4mmあたりのドット)あたりのドットにはG4がある間、G3ファックス解決は実際に1mmあたりのドット(または、線)で指定されます。
For example, G3 horizontal resolution is defined to be 1728 dots
per 215 mm which comes out to 80.4 dots per cm or about 203 dots
per inch. It is frequently referred to as just 200 dpi. To avoid
any possibility of problems due to round off error, this should be
represented by having XResolution = 17280/215 and ResolutionUnit =
3 (cm). However when reading, 204/1 or even 200/1 with
ResolutionUnit = 2 (inches) should be recognized as representing
the same resolution.
例えば、G3の水平な解決は、1cmあたり80.4のドットか1インチあたりおよそ203のドットまで出て来る215mmあたり1728のドットになるように定義されます。 それは頻繁にちょうど200dpiと呼ばれます。 誤りを丸くするのにおいて当然の問題のどんな可能性も避けるために、XResolutionに17280/215とResolutionUnit=3と等しくさせることによって、これは表されるべきです(cm)。 しかしながら、読むとき、ResolutionUnit=2(インチ)がある204/1か200/1さえ同じ解決を表すと認識されるべきです。
For G4, on the other hand, the resolution 400 dots/inch should be
represented by an XResolution of 400/1 and ResolutionUnit = 2.
他方では、G4に関しては、解決400ドット/インチは400/1とResolutionUnit=2のXResolutionによって表されるはずです。
The following table shows various ways of representing the
standard resolutions in order of preference:
以下のテーブルは好みの順に標準の解決を表す様々な方法を示しています:
ResolutionUnit XResolution YResolution
-------------- ----------- -----------
ResolutionUnit XResolution YResolution-------------- ----------- -----------
G3 normal 3 17280/215 3850/100
3 80/1 3850/100
3 17280/215 385/10
3 80/1 385/10
2 2042/10 9779/100
2 204/1 98/1
2 200/1 100/1
正常なG3の3 17280/215 3850/100 3 80/1 3850/100 3 17280/215 385/10 3 80/1 385/10 2 2042/10 9779/100 2 204/1 98/1 2 200/1 100/1
G3 fine 3 17280/215 77/1
3 80/1 77/1
2 2042/10 19558/100
2 204/1 196/1
2 200/1 200/1
G3のすばらしい3 17280/215 77/1 3 80/1 77/1 2 2042/10 19558/100 2 204/1 196/1 2 200/1 200/1
Katz & Cohen [Page 17] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[17ページ]RFC1314イメージは1992年4月に形式を交換します。
G4 200 dpi 2 200/1 200/1
G4 200dpi2 200/1 200/1
G4 300 dpi 2 300/1 300/1
G4 300dpi2 300/1 300/1
Other 300 dpi 2 300/1 300/1
他の300dpi2 300/1 300/1
G4 400 dpi 2 400/1 400/1
G4 400dpi2 400/1 400/1
600 dpi 2 600/1 600/1
600dpi2 600/1 600/1
It is suggested that Image readers be able to handle all of the
above representations.
Image読者が上の表現のすべてを扱うことができると示唆されます。
4. A Sample TIFF Image File
4. サンプルいさかいイメージ・ファイル
Below is a sample of what might be in a TIFF file for an MMR (G4) encoded single image which is about 100K bytes compressed at 400 dpi. A generic outline is given first, followed by a more detailed hex listing.
以下に、何が400dpiで圧縮されたおよそ100KのバイトであるMMR(G4)のコード化されたただ一つのイメージのためのTIFFファイルにあるかもしれないかに関するサンプルがあります。 より詳細な十六進法リストが支えていて、最初に、一般的なアウトラインをします。
4.A. Sample File
4. A.サンプルファイル
Comments are to the right and are preceded by a semicolon. Note that tags must be sorted in order of the tag codes.
コメントを右にはあって、セミコロンは先行します。 タグコードの順にタグを分類しなければならないことに注意してください。
0:, IFDADDR:, and STRIP0: are addresses within the file and denote the number of bytes from the beginning of the file.
0:、IFDADDR、: STRIP0: ファイルの中にアドレスがあります、そして、ファイルの始まりからバイト数を指示してください。
Header:
ヘッダー:
0: Byte Order= hex 4D4D ;first bytes of the file, from
;most significant bit to least
;significant (big endian)
Version= 42 (hex 002A) ;Must be 42
First IFD= IFDADDR ;Address of first (and only) IFD
0: バイトOrderは十六進法4D4D; ; 最少への最上位ビット;重要な(ビッグエンディアン)バージョンからのファイルの最初のバイト=42(十六進法002A); 42First IFD= IFDADDRでなければなりません; 最初に(単に)、IFDのアドレスと等しいです。
Image File Directory (the only one in this example):
イメージFileディレクトリ(この例の唯一無二):
IFDADDR:
IFDADDR:
IFD Entry Count= 24 ;(NOT A TAG) Count of
; Number of IFD Entries
=24 ; (タグでない)が数えるIFDエントリーカウント。 IFDエントリーの数
NewSubFileType= 0
ImageWidth= 3400 ;8.5 inches at 400 dpi
ImageLength= 4400 ;11 inches at 400 dpi
BitsPerSample= 1 ;Bi-Level
400dpi BitsPerSample=1のうちの4400;11 400dpi ImageLengthの3400;8.5 0NewSubFileType=ImageWidth=インチ=インチ; 両性愛者のレベル
Katz & Cohen [Page 18] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[18ページ]RFC1314イメージは1992年4月に形式を交換します。
Compression= 4 ;MMR
Photometric-
Interpretation= 0
DocumentName= "LAMap1"
ImageDescription= "A map of Los Angeles"
Make= "Fujitsu"
Model= "M3093E"
StripOffsets= <STRIP0> ;There is only one strip in
;this example. However, note
;that strips can be in any
;order. (Offsets are from the
;beginning of the TIFF file.)
圧縮=4; 0MMR Photometric解釈=DocumentNameは「"M3093E"「富士通」LAMap1" ImageDescription=「ロサンゼルスの地図」Make=Model=StripOffsetsは<STRIP0>と等しいです; 中のある片だけ; この例があること」と等しいです。 片がいずれにもあることができるというメモ; しかしながら、注文してください。 (オフセットがある、;、TIFFファイルの始まり)。
SamplesPerPixel= 1 ;Bi-Level
RowsPerStrip= 4400 ;Entire image in 1 strip
StripByteCounts= <COUNT0> ;Byte count of entire
;compressed image
SamplesPerPixel=1; 両性愛者のレベルRowsPerStripは<COUNT0 1片StripByteCounts=>; 全体のバイト・カウント; 圧縮画像において全体の4400;イメージと等しいです。
XResolution= 400/1
YResolution= 400/1
XPosition= 0/1 ;position of left side of image
YPosition= 0/1 ;position of top of image
Group4Options= hex 00000002 ;bit 1 on means uncompressed
;mode MAY be used
400/1 400/1XResolution=YResolution=XPositionは0/1と等しいです; イメージYPosition=0/1の左側の位置; イメージGroup4Options=十六進法00000002の先端の位置; 手段のビット1は解凍しました; モードは使用されるかもしれません。
ResolutionUnit= 2 ;Inches
Software= "Xionics"
DateTime= "1990:10:05 15:00:00"
Artist= "Joe Pro"
HostComputer= "Tardis.Isi.Edu"
ResolutionUnit=2 ; インチソフトウェア=「Xionics」DateTimeが等しい、「1990:、10:05 15:00、: 0インチの芸術家は「」 ジョーPro HostComputerは"Tardis.Isi.Edu"と等しいこと」と等しいです。
Next IFD Pointer= hex 00000000 ;(NOT A TAG) Indicates no
; more IFDs in this file
次のIFD Pointerは十六進法00000000と等しいです; (A TAGでない)は、いいえを示します。 このファイルの、より多くのIFDs
Image Data:
イメージデータ:
<STRIP0>: <actual compressed image data>
<STRIP0>: <の実際の圧縮画像データ>。
[end of TIFF file]
[TIFFファイルの端]
In this example there is only one strip. Note that if there were more than one, the TIFF specification does not require them to be in any particular order. Strips may be given in any order and TIFF readers must use the StripOffsets to locate them.
この例には、1片しかありません。 1つ以上があるなら、TIFF仕様が、彼らがどんな特定のオーダーにもいるのを必要としないことに注意してください。 順不同に片を与えるかもしれません、そして、TIFF読者は彼らの居場所を見つけるのにStripOffsetsを使用しなければなりません。
Also, the TIFF document recommends not relying on the default values of the tags.
また、TIFFドキュメントは、タグのデフォルト値を当てにすることを勧めません。
Katz & Cohen [Page 19] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[19ページ]RFC1314イメージは1992年4月に形式を交換します。
4.B. Detailed Hex Listing
4. B.の詳細な十六進法リスト
All offsets and values are represented by hex except for ASCII strings which are double quoted. Remember that Value Offsets must always be an even number since the value it points to must always be on a 16-bit word boundary.
すべてのオフセットと値は引用されていた状態で二重なASCIIストリング以外の十六進法によって表されます。 それが示す値が16ビットの語境界にいつもあるに違いないのでValue Offsetsがいつも偶数であるに違いないことを覚えていてください。
Entries in the Name column are for reference and are not actually a part of the TIFF file.
Nameコラムにおけるエントリーは、参照のためにあって、実際にTIFFファイルの一部ではありません。
Offset Name Value ---- ------------------- ------------------------------------- Header (first byte is Offset 0): 0000 Byte Order 4D4D 0002 Version 002A 0004 1st. IFD pointer 00000010
名前値を相殺してください。---- ------------------- ------------------------------------- ヘッダー(最初のバイトはOffset0です): 0000バイトオーダー4D4D0002バージョン002A0004 1番目。 IFDポインタ00000010
IFD (IFDADDR from above is 0010 here): 0010 Entry Count 0018 0012 NewSubFileType 00FE 0004 00000001 00000000 001E ImageWidth 0100 0004 00000001 00000D48 002A ImageLength 0101 0004 00000001 00001130 0036 BitsPerSample 0102 0003 00000001 00010000 0042 Compression 0103 0003 00000001 00040000 004E Photometric Interp. 0106 0003 00000001 00000000 005A DocumentName 010D 0002 00000007 00000136 0066 ImageDescription 010E 0002 00000015 0000013E 0072 Make 010F 0002 00000008 00000154 007E Model 0110 0002 00000007 0000015C 008A StripOffsets 0111 0004 00000001 000001A8 0096 SamplesPerPixel 0115 0003 00000001 00010000 00A2 RowsPerStrip 0116 0004 00000001 00001130 00AE StripByteCounts 0117 0004 00000001 <COUNT0> 00BA XResolution 011A 0005 00000001 00000164 00C6 YResolution 011B 0005 00000001 00000164 00D2 XPosition 011E 0005 00000001 0000016C 00DE YPosition 011F 0005 00000001 0000016C 00EA Group4Options 0125 0004 00000001 00000002 00F6 ResolutionUnit 0128 0003 00000001 00020000 0102 Software 0131 0002 00000008 00000174 010E DateTime 0132 0002 00000014 0000017C 011A Artist 013B 0002 00000008 00000190 0126 HostComputer 013C 0002 0000000F 00000198 0132 Next IFD Pointer 00000000
IFD(IFDADDRは上からここの0010です): 0010年のエントリーカウント0018 0012NewSubFileType 00FE0004 00000001 00000000 001EのImageWidth 0100 0004 00000001 00000D48 002A ImageLength0101 0004 00000001 00001130 0036BitsPerSample0102 0003 00000001 00010000 0042圧縮0103 0003 00000001 00040000 004Eの光度測定のInterp。 0106 0003 00000001 00000000 005A DocumentName 010D0002 00000007 00000136 0066ImageDescription010E0002 00000015 0000013E0072は010F0002 00000008 00000154 007Eモデル0110 0002 00000007 0000015C008A StripOffsets 0111 0004 00000001 000001A8 0096SamplesPerPixel 0115 0003 00000001 00010000 00A2RowsPerStrip 0116 0004 00000001 00001130 00AE StripByteCounts0117 0004 00000001を<COUNT0>00BA XResolution 011A0005 00000001にします; 00000164 00C6 YResolution 011B 0005 00000001 00000164 00D2 XPosition011 0005 00000001 0000016C00DE YPosition011F0005 00000001 0000016C00EA Group4Options 0125 0004 00000001 00000002 00F6 ResolutionUnit0128 0003 00000001 00020000 0102ソフトウェア0131 0002 00000008 00000174 010EのE DateTime0132 0002 00000014 0000017C011A次の芸術家013B0002 00000008 00000190 0126HostComputer013C0002 0000000F00000198 0132IFDポインタ00000000
Fields Offsets Point to: 0136 DocumentName "LAMap1" 013E ImageDescription "A map of Los Angeles"
以下への分野Offsets Point 0136DocumentName、「LAMap1"013E ImageDescription、「ロサンゼルスの地図」、」
Katz & Cohen [Page 20] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[20ページ]RFC1314イメージは1992年4月に形式を交換します。
0154 Make "Fujitsu" 015C Model "M3093E" 0164 X,Y Resolution 00000190 00000001 016C X,Y Position 00000000 00000001 0174 Software "Xionics" 017C DateTime "1990:10:05 15:00:00" 0190 Artist "Joe Pro" 0198 HostComputer "Tardis.Isi.Edu"
0154は「富士通」015をCモデル"M3093E"0164Xにします、Y解決00000190 00000001 016C X、Y位置00000000 00000001 0174のソフトウェア「Xionics」017C DateTime、「1990:、10:05 15:00、0198HostComputer"Tardis.Isi.Edu"という: 0インチ0190芸術家「ジョーPro」、」
Image Data (<STRIP0> from above is here 01A8) 01A8 Compressed Data for single strip, of length <COUNT0> bytes
イメージData、(<STRIP0>、上から、01A8) 長さの<COUNT0>バイトのただ一つの片のための01A8 Compressed Dataはここで来ています。
[end of TIFF file]
[TIFFファイルの端]
NOTE: Since in this example there is only a single strip, there is only
one count for StripByteCounts and one offset for StripOffsets.
Thus, each of these only takes 4 bytes and will fit in the
Value Offset instead of being pointed to.
以下に注意してください。 この例には、1片しかないので、StripByteCountsのための1つのカウントとStripOffsetsのための1つのオフセットしかありません。 したがって、それぞれのこれらは、4バイト取るだけであり、示されることの代わりにValue Offsetをうまくはめ込むでしょう。
5. Conclusions
5. 結論
Bitmapped images transferred within the Internet should be in the following format:
以下の形式にはインターネットの中で移されたビットマップ画像がそうあるべきです:
1. The file format should be TIFF-B with multi-page files
supported. Images should be encoded as one TIFF strip
per page.
1. ファイル形式は支持されたマルチページファイルがあるTIFF-Bであるべきです。 イメージズは1ページあたり1TIFF片としてコード化されるべきです。
2. Images should be compressed using MMR when possible. Images
may also be MH or MR compressed or uncompressed. If MH or MR
compression is used, scan lines should be "byte-aligned".
2. イメージズは、可能であるときに、MMRを使用することで圧縮されるべきです。 また、イメージズは、圧縮されたか、または解凍されたMHかMRであるかもしれません。 MHかMR圧縮が使用されているなら、スキャン線は「バイトで、並べられるべきです」。
3. For maximum interoperability, image resolutions should
either be 600, 400, or 300 dpi; or else be one of the
standard Group 3 fax resolutions (98 or 196 dpi
vertically and 204 dpi horizontally).
3. 最大限のインターオペラビリティのために、イメージ解決は600、400、または300dpiであるべきです。 または、標準のGroup3ファックス解決の1つになってください、(98か196dpi、垂直である、204dpi、水平に)
Note that this specification is self contained and an implementation should be possible without recourse to the TIFF references, and that only the specific TIFF documents cited are relevant to this specification. Updates to the TIFF documents do not change this specification.
この仕様が独立であって、実現が償還請求なしでTIFF参照に可能であるべきであり、ドキュメントが引用した特定のTIFFだけがこの仕様に関連していることに注意してください。 TIFFドキュメントへのアップデートはこの仕様を変えません。
Existing commercial off-the-shelf products are available which can handle images in the above format. ISI would be delighted to help those interested in assembling a system.
既存の商用既製品製品は利用可能です(上の形式でイメージを扱うことができます)。 ISIは、システムを組み立てたがっていたものを助けて、喜ぶでしょう。
Katz & Cohen [Page 21] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[21ページ]RFC1314イメージは1992年4月に形式を交換します。
6. Acknowledgments
6. 承認
Many contributions to this work were made by members of the IETF Network Fax Working Group especially by its chairman, Mark Needleman and by Clifford Lynch of the University of California Office of the President, Library Automation. Also, Kiyo Inaba of Ricoh Co. Ltd. made a number of helpful suggestions.
この仕事への多くの貢献が特に議長にIETF Networkファックス作業部会のメンバーによってされました、ニードルマンと社長のカリフォルニア大学オフィスのクリフォード・リンチによるマーク、図書館Automation。 また、リコー社の株式会社Kiyo Inabaは多くの役立つ提案をしました。
7. References
7. 参照
[1] Borenstein, N., and N. Freed, "Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC in
preparation.
[1] 準備におけるBorenstein、N.、およびN.フリード、「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC。
[2] International Telegraph and Telephone Consultative Committee
(CCITT), Red Book, October, 1984.
[2] 国際電信電話諮問委員会(CCITT)、職員録、1984年10月。
[3] Aldus Corp., Microsoft Corp., "Tag Image File Format
Specification", Revision 5.0, Final, 1988.
[3] アルダス社、Microsoft Corp.、「タグ画像ファイル形式仕様」、改正5.0、決勝、1988。
[4] Cygnet Corporation, "The Spirit of TIFF Class F, 1990", available
from Cygnet Technologies, 2560 9th., Suite 220, Berkeley, CA
94710, FAX: (415) 540-5835.
[4] 白鳥のひな社、「いさかいの聖霊はF、1990を分類します」、Cygnet Technologies、2560年から9番目に利用可能である、Suite220、バークレー、カリフォルニア 94710、FAX: (415) 540-5835.
[5] Welch, T., "A Technique for High Performance Data Compression",
IEEE Computer, Vol. 17, No. 6, Page 8, June 1984.
[5] ウェルチ、T.、「高性能データ圧縮のためのテクニック」、IEEEコンピュータ、Vol.17、No.6、8ページ、1984年6月。
8. Security Considerations
8. セキュリティ問題
While security issues are not directly addressed by this document, it is important to note that the file format described in this document is intended for the communications of files between systems and across networks. Thus the same precautions and cares should be applied to these files as would be to any files received from remote and possibly unknown systems.
安全保障問題はこのドキュメントによって直接記述されませんが、本書では説明されたファイル形式がファイルに関するコミュニケーションのためにシステムの間と、そして、ネットワークの向こう側に意図することに注意するのは重要です。 したがって、リモートでことによると未知のシステムから受け取られたどんなファイルにはもあるだろうというとき、同じ注意と厄介がこれらのファイルに適用されるべきです。
Katz & Cohen [Page 22] RFC 1314 Image Exchange Format April 1992
キャッツとコーエン[22ページ]RFC1314イメージは1992年4月に形式を交換します。
9. Authors' Addresses
9. 作者のアドレス
Alan Katz USC Information Sciences Institute 4676 Admiralty Way #1100 Marina Del Rey, CA 90292-6695
アランキャッツUSC情報科学はマリーナデル・レイ、4676年のAdmiralty道#1100カリフォルニア90292-6695を設けます。
Phone: 310-822-1511 Fax: 310-823-6714 EMail: Katz@ISI.Edu
以下に電話をしてください。 310-822-1511 Fax: 310-823-6714 メールしてください: Katz@ISI.Edu
Danny Cohen USC Information Sciences Institute 4676 Admiralty Way #1100 Marina Del Rey, CA 90292-6695
ダニーコーエンUSC情報科学はマリーナデル・レイ、4676年のAdmiralty道#1100カリフォルニア90292-6695を設けます。
Phone: 310-822-1511 Fax: 310-823-6714 EMail: Cohen@ISI.Edu
以下に電話をしてください。 310-822-1511 Fax: 310-823-6714 メールしてください: Cohen@ISI.Edu
Katz & Cohen [Page 23]
キャッツとコーエン[23ページ]
一覧
スポンサーリンク
