RE: photo gallery architecture

[Angela Cymbalak]

oops...

photographer was supposed to be in that list, not looking like a
title after my name.

I know what you mean about create date.  I call it create date but
maybe we just want to have a few flexible date fields that can be utilized?

I think that we want to store two images the original and the
thumbnail.  But, then it is possible to add code that will allow you
to derive the additional sizes in between.  I used a package called
ImageInfo as part of Caitrin.  It is some open source code that I
found.  I used it to even get the thumbnail sizing.


Of course, we could add an EXIF reader to collect the metadata the
camera adds to the photo.  It would be much easier on the end user
than having to manually add all of it.

I would think we would want a fairly exhaustive list of possible
things that people would want to keep in addition to the
photograph.  That way we minimize the number of changes to the
repository we may have to make in the future to accommodate all the data.

Angie


At 10:35 PM 7/3/2008, you wrote:

>On Thu, Jul 3, 2008 at 7:13 PM, Angela Cymbalak
><<mailto:a.cymbalak@...>a.cymbalak@... > wrote:
>It appears that we are set on JCR and then maybe Sling and
>Tuscany.  The RESTful interface is going to be best for direct
>viewing of the photo gallery and then the WS interface will be
>available for whatever anyone wants to use it for (process type
>transactions probably).  What is the design of the JCR repository
>going to be?  What information needs to be collected for each photo?
>my quick suggestions:
>photo
>thumbnail
>create date
>caption
>tags
>
>
>Depends on how much you want to take on, really. Most digital
>cameras, and especially DSLRs, provide a whole slew of metadata in
>addition to the image(s). That might be important information for
>some people, although for others it would be irrelevant.
>
>Also, some of the attributes mentioned above are not always as
>obvious as they might seem. For example, what does 'create date'
>mean? The date the original photo was shot, the date it was last
>edited, or the date it was added to the content repository? Are two
>image sizes (original and thumbnail) sufficient, or would you want
>other sizes in between?
>
>Just some more food for thought.
>
>--
>Martin Cooper
>
>
>
>Angie
>photographer

---------------------------------------------------------------------
To unsubscribe, e-mail: projects-unsubscribe@...
For additional commands, e-mail: projects-help@...

[Roland Weber]

NOTE: The mailing list seems to be set up as "reply to sender",
not as "reply to list". When replying to mails here, use the
"Reply to all" option to make sure that your mail is sent to
the list and not just to the author of the post you reply to.
Oh how much fun we are having on legal-discuss with that ;-)


Angela Cymbalak wrote:
>
> I think that we want to store two images the original and the
> thumbnail.

Taking Wikimedia Commons as an example, there are many pictures
with a "preview" (reduced file size round 800x600) in addition
to the full-sized file. That's probably not what you would call
a thumbnail, right?

http://commons.wikimedia.org/wiki/Image:Nizao.jpg
http://commons.wikimedia.org/wiki/Image:Gahlenz.jpg

I'm not a photographer myself, but I sometimes stumble
over forum discussions between photographers. With that
(non-)background, I assume that some ambitious amateur
photographers would want to store the "original" in a
raw format, along with a full-sized version in a standard
image format (JPG) and a thumbnail.

> But, then it is possible to add code that will allow you to
> derive the additional sizes in between.

That assumes that a default algorithmic transformation of
the original (probably the JPG version rather than raw?)
yields the desired results. That's probably true for a
bunch of holiday snapshots, but might not be applicable
anymore even for ambitious amateurs. For example, people
might want to...
- generate different image sizes from the raw data rather
   than the JPG version
- generate beautified versions of a photo (sharpen/blur,
   adjust brightness&colors, remove red eyes,...)
- store different aspect ratios by manually cropping
   the image
- store different exposures of an image along with the
   HDR rendering as one photo [1]
- ...?

In 2006, I visited an exhibition of photographies by
Martin Munkacsi. [2,3] From what I learned there, he
considered cropping as an essential part of taking a
photo, because the camera would inevitably catch more
than he wanted to have on the photo.

To cut this short: I think you should distinguish
between a photo - something shot by someone with a
camera at a particular place and time - and the
image renderings of that photo. One photo may have
several image representations. Yes, most people will
just want to store their "photos", the JPGs they get
from their digital camera, along with a thumbnail
for browsing. But that is a requirement for the UI,
not a restriction to be built into the backend.

just my 0.02€ :-)

cheers,
   Roland

[1] http://en.wikipedia.org/wiki/High_dynamic_range_imaging#Exposure_examples
[2]
http://www.berlinerfestspiele.de/en/aktuell/festivals/11_gropiusbau/mgb_04_rueckblick/mgb_rueckblick_ausstellungen/mgb_archiv_ProgrammlisteDetailSeite_6905.php
[3] http://en.wikipedia.org/wiki/Martin_Munk%C3%A1csi


---------------------------------------------------------------------
To unsubscribe, e-mail: projects-unsubscribe@...
For additional commands, e-mail: projects-help@...