Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Image processing and embedding metadata in images?

 [1/8] from: jasonic::panix::com at: 12-Nov-2001 14:21


Developing an application which uses lots of images. A REBOL/View program helps contributors upload content to Zope and Vanilla sites. They will submit metadata along with images [jpeg, gif, png]. Other binary formats like Flash5 [.swf] will be used. I want to embed a modest amount of metadata into the image itself. I am thinking this may be done in several ways: - using header or end-of-file space - adding a thin data strip along the top/bottom edge whose datavalues are parsed by client/server-side tools to generate a standard block. - ?? Does anyone here have any experience with such? Specifically any advice for precise binary data manipulation of image formats in REBOL? I imagine there could be problems with embedding data in JPEG files, as it may get mabngled by compression settings. Python has a well-known library PIL [Python Imaging Library] http://www.pythonware.com/products/pil/ Along with ImageMagic PIL is used in Zope products too for some very useful server-side image processing such as Zope 'Photo and Photo Folder' http://www.zope.org/Members/rbickers/Photo/Photo-1.2.2.tgz/README.txt Photo objects provide a way to manage various display sizes of an image. They are very similar to Zope Image objects but generate and store multiple copies of the image in different sizes. These sizes are configurable for each Photo. Thus one uploads an image once to the server, usually a large source file. The new Photo object's params list defines what alternate sizes are generated. This takes processing time, but the result is a family of images sizes which can be called immediately by simple URL variations: <a href="http://localhost/myphoto.jpg/view?display=small">thumbnail</a> <a href="http://localhost/myphoto.jpg/view?display=medium">medium</a> <a href="http://localhost/myphoto.jpg/view?display=large">large</a> <a href="http://localhost/myphoto.jpg/view?display=full">full</a> etc Wondering what the REBOL / VANILLA equivalent is..? For server side tasks, we can use Python/PIL + REBOL, but am hoping for a more symetrical, lower-profile solution. In general, moving over from Python/Zope to REBOL/Vanilla.. It's more fun! Thanks - Jason

 [2/8] from: ryanc:iesco-dms at: 12-Nov-2001 12:28


I would rethink the whole approach. Data can be imprinted on gif, jpeg, png, and bmp, and saved as a png or bmp using /View very easily, but forget about swf. Could be done like so: save/png %out.png to-image layout [image %image.jpg text "Posted by Ryan Cole"] Generally though, I recommend referencing the metadata to the image, which makes much more sense. When you get into altering binaries, you basically need to be able to understand the whole thing. With simple formats like bmp and gif, this is very reasonable, but with more complex formats its a major endevour. --Ryan Jason Cunliffe wrote:
> Developing an application which uses lots of images. > A REBOL/View program helps contributors upload content to Zope and Vanilla
<<quoted lines omitted: 40>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 The contradiction so puzzling to the ordinary way of thinking comes from the fact that we have to use language to communicate our inner experience which in its very nature transcends lingistics. -D.T. Suzuki

 [3/8] from: jasonic:panix at: 12-Nov-2001 17:02


