The rotation is done by pilkit:
https://github.com/saimn/sigal/blob/master/sigal/image.py#L77
https://github.com/matthewwithanm/pilkit/blob/master/pilkit/processors/base.py#L113

But there may be an issue with the copy_exif_data setting which copy the original exif (with the unmodified orientation tag). To confirm this, could you try with copy_exif_data = False ?

Related to firefox not rotating the image: https://bugzilla.mozilla.org/show_bug.cgi?id=298619

Okay, so my understanding is that you are rotating the images, but not removing the orientation exif; hence exif-compliant software like Chrome rotates it again. Why can't we remove the tag ourselves?

https://github.com/saimn/sigal/blob/master/sigal/image.py#L73

 # Preserve EXIF data
    if settings['copy_exif_data'] and _has_exif_tags(img):
        if options is not None:
            options = deepcopy(options)
        else:
            options = {}
        options['exif'] = img.info['exif']

    # Rotate the img, and catch IOError when PIL fails to read EXIF
    try:
        img = Transpose().process(img)
        del options['exif']['Orientation']  # something like this

    except (IOError, IndexError):
        pass

Okay, so my understanding is that you are rotating the images, but not removing the orientation exif; hence exif-compliant software like Chrome rotates it again

Yes. The problem is that it is currently not possible to save the modified exif with Pillow. (There may be a possibility, hacking with the internal stuff of Pillow, but I did not managed to get it work yet)
A feature request has been filled : python-pillow/Pillow#520
Thus, the only solution I see for now is to add a new setting to disable the autorotation, and let the user choose between autorotation and exif copy (the 'copy_exif_data' setting).

Confirmed copy_exif_data = False does not have this problem in Chrome.

@saimn I'm not sure how long (if at all) the python-pillow/Pillow#520 will take to resolve, would you be opposed to a dependency on gexiv2. (gexiv2 is the update to pyexiv2, which is discussed in "How to use PIL to resize and apply rotation EXIF information to the file?".)

btw: jhead -norot does this nicely.

I was using pyexiv2 at the beginning (it was optional). But the installation of pyexiv2/gexiv2 is a problem, it is not available on pypi, so I don't want to add a dependency on this. And I don't know if it is easily installable on all platforms ?

That's helpful, any news on an upstream fix from PIL?

Just looked about, don't see any evidence of the bug python-pillow/Pillow#520 receiving any attention nor of gexiv2 (as an alternative) appearing in pypi. However, there are a fair amount of exif tools in pypi such as exifyay. There's also img_rotate "Rotates PIL Image instances after EXIF-tagged image orientation" (however, it loses exif data as well). But maybe there's something there that could help.

img_rotate doesn't modify the EXIF data, it just rotate the images and doesn't the EXIF data. exifyay is more interesting but, even if it is available on pypi, you must compile it manually with cmake.

Any news on this front? Sadly, I don't see any change.

Hi Joseph,
Nope, no news. However I'm working on a plugin system for sigal, so one option could be to make a plugin for exifyay. This way it would not add a strong dependency to sigal, but it would be a good solution for people who need this feature.

I'm wondering if there's been any movement on this one?

Not really, except another project which could be useful to save modified EXIF data (and based on Pillow): https://pypi.python.org/pypi/piexif

I haven't seen any progress at python-pillow/Pillow#520, any fixes available here?

Nothing new here ...

Is there a workaround for this issue?

@jfleach - If you set only one of 'autorotate_images' and 'copy_exif_data', it should be ok: either rotate images and don't copy exif data, or copy exif and rely on browsers to do the rotation.

In python-pillow/Pillow#2800, Pil is considering adding https://pypi.python.org/pypi/piexif as a dependency, so it seems there is movement there.

And as for browser-based rotation, it's also mostly stalled, as I documented elsewhere (Upload/Up1#49 (comment)). Basically, earlier CSS4 drafts had image orientation extensions that allowed the browser to automatically rotate (or not) images based on CSS directives, but that was pulled from the standard. It was argued this was better served in the semantic layer (HTML) but nothing has come up there.

So far only firefox has support for the deprecated CSS4 directive and there's a patch pending for Chrome, but it's been 4 years so I wouldn't hold my breath on that one, especially considering the time it takes for browser changes to make it across the whole ecosystem.

We need to rotate images on our own (losslessly, if I might add) and modify the related exif data. It's annoying gymnastics, but it's not really something we can avoid right now, regardless of what the up1 people say. ;)

(Incidentally, it might be nice to link to this bug report in the source code, sample config or warning messages so that people can follow progress more easily. I missed this bug report while filing #279 earlier.)

Great news if Piexif could be used in Pillow !

Pillow 6.0 added the possibility to modify the EXIF metadata and added ImageOps.exif_transpose :)
https://pillow.readthedocs.io/en/stable/releasenotes/6.0.0.html#added-imageops-exif-transpose

Any news?

Not really, the feature is in Pillow but time is lacking to update the code to use it.

I just looked at the code in this area. For me the images themselves get rotated correctly, but the thumbnails not. It looks like Transpose is missing from the thumbnail generation, is that correct?

That seems to be the case, I'm seeing the same thing over here.

Indeed. I added a parameter autorotate to generate_thumbnail and a passage to call Transpose in the same way as in generate_image and it seems to work.

This is another issue, but I have seen that recently too and committed a fix (a77b2e3).
That should happen only with use_orig = True because otherwise the thumbnails are created from the resized images which are rotated.