Downsized Images

[+brendan714]

How come, after an image is uploaded to a cache page (as a CO), the images become downsized and appended with "_l" when they get clicked? 

 

ie:

https://s3.amazonaws.com/gs-geo-images/c72969d5-b22c-4db4-bb04-1c8b77c2f637_l.jpg
versus the real full size image:

https://s3.amazonaws.com/gs-geo-images/c72969d5-b22c-4db4-bb04-1c8b77c2f637.jpg
 

It's a really bad feature that I've noticed lately.  I find myself having to manually remove the "_l" to download the full size image to actually see it properly.

 

It's a pain when you try to download somebody else's cache image too, as the "_l" image is severely downsized with terrible quality.  

 

Script experts, is there a script to get around this? Thanks!

[+palmetto]

PC, Windows Pro Firefox 70.0  Tampermonkey scripts running

 

I went looking for your listing, assumed current, unpublished, and found it GC8H6AQ 

 I see a bug (?) immediately, in the the gallery count that I see is 0 (possibly not a bug, but normal behavior on an unpublished cache? i dunno)

View Gallery (0)

When I click the gallery link currently there are 8 images loaded.

I think what you're seeing is normal and not new.  It's the same behavior that  you get when viewing images from logs. Click the link, get the image, small, centered on the page.

 

If you're looking of the URL of the full sized image (perhaps to load it as part the cache page description) click it from the EDIT page, not the cache page.

 

Here's the link of your image from the edit page

https://s3.amazonaws.com/gs-geo-images/c72969d5-b22c-4db4-bb04-1c8b77c2f637.jpg

 

and from the cache page

 

https://s3.amazonaws.com/gs-geo-images/c72969d5-b22c-4db4-bb04-1c8b77c2f637_l.jpg

 

nice catch on the subtle difference in the URL. I think at one time, the URL was rather difference, prefaced with "gallery".

the Help Center article on images in cache pages says this, though perhaps not as explicitly as it could.

 

QUOTE: It's a pain when you try to download somebody else's cache image too, as the "_l" image is severely downsized with terrible quality.  

I'm not seeing this on log images? again from the listing page, they load centered, small. Put the log on its own page, click the image to get it on its own page, and you have the URL

https://s3.amazonaws.com/gs-geo-images/4ba91b75-d8d8-43f1-abb3-22bb4da19223.jpg

 

 

 

Edited December 23, 2019 by palmetto

[+arisoft]

9 hours ago, brendan714 said:

It's a really bad feature that I've noticed lately.

 

I think that this is made intentionally. An ordinary geocacher would usually upload images that are way too large, like 2048px × 1536px. The space for images on the decsription area is only 670 px wide, so shrinking images is usually required anyway. When the user become aware of the size requirements and learn to adjust images forehand, the quality is not reduced.

 

[+brendan714]

1 hour ago, palmetto said:

If you're looking of the URL of the full sized image (perhaps to load it as part the cache page description) click it from the EDIT page, not the cache page.

Yes, fair enough, but what if I am selecting an image from another CO's cache page?  Or what if people are looking at my images from my cache page?  They don't have the option to go to the edit page.  They show up as compressed low quality images until the "_l" is removed.  I've seen others download these images and comment on their poor quality when they are printed.  (For example, sometimes I include maps or route info on cache pages for others to print)

 

And it does happen on log images too.  For example, when I go to a cache page, scroll down to the logs and click on an image, it pops up the image in a little window.  Now if I download that image or open it in a new tab, it comes as a low quality "_l" file.  This never used to happen.  I have to open the image in a new tab and remove "_l" to get the high quality image.

 

My other option, as you say, is to open the "view log" page which opens up a brand new page with the log and images.  Now if I click an image I get it as high quality.  But if I want to peruse the images, I can only see tiny little images in the corner and I have to click on them one-by-one instead of the "slideshow"-like feature that the cache page offers.

 

Why can't the high quality image be scaled down to fit in the window as it used to be?  I'm sure this "_l" thing never used to happen.  I remember downloading high quality images directly from the log slideshow on the cache page.

 

All I'm saying is, the default should not be ultra low quality.

 

