On my future todo list was to see how well I can integreate EMB JSR 86 with 
Sling, especially the MFB beans can serve as libraries for image manipulation 
and watermarking and a whole lot more. Please have a look at 
http://www.alphaworks.ibm.com/tech/emb 

Ransford Segu-Baffoe

[EMAIL PROTECTED]

https://serenade.dev.java.net/
http://www.noqturnalmediasystems.com/

--- On Mon, 7/7/08, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:

From: Bertrand Delacretaz <[EMAIL PROTECTED]>
Subject: Re: Image rendering (image creation / manipulation)
To: [email protected]
Date: Monday, July 7, 2008, 3:15 AM

Hi Bryce,

On Mon, Jul 7, 2008 at 6:48 AM, Bryce Ewing <[EMAIL PROTECTED]> wrote:
> ...I am thinking of creating a way of doing image rendering through sling
and
> thought I would first check with the community as to whether this has been
> thought of, and whether there are any thoughts on how this may work....

We don't have any concrete plans at the moment, but what you suggest
looks useful.

>... Thoughts that I have had as to what this can be used for are (among
others):
>   * scaling
>   * rotation
>   * watermarking
>   * layering (i.e. use one image as background another as foreground)
>   * format changing e.g. png -> jpg
>   * quality change (to reduce size of say jpg)...

Creating a java component (in a bundle) that implements these
operations would make that usable from any scripting language and
servlet, for example:

  // myResourceType.png script
  var s = sling.getService(org.apache.sling.imaging.Processor);
  var p = s.getImageProcessor();
  if(request.selectors[0] == "small") {
    p.scale = 0.5;
  } else {
    p.scale = 1;
  }
  p.rotation = 90;
  p.outputFormat = png;
  p.watermark = currentNode.getPath() + ".watermark.png";
  p.metadata.title = currentNode.title;
  p.render(currentNode,response);

And the image processor might also provide a simple way to store the
output in the repository, as an option to dynamic rendering.

> ...So say /img/test is a png image (with sling:resourceType =
"abc/def") and I
> requested /img/test.jpg that something would reformat the image from png
to
> jpg.  If I requested /img/test.small.jpg the image would be reduced and
the
> format changed...

Scripting, as above, will allow you to use the "small" selector
easily.

> ...So I guess the most "basic" way of doing this would be to
write a servlet
> that specifically did a certain type of image creation / manipulation....

As you also mention, a service that provides an image processor
component is more flexible.

> ...One of the issues I see with this is that it would require the imageio
and
> jai libraries to be added somewhere that would then be visible to this
even
> though in most cases nobody would use jsp for this etc.  Also I don't
think
> this would be that easy for someone who doesn't know a reasonable
amount
> about jai and imageio....

OSGi allows you to "hide" those libraries inside a bundle, and expose
just the service interface.

I'm not familiar with those libraries, but it's certainly possible to
write a facade that exposes image operations so that they can be used
as above, taking a Node as input, as long as the Node contains image
file data. At least for basic usage, and maybe provide a more direct
access to the libraries for advanced use.

> ...What I have been thinking about and what I am proposing is another
scripting
> bundle that is specifically used for image creation and manipulation. 
This
> would then have some sort of source (still thinking about how this would
> work) that would define the processing to perform.  Initial thoughts are
> something along the lines of a set of parameterized JAI operators, e.g.
> SubsampleAverageDescriptor, UnsharpMaskDescriptor, AddDescriptor....

I also thought about an image processing language at first, but I
think the above example where a script drives an image processor
component is more flexible and requires less work to implement. And
also allows offline processing of images, where repository events
trigger java code or scripts that process and store ready to use
images.

> ...Would be interested in any feedback, other options etc. before I start
> design / development of this....

Thanks for your suggestions, and I'm sure we'll do our best to help if
you're willing to work on this.

I'm sure you notice my "subtle" hints to people who might
contribute
useful stuff to Sling ;-)

Considering that the core is fairly stable now, and that important
functions like what you describe are still missing, I think it's a
really good time to get involved.

-Bertrand


      

Reply via email to