maintain orientation flag

[joncaris]

Please provide a flag to preserve image orientation exif data. I am unable to use portrait orientation photos in a site I am working on after they were reduced using guetzli.

[saurabheights]

@JonCaris - You may find ExifTool helpful for now. It will only write the Exif:Orientation metadata and would not re-encode the image.

[joncaris]

Thanks! I have been experimenting with ExifTool, it seems that even setting the orientation flag does not cause my images to display properly as background images. Do you know of another flag I can set in those images?

On Fri, Apr 21, 2017, 2:27 AM Saurabh Khanduja [email protected] wrote:

@JonCaris https://github.com/JonCaris - You may find ExifTool helpful for now. It will only write the Exif:Orientation metadata and would not re-encode the image.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/guetzli/issues/192#issuecomment-296106742, or mute the thread https://github.com/notifications/unsubscribe-auth/ADQeYmdIanJutWeXbX1qwAKvmcOG6dekks5ryFpGgaJpZM4ND2s- .

[saurabheights]

Could you upload a piece of project on how to reproduce issue at my end? Note css orientation metadata is not respected in chrome.

[joncaris]

I’m using grunt guetzli and minimizing with a quality value of the minimum 84.

I have an AngularJS application which sets the bound image url as the background image of an item in a gallery:

<div class="jc-smart-image {{classMixin}}" style="background-image: url({{imgUrl}})">
    <img class="sr-only" ng-src="{{imgUrl}}" alt="{{altText}}" title="{{title}}">
</div>

I found it odd that "portrait oriented" images were interpreted by the browser as "landscape" until I browsed them in my file system post guetzli and noticed it interpreted them the same way. Opening them in bridge and changing the orientation made them display correctly everywhere but the browser. Upon attempting to update the orientation with ExifTool, I found that the metadata had been set when rotating them with bridge, but the browser still interprets them as landscape. I didn't think the browser used that information anyway, so how DOES the browser interpret orientation? The images have the correct height and width upon inspection, with the height being greater than the width.

[saurabheights]

@JonCaris - Hi, I don't think I understood fully what you mean. I think you meant to say that only browser is ignoring the orientation metadata. If that's what you meant, you can try auto-orienting the image before running guetzli on it. You can try imagemagick for that:-

convert -synchronize <inputfilepath> -quality 100% -auto-orient <outputfilepath>

Note that decoding the image and re-encoding causes small loss in quality(Not significant unless you do this like a hundred times) - Generation Loss.

Edit:- Added quality since imagemagick defaults to 92 quality.

[joncaris]

@saurabheights Thanks again for taking the time. Yes, that is correct, the browser seems to ignore the orientation. Would running auto-orient on it before guetzli help? Wouldn't guetzli just remove the metadata that is added? The images were taken on an iPhone which I understand can make a difference as to how the metadata is written.

[DeeDeeG]

Maybe rotate with jpegtran, which is supposed to be lossless?: https://en.wikipedia.org/wiki/Libjpeg#jpegtran

This is available from these projects: libjpeg, mozjpeg, and probably also libjpeg-turbo.

[saurabheights]

@JonCaris - I'm so sorry for not getting back sooner. Auto-orient actually rotates the image itself. You can see this by opening image in viewers which do not use orientation metadata, example Sublime. So, there is no orientation metadata left for guetzli to remove.

@DeeDeeG - Thanks for providing this info(had totally missed it). I am no expert in jpegtran so could be wrong, but I have heard the same. I think it auto orients without actually decoding DCT coefficients(not sure though), which will also be faster. FYI, if the image resolution is not a multiple of 8, I think decoding will be needed but should be internally done by jpegtran.