New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EXIF metadata #4600

Open
bep opened this Issue Apr 10, 2018 · 25 comments

Comments

Projects
None yet
8 participants
@bep
Copy link
Member

bep commented Apr 10, 2018

See https://github.com/rwcarlsen/goexif

Looks a little bit early, but promising.

  • Add as metadata (params?) to the image resource for JPEG and TIF.
  • Probably also add it to the imageConfig template func?

@bep bep added this to the v0.40 milestone Apr 10, 2018

@digitalcraftsman

This comment has been minimized.

Copy link
Member

digitalcraftsman commented Apr 10, 2018

Add as metadata (params?) to the image resource for JPEG and TIF.

I would expected the name params in a context where the user can add and retrieve custom data. For Exif data I would call it meta or metadata instead.

But this are just my two cents :)

@bep

This comment has been minimized.

Copy link
Member Author

bep commented Apr 10, 2018

But this are just my two cents :)

But you are right, I didn't think. It needs its own header. This will require some thinking, I think.

@regisphilibert

This comment has been minimized.

Copy link

regisphilibert commented Apr 11, 2018

Metadata may be confusing with the existing implementation of .Resources metadata.

@kaushalmodi

This comment has been minimized.

Copy link
Member

kaushalmodi commented Apr 11, 2018

.. or just call it what it is...EXIF.

@bep bep modified the milestones: v0.40, v0.41 Apr 20, 2018

@bep

This comment has been minimized.

Copy link
Member Author

bep commented May 2, 2018

So, to show you how random my priorities are. I'm going to implement this as an "experimental feature" (I will add some flag to turn it on). Not because I'm going to remove it, but because of the library I'm going to use is a little bit alpha.

There are possible additions to this (makernote data etc.), but I will start with EXIF.

The library has a JSON marshaler, but it puts everything in slices, which I guess is correct (in the sense that every field can have more than one value). Given a fairly representative image (se below), I think that will not be very user friendly for the average Hugo user. I think we rather should add a isSlice func and add all EXIF fields with 1 element as a single int etc. into a map. I think I need to read up on the EXIF spec on this to see if I can identify the "list values".

Input on the datastrcuture would be cool. I suggest adding a map to Resource, say Data (which matches nicely with Page.Data).

So: Params is custom data from the user, Data is custom data from Hugo.

This way you can safely do with $myResource.Data.EXIF and it would not crash for non-image resources. Maybe.

