.\" This man page was generated by the Netpbm tool 'makeman' from HTML source.
.\" Do not hand-hack it!  If you have bug fixes or improvements, please find
.\" the corresponding HTML page on the Netpbm website, generate a patch
.\" against that, and send it to the Netpbm maintainer.
.TH "Tifftopnm User Manual" 0 "02 January 2015" "netpbm documentation"

.SH "نام (NAME)"

tifftopnm \- تبدیل یک فایل TIFF به تصویر PNM

.UN synopsis
.SH "خلاصه دستور (SYNOPSIS)"

\fBtifftopnm\fP

[\fB-alphaout=\fP{\fIalpha-filename\fP,\fB-\fP}]
[\fB-headerdump\fP]
[\fB-verbose\fP]
[\fB-respectfillorder\fP]
[\fB-byrow\fP]
[\fB-orientraw\fP]
[\fItiff-filename\fP]


.UN description
.SH "توضیحات (DESCRIPTION)"
.PP
این برنامه بخشی از
.BR "Netpbm" (1)\c
\& است.
.PP
برنامه \fBtifftopnm\fP یک فایل TIFF را به‌عنوان ورودی خوانده و یک تصویر PNM به‌عنوان خروجی تولید می‌کند. نوع فایل خروجی به فایل ورودی بستگی دارد \- اگر سیاه‌وسفید باشد، \fBtifftopnm\fP یک تصویر PBM تولید می‌کند؛ اگر در مقیاس خاکستری باشد، یک تصویر PGM تولید می‌کند؛ در غیر این صورت، خروجی PPM خواهد بود. برنامه نوعی را که در حال نوشتن آن است به شما اعلام می‌کند.
.PP
اگر فایل TIFF حاوی چندین تصویر باشد (چندین «دایرکتوری»)، \fBtifftopnm\fP یک جریان خروجی PNM چندتصویری تولید می‌کند. با این حال، پیش از Netpbm 10.27 (مارس ۲۰۰۵)، تمام تصاویر ورودی به‌جز تصویر اول نادیده گرفته می‌شدند.
.PP
آرگومان \fItiff-filename\fP نام فایلی است که تصویر TIFF را در بر دارد. اگر «-» را مشخص کنید یا این آرگومان را تعیین نکنید، \fBtifftopnm\fP از ورودی استاندارد (Standard Input) استفاده می‌کند.
.PP
در هر دو حالت، پیش از Netpbm 10.70 (مارس ۲۰۱۵)، فایل باید قابلیت پرش (seekable) می‌داشت. به این معنی که امکان استفاده از pipe وجود نداشت، اما هر فایل عادی قابل قبول بود. در نسخه‌های کنونی Netpbm نیازی به seekable بودن فایل نیست، اما اگر نباشد، \fBtifftopnm\fP یک فایل عادی موقت شامل کل تصویر ایجاد می‌کند، بنابراین باید منابع لازم برای آن را در اختیار داشته باشید (و این موضوع ممکن است دلیل شما برای استفاده از pipe را بی‌اثر کند).

