I’ve stumbled upon this new feature https://gohugo.io/extras/localfiles/ and I thought I would be useful to read the EXIF data of images to generate cool galleries with adanced informations or maps with GPS data from those images.
I would like to propose a new function readImages which works the same way as readDir but readImages returns within the for _, img := range readImages $path loop a new struct containing all file information from os.FileInfo and on top important EXIF data, not all but many of them (we can add more later). The only library I’ve found without importing C is https://github.com/rwcarlsen/goexif
I think this would be a handy feature to have and would be very useful.
I’ve been thinking quite a bit about expanding the definition of content. I’m putting together some slides this week (hopefully) that will explain this thinking a bit more…
In short the concept is that content means more than just text and front matter meta data. Images are content and have their own meta data. It would be great if they were treated as such. All of the rules around nodes & pages would be extended to these alternative content types.
Ultimately the difference in these two approaches is that the readDir / readImage approach works outside of what Hugo already gives you where the approach I’m thinking works inside of Hugo…
I admit it’s a bit rough today and there’s no reason to suppose that both approaches shouldn’t be used. Just as ReadDir works alongside the Hugo content processing today.
Perhaps just seeing what I’m thinking would help you design your feature in a way that could be leveraged further in the future. In fact, the more I think about it the more I think what you’ve outlined may be step 1 towards what I’m thinking.
First, sorry for reviving this post, but I found it while searching if it would be possible to read EXIF from my photos and build a gallery with title/aperture/speed/etc.
I have no idea if it’s possible now, do you have any news on this feature ?
There is no known native Go support for EXIF reading (as I know of …). We should eventually get it integrated with the rest of the image handling in Hugo. But I have no plans implementing EXIF on a low level.
In addition to basic EXIF, many photographers also write IPTC data when exporting JPEGs for use on a website. This library reads both EXIF and IPTC, but the author mentions it’s not polished:
And here is a wrapper for libiptcdata:
As an aside, I’ve seen instances where image optimization or compression programs or pre-flight scripts strip EXIF and IPTC data. One such example is:
Looks like there’s a working exif reader now for go, and they want more people exposing it to data.
Not sure what imageConfig is using under the hood, but seems similar is the sense it’s pulling meta-data from the image itself. I’d say the json output from go-exif would probably be the most useful.
Also, need to be very clear in docs that reading exif data from images needs to happen before any image manipulation, otherwise there won’t be anything to read.