I’m a newbie to Write.as but I’ve searched the forum and not found an answer to this one. When I upload photos to Snap.as and then copy them into my blog they are often rotated. Especially photos taken in portrait, are laid on their side … but it also looks as if landscape pictures I take with my phone ‘the wrong way round’ (what?) are rendered upside down.
Is there a way of rotating images in my blog post so they are correctly rendered?
Here’s a solution I found. You add a class to your CSS, e.g.
.rotateimg180 {
-webkit-transform:rotate(180deg);
-moz-transform: rotate(180deg);
-ms-transform: rotate(180deg);
-o-transform: rotate(180deg);
transform: rotate(180deg);
}
(Or 90 or 270… This should ensure it works in all browsers.)
Then enter the image with HTML, e.g.
<img class="rotateimg180" src="whatever" alt="" />
If you know of a neater solution please let me know.
Thanks for reporting this, @godspelled – that CSS solution does seem to work! But we’d really like to fix it on our end, as we’ve heard about a couple other people having this same issue, and we’re still investigating what’s going on.
If you don’t mind, could you email us the original image(s) you’re trying to upload to hello [ at ] snap.as, so we can take a look at what’s happening?
@matt
More thoughts on images: The images I uploaded were ones I had in Google Photos and had to download to my computer before I could upload them to Snap.as. It was when I uploaded them that the rotation happened: it was as if Snap.as didn’t want to accept portrait orientation.
When I added images to a post and used the CSS .rotateimg class to rotate them, there was also an issue with overlap: the rotated image overlapped content (either text or another image) above and below. My workaround was to add a couple of lines with before and after the image to adjust the spacing.
Hi @matt @godspelled,
Late to the party here. After playing around with snap.as for the past few weeks I noticed that the rotation issue seems to happen when I upload pictures I’ve taken using my phone.
If the photo was taken using a phone in the upright position then snap.as will rotate it to fit. Any photos that were taken landscape upload perfectly normal.
Hopefully, this helps. Or maybe this has been resolved by now.
I’d love to have a few simple photo editing features like rotation and cropping. Nothing crazy needed.
Have a great weekend everyone!
As an end-user, the simplest way to get the images to display correctly is to crop them slightly on your phone before uploading them. It doesn’t take much of a crop, just a few pixels, but that causes your phone to write the image differently and it’s then read correctly on the other end.
Been a few years since I’ve had the tools at hand to grovel through the jpeg data and metadata to determine exactly what’s going on there, but cropping the image is a fairly quick solution and it solves the problem (which is not unique to write.as - it happens on Lumberjocks.com where I post woodworking things).
I know this is something that write.as needs to fix, but whenever I run into this issue, this is what I do. First I make 3 copies of the photo on my phone. Then each copy gets rotated to a certain side. I then upload all 4 photos and pick the one that shows up correctly, then delete the rest.
Of course this fix only works when it happens to one or two photos. I’ve yet to see this issue occur on multiple photos.
just checking in on this. yesterday I uploaded a few photos from my phone and they showed up on snap.as rotated. looking forward to a fix and would love info on how to readjust the existing photos once this is sorted!
Hi Mel. I haven’t checked out the workarounds mentioned by @davepolaschek and @dino . If you look back at my solution (dated Aug 20) you’ll find a form of code that I put in the CSS file for my blog. Hope it helps.
Just figured I’d toss another voice in, I would really appreciate the ability to rotate photos on snap.as
I’d like to report the same issue as mason. I upload via phone exclusively. Everything taken in upright format is rotated 90° right by snap.as to make it horizontal. Horizontal pictures aren’t rotated. I don’t want to rotate every picture, just the upright ones. I’ll try the crop solution, but it would be nice if this could be fixed without a manual workaround on user side.
Edit: The cropping workaround works. Just cropping a few pixels on top and on the sides removes the issue. A bit tedious, but I am glad there is a workaround.
Hey everyone, really sorry this took so long to fix. But it is fixed now! When you upload your photos, you should notice they show up in the correct orientation now – no workaround needed at all.
Background / Cause
I realized this bug was probably introduced with changes around the new Snap.as backend we rolled out last year. Previously, we had more control over how images were served, and would store them as they were uploaded, but serve them with the correct image orientation, based on their metadata (here’s some background on how image orientation works, for those interested).
When we moved to the new system, we started serving images directly from our CDN, without any application involvement, meaning those raw images came out instead of the correctly-oriented ones. Now, we’ve fixed that by rotating the image correctly at the time it’s uploaded to Snap.as, so it always comes out correctly.
Other Changes
There are some side-effects from this change. One positive one: this also fixes an issue with optimized images getting their colors washed out. This should make Snap.as more suitable for professionals.
But we also now strip EXIF data from images. (This is the information that shows what camera you used to take a photo, aperture, shutter speed, GPS coordinates, and so on.) This part is good for privacy, but potentially bad if you want to preserve that information for anyone downloading your photos from Snap.as.
If anyone is going to miss that functionality, please let us know, and maybe we can add it back in. Otherwise, try uploading your photos again and let us know if you still notice any issues!
I haven’t looked yet to see if you’re stripping ALL EXIF data or just some of it, but if it’s all EXIF data that’s getting stripped, you’ll clobber color correction for any images that aren’t sRGB, which makes snap.as useless for “professionals.”
Not trying to slam you here, just pointing out that there’s a lot of critical data in the EXIF. If you have questions, I’d be happy to try and answer them. I’ve written a couple JPEG and TIFF parsers, beginning in the mid-1990s and know something about the standards. Also worked on Photoshop for over a decade before retiring.
That said, fixing the rotation problem will make a lot of people happy. Thanks for tackling that. I just worry you may have used too large of a hammer.
That’s great to know, @davepolaschek, thanks! I only have a basic knowledge of how image formats work, so I’ll let you know if I have other questions. But either way, sounds like it’s critical we preserve that information then.
Right now, the data is getting completely wiped out only because the server-side transformations don’t preserve it, and I had some trouble finding good Go libraries that could both read and write EXIF data back to the image. But there are some options out there that I’ll dig into now.
Not to worry, @matt - having looked at a lot of image libraries over the years, my impression is that a lot of the /implementors/ didn’t really understand all the details of the formats they were writing libraries for. Especially with JPEG, there are things like two different spots for storing the rotation that cause confusion to anyone not aware of both of them, especially since some popular libraries only write one of the two locations.
I’m retired, and don’t have access to a “real computer” any more, but I’ll be happy to answer questions as best I can.
-DaveP
Heh yeah, I can imagine that’s true.
So I spent some time reading the JPEG spec, looking at this site, the Go standard library, this ICC profile parser, and it seems like the color profile information is generally stored in the APP2 segment – so that would be the segment in particular to preserve. Does that sound correct?
I’m imagining we might also want to preserve the APP0 and APP1 segments at a minimum, if we’re just parsing raw data and copying it over to the final image? If all of that sounds right, I’ll give it a shot.
Once I get something that works, I plan to release a Go library for all of this, as I haven’t found a single one that covers this basic (seemingly common) use case.
Also out of curiosity, where are those two locations orientation is potentially stored in? Looks like the library we’re using right now for image orientation only looks in the APP1 segment.
Sorry for the delay in responding. Some days are busier than others, even when you’re retired. :-/
The other orientation flag is part of the JFIF spec, and because of the conflicts between the JFIF spec and the EXIF data, I don’t think it’s possible to write a JFIF that also matches the EXIF spec completely. Aren’t standards wonderful? If one doesn’t work out, just pick another!
So writers are kinda screwed. But readers can look at the two different orientations and make a choice if they don’t match.
I think in this case, you’ll want to preserve the APP0, APP1, & APP2 segments, but if the JFIF orientation doesn’t match the one in the APP0, you’ll need to flip a coin or make a choice or something. I don’t recall off the top of my brain which one of the two the iPhone prefers, and it seems to be the problem child relative to other jpeg writing devices.
-DaveP
No worries @davepolaschek, I just appreciate your help!
That does sound pretty crazy about the orientation stuff. I’ve tested our current system with some iPhone photos and it seems to work fine, so unless people report otherwise, I think we’ll stick with what we have (though it’ll be easy to debug if people start seeing funky things now!).
I went ahead and made it so we retain the APP2 data for now, which seems to be working well in my testing. Next, I’ll work on preserving the other sections. But I think it’ll be tricky with the orientation, since we actually rotate the photo – I suppose we’ll need to also remove the orientation flag, wherever it is.
Anyway, those changes are live now, so please feel free to give it a shot and let me know if you all run into any issues!
If you’re interested, I also wrote a quick post about debugging / figuring this stuff out, with a link to the small library I developed:
Yeah. I think the problem was (and I’m working from 25 year old memories here) is that the initial JFIF spec didn’t cover all the cases for rotation, so while it’s useful and used, it’s not good enough, so another field needed to be added later. But the initial one was widely used, so deprecating it entirely would be bad…
I haven’t had a chance to test things out with iPhone photos yet. Was shooting images with the mirrorless tonight.