.UN library
.SS "قابلیت TIFF (TIFF Capability)"
.PP
برنامه \fBpamtotiff\fP از کتابخانه TIFF موجود در Libtiff.org (یا هر معادل دیگری که ارائه دهید) برای تفسیر ورودی TIFF استفاده می‌کند؛ بنابراین مجموعه فایل‌هایی که قادر به تفسیر آن‌ها است عمدتاً توسط آن کتابخانه مشخص می‌شود.
.PP
این برنامه نمی‌تواند هر فایل TIFF ممکنی را بخواند \-\- چرا که تغییرات و گونه‌های بی‌شماری از قالب TIFF وجود دارد. با این حال، فایل‌های TIFF با رنگ‌های تک‌رنگ (monochrome)، مقیاس خاکستری (grayscale)، RGB، RGBA (قرمز/سبز/آبی همراه با کانال شفافیت)، CMYK (تفکیک رنگ جوهر Cyan-Magenta-Yellow-Black) و پالت رنگی را درک می‌کند. یک فایل RGB می‌تواند ساختار رنگی تک‌صفحه‌ای (interleaved) یا چندصفحه‌ای داشته باشد. این برنامه ورودی‌های ۱ تا ۸ و ۱۶ بیت در هر نمونه (bit-per-sample) را می‌خواند که مورد آخر می‌تواند با کدگذاری bigendian یا littlendian باشد. اطلاعات دایرکتوری TIFF نیز ممکن است bigendian یا littlendian باشد.
.PP
قالب‌های TIFF متعددی وجود دارد که \fBtifftopnm\fP تنها در صورتی می‌تواند آن‌ها را بخواند که تصویر به اندازه کافی کوچک باشد تا در حافظه جا بگیرد. \fBtifftopnm\fP در صورتی از تابع TIFFRGBAImageGet() متعلق به کتابخانه TIFF برای پردازش تصویر استفاده می‌کند که حافظه کافی در دسترس باشد تا TIFFRGBAImageGet() بتواند کل تصویر را یک‌باره در حافظه ذخیره کند (کاری که TIFFRGBAImageGet() انجام می‌دهد). در غیر این صورت، \fBtifftopnm\fP از یک راهبرد تبدیل سطر به سطر ابتدایی‌تر با استفاده از داده‌های خام دریافت‌شده از TIFFReadScanLine() و منطق داخلی خود استفاده می‌کند. این منطق داخلی به اندازه TIFFRGBAImageGet() قالب‌های مختلف را نمی‌شناسد، و برخی از قالب‌های فشرده‌شده را اساساً نمی‌توان با TIFFReadScanLine() خواند.
.PP
پیش از Netpbm 10.11 (اکتبر ۲۰۰۲)، \fBtifftopnm\fP هرگز از TIFFRGBAImageGet() استفاده نمی‌کرد، بنابراین قادر نبود بسیاری از قالب‌هایی را که امروزه درک می‌کند تفسیر نماید.
.PP
هیچ دلیل بنیادینی وجود ندارد که این برنامه نتواند انواع دیگر فایل‌های TIFF را، حتی زمانی که کل آن‌ها به‌طور هم‌زمان در حافظه جا نمی‌شوند، بخواند. محدودیت‌های فعلی عمدتاً به این دلیل است که تاکنون کسی درخواست پشتیبانی بیشتری نکرده است.

.UN output.SS تصویر خروجی (Output Image)
.PP
خروجی PNM دارای مقدار maxval یکسانی با ورودی Tiff است، به جز زمانی که ورودی Tiff دارای نگاشت رنگی (colormapped) باشد (که مستلزم یک maxval برابر با ۶۵۵۳۵ است)؛ در این صورت خروجی PNM دارای maxval برابر با ۲۵۵ خواهد بود. اگرچه این امر ممکن است منجر به از دست رفتن اطلاعات شود، اما چنین تصاویر ورودی به‌ندرت تفکیک‌پذیری رنگی بیشتری از آنچه یک maxval برابر با ۲۵۵ فراهم می‌کند دارند و کاربران معمولاً نمی‌توانند با فایل‌های PNM با مقدار maxval > 255 کار کنند. در مقابل، یک تصویر Tiff فاقد نگاشت رنگ که نیازی به maxval > 255 ندارد، خود نیز \fIفاقد\fP یک maxval > 255 است؛ بنابراین هنگامی که \fBtifftopnm\fP یک maxval > 255 بدون نگاشت رنگ را می‌بیند، آن را جدی گرفته و یک maxval منطبق در خروجی تولید می‌کند.
.PP
استثنای دیگر حالتی است که TIFF maxval بزرگ‌تر از ۶۵۵۳۵ باشد، که حداکثر مقدار مجاز در قالب‌های Netpbm است. در آن حالت، \fBtifftopnm\fP از یک maxval برابر با ۶۵۵۳۵ استفاده می‌کند و شما بخشی از اطلاعات را در تبدیل از دست خواهید داد.

