Support Forums

LFS image transforms not working

So I’ve been hitting my head against the wall with LFS and trying to get it all to work smoothly. I feel like I’m almost there but I’m now having an issue where image transforms don’t seem to be working.
I can see the images are all tracked in Netlify App
I’ve disabled asset optimization.
I’ve made sure Netlify has all the images with ‘git lfs push --all origin’.
But still no luck: https://nostalgic-wiles-6089e0.netlify.app/img/uploads/9.jpg?nf_resize=fit&w=491
If anyone can provide some guidance with what I’m missing here, that would be great. Thanks.

Hi, @torsten. When I look at the currently deployed files, none of them appear to be using Git LFS. I do see Git LFS files tracked but the deployed files at that same path did not use Git LFS.

Would you please send us the output of the two following commands (run in your local repo directory for this site)?

git lfs ls-files
git check-attr --all -- ./img/uploads/9.jpg

This will show what files Git LFS is tracking and the tracking type for that particular file in the current commit.

You can send that publicly or send it to me via private message if you prefer.

Hi Luke, thanks for your reply. Here’s what I get with those commands:

git lfs ls-files
15a92eeb24 * public/img/uploads/1.jpg
2b68e39199 * public/img/uploads/2.jpg
3be79c0acd * public/img/uploads/3.jpg
fba91038c5 * public/img/uploads/4.jpg
63211c0982 * public/img/uploads/5.jpg
a91e0ca1dc * public/img/uploads/6.jpg
80203be7e4 * public/img/uploads/7.jpg
e11c91411f * public/img/uploads/8.jpg
d6cbdb7947 * public/img/uploads/9.jpg
git check-attr --all -- ./img/uploads/9.jpg

Doesn’t return anything but…

git check-attr --all -- "public/img/uploads/9.jpg"
public/img/uploads/9.jpg: diff: lfs
public/img/uploads/9.jpg: merge: lfs
public/img/uploads/9.jpg: text: unset
public/img/uploads/9.jpg: filter: lfs

Not sure how relevant this is but I’m using widgets from Netlify CMS for the image upload process. Perhaps it could be I’m not using the correct paths for the image urls when looping through the image references?


Hi, @torsten. Well, now I’m official stumped as I cannot see where the failure is. It all looks correct both at Netlify and in your local repo.

I’m escalating this to our developers and I’ll reply here as soon as we have more information. Please feel free to reply anytime though if there are others questions or new details to share.

Hi Luke. Thanks. Again, not sure how relevant this is, but it does appear that images are now being resized to an arbitary(?) size on the admin preview panel. E.g. blob:https://nostalgic-wiles-6089e0.netlify.app/8311581c-408d-4ceb-a83f-477a9fe93ed6. Just not on the live site with the parameters set in the url…

Hi, @torsten. Thanks for the additional information. I don’t think it is related but more information tends to be better than too little and I appreciate the update all the same.

I haven’t gotten a response from our developers on this yet but I’ll reply here when I do.

Hi, @torsten. After researching this further, it appears the tracked files are in the output directory:

This isn’t normally a directory that would be tracked by Git because it isn’ the site source code. Instead this directory would normally contains the output of the build process none of that content would be tracked by Git.

Our best guess as to what is happening is that somewhere you also have the non-LFS version of these files in the repo and the build process is overwriting the Git LFS pointer files with the actual binary image file.

However, this is only a best guess as we don’t have access to the repo itself. The build system can download the repo but our support team cannot see it beyond know what the upstream URL for the repo it. We know the repo URL but get a 404 at the Git host if we visit that link.

Also, based on the statement that the images are now resized, it would imply that the site build is somehow working with the binary files somewhere else in the directory structure and then overwriting the LFS version in the public directory.

Would you be willing to please confirm how your site processes these image files during the build? You can also grant me repo access (read only is fine) and I would be happy to look into that as well. For example, if this were a GitHub repo, my username there is overlordofmu (the username is a joke which only I think is funny it would seem).

Again, you might be able to confirm this without my looking as well. ​Please let us know if there are other questions about this.

1 Like

I laughed (possibly because of the parentheses)! :rofl:

Hi @luke. Thanks for going through that for me. I had a feeling that I shouldn’t be tracking my public files, however previous attempts at getting the site to load correctly without tracking them resulted in broken image links, which didn’t make much sense to me but I just went along with it!

Having read through the issues outlined in your reply, I’ve gone back and untracked all the public files, tracked the source files, and it is indeed now working! So I must have fixed something else along the way since trying it last, or I just have a better understanding of how it all works now.

Many thanks for your help!

1 Like

Hi, @torsten. Thank you as well for letting us know how you fixed it. Cooperation for the win!