NLM -> accepted image formats e.g. JPG

If a user uploads a .JPG then the image is served up without any cropping or resizing even if I request .jpg. It is not that easy to convince users to rename their files to .jpg

If .JPEG, JPG and .jpeg where all accepted as well as jpg that would make for fewer unexpected huge downloads. Workarounds are not straight forward.

Perhaps this isn’t a .JPG thing. I renamed the existing files and am still having problems.

The following image is coming out at original size. Have you a max file size? This would be good to know in the limitations.

https://nlm--clever-khorana-bddb4f.netlify.app/images/integrity-blog-3.jpg?nf_resize=smartcrop&w=500&h=333

Looks like apple in the docs page is 1.9MB and I’m struggling with an image of just 1.4MB. Could it be an artifact of originally being loaded as .JPG? Seems odd.

Maybe the .gitattributes file is case sensitive? No clue if it works, but worth trying:

*.jpg filter=lfs diff=lfs merge=lfs -text
*.JPG filter=lfs diff=lfs merge=lfs -text
*.jpeg filter=lfs diff=lfs merge=lfs -text
*.JPEG filter=lfs diff=lfs merge=lfs -text

Good shout but I do have these all in my attributes file. I think the image is in LFS it’s just not being hitting the image transformations. I’m not really sure how to check. It was loaded initially via Forestry.io so I think LFS is guaranteed.

I checked the file was an LFS and it is. I think this is to do with the Transformation internals.

git lfs ls-files | grep src/images/integrity-blog-3.jpg    
58daa9c0e6 * src/images/integrity-blog-3.jpg

You could try to run git lfs push --all to make sure all the images are actually uploaded as LFS objects

@tomrutgers I have several GB of images and all of them have been added to git and I downloaded them from git. The files are very much there but are being served without transformation. Furthermore if I natigate to the files in the browser it initiates a download, whereas a normal image will display in the window.

Have a look: https://nlm–clever-khorana-bddb4f.netlify.app/images/integrity-blog-3.jpg?nf_resize=smartcrop&w=500&h=333

It’s responding with data type application/x-www-form-urlencoded where as a request to a file that has always been a jpg returns a image/jpeg. They aren’t hitting the same pipeline in netlify. Once a JPG always a blob → like a pfd or binary. It would be nice to know how to make this blob be recognised as an image type until the definition of an image can be extended to include .JPG. Interestingly .jpeg is supported and is treated like a .jpg.

Maybe @luke or another member of the support team can shed some light on this matter. Hold tight, someone will address this topic, hopefully soon.

Hi, @CraigC. The incorrect content type is almost certainly the cause of the image transformations not working.

I’ve escalated this to our developers and we will reply again here when the content type is fixed.

By the way, we will need to also find and fix the root cause of the wrong content type being used or this will just keep happening. In most cases the root cause is one of these two things:

  • Old git lfs version
  • Git config flag lfs.contenttype is not true

Do you know if either of those would apply here?

1 Like

Hi Luke

The images were added via Forestry.io media uploads so how that works is a mystery to me. I would have to ask what LFS version they use but I have no reason to believe they use an old one.

I’ll check on the configuration when I get a chance.

C

Hi, @CraigC. We are working to put in some safeguards to prevent out of data clients from causing this. Now, I don’t know for certain if that is what caused this issue in your case but, if so, we are working on a fix to return errors to Git clients using an out of Git LFS version to talk to Large Media.

About the file which cannot be transformed, it turns out it is more complicated to fix than I realized. Would it be possible to change the filename and upload it again? Also, the image itself must be modified in same way that changes the file checksum when this is done. (So, new name and new checksum - both.)

I realize that might not be possible though. If it is not, please let us know and I’ll see about fixing this “the hard way”. :+1:

I probably can sort this but as you say, a bit of pain and I kind of doubt I’m on my own with this problem. It took me a few months to really notice. I think there are a couple dozen images or more and I can’t stop people adding more from the CMS.

The files were mostly created by forestry.io they have a media library. I have some other JPG that may have originated from my local git so I’ll see how they compare.

Hi, @CraigC. I would check to see what version of Git LFS forestry.io supports as our Large Media service (which is a Git LFS service - and more) does have specific version requirements. Large Media required Git LFS 2.5.1 or newer and I’m not sure what version Forestry supports.

Note, if it isn’t possible to use Large Media, you can still use Git LFS for the repo by reverting the the Git LFS service for the company that hosts the repo (GitLab, Bitbucket, GitHub).