.UN options
.SH "گزینه‌ها (OPTIONS)"
.PP
علاوه بر گزینه‌های مشترک بین تمامی برنامه‌های مبتنی بر libnetpbm (به‌ویژه \fB-quiet\fP، به
.UR index.html#commonoptions
گزینه‌های مشترک (Common Options)
.UE
\& مراجعه کنید)، \fBtifftopnm\fP گزینه‌های خط فرمان زیر را به رسمیت می‌شناسد:
.PP
می‌توانید هر گزینه را به کوتاه‌ترین پیشوند یکتای آن مخفف کنید. می‌توانید به جای یک خط تیره از دو خط تیره در گزینه‌ها استفاده کنید. می‌توانید یک گزینه و مقدار آن را با علامت مساوی یا فاصله (whitespace) از یکدیگر جدا کنید.


.TP
\fB-alphaout=\fP\fIalpha-filename\fP
\fBtifftopnm\fP یک فایل PGM حاوی مقادیر کانال آلفا در تصویر ورودی ایجاد می‌کند. اگر تصویر ورودی فاقد کانال شفافیت باشد، فایل \fIalpha-filename\fP تماماً حاوی مقادیر صفر (کاملاً شفاف) برای شفافیت خواهد بود. اگر \fB-alphaout\fP را مشخص نکنید،
\fBtifftopnm\fP فایل شفافیت تولید نمی‌کند، و چنانچه تصویر ورودی دارای کانال شفافیت باشد، \fBtifftopnm\fP به‌سادگی آن را نادیده می‌گیرد.
.sp
اگر \fB-\fP را به عنوان نام فایل مشخص کنید، \fBtifftopnm\fP خروجی شفافیت را در خروجی استاندارد (Standard Output) می‌نویسد و از تصویر صرف‌نظر می‌کند.
.sp
برای دیدن یکی از روش‌های استفاده از فایل خروجی شفافیت، به
.BR "pamcomp" (1)\c
\& مراجعه کنید.

.TP
\fB-respectfillorder\fP
به‌طور پیش‌فرض، \fBtifftopnm\fP برچسب «fillorder» را در ورودی TIFF نادیده می‌گیرد، که به این معنی است که ممکن است تصویر را به نادرستی تفسیر کند. برای اینکه از مشخصات استاندارد تبعیت کند، از این گزینه استفاده کنید. برای بحثی مفصل اما جذاب درباره اینکه چرا \fBtifftopnm\fP بدین صورت عمل می‌کند و نحوه استفاده از گزینه \fB-respectfillorder\fP، به یادداشت مربوط به fillorder در ادامه مراجعه کنید.

.TP
\fB-byrow\fP
این گزینه می‌تواند باعث شود \fBtifftopnm\fP سریع‌تر اجرا شود.
.sp
\fBtifftopnm\fP برای انجام تبدیل از Tiff به PNM دو روش دارد که به ترتیب از دو قابلیت کتابخانه TIFF بهره می‌برند:



.TP
Whole Image (تصویر کامل)
رمزگشایی یک‌باره کل تصویر در حافظه با استفاده از \fBTIFFRGBAImageGet()\fP، سپس تبدیل به PNM و ارسال به خروجی به‌صورت سطر به سطر.
   
.TP
Row By Row (سطر به سطر)
خواندن، تبدیل و خروجی دادن هر بار یک سطر با استفاده از \fBTIFFReadScanline()\fP


