New version of readDir for images with EXIF data

I’ve stumbled upon this new feature 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

Available EXIF fields:

Any thoughts? Maybe a better name for the function or which fields to include in the new EXIF struct?

Go or No-Go?

1 Like

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.

1 Like

Great thoughts. That means we can even add more content-types. No need to hurry with your slides. I’m off to FOSDEM.

Hello there,

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 ?

Thank you very much.

Any news on this feature?

No news. Someone needs to work on this task.

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.

Brad Fitz is also contributing to so native Go support is given.

That is brilliant and bookmarked – but his commit is like 1 hour old… Almost exactly at the same time as my comment.

1 Like

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:

You have to remember to turn that stripping off.

+10 for IPTC support if possible. All to often overlooked but I’ve long used it for cataloguing images.

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.

I’ll add a note to the open issue as well.

With exif data now supported, is this suggestion possible?