! Result of intermediate graphic filters can be stored in memory (SVN only)

Monde en
1

Hi,

Arnaud Martin has just created a system which enables to chain several
graphic functions in memory, without any file saving.

Tested on a website with a lot of galleries, his image CACHE has been
reduced from 1.4Go to 51Mo !
For each image, he stored several intermediate PNG files (a png weighs
between 5 and 10 times the weight of the corresponding JPEG). As
example, if he saved 5 files png weighing 6 times the file of origin,
approximately that gaves : 30 times the weight of the original file,
only for intermediate calculations. From now on : We have the original
JPEG, and the result JPEG -- that's all.

The principle is to frame the series of graphic filters by the two
following filters:
- image_lire ($img)
- image_ecrire ($img, $fmt)
($fmt is "jpg", "gif", or "png").

For example:
[(#FICHIER |image_lire
     |image_reduire{400}
     |image_sepia
     |image_rotation{90}
     |image_ecrire{jpg} )]

- It is conceived so that, if one doesn't insert image_lire and
image_ecrire, the functions adopt the old method and nothing should be
modified. This point is to be checked, obviously; if there is any
change when the new functions aren't used, it is a bug.

- One thus gains much space on the hard disk.

- computing time is faster, because the number of intermediate files
writings is reduced

- On the other hand, if verrrrry heavy functions are used, the new
method won't work because it doesn't save intermediate stages : so if
the whole operations between image_lire and image_ecrire cannot be
processed before the time_out, then that will _never_ pass.

IMPORTANT :

This method applies only on unique images (on #FICHIER, or #LOGO_xx
for ex.), but not #TEXTE (actually, maybe this will be improved)

More important : this method hasn't been deeply tested yet, and you
need the SVN version of SPIP. At you own risks only :wink:

enjoy !!

.Gilles

2

An example of what can be done automatically with graphic filters :
http://www.paris-beyrouth.org/Un-site-dument-timbre

(and lots of tutorials can be found on the Arnaud's website :
http://www.paris-beyrouth.org/-SPIP- )

.Gilles
--
2007/2/13, Gilles Vincent <gilles.vincent@gmail.com>:

Hi,

Arnaud Martin has just created a system which enables to chain several
graphic functions in memory, without any file saving.

Tested on a website with a lot of galleries, his image CACHE has been
reduced from 1.4Go to 51Mo !
For each image, he stored several intermediate PNG files (a png weighs
between 5 and 10 times the weight of the corresponding JPEG). As
example, if he saved 5 files png weighing 6 times the file of origin,
approximately that gaves : 30 times the weight of the original file,
only for intermediate calculations. From now on : We have the original
JPEG, and the result JPEG -- that's all.

The principle is to frame the series of graphic filters by the two
following filters:
- image_lire ($img)
- image_ecrire ($img, $fmt)
($fmt is "jpg", "gif", or "png").

For example:
[(#FICHIER |image_lire
     |image_reduire{400}
     |image_sepia
     |image_rotation{90}
     |image_ecrire{jpg} )]

- It is conceived so that, if one doesn't insert image_lire and
image_ecrire, the functions adopt the old method and nothing should be
modified. This point is to be checked, obviously; if there is any
change when the new functions aren't used, it is a bug.

- One thus gains much space on the hard disk.

- computing time is faster, because the number of intermediate files
writings is reduced

- On the other hand, if verrrrry heavy functions are used, the new
method won't work because it doesn't save intermediate stages : so if
the whole operations between image_lire and image_ecrire cannot be
processed before the time_out, then that will _never_ pass.

IMPORTANT :

This method applies only on unique images (on #FICHIER, or #LOGO_xx
for ex.), but not #TEXTE (actually, maybe this will be improved)

More important : this method hasn't been deeply tested yet, and you
need the SVN version of SPIP. At you own risks only :wink:

enjoy !!

.Gilles

3

2007/2/13, Gilles Vincent <gilles.vincent@gmail.com>:

Arnaud Martin has just created a system which enables to chain several
graphic functions in memory, without any file saving.

Update :

The last change of Spip generalizes this mechanism :
intermediate images are finally still written on disk (in order to
enable to allow large calculations)

But intermediate files are destroyed even if you use the standard
method (without image_lire and image_ecrire). This mechanism works on
any use of image filters, including on text fields.

Now you can abuse of
[(#TEXTE|image_reduire{520,0}|image_reduire{150}|image_rotation{90}|image_recadre{200,200,'center','red'}|image_aplatir{jpg})]
without exploding you image CACHE directory. :wink:

Technical details here :
http://trac.rezo.net/trac/spip/changeset/8673

.Gilles
---

Tested on a website with a lot of galleries, his image CACHE has been
reduced from 1.4Go to 51Mo !
For each image, he stored several intermediate PNG files (a png weighs
between 5 and 10 times the weight of the corresponding JPEG). As
example, if he saved 5 files png weighing 6 times the file of origin,
approximately that gaves : 30 times the weight of the original file,
only for intermediate calculations. From now on : We have the original
JPEG, and the result JPEG -- that's all.

The principle is to frame the series of graphic filters by the two
following filters:
- image_lire ($img)
- image_ecrire ($img, $fmt)
($fmt is "jpg", "gif", or "png").

For example:
[(#FICHIER |image_lire
     |image_reduire{400}
     |image_sepia
     |image_rotation{90}
     |image_ecrire{jpg} )]

- It is conceived so that, if one doesn't insert image_lire and
image_ecrire, the functions adopt the old method and nothing should be
modified. This point is to be checked, obviously; if there is any
change when the new functions aren't used, it is a bug.

- One thus gains much space on the hard disk.

- computing time is faster, because the number of intermediate files
writings is reduced

- On the other hand, if verrrrry heavy functions are used, the new
method won't work because it doesn't save intermediate stages : so if
the whole operations between image_lire and image_ecrire cannot be
processed before the time_out, then that will _never_ pass.

IMPORTANT :

This method applies only on unique images (on #FICHIER, or #LOGO_xx
for ex.), but not #TEXTE (actually, maybe this will be improved)

More important : this method hasn't been deeply tested yet, and you
need the SVN version of SPIP. At you own risks only :wink:

enjoy !!

.Gilles