.sp
روش Whole Image ترجیح داده می‌شود زیرا کتابخانه Tiff بخش بیشتری از کار را انجام می‌دهد، که به این معناست که قابلیت‌های بیشتری از قالب Tiff را در حال حاضر و آینده درک می‌کند. همچنین، برخی قالب‌های فشرده TIFF امکان استخراج یک سطر جداگانه را نمی‌دهند.
.sp
روش Row By Row حافظه بسیار کمتری مصرف می‌کند، به این معنی که با تصاویر بزرگ، می‌تواند در محیط‌هایی اجرا شود که Whole Image امکان‌پذیر نیست و همچنین ممکن است سریع‌تر اجرا شود. و از آنجا که کد Netpbm بخش بیشتری از کار را انجام می‌دهد، این امکان وجود دارد که انعطاف‌پذیرتر باشد یا حداقل در صورت وجود اشکالی در TIFF، اطلاعات تشخیصی بهتری ارائه دهد.
.sp
کد بومی Netpbm ممکن است کاری را به درستی انجام دهد که کتابخانه TIFF به نادرستی انجام می‌دهد، یا برعکس.
.sp
در Netpbm، ما قابلیت عملکردی را بر کارایی ترجیح می‌دهیم، بنابراین به‌طور پیش‌فرض ابتدا Whole Image را امتحان می‌کنیم، و اگر نتوانیم حافظه کافی برای تصویر رمزگشایی‌شده به دست آوریم یا \fBTIFFRGBAImageGet()\fP با شکست مواجه شود، به Row By Row بازمی‌گردیم. اما اگر گزینه \fB-byrow\fP را مشخص کنید، \fBtifftopnm\fP روش Whole Image را امتحان نخواهد کرد. اگر Row By Row کار نکند، برنامه به‌سادگی با خطا خاتمه می‌یابد.
.sp
برای شرح حالتی که در آن Row By Row تفاوت چشمگیری در نتایج شما ایجاد می‌کند، به
.UR #cmyk
تصاویر تفکیک رنگ (CMYK) در TIFF
.UE
\& مراجعه کنید.
.sp
روش Whole Image زمانی که تصویر TIFF شما بیش از ۸ بیت به ازای هر نمونه (sample) استفاده می‌کند، باعث افت دقت می‌شود. تابع \fBTIFFRGBAImageGet()\fP نمونه‌ها را به ۸ بیت تبدیل می‌کند. سپس \fBtifftopnm\fP آن‌ها را مجدداً به maxval برابر با ۶۵۵۳۵ مقیاس‌بندی می‌کند، اما ۸ بیت اطلاعات پایین‌تر از دست رفته است.
.sp
در بسیاری از نسخه‌های کتابخانه TIFF، تابع \fBTIFFRGBAImageGet()\fP فایل‌های TIFF را که در آن‌ها جهت‌گیری رستر ستون‌محور (column-major) است (یعنی یک سطر از رستر، ستونی از تصویر است) به‌درستی تفسیر نمی‌کند. با چنین کتابخانه و فایلی، برای دریافت خروجی درست باید از \fB-byrow\fP استفاده کنید.
.sp
پیش از Netpbm نسخه 10.11 (اکتبر ۲۰۰۲)، \fBtifftopnm\fP همواره به روش Row By Row عمل می‌کرد. Netpbm نسخه 10.12 همواره ابتدا Whole Image را امتحان می‌کرد. گزینه \fB-byrow\fP همراه با Netpbm نسخه 10.13 (ژانویه ۲۰۰۳) معرفی شد.

