Brett on 12 Jun, 2016 09:36 PM
Marked simply displays the image as it exists on the disk. If there's exif data that changes the way an actual photo app displays it, you'll need a workflow that actually applies that when the image is saved (either on iPhone or using something like Hazel on your Mac).
One of the photos (filename ending in 4465) is a portrait-orientation photo
that shows up in Marked (and a few other places) as sideways, with the top
of my head pointing to the right (instead of up). However, the photo shows
up oriented properly in most other places, including:
- viewed in the finder on my Mac (running OS X 10.11.5)
- viewed in the Dropbox web interface
- viewed in Editorial on my iPhone 5S
- viewed in Write on my iPhone 5S
- viewed in 1Writer
Other places that don't orient the photo properly:
- nvAlt on my Mac
- MultiMarkdown Composer on my Mac
The other photo (ending in 4464) is landscape, and shows up correctly (top
of my head at the top of the frame) everywhere I've checked.
The orientation data does seem to travel with the image. Both images went
from my phone to Dropbox (via 1Writer) and then to my Mac. Here's the EXIF
data from the copy of the portrait photo (ending in 4465) on my Mac, as
gathered with File Viewer:
Brett on 16 Jun, 2016 03:02 PM
So it looks like the webkit version used by OS X applications does not
automatically handle image rotation. I'm still trying to figure out why
Chrome and Safari do by default, but neither currently support the
"image-orientation: from-image" property, so I've been unable to force
it thus far.
I don't see this currently being possible, but will explore further.
I'm having this trouble too. Specifically, it seems that portrait-oriented images come out 90º counterclockwise.
My use case if for a daily journal. I write throughout the day on paper, then in the evening I transcribe it to a markdown file. I want to be able to include the occasional sketch inline.
I use an Automator service that converts from heic to jpg, moves the image to my Assets folder, and copies the file path for inclusion in a TextExpander-driven markdown image.
I tried including a 90º-clockwise rotation step in my workflow, but then the image rotates a full 180º in the Marked-rendered version. I inserted a second, backwards rotation to counteract the first, and it seems to be working.
It's embarrassingly kludgy. Has anyone found a more elegant solution?