1 hour ago, arisoft said:

I think that this is made intentionally. An ordinary geocacher would usually upload images that are way too large, like 2048px × 1536px. The space for images on the decsription area is only 670 px wide, so shrinking images is usually required anyway. When the user become aware of the size requirements and learn to adjust images forehand, the quality is not reduced.

I'm not sure that's true.  If I use the "_l" image and upload it to my cache page, the quality is MUCH poorer than if I take the full quality image and upload it as the same size.  It seems that the "_l" image has significantly reduced quality.  For example, below I have added the same two images as the same size to my cache page.  The first image uses the "_l" file while the second uses the original high quality file.

 

Here's my source code:

<center>Here I'm using the low quality image:</center>
<center><img src="https://s3.amazonaws.com/gs-geo-images/f936ca51-9821-4011-bf83-ae9dc4469d57_l.jpg" style="height:480px;width:640px;" /></center>
<center>And here's the high quality image:</center>
<center><img src="https://s3.amazonaws.com/gs-geo-images/f936ca51-9821-4011-bf83-ae9dc4469d57.jpg" style="height:480px;width:640px;" /></center>

 

If you're a cache owner who doesn't know any better, you could very easily upload "_l" images to your cache page - in fact, I have seen that happen quite a bit lately.

Edited December 23, 2019 by brendan714

[+palmetto]

Sidestepping the issue you raise, I'll just say that the for some time, the worst way to upload images to your owned cache pages is via the link on the edit page, pre-publication or the Upload images link in the admin box after the cache is published.  

Do it as image upload from a log. Pre-publication, use a Write Note log, if you use  reviewer note, the image will archive along the log on publish.

 

Upload with log gives you (and others) easy access to the image url not as munged through whatever processes are being applied to owner gallery images.  And yes, I can see your images intact, only because i'm a reviewer, which gives me the same admin rights on your pages that you have. No one else do it.

 

 

[+brendan714]

10 minutes ago, palmetto said:

Upload with log gives you (and others) easy access to the image url not as munged through whatever processes are being applied to owner gallery images. 

A question for the site developers: why don't we simply avoid any and all image processing? If the "virgin" image is shown in the "view log" screen, why can't it be shown in the pop-up slideshow window on the cache page and in the cache page gallery?

 

As I mentioned, I'm quite confident that this is a recent change to the site as I'm almost positive this didn't happen a few months ago.  I've always written up my cache pages in the same way (uploading images to the page and using the links from the cache page gallery), and only lately have I found this lovely little "_l" feature.

[+arisoft]

4 hours ago, brendan714 said:

Why can't the high quality image be scaled down to fit in the window as it used to be?

 

There is a very good reason - the file size. Larger files require more bandwith which equals higher costs and slower response.

Both of your example images above are useful.

 

If there is a special reason to user better quality version you can choose the original sized image.

 

I don't understand why this is a problem for you, because you already know how to get the better quality image when you need it.

Edited December 23, 2019 by arisoft

[+brendan714]

6 minutes ago, arisoft said:

I don't understand why this is a problem for you, because you already know how to get the better quality image when you need it.

1) It's a pain in the butt to have to do it every time I want to see / download a high quality image.

 

2) Other cachers see my uploaded images as low quality and don't know how to fix the problem.

 

3) I don't think the website should be this way - it should use high quality images (like it used to until recently - this is a website downgrade).

 

4) Why use high quality images in the "view log" page but simultaneously compress them when they're viewed on the cache page slideshow?  Why not use either high quality for both or low quality for both?

 

5) Surely there are other people out there with the same problem.  I've seen some people download my images and not realize they're downloading/printing/sharing a very low quality image.  I've seen people take my images from logs and share them to social media (with my permission), not realizing it's a "_l" file, then wondering why the quality is abysmal when posted on social media.  I've only recently noticed this "_l" thing, but 99.99% of people surely don't realize there's some behind-the-scenes image manipulation going on. 

 

