Using PNG EXIFtags in Jekyll? (P.S.: JPGs are working fine)

I am using Jekyll 3.9 and am using exiftag as part of the tutorial at Using LightGallery in Jekyll without tedious configs without any problem for JPG images. It works great.

The album.html file loads the exif tags as follows:

    {% for image in site.static_files %}
        {% if image.path contains 'images/galleryv2' and image.path contains include.albumname %}
            <a href="{{ image.path }}" data-sub-html="{% exiftag image_description, , {{ image.path }} %}" >
                <img src="/thumbnails{{ image.path }}" />
            </a>
        {% endif %}
    {% endfor %}

Note the {% exiftag image_description, , {{ image.path }} %} part: it works great.

However, I wonder how to use the same for PNG images? I am using a tool called SetEXIFData v9.2 (Marc's Place - SetEXIFData) via which I can confirm that I can include ImageDescription EXIFData to a PNG, just like to a JPG.

However, the {% exiftag image_description, , {{ image.path }} %} is not working for PNG images … it instead shows the image path.

How to make the caption work please for PNG images?

Additionally, I have a general question about plug-ins. I already added gem "exifr" in my Gemfile. And so (after bundle install or bundle update) I can retreive an exifr-1.3.9 in my vendor/bundle/ruby/gems folder. In it I can see a lib/exifr/ folder with inside the following files: jpeg.rb and tiff.rb
In the same lib/ folder there is also an exifr.rb file.

So I wonder why the tutorial asks me to also install a seperate exiftag.rb file inside my Jekyll main directory’s _plugins folder?

How do these plugins in the _plugins folder relate to the installed gems in the vendor/bundle/ruby/ folder please?

I think the tool you are using only works on jpeg and maybe tiff files:

EXIF Reader is a module to read metadata from JPEG and TIFF images.

1 Like

Hi @rdyar Thanks.

Would it be easy to provide a patch for the exifr gem, such that it works for PNG?
Currently I receive the error no start of image marker found in my terminal when including a PNG.

This is coming from https://github.com/remvee/exifr/blob/master/lib/exifr/jpeg.rb

def examine(io)
  io = Reader.new(io)

  unless io.getbyte == 0xFF && io.getbyte == 0xD8 # SOI
    raise MalformedJPEG, "no start of image marker found"
  end

If not, I wonder what other tool to use?

Files: .jpg , .tif , .heic , .png

But I do not know how to use that with Jekyll? Would it keep the project light-weight?

If not, perhaps

Otherwise, I might give one of the following a try:

I am not sure which one would keep the project light-weight and minimal and build fast. My feeling tends towards the last option multi_exiftool ?

Yes you can use it. The top of the readme covers gem install. The repo is a mix of ruby and c code and you can treat it as a ruby gem to install and use a Jekyll plugin. It won’t work on standard GH Pages though, as with any unsupported plugin.

1 Like

Look closer. The table in readme says no PNG support for exif.

1 Like

OK thank you @MichaelCurrin I am trying to get GitHub - tonytonyjan/exif: The fastest Ruby EXIF reader. to work. So I included gem "exif" in my Gemfile. Subsequently did bundle update and after that gem install exif as well, to be sure?

But I have a feeling that I also need to put some files inside _plugins ? Is that correct please?

Because, for comparison, when we were using the plugin GitHub - remvee/exifr: EXIF Reader (following the tutorial Using LightGallery in Jekyll without tedious configs) there was a necessity for an additional ruby file called exiftag.rb https://github.com/benib/jekyll-exiftag/blob/master/lib/jekyll-exiftag.rb (described as "

A LiquidTag to get Exif Tags using EXIFR

") which would be placed inside the _plugins folder.

I believe we would need something similar for Jekyll to be able to access an image’s EXIF data via GitHub - tonytonyjan/exif: The fastest Ruby EXIF reader. ? Because when I try data.image_description it doesn’t really work. The usage instructions there aren’t really understandable for a noob like me.

For comparison, using exiftag.rb (from https://github.com/benib/jekyll-exiftag/blob/master/lib/jekyll-exiftag.rb) we were calling the data from GitHub - remvee/exifr: EXIF Reader in Jekyll using:

{% exiftag image_description, , {{ image.path }} %}

I am just trying to adapt it to use with the new tool GitHub - tonytonyjan/exif: The fastest Ruby EXIF reader. but

{% **exif data.image_description**, , {{ image.path }} %} is of course not working out of the box like that … I understand because there is no Jekyll tag defined.

If you add the gem to Gemfile and run bundle update, that is sufficient.

You should not run gem install exif as in the docs as that will install in a gems folder shared across projects.

exif is not a Jekyll plugin, just a Ruby gem. So it can go anywhere inside Gemfile. not in a plugin group and not in plugins key.

If you installed a gem with bundle, you can find it with

bundle open exif

Normally there should be no need to edit your own _plugins directory as Jekyll will look at the gem in your vendor gems.

You would need the _plugins directory if you want to write your own ruby code or copy and paste a single script plugin.

In this case it sounds like you want to use the existing Jekyll plugin which only handles jpeg and tiff and extend it. So you can do that with a script in plugins directory and do an import exif in ruby and use that.

If your adapted plugin is multiple files, then it is probably better to make a fork of the plugin you want to use, add exif to it and then install your forked plugin using a GitHub URL.

e.g.

group :jekyll_plugins do
  gem "jekyll-exiftag", git: "https://github.com/MichaelCurrin/jekyll-exiftag"
end
1 Like

Generally for gems that are Jekyll plugins, make sure it is inside the plugins group.

group :jekyll_plugins do
  gem "jekyll-seo-tag"
end

Note that using a gem inside the plugins group as above is sufficient. You do not have to add to plugins key in the config. I’ve tested this with several plugins yes use of the plugins key still persists in documentation.

1 Like