12 Feb
2012
12 Feb
'12
11:54 p.m.
Hello fellow xwiki users,
we discovered recently the usage of the width parameter when delivering a picture from an
xwiki document attachment.
Surprisingly this is available in our production server, based on the grumpy xwiki 1.5,
but has not been used in the UI of Curriki which has, however, been made by a team of
XWiki SàRL originally.
- can someone describe me how this feature is working?
- is the resulting downscaled image cached in file or in ram?
- has there been a different implementation between the current xwiki (e.g. 3.4) and 1.5?
- except for the CPU hogging of computing the downscaled version, is there any reason not
to use this feature? (e.g. RAM overloading?).
thanks in advance
Paul
14 Feb
14 Feb
7:56 a.m.
On 02/12/2012 05:54 PM, Paul Libbrecht wrote:
Hello fellow xwiki users,
we discovered recently the usage of the width parameter when delivering a picture from an
xwiki document attachment.
Surprisingly this is available in our production server, based on the grumpy xwiki 1.5,
but has not been used in the UI of Curriki which has, however, been made by a team of
XWiki SàRL originally.
Yes, this has been implemented for a very long time. If I remember
correctly, it might have been introduced even before 1.0, or at least
very soon after that.
- can someone describe me how this feature is working?
Basically, whenever an image download request is processed, the
ImagePlugin intercepts it via the downloadAttachment plugin SPI method,
and, if there are width or height request parameter, instead of serving
the original attachment, it will create a new fake attachment holding
the resized image.
- is the resulting downscaled image cached in file or
in ram?
There's a filesystem cache for resized images, indeed, so that the same
file isn't scaled for each request. Still, when downloading a specific
image, it will be held in memory as any XWikiAttachment object.
- has there been a different implementation between
the current xwiki (e.g. 3.4) and 1.5?
Yes, kind of. It used to be all in
https://github.com/xwiki/xwiki-platform/blob/c9b8a703cff266363782eee623ff4e…
but the image scaling code has been moved out of the plugin, and is now
in
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
(the call to this component is still in the plugin, though).
There have been a few changes and improvements between the two versions.
Besides the width and height parameters, now there's support for a
"quality" parameter, a number between 0 and 1 controlling the
compression quality for JPEG files, and a "keepAspectRatio" parameter
which means that in case both a width and a height are specified, the
image will be scaled with the same aspect ratio to fit within the
specified width and height.
- except for the CPU hogging of computing the
downscaled version, is there any reason not to use this feature? (e.g. RAM overloading?).
It should be used as much as possible. The only problems are the extra
storage needed for storing thumbnails, and the extra CPU time needed to
scale, or at least to access the cached file from the disk.
In recent versions this feature has been used more and more, so most
places where images are used at a different size should already be
making use of this feature.
thanks in advance
Paul
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
7:59 a.m.
Would be interesting to be moved as documentation on xwiki.org… :)
Best place IMO would be to create an extension for the Image Plugin on
extensions.xwiki.org and document it.
Thanks
-Vincent
On Feb 14, 2012, at 7:56 AM, Sergiu Dumitriu wrote:
On 02/12/2012 05:54 PM, Paul Libbrecht wrote:
Hello fellow xwiki users,
we discovered recently the usage of the width parameter when delivering a picture from an
xwiki document attachment.
Surprisingly this is available in our production server, based on the grumpy xwiki 1.5,
but has not been used in the UI of Curriki which has, however, been made by a team of
XWiki SàRL originally.
Yes, this has been implemented for a very long time. If I remember correctly, it might
have been introduced even before 1.0, or at least very soon after that.
- can someone describe me how this feature is
working?
Basically, whenever an image download request is processed, the ImagePlugin intercepts it
via the downloadAttachment plugin SPI method, and, if there are width or height request
parameter, instead of serving the original attachment, it will create a new fake
attachment holding the resized image.
- is the resulting downscaled image cached in
file or in ram?
There's a filesystem cache for resized images, indeed, so that the same file
isn't scaled for each request. Still, when downloading a specific image, it will be
held in memory as any XWikiAttachment object.
- has there been a different implementation
between the current xwiki (e.g. 3.4) and 1.5?
Yes, kind of. It used to be all in
https://github.com/xwiki/xwiki-platform/blob/c9b8a703cff266363782eee623ff4e…
but the image scaling code has been moved out of the plugin, and is now in
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
(the call to this component is still in the plugin, though).
There have been a few changes and improvements between the two versions. Besides the
width and height parameters, now there's support for a "quality" parameter,
a number between 0 and 1 controlling the compression quality for JPEG files, and a
"keepAspectRatio" parameter which means that in case both a width and a height
are specified, the image will be scaled with the same aspect ratio to fit within the
specified width and height.
- except for the CPU hogging of computing the
downscaled version, is there any reason not to use this feature? (e.g. RAM overloading?).
It should be used as much as possible. The only problems are the extra storage needed for
storing thumbnails, and the extra CPU time needed to scale, or at least to access the
cached file from the disk.
In recent versions this feature has been used more and more, so most places where images
are used at a different size should already be making use of this feature.
thanks in advance
Paul
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
9:47 a.m.
Le 14 févr. 2012 à 07:59, Vincent Massol a écrit :
Would be interesting to be moved as documentation on
xwiki.org… :)
I'd agree.
This is about UI writing however... not sure where that can be.
(in the syntax definition??)
Best place IMO would be to create an extension for the
Image Plugin on extensions.xwiki.org and document it.
That seems to be a core feature, I would rather keep this inside and not separate it.
paul
9:48 a.m.
Thank you very much Sergiu,
is there any way that can be ensured to avoid the attachment be loaded currently?
paul
Le 14 févr. 2012 à 07:56, Sergiu Dumitriu a écrit :
On 02/12/2012 05:54 PM, Paul Libbrecht wrote:
Hello fellow xwiki users,
we discovered recently the usage of the width parameter when delivering a picture from an
xwiki document attachment.
Surprisingly this is available in our production server, based on the grumpy xwiki 1.5,
but has not been used in the UI of Curriki which has, however, been made by a team of
XWiki SàRL originally.
Yes, this has been implemented for a very long time. If I remember correctly, it might
have been introduced even before 1.0, or at least very soon after that.
- can someone describe me how this feature is
working?
Basically, whenever an image download request is processed, the ImagePlugin intercepts it
via the downloadAttachment plugin SPI method, and, if there are width or height request
parameter, instead of serving the original attachment, it will create a new fake
attachment holding the resized image.
- is the resulting downscaled image cached in
file or in ram?
There's a filesystem cache for resized images, indeed, so that the same file
isn't scaled for each request. Still, when downloading a specific image, it will be
held in memory as any XWikiAttachment object.
- has there been a different implementation
between the current xwiki (e.g. 3.4) and 1.5?
Yes, kind of. It used to be all in
https://github.com/xwiki/xwiki-platform/blob/c9b8a703cff266363782eee623ff4e…
but the image scaling code has been moved out of the plugin, and is now in
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi…
(the call to this component is still in the plugin, though).
There have been a few changes and improvements between the two versions. Besides the
width and height parameters, now there's support for a "quality" parameter,
a number between 0 and 1 controlling the compression quality for JPEG files, and a
"keepAspectRatio" parameter which means that in case both a width and a height
are specified, the image will be scaled with the same aspect ratio to fit within the
specified width and height.
- except for the CPU hogging of computing the
downscaled version, is there any reason not to use this feature? (e.g. RAM overloading?).
It should be used as much as possible. The only problems are the extra storage needed for
storing thumbnails, and the extra CPU time needed to scale, or at least to access the
cached file from the disk.
In recent versions this feature has been used more and more, so most places where images
are used at a different size should already be making use of this feature.
thanks in advance
Paul
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users 
10 a.m.
The most important improvemens are:
1/ We guarantee that the image will always show up, even if the conversion
failed, which is something that does happen with certain specific file
formats. We've introduced exception catching if these cases which makes
sure that at least you'll have the original image.
2/ default quality ratio is better then it used to be
I'm not completely sure also but I think we might have changed the output
format or made sure we keep the original format.
Indeed documentation would be great.
As for why it was not used in Curriki, I think it did not exist when most
of Curriki was developped. Also the issue with possible failures made it
dangerous to use when you don't control the images passed through the
system.
Ludovic
2012/2/14 Sergiu Dumitriu <sergiu(a)xwiki.com>
On 02/12/2012 05:54 PM, Paul Libbrecht wrote:
Basically, whenever an image download request is processed, the
ImagePlugin intercepts it via the downloadAttachment plugin SPI method,
and, if there are width or height request parameter, instead of serving the
original attachment, it will create a new fake attachment holding the
resized image.
- is the resulting downscaled image cached in file or in ram?
There's a filesystem cache for resized images, indeed, so that the same
file isn't scaled for each request. Still, when downloading a specific
image, it will be held in memory as any XWikiAttachment object.
- has there been a different implementation between the current xwiki
> (e.g. 3.4) and 1.5?
Yes, kind of. It used to be all in https://github.com/xwiki/**
xwiki-platform/blob/**c9b8a703cff266363782eee623ff4e**
b61aad4b45/xwiki-core/src/**main/java/com/xpn/xwiki/**
plugin/image/ImagePlugin.java#**L165<https://github.com/xwiki/xwiki-plat…
the image scaling code has been moved out of the plugin, and is now in
https://github.com/xwiki/**xwiki-platform/blob/master/**
xwiki-platform-core/xwiki-**platform-oldcore/src/main/**
java/com/xpn/xwiki/internal/**plugin/image/**DefaultImageProcessor.java<…
call to this component is still in the plugin, though).
There have been a few changes and improvements between the two versions.
Besides the width and height parameters, now there's support for a
"quality" parameter, a number between 0 and 1 controlling the compression
quality for JPEG files, and a "keepAspectRatio" parameter which means that
in case both a width and a height are specified, the image will be scaled
with the same aspect ratio to fit within the specified width and height.
Hello fellow xwiki users,
we discovered recently the usage of the width parameter when delivering a
picture from an xwiki document attachment.
Surprisingly this is available in our production server, based on the
grumpy xwiki 1.5, but has not been used in the UI of Curriki which has,
however, been made by a team of XWiki SàRL originally.
Yes, this has been implemented for a very long time. If I remember
correctly, it might have been introduced even before 1.0, or at least very
soon after that.
- can someone describe me how this feature is working?
- except for the CPU hogging of computing the downscaled version, is
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
there any reason not to use this feature? (e.g.
RAM overloading?).
It should be used as much as possible. The only problems are the extra
storage needed for storing thumbnails, and the extra CPU time needed to
scale, or at least to access the cached file from the disk.
In recent versions this feature has been used more and more, so most
places where images are used at a different size should already be making
use of this feature.
thanks in advance
Paul
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
______________________________**_________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/users<http://lists.xwiki.org/m…
10:28 a.m.
Hi Paul,
On Feb 14, 2012, at 9:47 AM, Paul Libbrecht wrote:
I think you misunderstand what we call an extension.
Core features are packaged as "extensions" even though they're bundled by
default.
Check http://extensions.xwiki.org to see what we have there and you'll see "core
features" are documented there.
Thanks
-Vincent
Le 14 févr. 2012 à 07:59, Vincent Massol a écrit :
From Sergiu's answer I understood it's a feature of the Image plugin.
That said this feature is also partially located in the Platform module for extending the
Rendering (XWikiWikiModel) so we also need to create a module on extensions.xwiki.org for
that and document it there too.
Would be interesting to be moved as documentation
on xwiki.org… :)
I'd agree.
This is about UI writing however... not sure where that can be. (in the syntax definition??)
Definitely not in the syntax.
This should go in the documentation for the Image Plugin and the Platform extension of
Rendering, i.e. both on http://extensions.xwiki.org.
Best place IMO
would be to create an extension for the Image Plugin on extensions.xwiki.org and document
it.
That seems to be a core feature, I would rather keep this inside and not separate it.
11:23 a.m.
Le 14 févr. 2012 à 10:28, Vincent Massol a écrit :
you need to make it central in the documentation.
Documenting all the details in an extension is useful for sure.
But the basic should be referenced from the syntax I feel.
Le 14 févr. 2012 à 10:00, Ludovic Dubost a écrit :
(in the syntax
definition??)
Definitely not in the syntax.
This should go in the documentation for the Image Plugin and the Platform extension of
Rendering, i.e. both on http://extensions.xwiki.org. As for why it was not used in Curriki, I think it did
not exist when most
of Curriki was developped. Also the issue with possible failures made it
dangerous to use when you don't control the images passed through the
system.
Thanks, that is the perfect explanation.
And indeed we have places where it miserably fails.
We'll be sure to use it better on the new core.
paul
4601
days inactive
4603
days old
7 comments
4 participants
participants (4)
-
Ludovic Dubost -
Paul Libbrecht -
Sergiu Dumitriu -
Vincent Massol