Fix rendering of fnumber in EXIF data

[ramatevish]

FNumber is represented as a imagemeta.rat[uint32], which contains a numerator and a denominator. If used directly in a template this results in fractional apertures (e.g. 5.6) in their rational form (e.g. 28/5) rather than as a float with one sig fig.

This commit updates the EXIF rendering logic, casting the rational to a float64, and then rendering it with at most 1 sig fig.

Before:

After:

I looked at example photos with both rational and integer apertures, and didn't see any issues, though this wasn't exhaustive.

[mfg92]

Thanks for your contribution. What version of Hugo are you using? I am running into this problem:

execute of template failed at <.FNumber.Float64>: can’t evaluate field Float64 in type interface {}

I'm using Hugo 0.129.0. Because of a bug in 0.130.0 and 0.131.0 I'm stuck whith that older version. Fortunately, this bug is already fixed in main.

[mfg92]

Hugo 0.132.0 has been released and contains the fix I have been waiting for. With this version I can reproduce the problem you are having with the apperture number. My analysis shows: The change of the library (introduced in version 0.130.0) that is used by Hugo to read the image metadata must have changed how .FNumber behaves. Your solution fixes this. However, it also raises the minimum supported Hugo version to 0.130.0.

I also noticed that ISO is no longer displayed with the new version of Hugo. This is caused by the renaming of the corresponding field in the metadata object. I will fix that after the merge.

[ramatevish]

This was run on v0.131.0

> hugo -v
hugo v0.131.0-bfbee17932ff24009008aa94cdd75c0c41f59279+extended linux/arm64 BuildDate=2024-08-02T09:03:48Z VendorInfo=hugomods

[mfg92]

This is now part of of v1.3.0. Thanks a lot for your contribution.