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