.TP
\fB-orientraw\fP
یک جریان TIFF حاوی داده‌های رستری است که می‌توانند به روش‌های گوناگونی در جریان چیده شوند. معمولاً این داده‌ها به صورت سطری مرتب می‌شوند، با بالاترین سطر در ابتدا، و پیکسل‌ها از چپ به راست در هر سطر، اما بسیاری از جهت‌گیری‌های دیگر نیز ممکن هستند.
.sp
جهت‌گیری معمول همان موردی است که قالب‌های Netpbm استفاده می‌کنند، بنابراین هنگامی که رستر TIFF به آن صورت جهت‌گیری شده باشد، \fBtifftopnm\fP می‌تواند وظایف خود را بسیار کارآمد انجام دهد.
.sp
اما اگر رستر TIFF به هر شکل دیگری جهت‌گیری شده باشد، تبدیل آن به قالب Netpbm ممکن است به میزان قابل توجهی پردازش توسط \fBtifftopnm\fP نیاز داشته باشد.
.sp
گزینه \fB-orientraw\fP اعلام می‌کند که تصویری خروجی تولید شود که بیانگر رستر خام درون جریان TIFF باشد، نه تصویری که انتظار می‌رود جریان TIFF نمایانگر آن باشد. در خروجی، گوشه بالا سمت چپ منطبق بر ابتدای رستر TIFF است، پیکسل بعدی به سمت راست همان پیکسل بعدی در رستر TIFF است و غیره. \fBtifftopnm\fP می‌تواند این کار را به آسانی انجام دهد، اما شما تصویر درستی دریافت نمی‌کنید. می‌توانید از \fBpamflip\fP استفاده کنید تا خروجی را به تصویری که جریان TIFF نمایش می‌دهد تبدیل کنید (اما اگر این کار را انجام دهید، عملاً مزیت \fB-orientraw\fP را از دست خواهید داد).
.sp
با این گزینه، \fBtifftopnm\fP همیشه از روش Row By Row استفاده می‌کند (به \fB-byrow\fP مراجعه کنید).
.sp
این گزینه در Netpbm نسخه 10.42 (مارس ۲۰۰۸) جدید بود. پیش از آن، \fBtifftopnm\fP معمولاً با تصاویر TIFF که جهت‌گیری غیر از حالت متداول داشتند، نتایجی دلخواه و غیرقابل پیش‌بینی تولید می‌کرد.

.TP
\fB-verbose\fP
پیام‌های بیشتری درباره تبدیل در خطای استاندارد (Standard Error) چاپ می‌کند.

.TP
\fB-headerdump\fP
اطلاعات فایل TIFF را نیز در stderr تخلیه (dump) می‌کند. این اطلاعات ممکن است در اشکال‌زدایی مشکلات تبدیل فایل TIFF مفید باشد.



.UN notes.SH "نکات (NOTES)"

.UN fillorder
.SS "ترتیب پر کردن (Fillorder)"
.PP
در سرآیند یک تصویر TIFF، اطلاعاتی با عنوان «fillorder» وجود دارد. مشخصات فنی TIFF به‌روشنی بیان می‌کند که این مقدار، ترتیب چیدمان بیت‌ها را درون یک بایت هنگام توصیف پیکسل‌های تصویر تعیین می‌کند. با فرض این‌که قالب تصویر طوری باشد که بیش از یک پیکسل در یک بایت واحد نمایش داده شود، دو حالت وجود دارد: ۱) بایت از باارزش‌ترین بیت (MSB) به کم‌ارزش‌ترین بیت (LSB) از چپ به راست در تصویر پر می‌شود؛ و ۲) حالت برعکس آن.
.PP
با این وجود، درک نادرست و سردرگمی زیادی دربارهٔ معنای fillorder وجود دارد. شواهد نشان می‌دهد برخی از افراد گمان می‌کنند این مفهوم مربوط به ترتیب بایت‌ها (byte order) در مواردی است که یک مقدار منفرد توسط دو بایت نمایش داده می‌شود.
.PP
این افراد باعث ایجاد تصاویری با فرمت TIFF می‌شوند که اگرچه در عمل از ترتیب پر کردن MSB-to-LSB استفاده می‌کنند، اما برچسب fillorder آن‌ها نشان می‌دهد از LSB-to-MSB استفاده شده است. در این حالت، برنامه‌ای که تصویر TIFF را به‌درستی تفسیر کند، نتیجه‌ای متفاوت از آن‌چه سازندهٔ تصویر در نظر داشته ارائه خواهد داد.
.PP
برای مدتی طولانی، \fBtifftopnm\fP خود مقدار fillorder را درک نمی‌کرد و بدون در نظر گرفتن برچسب fillorder در سرآیند TIFF، همواره فرض را بر این می‌گذاشت که fillorder از نوع MSB-to-LSB است. تا آنجا که مشخص است، هیچ دلیل موجهی برای استفاده از ترتیبی به‌جز MSB-to-LSB وجود ندارد؛ بنابراین کاربران \fBtifftopnm\fP با رضایت از همان تصاویر TIFF که برچسب‌های fillorder نادرستی داشتند استفاده می‌کردند.
.PP
برای اینکه این دسته از کاربران همچنان بدون مشکل به کار خود ادامه دهند، امروزه نیز \fBtifftopnm\fP برچسب fillorder را نادیده می‌گیرد، مگر اینکه صریحاً خلاف آن را مشخص کنید (با این حال، هرگاه برچسب fillorder مقداری به‌جز MSB-to-LSB داشته باشد، هشدار می‌دهد که برچسب در حال نادیده گرفته شدن است).
.PP
اگر بنا به دلایلی یک تصویر TIFF در اختیار دارید که واقعاً ترتیب پر کردن آن LSB-to-MSB است و برچسب fillorder آن نیز به‌درستی به این نکته اشاره دارد، باید از گزینهٔ \fB-respectfillorder\fP در \fBtifftopnm\fP استفاده کنید تا خروجی صحیحی به دست آورید.
.PP
نمونه‌هایی از تصاویر نادرست TIFF در آدرس زیر وجود دارند:
.UR ftp://weather.noaa.gov
ftp://weather.noaa.gov
.UE
\& این تصاویر ظاهراً توسط برنامه‌ای به نام \fBfaxtotiff\fP ایجاد شده‌اند.
.PP
این یادداشت در ۱ ژانویه ۲۰۰۲ نوشته شده است.


