cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Spörk <jakob.spo...@gmx.at>
Subject RE: [C3] Imaging Module
Date Tue, 20 Jan 2009 14:17:52 GMT
Maybe it's even possible to package all the aggregation or blending
information into another image (mask). For example, use a 8 bit grayscale
image where black means image1, white means image2 and all different gray
scales means a blending of the two images. That mask would allow to code
areas as well as blending operations.

One problem would be how to describe that image2 with size 200x200 shall be
placed in the middle of image1 downscaled to a size of 100x100. 

+---------+
|    1    |
|  +---+  |
|  | 2 |  |
|  +---+  |
|         |
+---------+

It would be possible to use a resize transformer for image2 but how do the
aggregation transformer know where to start including image2 into image1. 

My experience with image processing is that as much as possible is
represented using images. For example using graphics hardware, you use
textures for texturing itself as well as for normal mapping, bump mapping or
other effects. I've even read a paper where database operations were
implemented using graphics hardware and where the author used textures to
represent the database. So I think to use graphics to represent additional
configuration information would also be a possibility.

Best Regards,
Jakob

-----Original Message-----
From: Steven Dolg [mailto:steven.dolg@indoqa.com] 
Sent: Dienstag, 20. Januar 2009 11:20
To: dev@cocoon.apache.org
Subject: Re: [C3] Imaging Module

Andy Stevens schrieb:
> 2009/1/19 Steven Dolg <steven.dolg@indoqa.com>:
>   
>> Vadim Gritsenko schrieb:
>>     
>>> On Jan 15, 2009, at 9:05 AM, Reinhard Pötz wrote:
>>> But question is, can you aggregate, include images?
>>>       
>> There is no component for that yet. But I'm confident this is easily
>> possible.
>>     
>
> Interesting problem - what exactly would an "aggregate" image be?  The
> relevant parts side by side, one below the other, as separate layers
> in a combined image?  If the latter, what "mode" would you use to
> combine them - blend/burn/multiply/as a mask - and what opacities?
> Should they be scaled to the same size before combining or not?
> Doesn't really fit with the usual map:aggregate/map:part without a ton
> of extra info as to how it should be done.
>   
Yes, we could easily end up with having thousands of possible ways users 
would like to use.

I thought about this and implemented a simple first approach
* use one image as the "background"
* use one image as the "overlay"
* define an anchor for the overlay (Center, North, South, Southeast, 
...) relative to the background
* allow for an additional offset to the anchor
* draw the overlay on the background, overwriting it - but applying 
existing transparency information in the overlay

[This is also the way Amazon does it:
e.g. 
http://ecx.images-amazon.com/images/I/41CHSFA4GTL._BO2,204,203,200_PIsitb-st
icker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg
"TopRight,35,-75" is anchor, offsetX, offsetY - try changing it, it's 
fun ;-)]

In the imaging module this would look like:
        Pipeline pipeline = new NonCachingPipeline();

        // the background
        pipeline.addComponent(new ImageGenerator(backgroundUrl));
        // scale the background to a fixed size (to have a predictable 
"background-to-overlay" size ratio)
        pipeline.addComponent(new MaxSizeImageTransformer(200, 200));
        // apply the overlay (TopRight, slightly beyond the right and 
the top border)
        pipeline.addComponent(new 
AggregateImageTransformer(additionalUrl, Anchor.NORTHEAST, 22, -20));
        // scale again to fixed size (overlay increases image size)
        pipeline.addComponent(new MaxSizeImageTransformer(200, 200));
        // write the image
        pipeline.addComponent(new ImageSerializer());


Theoretically this should allow to create what you called "combined 
images" (if I understood your idea correct) as well as the "side by 
side" approach.
And this would only require 3 additional parameters (making the offset 
optional would reduce it to one required parameter).

However blend/burn/multiply/as mask would certainly require more (and me 
finding out what this actually means and how to achieve that :-) ).

As to the scaling (or generally transforming) before combining: I guess 
this could be achieved by applying a transformation to the overlay 
before using it.
In a sitemap this would be rather simple - with some little changes, 
this should also be possible with the pure Pipeline API, like allowing 
the AggregationImageTransformer (already existing on my machine, but yet 
to be published) to read the overlay from an InputStream which is 
created by another pipeline, or something like that.


I still think it should be possible to provide some general purpose (and 
rather basic) transformers. As long as you can combine them, a lot of 
different effects should be possible.
E.g. the AggregateImageTransformer will increase the image size so that 
both background and overlay are fully contained. If that's not desired, 
one can apply an CropImageTransformer afterwards, cutting of the 
unwanted parts.
Of course this will require some more flexibility as some of the 
configuration of the transformers must be determined while executing the 
pipeline - but I think it should be possible in most cases...


> OTOH, something like the include transformer might work better - an
> input document describing how the images should be combined, with
> :include elements specifying the various other input sources.  But
> then you need a pipeline that handles both XML and image data...
> Sounds like fun ;-)
>   
Not sure I understand what you mean.
Is that like describing the image transformation in XML and having a 
transformer evaluate the XML and then process images based on that 
description?
I think such an approach would limit the usage scenarios for the 
transformer, as it could not be used after some other transformation 
that returns only the resulting image.

But I guess, we could have a transformer that is configured with an URL 
to the XML document describing the transformation. That would even allow 
to have another pipeline build that document (if that makes any sense) 
or retrieving it from somewhere else - making it easier to adjust it 
during runtime than having it directly in your code/sitemap/whatever.

An interesting idea...

> Regards,
>
>
> Andy
>   


Regards,
Steven


Mime
View raw message