Hi Ryan
> I would rethink the whole approach. Data can be imprinted on gif, jpeg,
png,
> and bmp, and saved as a png or bmp using /View very easily, but forget
about
> swf. Could be done like so: > > save/png %out.png to-image layout [image %image.jpg text "Posted by Ryan
Cole"]
Thanks for your comments.. Yes REBOL's to-image layout is a handy feature :-) And you nmay be right that I am on the wrong track. Let me explain better. Pro: Surprinting is handy for some things like overt copyright [Associated Press use it often on the web]. Con: But really messy for others, especially where images must be 'clean' and usable for various media composition or output. It is innefieicent and they can not be edited. Privacy/Transparency are issues too. SWF is *not* the problem. Easy to include all kinds of metadata or smart behaviors in Flash files. That's partly what got me started again on this. There is a superb tool called jpeg2swf http://wahlers.de/webcam.html It only creates a minimal SWF version of JPEG images, but the beauty is one can add all sorts of other infromation, and features as soon as it is converted to SWF without changing the name etc. Forever one must take images and need to attach/associete meta-data. This is for archival, linking, and workflow reasons. Some typical examples round here: 1. Original Source File Name problems 1.a may be part of a big sequence like: "a1b_spider_0029.JPG" That is meaningful name given an image for one applcation, which is not helpful in another. By renaming it I 'lose' the ability to return 1.b worse it may one of zillion sequenced video/digital still captures: PFP000125489.JPG 2. Timestamping and GeoReferencing Most photos objects people have several implicit geo-referenced metadata attributes which are lost or thrown away becuase there are sensible means to embed them. Every photo video image was taken somewhere at some time unless it was generated entrirely artifically or has been composited beyond tangible reality. New photos are especially sensitive to this. 3. Contextual Renaming There are many reason why one wants to rename images. 3.a http://www.google.com/imghp?hl=en is one 3.b web-site or multimedia content management programming is another 3.c .. oh yeah people! 4. Captions Many images benefit from captions in addition to decent titles. Filenames whcih are not meaningful directly for people, mean more work and more questions. They also tend to cancel out automated backgound tools. Captions are a powerful tool which have been around esential since the publishing explosion 500 year ago. I find it very very strange that digital image formats have negelected these needs. 5. Authors 6. Hyperlinks useful for dynamic metadata, registration, search, archiving, smaller files. 7. Rights and permsissions 8. Workflow & Groupware functionality This is main reason I am pursuing this. I know how much time and effort it is to go 'back' and dig up infromation or pass it along with images. This is unlike almost any other media you can thing of: books, printing, film, video, music, sodacans and clothing... They ALL keep embed some metadata with the medium. Why not Images? Often times skills people equipment tools are wise in scope. Keeping basic things together aids workflow, especially in any distributed scheme. making simple things simple.. 9. Other Cool Stuff urls to REBOL image processing functions urls to Vanilla snips 10. *errorism and ilk LOL! sigh yes anything'r'possible{tm}, but is a lot like 5 years ago when ignorant people publicly focused on Internet Porn and thus gave it lotta free global publicity.
> Generally though, I recommend referencing the metadata to the image, which > makes much more sense.
Why? regards - Jason

 [4/8] from: carl:cybercraft at: 13-Nov-2001 12:45


On 13-Nov-01, Jason Cunliffe wrote:
> 4. Captions > Many images benefit from captions in addition to decent titles.
<<quoted lines omitted: 3>>
> esential since the publishing explosion 500 year ago. I find it very > very strange that digital image formats have negelected these needs.
Electronic Arts' IFF format may be of interest to you, though whether it'd address exactly what you want I'm not sure. See... http://www.borg.com/~jglatt/tech/aboutiff.htm By establishing Interchange Format Files (ie, IFF) and releasing the documentation for such, as well as C source code for reading and writing IFF type of files, Electronic Arts has helped make it easier for programmers to develop backward compatible" and "extensible" file formats." Its ILBM format was the default image format for the Amiga in its day. They don't compress as well as GIFs or JPGs though, but I guess IFF could include them - not too sure about that though... -- Carl Read

 [5/8] from: jasonic:panix at: 12-Nov-2001 19:54


Hi Carl Thanks for the IFF tip. Helpful because I can surely learn something. good reading. In my Amiga days I was more conccerned with having too much fun in DPaint than header format design. Are you suggesting using IFF as an common image storage and transfer format? Does REBOL handle it on all systems? IFF is perhaps not directly helpful, because I must work mostly with standard file formats. By embedding data in the image file correctly, the files can pass through any 3rd party software, transfer protocol etc. An essential consideration. The whole idea is that less is more. Less pieces are more useful. Less punctuation. Less database work. Less for people to track when they know what they want to say.. etc I gues I need to look much more deeply into some graphic formats. Iseem to remember ther was some cool stuff related to NCSA deevloped HDF format for sceintic miagng. That has survived quite well and to here may be a lot of libarires to apply for conversion. hmmm PNG maybe the best REBOL bet. For example storing stuff in a named layer.. Any REBOL tools out there for browsing binary image formats? - Jason

 [6/8] from: carl:cybercraft at: 13-Nov-2001 18:44


On 13-Nov-01, Jason Cunliffe wrote:
> Hi Carl > Thanks for the IFF tip.
<<quoted lines omitted: 3>>
> Are you suggesting using IFF as an common image storage and transfer > format?
Not really. Just that it's a format you could embed text in and some programs still support it, though probably more for loading than saving. But as it looks like you've found that PNG will do what you want, it seems the way to go given REBOL's PNG support.
> Does REBOL handle it on all systems?
It doesn't handle it on the Amiga, let alone other systems. (Which isn't a complaint, just how it is and should be - as in the same on all systems.) -- Carl Read

 [7/8] from: media:quazart at: 13-Nov-2001 8:42