type EXIF struct {
Lat float64
Long float64
Date time.Time
Values map[string]interface{} // See below

/cc @digitalcraftsman @kaushalmodi @regisphilibert @onedrawingperday and gang. Input and suggestions welcome.

GPSSatelites => "06" Format: string
GPSDateStamp => "2018:04:11" Format: string
FocalPlaneResolutionUnit => 3 Format: int
ExposureMode => 0 Format: int
Contrast => 2 Format: int
GPSLongitudeRef => "E" Format: string
GPSAltitude => "70/100" Format: rational
GPSTimeStamp => ["12/1","12/1","26000/1000"] Format: rational
ShutterSpeedValue => "8965784/1000000" Format: rational
Make => "RICOH IMAGING COMPANY, LTD." Format: string
GPSLongitude => ["6/1","446111/10000","0/1"] Format: rational
DateTimeOriginal => "2018:04:11 14:12:26" Format: string
FocalLength => "1600/100" Format: rational
GPSLatitudeRef => "N" Format: string
GPSSpeedRef => "K" Format: string
GPSMapDatum => "WGS-84" Format: string
Software => "Adobe Photoshop Lightroom Classic 7.3 (Macintosh)" Format: string
ExifIFDPointer => 292 Format: int
FNumber => "9/1" Format: rational
DateTimeDigitized => "2018:04:11 14:12:26" Format: string
Sharpness => 2 Format: int
SubjectDistanceRange => 2 Format: int
GPSProcessingMethod => "ASCIIGPS" Format: undefined
XResolution => "140/1" Format: rational
ISOSpeedRatings => 100 Format: int
FocalPlaneYResolution => "83927223/32768" Format: rational
SensingMethod => 2 Format: int
GPSTrack => "16169/100" Format: rational
ApertureValue => "633985/100000" Format: rational
Flash => 16 Format: int
GPSStatus => "A" Format: string
FocalPlaneXResolution => "83927223/32768" Format: rational
SceneCaptureType => 0 Format: int
Saturation => 0 Format: int
GPSTrackRef => "T" Format: string
Model => "PENTAX K-3 II" Format: string
GPSInfoIFDPointer => 850 Format: int
GPSSpeed => "1/100" Format: rational
DateTime => "2018:05:02 16:09:05" Format: string
ExposureTime => "1/500" Format: rational
LensModel => "smc PENTAX-DA* 16-50mm F2.8 ED AL [IF] SDM" Format: string
GPSImgDirectionRef => "T" Format: string
ResolutionUnit => 2 Format: int
Artist => "bjorn.erik.pedersen@gmail.com" Format: string
ThumbJPEGInterchangeFormatLength => 11537 Format: int
ExifVersion => "0230" Format: undefined
ColorSpace => 1 Format: int
GPSAltitudeRef => 0 Format: int
YResolution => "140/1" Format: rational
MeteringMode => 5 Format: int
WhiteBalance => 0 Format: int
FocalLengthIn35mmFilm => 24 Format: int
GPSVersionID => [2,3,0,0] Format: int
GPSLatitude => ["61/1","247253/10000","0/1"] Format: rational
ThumbJPEGInterchangeFormat => 1326 Format: int
ExposureProgram => 3 Format: int
ExposureBiasValue => "0/10" Format: rational
CustomRendered => 0 Format: int
GPSImgDirection => "27339/100" Format: rational
GPSMeasureMode => "3" Format: string

Taken:  2018-04-11 14:12:26 +0200 CEST
lat, long:  61.41208833333334 ,  6.743518333333333

bep added a commit to bep/hugo that referenced this issue May 2, 2018

@bep bep referenced a pull request that will close this issue May 2, 2018

Open

WORK IN PROGRESS: resource: Add preliminary EXIF support #4692

bep added a commit to bep/hugo that referenced this issue May 2, 2018

bep added a commit to bep/hugo that referenced this issue May 2, 2018

bep added a commit to bep/hugo that referenced this issue May 2, 2018

@bep

This comment has been minimized.

Copy link
Member Author

bep commented May 2, 2018

image

Not sure what to do with the rational numbers. In the above, they are math/big.Rat which is, of course, the most precise value. That Rat has methods to convert it to a float etc., but it may be hard to use from the templates, so perhaps just convert it to the nearest float?. But there will maybe people needing this kind of precision, so ...

@regisphilibert

This comment has been minimized.

Copy link

regisphilibert commented May 2, 2018

That is really nice!

I think that will not be very user friendly for the average Hugo user. I think we rather should add a isSlice func and add all EXIF fields with 1 element as a single int etc. into a map.

Yep makes sense.

Not sure what to do with the rational numbers. In the above, they are math/big.Rat which is, of course, the most precise value.

I think people will expect raw values. I'm sure users will find ways to format it to their likings. If they cannot, maybe some template func could be introduced later on.

This will make some nice "photography" themes...

bep added a commit to bep/hugo that referenced this issue May 3, 2018

@TotallyInformation

This comment has been minimized.

Copy link

TotallyInformation commented May 3, 2018

Hi, I'm afraid that I don't agree about the raw values. Most photo's and photo-using sites are not likely to want such horrible numbers to deal with. I am not even sure they may any sense at all in fact given that the difference in visual data would be infinitesimal.

F-stop differences below 0.1 are very unlikely to be useful. Shutter-speed differences below 1 thousandth of a second (maybe 1/10,000) would only be useful in limited scientific settings. Generally, cameras will use well-recognised settings since F-stop/shutter-speed interactions are well understood.

It would be worth noting that one of the leading experts on these things is Phil Harvey who has spent years developing the definitive exiftool. So worth looking at the outputs that produces.

@bep

This comment has been minimized.

Copy link
Member Author

bep commented May 3, 2018

@TotallyInformation My example above is not fantastic, but I agree that for a presentation I would only want to output f2.8 it that was the aperture. I don't need gazillions of decimals and precision. That said, I have not thought too hard about what people want to use this feature for. Maybe output some JSON file as an input to some image processing library and that library really need the accuracy... I will have a look at exiftool.

@TotallyInformation

This comment has been minimized.

Copy link

TotallyInformation commented May 3, 2018

No worries, I just know how easy it is for us techies to get carried away :)

I can see that a portfolio site would find this useful as would some sites that publish photos of the natural world (I have a friend who is an insect specialist for example). In those cases, telling people something about the settings that produced the photo can help in understanding.

For me personally, the only EXIF data I would want to make use of would be date and comment. I actually use IPTC tags a lot more as these provide a much richer set of metadata.

@bep

This comment has been minimized.

Copy link
Member Author

bep commented May 3, 2018

Yea, well:

image

I guess float values makes most sense for most people.

