Hello Mick,

The image size on the stream is actually "fluid" as we made it to fill the viewing area on the stream.

Eventually I would love to see admins be able to set the image size (I'm not talking about the stream, the actual raw image.jpg). There are cases where an admin knows the exact size of their template in which they could have the large image not be any bigger than that specified size. In the future I suspect there will be a way to insert images into articles which is when image sizing will be especially important.

Thanks for the heads up on this Josh. We might add a new option in the future to restrict the maximum width / height but do take note that whenever a "resizing" occurs, you lose out on some image quality

Right, I learned that in photography class. While resizing the original for some would be nice for many, I was actually talking about setting the boundaries for individual image sizes. Take for example, right now the image size of a large image is 1280px by default. What I'm proposing is allowing the admin to change that large image to whatever they want. The biggest reason is for bandwidth reasons but also in some cases for visual reasons.

I will be creating pages like this one, notice the big panorama at the very beginning of the article? It's 800px wide. So for some sites we can save on bandwidth use by using smaller large images considering that if photos are generally used for pages that have a width of 1024px. This theory is to include other image sizes as well such as the thumbnail. Right now the thumbnail size is 341px. However on the size of the featured images on the right are around 200px in size. So by allowing the admin to specify the image sizes you allow us to maximize bandwidth usage.

Off topic but a neat thought:
JoomGallery has a cool featured called image regeneration which if for some reason non original photos need to be re-generated, they can be. So if an admin specifies a image size that is too small, they could theoretically regenerate them which would be pretty straight forward. This would solve the issue of uncareful admins.

Hello Josh,

Yep, we do have image re-generation as well and that is why we kept the "stock" version untouched so that we don't lose too much quality when the resizing occurs

How do you use image re-generation? I tried looking for it in both the frontend and the backend. Wouldn't the original photo be better for image re-generation rather than using the stock photo?

Hello Josh,

The "original" is actually a "resized" version and the "stock" is the one that isn't resized. We only generate it on the initial uploading of photos and we don't actually re-generate it but it's possible to re-generate it though.

Question on the image sizes .. When I say upload an image of 2.9meg I am assuming the script resizes to smaller if yes how much smaller in size ? Where is this done I would like to play with image size .

Cheers
Mick

The original is not actually resized, here is proof of this: http://www.test.alpineascent.com/media/com_easysocial/photos/47/119/af8c0d9677ee836996f18bcd4098dba4_original.jpg

So if the original is not the resized one, what does the stock one do?

Hello Josh,

Ah okay I was wrong. What actually happens is that the original and the stock is pretty much the same file but when an image is rotated, the original image file will also be rotated but the stock photos are still preserved as it is to ensure that the quality of the image still retains.

Thanks for the explanation on why there is a stock photo. 99% of the time I will fight for the best image quality possible. However in this case it seems a bit over the top to store an extra original due to the very slight quality loss of an image rotation for the few who do rotate their photo. Keep in mind I do admire your passion to make sure people get the best quality photos possible, as a photographer I too take this sort of thing very seriously. But this loss of quality from a rotation seems like a very small amount. I would think 95% image quality would be much more damaging to a photo than a rotation.

If we must have the stock photo, I strongly suggest it be an admin option that can be turned off or on. Originals take up a lot of space, having an extra original per photo doubles the space consumption (well aside from the smaller image sizes). Space usage should be heavily considered. Some day I'll probably use some sort of virtual private server that is zipping fast, however because of the large quantity of data I want to minimize my impact where I can to maintain speed. Plus all the shared host folks would really appreciate it.

Hello Josh,

Assuming that you only rotate the photo once, it's perfectly fine. If you go through round the clock multiple times, your picture would be pixelated very badly. It's like resizing on top of a rotated / resized photo over and over again.

That makes sense. You mentioned the idea of having an area for "Storage Settings" right? What if one of the options was "Store Stock Photo" which by default it could be set to yes. If the admin chose to set it to no, not only would ES not store the stock photo but image rotation and such would rely on the original instead of the stock photo (hence preventing an error). This would clear up the issue of the system knowing which photo to use (original or stock).

For my own site I am willing to help out users on a case per case basis. So in the rare scenario of a user rotating an image a bunch of times, I'm willing to go in and replace their image or help them get it replaced to have clean quality. You might ask why go through the trouble? A little bit of work every blue moon is worth saving lots of space.

@Josh

But this loss of quality from a rotation seems like a very small amount. I would think 95% image quality would be much more damaging to a photo than a rotation.

Quick question: Do you mean 95% of the default 80% image quality that Stackideas have in the settings for photos or did you change that image quality setting to 100% before uploading your photos?

I changed my quality to 100%, I want my photos to look awesome! When I said 95%, I was referring to the image quality setting as a hypothetical comparison to a single rotation. A single rotation would probably do very little damage, but as Mark mentioned a lot of rotations could pose an issue. For this reason I was proposing the stock image to be optional and allow the admin to address the images on a case per case basis. After all it's not that common for a user to accidentally rotate an image 4 times.

Ah I understand, make sense, thank you.

I will adjust all my component settings to 100%, I know it only affects new images but I have to upload them again anyway and it won't take long.

Hello Josh,

I am not sure if making it optional is a wise choice at all. It's either a "go" or "no go" because the logics for this would be pretty massive considering that there are times where stock photos are not available and there are times where stock photos are available.

If a admin had the stock option enabled for a while but later decides they simply don't want them, the stock photos would simply sit there and do no harm to the gallery. In the other scenario where the admin turns it off but then later decides to re-instate it I see how it "could be problematic" for the already posted photos. To solve this issue when the stock image does not exist it could use the original as a fall back. Right now if you delete the stock image there is zero fall back in which it deletes all the other sizes when you rotate the photo. The original photo fall back method would solve that.

Thanks for the heads up on this but as of now, we do not have plans to alter this behavior yet. Perhaps in the future maybe

I'm glad I understand why, and the idea might be re-looked into someday. The good news is that I feel better about the stock photo than I did before.

Thanks Josh