Posting Images to Blog - Why are all the uploaded sizes different?!

One of my patrons has explained this a few times but i didn’t fully grasp it until now. They are also planning to send in a report about it but I’m sending one here as a creator because this is deeply concerning.

So yesterday i uploaded a file to my patreon blog that was about 400x700 px. A small doodle for this patron. My patron expressed there was a difference between the embed and the popout pixel size and wanted to know what the size was that i intended it to be before they saved it so they could save the RIGHT one and not whatever Patreon is doing to my images. (they’ve been saving both versions of every image for YEARS because they didn’t know which was right and this is just crazy that they have to do this.)

My Patron got:
Direct save from Blog page embed: ~1600x2800 (What?!)
Popout when you click on image: ~400x700 (This is the correct size!)
They are using Firefox 61.0.2

Me (saving the SAME image)
Direct save from Blog page embed: ~600x1100 (How did i get a different WRONG size?! XD )
Popout when you click on image: ~400x700 (This is the correct size!)
I am using Firefox 63.0

Both on PC.

Is patreon changing my DPI or something? There is a difference in the sizes of the images when viewed on the respective computers and it’s really confusing to myself and my patrons when they want to save my content. I shouldn’t have to attach the actual file to every post just so they can save the right image size and not have patreon muck up my content (which it does, the larger image looks like crap as is expected!)

My patron also says the following:
“Sometimes the embedded is smaller. Maybe they try to normalize the embedded picture size to certain dimensions in the post?
For one artist, the popped up was 2400 x 3000 and 3.92MB, the embed was 1600 x 2000 and clocked in at 2.37MB
The artist also linked the file as a download at the bottom of the post, and it matched the pop up’s figures.”
They also say
“This may affect other images where a post has multiple images posted below the main image. Those do not zoom in when clicked on, so I think the user is stuck with the resized image. I am basing this off of an artist who also linked in the posted images at the end of the post. I am seeing a size discrepancy in that case as well.”

Other sites seem to be able to save out the same (proper) file from the page embed and the download/view option just fine as long as you are on the submission page and not looking at the thumbnail listings. My patrons are potentially getting the wrong sizing of images (which could be terrible versions of my images they don’t realize until they look later which could also look poorly on me if they think i purposefully saved it that way) thanks to whatever the site is doing to it and this is not okay. :confused:

@mindy @carla

1 Like

Do you maybe have a public post we could use to test this?
I cannot replicate this at all. I quickly uploaded a rather small image (300x300 px) and a rather large image (3000x3000px) to my feed and all images remain unchanged when viewed or downloaded.

From a technical point of view, I see no reason whatsoever why different devices would get different images sizes from the same website. The server just stores the images and delivers them. They aren’t generated on the fly when viewed—let alone depending on browser versions.
By the way: How are you guys measure the pixel size? Maybe the problem lies there.

Perhaps this will clear up what I’m talking about.

There are two views of an image on the blog page (not including attachments) There is the direct, on the blog, embedded image (I save as A) and the popout/lightbox image (I save as B.)

I’ve done this for multiple of my own images on my patreon and so have some of my patrons and have found differences between the two. (How both my patron and myself got different larger image files on the -same- blog post i have no idea but they have also tested this on other artists pages too when trying to download rewards and saved both different versions because they were unsure which was the intended size.)

And yes, from a technical stand point it makes no sense. Every other site i save images from, saving from either the embed or the popout/lightbox gets you the -same- image save. No pixel differences what so ever but somehow whatever Patreon is doing to resize the images is well, causing weird differences.

Here is an example of the same thing, using Chrome, on a completely different patreon page that i also run.


And here is another, from someone else’s patreon page, back using firefox again.


To reiterate, The A saves, are directly from the blog page.
B saves are from the lightbox/popout image.

Okay, I can replicate it now. It doesn’t happen on the main feed, which I tried first. It does however happen when a single post is opened. The embedded image on the post page (but not the lightbox image) is scaled up to a width of 1600 pixels if it is smaller.

Maybe they do it for better social media sharing, because the Open Graph image uses that same file with a width of 1600 pixels. Social media services require certain minimum sizes or they will reject the image.

I am not sure if I am for or against the “feature”. Blowing images up and making them blurry might not be ideal when they are downloaded by users, but I guess Patreon still did that for a reason. The tech team would know for sure.

Thanks for all the detail – will dig in with the product team to learn a little more. A lot of the team is out, so it may take longer to have any sort of feedback.

Totally understandable! :slight_smile:

I also want to pop in and add that I find the auto-resizing of embedded graphics problematic. Sometimes I want to upload a tiny graphic that isn’t intended to distract from the text, and when I see the emails/posts it’s been autoresized to fill the entire width and it’s awful and pixellated.

1 Like

yeah, kinda is annoying that you have an “avatar / logo” size and then is oversized there
tbh, when in fact this could be a really good chance to have a better detailed art automatically, this become one that does hurt the creators.

i have a theory, that could have the cover art and avatar as the main culprits there,
due the resizing cover art , it needs to crop the art so it can be filled, but also, it is stretched in a lot of ways,
and the same way to upload pictures in the cover is the same to upload images.

so basically uploading a small pic, the system tries to update the image to make it adjustable to their factors, but rather than doing exactly that, is the default size and zooming , so yeah, it is for uploading images with the scripts from the cover art.

This is Irksome, my patron got back to me about their support conversation.

Patreon responded to me about the image thing today:

Thank you for reaching out to us regarding this issue, I’m more than happy to offer you assistance.

I would like to inform you that we compress images for optimization purposes on our platform.

The creator will need to upload the images for you to download in the actual resolution.

Since creators are 100% responsible for the fulfillment and troubleshooting of benefits, you’ll want to reach out to them directly.

If you want to send this message along to the creator, you can send them a message by clicking the More option on the Overview section of their creator page.

Please refer the creator to us directly if they run into any issues.

The staffer ignored half the stuff my patron said to them, which also included this:

However, if November_sketches_1.png was not added to the post, the user would not be able to access the true resolution image for the second embedded picture. Would you be able to have the images in the posts download as the true file size and image dimensions for the artists’ uploaded pictures? Could the original image be scaled and fit to viewable dimensions, while retaining the original image for saving purposes? Alternatively, could there be an option to automatically add links to download the original files at the end of the post? For example, if the user created a post with images A, B, and C, could the post automatically generate links at the bottom of the post for A, B, and C at the dimensions the artist uploaded?

And this was only about 1/3 of the initial submitted post by my patron. It feels like a really lacking and crappy response from patreon staff. o.O Also, he has some awesome suggestions, especially the automatically add links to download what the creator initially uploaded to the page in the first place. I support this and all his other suggestions honestly.

I get that it’s probably at least based on a copy/paste response but first and foremost, HOW ARE CREATORS SUPPOSED TO KNOW THAT PATREON DOES THIS? There’s no tool tip when uploading, no FAQ i’ve ever seen that states specifically this, nothing. Only that there is the option of attaching more files at the bottom of the post, not the it’s NESSESARY for accurate delivery if you are doing it within the post itself and not through other means. (All my patrons do get high res stuff at the end of the month through dropbox but some do still save the smaller copies so they have it because sometimes shit happens.) I’ve never used the attachment option in posts (outside of if it was my only option like specific file types, etc) for my work because myself and all my patrons thought we were getting the right sized images in the blog post. How are we to know otherwise? We can’t see what patreon is doing unless someone like my diligent patron here looks at the properties of the image after saving. So many other sites don’t have this problem and save and re-size from ONE source (except for thumbnails usually, which are separate, but that’s painfully obvious when you save those 100-ish pixels out that it’s not the large size.)

@carla @mindy

I’m SO sorry - I’m still trying to get to the bottom of why this is happening in general. I’m on a plane right now, but am talking to the product team to try and get some answers. It may be a few days even before I can understand why/how this is. I had talked briefly to a product person before when this came up, but clearly the answers weren’t satisfactory.

1 Like

No problem! Thanks for looking into it though! :smiley: Super appreciated!