For me the EXIF value is focal length, aperture and shutter speed. For me and the common blogger I guess the GPS position and date is also useful.

@bep

This comment has been minimized.

Copy link
Member Author

bep commented May 3, 2018

image

So there is shutter speed value and ExposureTime...

I would say that 1/640 reads better than 0.0015625

@regisphilibert

This comment has been minimized.

Copy link

regisphilibert commented May 3, 2018

I am no photographer, but I am used to see Exposure Time and Shutter Speed Value displayed as fraction on my camera. As this how we set them, it would make sense to read them this way too, in my opinion.

@kaushalmodi

This comment has been minimized.

Copy link
Member

kaushalmodi commented May 3, 2018

So @bep says:

I would say that 1/640 reads better than 0.0015625

@regisphilibert So looks like we are in agreement here :). And I too would love to see the ExposureTime in fractions like 1/640.

I do photography by hobby, but I don't understand ExposureTime vs ShutterSpeed. I always call that 1/640 value the "shutter speed".. but here that value is 9.32..? Can someone clarify the difference here?

@bep

This comment has been minimized.

Copy link
Member Author

bep commented May 3, 2018

image

I have tested a little bit more, and concluded that: If the numerator is 1 (as in 1/500), I will use the rational number, else convert it to a float. Quckly looking at the exiftool output, I'm not too far off. But remember that that is a specialist tool that the author has spent years fine-tuning ...

The "ExposureTime vs ShutterSpeed" ... there are some complex explanations online. The conclusion is: I'm using the ExposureTime.

@regisphilibert

This comment has been minimized.

Copy link

regisphilibert commented May 3, 2018

: If the numerator is 1 (as in 1/500), I will use the rational numbe

Spot on, this is what we you're used to see in our camera settings.

@kaushalmodi

This comment has been minimized.

Copy link
Member

kaushalmodi commented May 3, 2018

Coincidentally this came up in the forum: https://discourse.gohugo.io/t/how-to-use-image-orientation-with-image-processing/11823.

Looks like none of the EXIF variables listed above store the Orientation info? Or may be it's just the test image you happened to pick?

@kaushalmodi

This comment has been minimized.

Copy link
Member

kaushalmodi commented May 3, 2018

After some more digging, it looks like the Orientation flag will show up automatically if present?

https://github.com/rwcarlsen/goexif/blob/d4c99c2ae043cae162d53024b1dc50c3a189a27c/exif/fields.go#L16

@kaushalmodi

This comment has been minimized.

Copy link
Member

kaushalmodi commented May 3, 2018

I think we rather should add a isSlice func

Related: I had made a full proposal here.

and add all EXIF fields with 1 element as a single int etc. into a map.

Sounds good.

Input on the datastrcuture would be cool. I suggest adding a map to Resource, say Data (which matches nicely with Page.Data).

This way you can safely do with $myResource.Data.EXIF

+1. I think that also leaves room for possibly stuff like $myResource.Data.IPTC in future?

@bep bep added this to the v0.42 milestone May 25, 2018

@bep bep modified the milestones: v0.42, v0.43 Jun 5, 2018

@bep bep modified the milestones: v0.43, v0.44 Jun 30, 2018

@bep bep modified the milestones: v0.44, v0.45, v0.46 Jul 10, 2018

@bep bep modified the milestones: v0.46, v0.47, v0.48 Aug 3, 2018

@bganderson

This comment has been minimized.

Copy link

bganderson commented Aug 14, 2018

Would really love to see this added.

@bep

This comment has been minimized.

Copy link
Member Author

bep commented Aug 14, 2018

Would really love to see this added.

Yea, I have an implementation floating around. But I got hindered by a bug in a third-party library (which I fixed, but I wait for a merge of a PR). I will eventually get back to it.

@bep bep modified the milestones: v0.48, v0.49 Aug 22, 2018

@bep bep modified the milestones: v0.49, v0.50 Sep 13, 2018

@bep bep modified the milestones: v0.50, v0.51 Oct 6, 2018

@bep bep modified the milestones: v0.51, v0.53 Nov 8, 2018

@bep bep modified the milestones: v0.53, v0.54 Dec 6, 2018

@bep bep modified the milestones: v0.54, v0.55 Dec 26, 2018

@bep bep modified the milestones: v0.55, v0.56 Feb 1, 2019

@acahir

This comment has been minimized.

Copy link

acahir commented Feb 8, 2019

FYI, seems like there's a (possibly?) less "alpha" exif tool for go than what you started with:

https://github.com/dsoprea/go-exif

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment