ken@turtlevax.UUCP (Ken Turkowski) (07/18/85)
In article <10571@rochester.UUCP> sher@rochester.UUCP writes: > >Generalized Image Storage Format? > >In Ballard & Brown, Computer Vision, a generalized image is defined >as an iconic like array containing information relevant to an image >(paraphrase not quote). Examples of generalized images are Fourier >transformed images, edge images, stereo pairs, circle location points, >image histograms... If there were generally accepted formats for >generalized images then I could use edge recognition programs written >at CMU and image interpretation routines written at U. Mass to test my >texture recognition routines written here at U. Rochester. As far as >I can tell every university stores images differently. As far as >other generalized images then every program stores them differently. >This I believe acts as a gigantic brake on vision research. It would be nice if the generalized image could accommodate images used in computer graphics as well as image processing and machine vision. One of the more fundamental things about computer graphic images is that they may not be rectangular, and they may not be opaque (i.e. they may have some amount of transparency). Such things are accommodated by including an ALPHA image in addition to intensity or RGB. The alpha image acts as a mask, to merge two images, and can be any number of bits. One bit alphas are useful as binary masks which perform a hard switch between one image and another, but generate jagged edges (and high frequencies!) at the borders between two images. The jagged edges resultant from image composition disappear quickly when using 2 or more bits for alpha. Additionally, images may be created in different types of color spaces: the standard intensity or RGB color spaces are at one end of the spectrum (pardon the pun) and images painted with a random palette are at the other. One type of color space between these two is the one used by Alvy Ray Smith and Garland Stern for their SoftCel/TintFill system: several linearly interpolated color spaces with one common color at one end of each line. Image files should contain parameters that describe (probably symbolically) the color space that the image was created in. The image file may also want to include the un-gamma corrected colormap as well. -- Ken Turkowski @ CADLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,nsc,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA
fritz@utastro.UUCP (Fritz Benedict) (07/18/85)
> In article <10571@rochester.UUCP> sher@rochester.UUCP writes: > > > >Generalized Image Storage Format? > > > >In Ballard & Brown, Computer Vision, a generalized image is defined > >as an iconic like array containing information relevant to an image > >(paraphrase not quote). Examples of generalized images are Fourier > >transformed images, edge images, stereo pairs, circle location points, > >image histograms... If there were generally accepted formats for > >generalized images then I could use edge recognition programs written > >at CMU and image interpretation routines written at U. Mass to test my > >texture recognition routines written here at U. Rochester. As far as > >I can tell every university stores images differently. As far as > >other generalized images then every program stores them differently. > >This I believe acts as a gigantic brake on vision research. > Take a look at two papers discribing "Flexible Image Transport System" = FITS. We astronomers have been swapping images around on tape using this protocal for 4-5 years. We can now even pass tabular data around. At least 20 astronomical research sites can communicate image and tabular data with relative ease. References: "FITS: A Flexible Image Transport System", Astronomy and Astrophysics Suppl. Series, vol 44, pgs 363-370, 1981. "An Extension of FITS for Groups of Small Arrays of Data", ibid, pgs 371-374, 1981. Alas, the table extension description has not yet been published. Unix compatible code to read and write FITS tapes exists. FITS works on up to 9 dimensional data, too (useful in radio astronomy). -- Fritz Benedict (512)471-4461x448 uucp: {...noao,decvax,ut-sally}!utastro!fritz arpa: fritz@ut-ngp snail: Astronomy, U of Texas, Austin, TX 78712
lee@rochester.UUCP (Lee Moore) (07/18/85)
> Take a look at two papers discribing "Flexible Image Transport System" = > FITS. We astronomers have been swapping images around on tape using this > protocal for 4-5 years. We can now even pass tabular data around. > At least 20 astronomical research sites can communicate image and tabular > data with relative ease. > Actually, this doesn't answer the question. The original poster wasn't interested in an image interchange format -- many places already use the NATO image format -- the question is what representation is used for image processing/analysis. People invariably convert the interchange format to some local representation. Unfortuately, the design of a local representation is highly machine dependent. Word size, disk block size, and other factors influence the final design. In this sense, there can't be a representation that is both efficient and universal. On the bright side, most places doing vision research have Vax/Unix systems so finding a standard for that op. sys./hardware combination will do alot of good. Has ANYBODY out there adopted somebody else's format? We originally used Xerox's AIS format but we changed it so much that it isn't very compatible anymore... -- TCP/IP: lee@rochester.arpa UUCP: {decvax, allegra, seismo, cmcl2}!rochester!lee XNS: Lee Moore:CS:Univ Rochester Phone: +1 (716) 275-7747, -5671 Physical: 43 01' 40'' N, 77 37' 49'' W
foo@steinmetz.UUCP (foo) (07/24/85)
One problem with the image formats discussed so far is that they have no provision for geometric entities which may have been extracted from the image. -- C. Ian Connolly, WA2IFI - USENET: ...edison!steinmetz!connolly , , ARPANET: connolly@ge-crd An rud a bhionn, bionn.
foo@steinmetz.UUCP (foo) (07/24/85)
> > Has ANYBODY out there adopted somebody else's format? We originally > used Xerox's AIS format but we changed it so much that it isn't very > compatible anymore... > -- > TCP/IP: lee@rochester.arpa > UUCP: {decvax, allegra, seismo, cmcl2}!rochester!lee > XNS: Lee Moore:CS:Univ Rochester > Phone: +1 (716) 275-7747, -5671 > Physical: 43 01' 40'' N, 77 37' 49'' W We've been switching over from an internal format to SRI's (?) IU-workbench format. This is the default format for Image-Calc and seems to be adequate for the time being. When we store scene structures with line segments thrown in, we use an adaptation of the format used by Image-Calc for color images (i.e., a master file which contains paths for each component image, and then all the definitions for the lines & their properties). -- C. Ian Connolly, WA2IFI - USENET: ...edison!steinmetz!connolly , , ARPANET: connolly@ge-crd An rud a bhionn, bionn.
ken@turtlevax.UUCP (Ken Turkowski) (07/29/85)
In article <195@steinmetz.UUCP> connolly@steinmetz.UUCP writes: >We've been switching over from an internal format to SRI's (?) IU-workbench >format. This is the default format for Image-Calc and seems to be adequate >for the time being. When we store scene structures with line segments >thrown in, we use an adaptation of the format used by Image-Calc for color >images (i.e., a master file which contains paths for each component image, >and then all the definitions for the lines & their properties). Could you post the formal description of these image formats? I'd like to see what the advantages and disadvantages are, and whether they are machine independent and are flexible enough to be used for my application. -- Ken Turkowski @ CADLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,nsc,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA