Hi,
(I don’t think this is caused by the same issue on this thread, but i’m not 100% sure)
I’ve noticed that once I resize an image using .Resize causes images (with EXIF data it seems) to be rotated 90 degrees to the left. Is this a bug I should report?
There is an open issue about it. I would not call it a bug – I added the “rotate action” to the API because of this – before we got Exif support. Now we could do “auto orientation”, but nobody has gotten around to it, yet.
There are threads on here with a workaround. Someone may chime in if they are better with the search than me.
cool.
i think for now i’m going to remove exif data from the images… since i’m already doing some image cleanup and compression before hugo get involved. that would work, no?
Removing the data isn’t the problem you’re seeing; the EXIF contains rotation info that Hugo currently ignores. But you can apply that rotation yourself. There is a thread about it.
I tried the solution in this thread but was running into an error: ...error calling Exif: metadata init failed: loading EXIF sub-IFD: exif: sub-IFD ExifIFDPointer decode failed: zero length tag value. even when running with with statements :
{{ with $res }}
{{ with .Exif }}
{{ . }}
{{ end }}
{{ end }}
Is there a way to force this to ignore gracefully?
I’ve read in another post, that, if you work on images with Hugo’s image functions, the EXIF information is deleted. Your images most probably were done with a mobile phone or a modern camera that adds EXIF information about the positioning of the camera (portrait, landscape mode, 180 degrees rotation). If that is removed the “normal” rotation is shown, which appears to be rotated to the left.
You should run through your images with a tool like mogrify that saves all photos in their proper rotation based on that EXIF info before you let Hugo touch it.
After looking at the images in which this was happening, I do think that the “shot on a mobile phone” issue is why things were wonkey.
Yeah, I was sing if there was a way to fix things in Node by going through all assets and “cleaning stuff up” but i wasn’t able to detect any difference b/w files. But i will def have a look at the script that you mentioned and see if i can fix it into the workflow.
Looking at the error, though, there seems to be something funky going on since with should allow for a graceful error…
The with does not know what the .Exif does and from the language of the error I think that the way Hugo is establishing the Exif data has no silent fallback. That might be a bug in Hugo’s image library or upstream with the library that is invoked in the .Exif-function.