Say I have an epic caching day with a friend.  He uploads some photos to his cache logs.  I like his photos and I want to share them onto our local geocaching Facebook group.  How would one propose to do that?  Well, the most obvious answer is to go to the cache page, scroll down to his log, click the photo, save it to the computer, then upload it to Facebook.  "Hey, why is that image quality so bad?"  Sure, I know the solution.  But does anybody else?

 

This is the website forum where we can discuss potential bugs and feature upgrades, right?  Well, I think this is a concern worth addressing.

[+arisoft]

2 hours ago, brendan714 said:

This is the website forum where we can discuss potential bugs and feature upgrades, right?  Well, I think this is a concern worth addressing.

 

You are in the correct forum indeed.

 

I understand that your main concern is the extra work needed to get the link to the original resolution image. I remove _l appendixes quite frequently but have not noticed any frustration. I could remove them automatically if they bothers me but they doesn't. Now I understand what is your problem. It is still unclear what is your proposal. Replacing all low resolution images with high resolution images will not happen. There must be something else.

 

2 hours ago, brendan714 said:

I don't think the website should be this way - it should use high quality images

 

This is not primarily an image service. I think that geocaching.com is more focused to serve cache listings than high resolution log images.

Edited December 23, 2019 by arisoft

[+The A-Team]

4 hours ago, brendan714 said:

As I mentioned, I'm quite confident that this is a recent change to the site as I'm almost positive this didn't happen a few months ago.

 

I just took a look at some cache listings, and everything seems to work the way it has for years.

 

The "_l" for images uploaded to the cache listing isn't new. That's been around at least since HQ started using AWS S3 for storing images, which if I had to guess would be on the order of 6+ years ago. I'm pretty sure we had the same thing even when HQ was hosting the images themselves.

 

34 minutes ago, brendan714 said:

Say I have an epic caching day with a friend.  He uploads some photos to his cache logs.  I like his photos and I want to share them onto our local geocaching Facebook group.  How would one propose to do that?  Well, the most obvious answer is to go to the cache page, scroll down to his log, click the photo, save it to the computer, then upload it to Facebook.  "Hey, why is that image quality so bad?"  Sure, I know the solution.  But does anybody else?

 

I think it's pretty obvious that saving the small slideshow form of the photo will be lower quality than if you saved the full-sized photo. I'm not sure why you would expect to save an image displayed at about 600 pixels wide and expect the result to be the full-sized image. As with the "_l", the size of the slideshow images haven't changed recently. For as long as I can remember, the way you access the full-sized photo is to go to the log and click the photo there.

 

In the end, it's all about bandwidth and cost. A larger image costs more to store, and it consumes more bandwidth both for the system hosting the image and the user accessing it.

[+arisoft]

18 minutes ago, The A-Team said:

The "_l" for images uploaded to the cache listing isn't new. That's been around at least since HQ started using AWS S3 for storing images, which if I had to guess would be on the order of 6+ years ago. I'm pretty sure we had the same thing even when HQ was hosting the images themselves.

 

The same old way is still active and I am so used to it that I don't use AWS S3 links at all. The high quality link is still available direcly from the uploaded image if you know where it is. For example, this image is from my latest geocache listing uploaded couple of weeks ago  https://img.geocaching.com/cache/597ba075-26b1-462d-9fbe-ffbc89e6663b.jpg

 

[+The A-Team]

3 minutes ago, arisoft said:

The same old way is still active and I am so used to it that I don't use AWS S3 links at all. The high quality link is still available direcly from the uploaded image if you know where it is. For example, this image is from my latest geocache listing uploaded couple of weeks ago  https://img.geocaching.com/cache/597ba075-26b1-462d-9fbe-ffbc89e6663b.jpg

 

Yeah, I use that sometimes, but I've also found that some tools (like an online EXIF reader I use) don't like the redirect. I'll use different URLs depending on what I'm doing with it.

[+IceColdUK]

2 hours ago, The A-Team said:

The "_l" for images uploaded to the cache listing isn't new. That's been around at least since HQ started using AWS S3 for storing images, which if I had to guess would be on the order of 6+ years ago.

I agree.  I included a ‘Puzzle solving hint’ on this cache coming up for six years ago, and that wasn’t based on any recent change.

 

https://coord.info/GC4ZBK0