From tapi2@central.susx.ac.uk Thu Aug 11 19:30:57 1994 X-VM-Message-Order: (1 3 4 2) X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n" X-VM-Labels: nil X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil X-VM-Bookmark: 4 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["10850" "" " 5" "August" "1994" "20:06:49" "GMT" "Alan Lim Wui Tze" "tapi2@central.susx.ac.uk" "<31u64p$i0f@infa.central.susx.ac.uk>" "355" "Re: The pgm file format" "^From:" nil nil "8" "1994080520:06:49" "The pgm file format" (number " " mark " Alan Lim Wui Tze Aug 5 355/10850 " thread-indent "\"Re: The pgm file format\"\n") "<31t9hd$itd@mercury.kingston.ac.uk>"] nil) Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!gatech!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!doc.ic.ac.uk!susx.ac.uk!tapi2 Newsgroups: sci.image.processing Organization: University of Sussex Lines: 355 Message-ID: <31u64p$i0f@infa.central.susx.ac.uk> References: <31t9hd$itd@mercury.kingston.ac.uk> NNTP-Posting-Host: solx1.central.susx.ac.uk X-Newsreader: TIN [version 1.2 PL2] From: tapi2@central.susx.ac.uk (Alan Lim Wui Tze (The Night Owl)) Subject: Re: The pgm file format Date: 5 Aug 1994 20:06:49 GMT Paul Giaccone (cs_j675@king.ac.uk) wrote: : I have seen the man page for pgm and I am aware that the magic number can : take the values P2 and P5, which give greylevels as ASCII and bytes : respectively. Do other values exist? I had heard that there is the value : P6 which gives colour images by storing red, green and blue levels for : each pixel. Can anyone confirm this or suggest where I could find out for : myself? Please find below man pages for Pbm Pgm and Ppm. Sorry about the length of this articles, I thought it'll make sense if it is complete. ======================================= pbm(5) FILE FORMATS pbm(5) NAME pbm - portable bitmap file format DESCRIPTION The portable bitmap format is a lowest common denominator monochrome file format. It was originally designed to make it reasonable to mail bitmaps between different types of machines using the typical stupid network mailers we have today. Now it serves as the common language of a large fam- ily of bitmap conversion filters. The definition is as fol- lows: - A "magic number" for identifying the file type. A pbm file's magic number is the two characters "P1". - Whitespace (blanks, TABs, CRs, LFs). - A width, formatted as ASCII characters in decimal. - Whitespace. - A height, again in ASCII decimal. - Whitespace. - Width * height bits, each either '1' or '0', starting at the top-left corner of the bitmap, proceeding in normal English reading order. - The character '1' means black, '0' means white. - Whitespace in the bits section is ignored. - Characters from a "#" to the next end-of-line are ignored (comments). - No line should be longer than 70 characters. Here is an example of a small bitmap in this format: P1 # feep.pbm 24 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 0 0 0 1 1 1 1 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Programs that read this format should be as lenient as pos- sible, accepting anything that looks remotely like a bitmap. Solbourne Computer, Inc.27 September 1991 1 pbm(5) FILE FORMATS pbm(5) There is also a variant on the format, available by setting the RAWBITS option at compile time. This variant is dif- ferent in the following ways: - The "magic number" is "P4" instead of "P1". - The bits are stored eight per byte, high bit first low bit last. - No whitespace is allowed in the bits section, and only a single character of whitespace (typically a newline) is allowed after the height. - The files are eight times smaller and many times faster to read and write. SEE ALSO atktopbm(1), brushtopbm(1), cmuwmtopbm(1), g3topbm(1), gem- topbm(1), icontopbm(1), macptopbm(1), mgrtopbm(1), pi3topbm(1), xbmtopbm(1), ybmtopbm(1), pbmto10x(1), pnmto- ascii(1), pbmtoatk(1), pbmtobbnbg(1), pbmtocmuwm(1), pbmtoepson(1), pbmtog3(1), pbmtogem(1), pbmtogo(1), pbmtoi- con(1), pbmtolj(1), pbmtomacp(1), pbmtomgr(1), pbmtopi3(1), pbmtoplot(1), pbmtoptx(1), pbmtox10bm(1), pbmtoxbm(1), pbmtoybm(1), pbmtozinc(1), pbmlife(1), pbmmake(1), pbmmask(1), pbmreduce(1), pbmtext(1), pbmupc(1), pnm(5), pgm(5), ppm(5) AUTHOR Copyright (C) 1989, 1991 by Jef Poskanzer. Solbourne Computer, Inc.27 September 1991 2 ============================================================== pgm(5) FILE FORMATS pgm(5) NAME pgm - portable graymap file format DESCRIPTION The portable graymap format is a lowest common denominator grayscale file format. The definition is as follows: - A "magic number" for identifying the file type. A pgm file's magic number is the two characters "P2". - Whitespace (blanks, TABs, CRs, LFs). - A width, formatted as ASCII characters in decimal. - Whitespace. - A height, again in ASCII decimal. - Whitespace. - The maximum gray value, again in ASCII decimal. - Whitespace. - Width * height gray values, each in ASCII decimal, between 0 and the specified maximum value, separated by whi- tespace, starting at the top-left corner of the graymap, proceeding in normal English reading order. A value of 0 means black, and the maximum value means white. - Characters from a "#" to the next end-of-line are ignored (comments). - No line should be longer than 70 characters. Here is an example of a small graymap in this format: P2 # feep.pgm 24 7 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 3 3 3 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 15 15 15 0 0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 15 0 0 3 3 3 0 0 0 7 7 7 0 0 0 11 11 11 0 0 0 15 15 15 15 0 0 3 0 0 0 0 0 7 0 0 0 0 0 11 0 0 0 0 0 15 0 0 0 0 0 3 0 0 0 0 0 7 7 7 7 0 0 11 11 11 11 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Programs that read this format should be as lenient as pos- sible, accepting anything that looks remotely like a gray- map. Solbourne Computer, Inc.12 November 1991 1 pgm(5) FILE FORMATS pgm(5) There is also a variant on the format, available by setting the RAWBITS option at compile time. This variant is dif- ferent in the following ways: - The "magic number" is "P5" instead of "P2". - The gray values are stored as plain bytes, instead of ASCII decimal. - No whitespace is allowed in the grays section, and only a single character of whitespace (typically a newline) is allowed after the maxval. - The files are smaller and many times faster to read and write. Note that this raw format can only be used for maxvals less than or equal to 255. If you use the _p_g_m library and try to write a file with a larger maxval, it will automatically fall back on the slower but more general plain format. SEE ALSO fitstopgm(1), fstopgm(1), hipstopgm(1), lispmtopgm(1), psid- topgm(1), rawtopgm(1), pgmbentley(1), pgmcrater(1), pgmedge(1), pgmenhance(1), pgmhist(1), pgmnorm(1), pgmoil(1), pgmramp(1), pgmtexture(1), pgmtofits(1), pgmtofs(1), pgmtolispm(1), pgmtopbm(1), pnm(5), pbm(5), ppm(5) AUTHOR Copyright (C) 1989, 1991 by Jef Poskanzer. Solbourne Computer, Inc.12 November 1991 2 ============================================================== ppm(5) FILE FORMATS ppm(5) NAME ppm - portable pixmap file format DESCRIPTION The portable pixmap format is a lowest common denominator color image file format. The definition is as follows: - A "magic number" for identifying the file type. A ppm file's magic number is the two characters "P3". - Whitespace (blanks, TABs, CRs, LFs). - A width, formatted as ASCII characters in decimal. - Whitespace. - A height, again in ASCII decimal. - Whitespace. - The maximum color-component value, again in ASCII decimal. - Whitespace. - Width * height pixels, each three ASCII decimal values between 0 and the specified maximum value, starting at the top-left corner of the pixmap, proceeding in normal English reading order. The three values for each pixel represent red, green, and blue, respectively; a value of 0 means that color is off, and the maximum value means that color is maxxed out. - Characters from a "#" to the next end-of-line are ignored (comments). - No line should be longer than 70 characters. Here is an example of a small pixmap in this format: P3 # feep.ppm 4 4 15 0 0 0 0 0 0 0 0 0 15 0 15 0 0 0 0 15 7 0 0 0 0 0 0 0 0 0 0 0 0 0 15 7 0 0 0 15 0 15 0 0 0 0 0 0 0 0 0 Programs that read this format should be as lenient as pos- sible, accepting anything that looks remotely like a pixmap. There is also a variant on the format, available by setting the RAWBITS option at compile time. This variant is Solbourne Computer, Inc.27 September 1991 1 ppm(5) FILE FORMATS ppm(5) different in the following ways: - The "magic number" is "P6" instead of "P3". - The pixel values are stored as plain bytes, instead of ASCII decimal. - Whitespace is not allowed in the pixels area, and only a single character of whitespace (typically a newline) is allowed after the maxval. - The files are smaller and many times faster to read and write. Note that this raw format can only be used for maxvals less than or equal to 255. If you use the _p_p_m library and try to write a file with a larger maxval, it will automatically fall back on the slower but more general plain format. SEE ALSO giftoppm(1), gouldtoppm(1), ilbmtoppm(1), imgtoppm(1), mtvtoppm(1), pcxtoppm(1), pgmtoppm(1), pi1toppm(1), pict- toppm(1), pjtoppm(1), qrttoppm(1), rawtoppm(1), rgb3toppm(1), sldtoppm(1), spctoppm(1), sputoppm(1), tga- toppm(1), ximtoppm(1), xpmtoppm(1), yuvtoppm(1), ppmtoacad(1), ppmtogif(1), ppmtoicr(1), ppmtoilbm(1), ppmtopcx(1), ppmtopgm(1), ppmtopi1(1), ppmtopict(1), ppmtopj(1), ppmtopuzz(1), ppmtorgb3(1), ppmtosixel(1), ppmtotga(1), ppmtouil(1), ppmtoxpm(1), ppmtoyuv(1), ppmdither(1), ppmforge(1), ppmhist(1), ppmmake(1), ppmpat(1), ppmquant(1), ppmquantall(1), ppmrelief(1), pnm(5), pgm(5), pbm(5) AUTHOR Copyright (C) 1989, 1991 by Jef Poskanzer. Solbourne Computer, Inc.27 September 1991 2 From mwm+@cs.cmu.edu Mon Aug 29 08:00:29 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["839" "" "25" "August" "1994" "06:33:10" "GMT" "Mark Maimone" "mwm+@cs.cmu.edu" "<33hdv6$d97@cantaloupe.srv.cs.cmu.edu>" "20" "Re: Need info on image formats" "^From:" nil nil "8" "1994082506:33:10" "Need info on image formats" (number " " mark " Mark Maimone Aug 25 20/839 " thread-indent "\"Re: Need info on image formats\"\n") ""] nil) Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!caen!zip.eecs.umich.edu!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!bb3.andrew.cmu.edu!cantaloupe.srv.cs.cmu.edu!mwm Newsgroups: sci.image.processing Organization: School of Computer Science, Carnegie Mellon Lines: 20 Message-ID: <33hdv6$d97@cantaloupe.srv.cs.cmu.edu> References: NNTP-Posting-Host: a.gp.cs.cmu.edu From: mwm+@cs.cmu.edu (Mark Maimone) Subject: Re: Need info on image formats Date: 25 Aug 1994 06:33:10 GMT In article , Srinagesh Ramaswamy wrote: >Could someone please direct me to some textbook/reference which deals >with the various image/graphic formats (gif/tiff/pbm/fbm/etc ..)? ftp://zaphod.ncsa.uiuc.edu/misc/file.formats/graphics.formats has lots of image format descriptions. Less common formats are also covered in: http://web.msi.umn.edu/WWW/SciVis/Formats/formats.html http://www.tnt.uni-hannover.de/data/info/www/tnt/soft/sci/vis/compgraph/fileformats/overview.html These are all listed at the bottom of the Computer Vision home page: http://www.cs.cmu.edu:8001/afs/cs/project/cil/ftp/html/vision.html -- Mark Maimone phone: +1 (412) 268 - 7698 Carnegie Mellon Computer Science email: mwm@cmu.edu WWW: http://www.cs.cmu.edu:8001/afs/cs/usr/mwm/ftp/www/home.html From spl@szechuan.ucsd.edu Mon Aug 29 08:00:45 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1036" "" "26" "August" "1994" "19:27:17" "GMT" "Steve Lamont" "spl@szechuan.ucsd.edu" "<33lfml$qig@network.ucsd.edu>" "21" "Re: Need info on image formats" "^From:" nil nil "8" "1994082619:27:17" "Need info on image formats" (number " " mark " Steve Lamont Aug 26 21/1036 " thread-indent "\"Re: Need info on image formats\"\n") "<33hdv6$d97@cantaloupe.srv.cs.cmu.edu>"] nil) Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!darwin.sura.net!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!network.ucsd.edu!szechuan.ucsd.edu!spl Newsgroups: sci.image.processing Organization: University of Calif., San Diego/Microscopy and Imaging Resource Lines: 21 Message-ID: <33lfml$qig@network.ucsd.edu> References: <33hdv6$d97@cantaloupe.srv.cs.cmu.edu> NNTP-Posting-Host: szechuan.ucsd.edu From: spl@szechuan.ucsd.edu (Steve Lamont) Subject: Re: Need info on image formats Date: 26 Aug 1994 19:27:17 GMT In article <33hdv6$d97@cantaloupe.srv.cs.cmu.edu> mwm+@cs.cmu.edu (Mark Maimone) writes: >In article , >Srinagesh Ramaswamy wrote: >>Could someone please direct me to some textbook/reference which deals >>with the various image/graphic formats (gif/tiff/pbm/fbm/etc ..)? There is also a book out by the O'Reilly folks called _Encyclopedia of Graphics Data Formats_ (I may have this slightly wrong but it's close). It comes with a CDROM with a lot of compiled freely-available software. See my recent review of this book in Comp.graphics for more detail. [disclosure: I got a free copy from O'Reilly and Associates, so I may be possibly considered slightly biased] spl -- Steve Lamont, SciViGuy -- (619) 534-7968 -- spl@szechuan.ucsd.edu San Diego Microscopy and Imaging Resource/UC San Diego/La Jolla, CA 92093-0608 "[S]cientific visualization should be called ... data display. But then it would be clear that is what we've been doing all along." - Alan Fournier From olander@gdwest.gd.com Mon Aug 29 08:01:33 1994 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["630" "" "19" "August" "1994" "08:24:27" "-0700" "Neal F. Olander" "olander@gdwest.gd.com" "<332irb$6qe@gdwest.gd.com>" "15" "Re: HELP: LEAST SQUARE COORDINATE TRANS." "^From:" nil nil "8" "1994081915:24:27" "HELP: LEAST SQUARE COORDINATE TRANS." (number " " mark " Neal F. Olander Aug 19 15/630 " thread-indent "\"Re: HELP: LEAST SQUARE COORDINATE TRANS.\"\n") ""] nil) Path: saips.cv.nrao.edu!hearst.acc.Virginia.EDU!concert!news-feed-1.peachnet.edu!emory!sol.ctr.columbia.edu!ucsnews!gdwest.gd.com!gdwest.gd.com!not-for-mail Newsgroups: sci.image.processing Organization: Computer Sciences Corporation Lines: 15 Distribution: world Expires: 12/12/94 Message-ID: <332irb$6qe@gdwest.gd.com> References: NNTP-Posting-Host: gdwest Summary: Standard Text reference Keywords: HELP: LEAST SQUARE COORDINATE TRANS. From: olander@gdwest.gd.com (Neal F Olander) Sender: olander@gdwest.gd.com Subject: Re: HELP: LEAST SQUARE COORDINATE TRANS. Date: 19 Aug 1994 08:24:27 -0700 Thet field of photogrammetry deals with least squares fittings. Commercial companies like Intergraph or Helava sell software packages that fit mappings between the real-world model and image-space. The standard textbook is "Photogrammetry" by F. Moffitt and E. Mikhail, published by Harper and Row, 1980. I am unaware of any "shareware" for this sort of least squares. However, the formulas are relatively simple (about 4 equations using array/vector notation) and most people just code it themselves. The debugging process helps you lear the algorithm. The algorithm is stated in the above-referenced textbook. Good luck.