Closed GoogleCodeExporter closed 9 years ago
I am not sure I can do much to help overcome the problem. Whenever you have
"Use cache for images" enabled, sigplus stores images from a large number of
different source folders in the same cache folder. Avoiding naming conflicts is
mandatory or else generated images would overwrite one another. This is done by
computing a hash, from the following pieces of information:
* full image path or path component of remote image URL
* image width (in pixels)
* image height (in pixels)
* whether the image has been cropped or scaled
* image quality (for JPEG format only)
This implies that the image hash is dependent on where the original is, and how
large the generated images are and what properties (cropping, quality) they
have. As a result, moving an image from one location to another changes the
hash, and sigplus has to generate a new preview image and/or thumbnail.
As far as I can see, sigplus could identify that two images are the same even
after they have been moved to a different location only under prohibitively
restrictive conditions.
(1) You could provide tracking information. This means you would tell sigplus
that you have moved one set of images from one location to another. For image
gallery management extensions (e.g. Phoca), this approach comes naturally
because they have a very complex administration interface of their own. The
power of sigplus comes precisely from the fact that it is NOT a management
extension, it discovers images as you place them into a folder. Of course, this
ease of use must come at a price, which is that images at two different
locations are considered different images, even if they are the same pixel by
pixel. File creation date is not enough distinction to tell apart two images:
many images may have the same timestamp and some hosts periodically update the
timestamp as data is moved from one server of a cluster to another to provide
better load balancing on shared servers. (This happens quite often to web data
on the host of my Joomla projects site.)
(2) sigplus could compute an image fingerprint (cyclic redundancy code). Images
with the same fingerprint would constitute identical images and the same
preview image and/or thumbnail could be shared among them. Unfortunately,
computing a fingerprint is comparable to generating preview images, which means
there is little we win with this approach.
That said, I am closing this issue. If you feel there is a yet another approach
that I am overlooking, please let me know and I will re-open the issue.
Original comment by huny...@gmail.com
on 17 Aug 2012 at 11:27
[deleted comment]
Ability in SIGPlus define path to me cache directory?
then:
- There is no threat of loss of views when cleaning the cache of Joomla!
- There is no threat of removal podgldami directory user with access to the own
directory photos.
- I can easily create a backup of this directory, or even move it to another
site for example?
Original comment by venapr...@gmail.com
on 18 Aug 2012 at 7:26
(1) If you could move the generated images directory outside of the Joomla
cache directory, it carries a message that the generated images are not
temporary when in fact they are. Precisely when you clean the Joomla cache, you
should (in my opinion) also clean all sigplus generated images. Of course,
there are other approaches. For example, the Gantry template framework has its
own T3 cache (for minified and merged stylesheets and scripts), and it has a
dedicated button to clean the T3 cache. I am somewhat against this approach:
imagine all the extensions with a caching mechanism had a clean cache button of
their own... When you clean the cache in Joomla, sigplus should automatically
recognize that this has happened, and will re-generate preview and thumbnail
images.
(2) True but "Use cache for images" enabled also has this advantage.
(3) No, you would not be able to create a backup of and migrate the directory
even if setting you propose existed. This is because the hashed file name
contains the full path to the image, see my first comment. When you migrate the
site, the path to the images changes (the original images will be found under a
different node in the directory tree), and thus the automatically generated
name for preview and thumbnail images will change as well.
Original comment by huny...@gmail.com
on 18 Aug 2012 at 9:58
Thanks for you reply.
||Precisely when you clean the Joomla cache, you should (in my opinion) also
clean all sigplus generated images.
— Why do you think so? What worries me is poorly does not SigPlus not for
some service system, which will help rebuild ® s your base without limitation,
the front-end activities.
|| imagine all the extensions with a caching mechanism had a clean cache button
of their own...
— You're right, this is a big administrative problem. Gantry cache also
stores your settings Joomla cache, but the difference is. When I make a mistake
eg a temporary troubles with the new extension and frequent cleaning and
clearing the cache memory of the gantry is not so much a consequence of the
action as to remove the cache SigPlus for several galleries. I'm glad you take
care of this problem.
|| No, you would not be able to create a backup of and migrate the directory
even if setting you propose existed.
— As I wrote a big problem because of the lack of an error display images or
messages while this library SigPlus play. Well if you manage to swtorzyć
independent of the front-end system maintenance SIGPlus gallery, or limit the
generation of new previews only currently viewing gallery. I do not know what
will happen with server resources when multiple users at once will be called
SigPlus thumbnail generation.
Regards!
Original comment by venapr...@gmail.com
on 22 Aug 2012 at 7:05
This issue realted this http://code.google.com/p/sigplus/issues/detail?id=35
I'm sorry for repeating.
Quietly waiting for new ideas, the more that even so, this subject is to me a
little bit more important:
http://code.google.com/p/sigplus/issues/detail?id=36
Reagrds!
Original comment by venapr...@gmail.com
on 22 Aug 2012 at 7:20
Original issue reported on code.google.com by
ten.mari...@gmail.com
on 23 Jul 2012 at 10:31