.UN cmyk
.SS "تصاویر TIFF تفکیک رنگ (CMYK)"
.PP
برخی از تصاویر TIFF اطلاعات رنگ را در قالب CMYK ذخیره می‌کنند، در حالی که تصاویر PNM از RGB استفاده می‌کنند. فرمول‌های گوناگونی برای تبدیل میان این دو قالب وجود دارد و \fBtifftopnm\fP می‌تواند از هر یک از دو روش بهره ببرد.
.PP
کتابخانهٔ TIFF (نسخهٔ 3.5.4 از libtiff.org) در سرویس TIFFRGBAImageGet() خود از فرمول Y=(1-K)*(1-B) (به طور مشابه برای R و G) استفاده می‌کند. زمانی که \fBtifftopnm\fP در حالت تصویر کامل (Whole Image) کار می‌کند، از این سرویس بهره می‌برد؛ بنابراین این همان تبدیلی است که دریافت می‌کنید.
.PP
اما هنگامی که \fBtifftopnm\fP در حالت سطر به سطر (Row By Row) اجرا می‌شود، از TIFFRGBAImageGet() استفاده نمی‌کند و تبدیلی به دست می‌آورید که به‌نظر کاربردی‌تر می‌آید: Y=1-(B+K). این حالت معکوس عملکرد \fBpnmtotiffcmyk\fP است.
.PP
برای اطلاعات بیشتر دربارهٔ مقایسهٔ حالت تصویر کامل (Whole Image) در برابر حالت سطر به سطر (Row By Row)، گزینهٔ \fB-byrow\fP را ببینید.
.PP
پیش از نسخهٔ Netpbm 10.21 (مارس ۲۰۰۴)، \fBtifftopnm\fP همواره از فرمول Y=(1-K)*(1-B) استفاده می‌کرد.


.UN seealso
.SH "همچنین ببینید (SEE ALSO)"
.BR "pnmtotiff" (1)\c
\&,
.BR "pnmtotiffcmyk" (1)\c
\&,
.BR "pamcomp" (1)\c
\&,
.BR "pnm" (1)\c
\&

.UN author.SH "نویسنده (AUTHOR)"
.PP
برگرفته‌شده توسط Jef Poskanzer از tif2ras.c، با کپی‌رایت (c) ۱۹۹۰ متعلق به Sun Microsystems, Inc. نویسنده: Patrick J. Naughton (\fInaughton@wind.sun.com\fP).
.SH "منبع سند (DOCUMENT SOURCE)"
این صفحهٔ راهنما توسط ابزار Netpbm یعنی \(aqmakeman\(aq از منبع HTML تولید شده است. مستندات اصلی در نشانی زیر قرار دارد:
.IP
.B http://netpbm.sourceforge.net/doc/tifftopnm.html
.PP