Hi everyone, I just thought I'd poke in this discussion with a little bit of my two cents... and some interesting metadata usage... just to add a bit to metadata useage, now even hardware is starting to include meta data directly in chips that are included in the casing... the lastest video tapes and archiving tapes from high-end companies (like sony dtf-2 archiving tapes) have eeproms which are inside the tapes to store the tape's directory instead of having it on tape only... this improves access times considerably and when the tapes are used in tape libraries, it allows them to cache the structure instantly without having to rewind the tape everytime it is removed/inserted into the tape robot... some of the most advanced data tracking systems now use on-tape magnetic-type stickers which are detected by sensors at each door of a building's production facility... this allows a producer to track his tape in the building at any moment. SO given a common task that a clip is needed on the tape in short notice (a late breaking news spot, for example), the director can browse the company's image library (everyting is references by metadata) and then the system tells him where the clip is physically in the building and in what formats... this, even if the tape has left the archives and the guy (or gal ;-) with the tape is taking a break in the cafeteria. On anotherr level, Some systems now even do image testing to detect image similarities and will return VERY convincing results when asked to find similar images... the fastest systems use colorspace evaluation and this works pretty well. An example of what they do is store a histogram-type image analysis which tells the system how much red or luminance (amongst MANY other things) are in the image or any precise anomaly. When you look for similar images, it will cross-reference the current image with this image analysis metadata and return (within a preciseness threshold ) any image which seem to hold about the same analysis or some peculiarly similar detail... surprisingly enough, if you look at an image shot at a specific date and time, most probably, it will return all images of the same subject shot within the same lighting conditions. Its quite impressive to see working... so, someone pointed that its better to link to the meta data... I'm not so sure... corruption is a dangerous possibility with linking and agencies cannot have a system which simply _could_ corrupt itself... if the metadata is stored right in the image, its MUCH safer and in the case of a system crash, it just has to re-index images in order to re-build its data structure. I think most systems will use a two-level structure where the data is within the images AND in a "live" (linked) database. Here is one solution, if your application is a closed circuit one and your application only needs to serve a precise boundary (inside your office or agency, for example). You can embed meta-data in pretty much every image (the saved format must not be lossly of course... so JPEG is out ;-) by adding some binary data within a region opf the image which is beyond the bounds of the image... just stamp the image on a bigger canvas and encode your binary data as rgb data in this extra space. For a more invisible (and faster) approach, you could use a format with alpha channel and encode your meta data in there! you just need to be able to poke/peek into the rgb array and then its quite easy to make little codecs which dump and get data to the rgb (or alpha) channel/buffer/raster/whatever. I used to do it with a VIC-20 style system... so I think its still possible to do it now ;-) my 1 cent (2cents worth of canadian money) -Max

 [8/8] from: media:quazart at: 13-Nov-2001 9:14


IFF can store ANY type of metadata. you can link several data packets inside it... for example, most IFF/ILBM images also had a palette block... which defined the colors to use for the image... this made the ILBM pretty flexible. and you could also have GFX packages which included vector drawings AND pre-rendered ILBM block for programs which only supported that. Some word-processors programs stored an ascii-only version of all the text so that it could be pasted directly within the clipboard engine (which is also iff based, if I remember well!) -MAx

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted