By ETS-Consulting on Tuesday, 21 July 2015
Posted in Technical Issues
Replies 12
Likes 0
Views 0.9K
Votes 0
It could not manage to configure EasySocial to handle images uploaded into albums or togehter with user posts without originals. I mean after upload and resizing the user image the original could be ignored / deleted.

In my opinion there is rarely a need (in social network) to store originals. Users want to share pictures with other users on the social network dashboards, they don’t care whether the system store the original copy of the image on the server drive or not. It is sufficient to keep the resized copy of the uploaded image.
Users mainly upload their images directly from their digital camera or smartphone and they do not want (or do not know how) to resize images before upload.

I have tried to disable the options “Allow Photo Downloads” and “Allow View Original Photo”. So theoretically after upload the original files are not really needed (the “stock” and “original” variants). But I see the originals are always stored - even as two files - “a pure original (stock.jpg)” and “compressed original (original.jpg)”.
In my opinion it is a huge waste of the drive storage because after disabling the both above mentioned options original files are not needed.

I though EasySocial and user albums build into it can replace another gallery component I have currently installed. But because of this problem I will run quickly into out of space problem. It is a basic feature every gallery / albums component must support.

Actually the same problem relates to the images uploaded as attachment to the normal user post. The original file is always stored on the drive.

After a couple of weeks I will run out of space when user start to share images taken with their 5Mpx cameras (

I mean it not bad to have an option to keep originals and let the users to download the originals. But this would be nice feature useful only in some special cases for those having a lot of hardware resources. For 99% of social installations it is a very big resource problem !

I would really need urgently your support on this topic.

PS. I assume the same problem affects to other components (Komento, EasyDiscuss). It is a serious limitation.
Hi,

I'm really sorry that delayed of this reply,

Unfortunately that was not possible after upload the photo and remove/ignore those 'stock' and 'original' image file is because all the image version 'large', 'square', 'thumbnail', 'featured', 'original', 'stock' also have their own purpose display some way on Easysocial page.

But we have one of the feature for remote storage allows you to store your photos, avatars and files on a remote location. Perhaps you can try using AMAZON S3 ( Documentation : http://stackideas.com/docs/easysocial/administrators/remote-storage/setup-amazon ), when the user upload the photo in your site, it will automatically store in your remote location and it will not store in your server.

Hope this will help.
·
Tuesday, 21 July 2015 13:08
·
0 Likes
·
0 Votes
·
0 Comments
·
hi Arlex,

thanks a lot for your replay and as first I must say I am really impressed by your products and I enjoy installing, testing and hopefully soon starting online on my website

Concerning my question and your answer - it is a "litte bit" a bad news for me. How do other clients of the EasySocial product deal with this fact?

I hope you agree with my argumentation Social network is not a kind of "image sharing website for professional photographers" where downloading the originals is a nice feature - but a tool to share a lot of data and pictures with other users. Here the size and quality of the image does not matter. After couple of days every uploaded image has no value anymore.

Storing data somewhere remotelly and paying extra money for that is not really an option for me. Those data (originally uploaded files) do not have any value and it is not worth to pay extra for something what is never to be used.

I know that there are cases where 'original' and 'stock' have their own purposes (when the "Download and Original" options are activated). But i my opinion I cannot belive anyone really need this option in social network - especially in user posts. Maybe in user albums ...

I have checked a little bit the implementation and database structure. I see you handle all pictures (post, albums, avatars, covers) similar way. You store in the table the size of the originally uploaded file.

So I see another problem. I have set the user upload quota to 100MB. If we could count the size of images after resizing and compressing - every user could upload up 1000 images. But when keeping the original the user can only upload up to 30 images (assuming 5Mpx camera).

I have started to write today a small batch job for me, which:
- scans the entire upload directory
- resize all orginals to the desired max resolution (in my case of 1200px) and replace the "original original" with the resized original
- update the corresponding entry in database (correct the file size value)

With this quick fix I can save 95% of space without any drawback for my users. But I would wish such functionality would be integrated directly in the EasySocial framework during uploading images.

I see Komento component has the same issue - there is no possibility to automatically resize the attached images. I am going to prepare the fix directly into the Komento component.

My server has 2TB of storage and it would be sufficient for long time if both components would avoid storing original files.

Maybe we could agree I would help you integrating those fixes into your components? Without this modification I can not imagine I could start online EasySocial and Komento on my Website.

best regards

Martin
·
Tuesday, 21 July 2015 16:00
·
0 Likes
·
0 Votes
·
0 Comments
·
Hi guys,

I see many of your clients are asking questions related to resizing images and saving the space on the server. I see some older version of your components already did this correctly.

Why not to introduce a general setting in all your components to automatically reduce the size of all original image attachments uploaded by all users to any component (ESocial, EDiscuss, EBlog, Komento) to maximal values configured by the administrator. You could still keep the same structure of files and database (keep all variants of the uploaded files) the only one small modification you need to do is to resize the uploaded file immeditally after transferred by the http request - before making any other processing you currently do in your components. Such reduced orignial file would be handled as the original file. If such option would be disabled - the uploaded orginals would be handled without resizing.

Or even more simple - just give an configuration option to automatically delete te *stock* file and keep only the resized originals you anyway already generate (*original*).

It is really a small modification but really crucial for the productiuon usage of your components. Every uploaded 5MB file would be reduced by factor /30 or more. You do already resizing of the original to thumbnails - why not to resize the orginal to "reduced" original at the same step ?

I see your comment on similar topic (http://stackideas.com/forums/original-image-size)

>> "To be honest I am not entirely sure if there are any extension that does this Why don't they use photoshop to do this?"

1) I have many user gallery components in usage with Joomla. All of them HAVE option to set the maximum size of the orginal. If the user uploads an image which is bigger than this limit - it is automatically reduced during upload on the server side and all other resized variants are created as well (big, medium, small ...)

2) I can not say my users - please use Photoshop !! Those are normal users using tablets or smartphones !!!!! They just do want to uplad pictures taken right now - not after a home evening session with Photoshop or GIMP.

Guys, please try to understand your customers and user.

I can help you on this, please only accept our point of view on this issue

best regards and many thanks in advance.
·
Wednesday, 22 July 2015 20:22
·
0 Likes
·
0 Votes
·
0 Comments
·
hey there,

I am really sorry that delay of this reply,

Thanks for your feedback, but unfortunately that was not possible at this point of time.

perhaps you can increase your server disk space and restrict the upload photo size limit to 1MB or 2MB from your backend > Easysocial > profile type > select your profile type > access > photos > Maximum file size ( http://screencast.com/t/SpLKrzpfaF ) , so the system will check if the photo size more than 2MB then it will not allow to upload to your server.
·
Friday, 24 July 2015 15:57
·
0 Likes
·
0 Votes
·
0 Comments
·
hi Arlex,

no problem ... I would be happy if you could implement such "must" feature in the near feature I hope it is just a small modification required in your components.

I understand your "technical suggestions" or suggested workarounds (I am a software developer as well) BUT - you have to think about the end user of your products. The end user is the king and the end user and the usability of the product is deciding whether to use the product or no.

I CAN NOT limit my users by forcing them to use photoshop or reject images bigger then 1MB or any like that.

I have already implemented a simple cron jobs on my side which do workaround this problem for now. It does:
- deletes the "*stock.jpg" files
- create a symbolic link from "*stock.jpg" pointing to "*orignal.jpg" (reduced one - which your component do already anyway)
- make an update of the corresponding entry in the database (the size of the original set to the size of the reduced original).

With this workaround I can wait until you come up with solution for this problem.

My suggestion is simple - just give an option to not store the "stock" files. Keeping the rest ('square', 'thumbnail', 'featured', reduced 'original') is maybe too much anyway but acceptable considering the usage of the hardware resources on the server.

I think for files like attachments in the user posts keeping so many variants of the image (small, medium, large, reduced original, stock - the pure original) - is just an OVERDESIGN. As I sad - every picture posted by the user on his social wall has a very SHORT TIME OF VALIDITY - there is no need to waste so much disc space for this.

I hope you understand my point (and end users of your products)

thanks a lot in advance

kind regards
Martin
·
Friday, 24 July 2015 17:07
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Martin,

Thanks for your input on this and we appreciate this very much. The reason that these image variants had to be created was simply because:

1. Original photo is used to allow users to download the exact original version of the image
2. Stock photo is used to allow users to rotate / perform image manipulation (Untouched so that the quality is retained as is)

The rest of the variants is to be used on different areas of the site where it sees fit. For instance, if a page only requires the image to be loaded at 100x100, it doesn't make sense to load the original version (This will slow the site down indefinitely if you have tons of images)

However, we are looking to see if we can reduce the number of files generated when a photo is uploaded on the site in the next major release
·
Friday, 24 July 2015 17:35
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Mark,

thank for your detailed answear. It is really great you support so many features in your components.

I understand and fully agree with multiple reduced variants of the image you create - this the right direction.

I did know about the "rotate" feature - really great

You can of course decide much better what could be done to reduce the disc usage.

From my point of view:
- you can offer an OPTION for reducing the "pure user original" file variant directly during the user upload request to configured max width / max height / compression level. Such file would be handled as the user original and replace the originally upladed file. If the administrator decides to not use this option - the "pure user original" file variant would be exact the file as uploaded by the user.
- even better if this setting would be separated for post images and user albums. From my point of view as administrator I can imagine to allow in user albums to keep the originally upladed files (I have set an limit max 10 albums x 50 photos per users) - this would be manageable amount of space I can plan for my hardware. In case of images in user posts please see my argumentation above. For those there is really no need to waste space.

kind regards

Martin
·
Friday, 24 July 2015 18:21
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Martin,

Thanks for the heads up on this and I appreciate this very much. We can't really perform these major changes right away as this will most likely be added in one of the major releases in the near future
·
Saturday, 25 July 2015 01:35
·
0 Likes
·
0 Votes
·
0 Comments
·
hi Mark,

as I have mentioned already some time ago my website does not use any external storage. Really .. I do not see any problem with that if ES would reduce the size of all images uploaded by users (originals) directly after uploading to the server - this would be really a great feature in EasySocial what many of your clients would welcome.

I have done on my latest installation of EasySocial a "quick modification" in one file to achieve what I want -
to reduce the size of the photos variants "_stock" and "_original" immediately after uploading. After this modification the storage usage on my server went dramatically down - from ~5MB per uploaded photo to ~0,12MB per photo. Now I am really happy with ES

I did the modification in the file:
administrator/components/com_easysocial/includes/photos/photos.php

replacing the following block:

// Create stock image
$filename = $this->generateFilename('stock', $overrideFileName);

$file = $path . '/' . $filename;
$files['stock'] = $filename;

$this->image->copy( JPATH_ROOT . $path . '/' . $filename );

// Create original image
$filename = $this->generateFilename( 'original' );
$file = JPATH_ROOT . $path . '/' . $filename;
$files['original'] = $filename;
$this->image->rotate(0); // Fake an operation queue
$this->image->save( $file );

with following:
// Create stock image
$filename = $this->generateFilename('stock', $overrideFileName);

$file = $path . '/' . $filename;
$files['stock'] = $filename;

$this->image->fit(1200, 1200); // <-- this should go to configuration
$this->image->save( JPATH_ROOT . $path . '/' . $filename );

// Create original image
$filename = $this->generateFilename( 'original' );
$file = JPATH_ROOT . $path . '/' . $filename;
$files['original'] = $filename;
$this->image->rotate(0); // Fake an operation queue
$this->image->fit(1200, 1200); // <-- this should go to configuration
$this->image->save( $file );

I would really appreciate if such or any similar (optional) feature would be implemented in the EasySocial in the next version. I would like really to continue the subscription in the future and upgrade my ES to any of the new versions you would release in the future but I do not want to implement my "fix" after every update again and again.

Many thanks in advance and best regards

Martin
·
Sunday, 20 March 2016 05:48
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey there,

Thanks for the input on this and I appreciate it very much. We'll see what we can do to enforce a maximum width / height for original images.
·
Sunday, 20 March 2016 15:09
·
0 Likes
·
0 Votes
·
0 Comments
·
hi Mark,

thanks. Would be great if you could add such feature - optional of course - so not every website must to activate such feature. Look at the Facebook and other social communities - they never work with huge original images (like 5MB) - after uploading those are downsized to some maximum limit and users can work with such reduced files.

best regards
Martin
·
Sunday, 20 March 2016 15:26
·
0 Likes
·
0 Votes
·
0 Comments
·
Hey Martin,

I believe Facebook does store original images but you wouldn't know because you can't really see them. When rotating images / cropping images, you'll notice that the image quality is not affected. Nevertheless, I believe if you really want to build a successful social network, disk size should be your least concern
·
Sunday, 20 March 2016 15:33
·
0 Likes
·
0 Votes
·
0 Comments
·
View Full Post