Just discovered, to my dismay, that when I annotate a high-res image or photo saved in a note—whether adding text, or even just cropping it—Evernote reduces its size and resolution to 72 dpi without warning. Trouble-shooting revealed another disturbing surprise: the Evernote iOS app captures images at only 72 dpi, instead of using the iPhone's full, native high resolution. These surprises caused me real problems today, and make me worry what other images I thought I'd saved at hi-res in Evernote have had their resolutions reduced below what I need, without my knowledge.
This behavior strikes me as a bug that should be fixed. At minimum, if reducing image resolution is an intentional "feature", whenever an image is cropped or annotated, Evernote should warn the user before making it permanent. Evernote should also be more explicit about what resolution the iOS app will actually save when capturing photos with the iPhone camera.
More detail below...
=======================================
[UPDATE 1: OK, now I'm convinced it's a bug, or multiple bugs, but I'm more confused than ever. Since writing my original long post, I went back and rescanned this diagram as a photo, exactly as I'd done before. But this time EN behaved more or less as expected, even with annotations: it still changed the resolution from 300 dpi to 72 dpi, but this time kept the number of pixels at 3,267 x 2,533, and displayed in high-resolution both in EN and in Preview, even after adding a text annotation. Repeated the process several times, and maybe 4 out of 6 times it maintained the correct size through annotations. But at least twice it changed both the resolution and the pixel size as described in my original post.
The only difference I noticed in these multiple attempts related to the page orientation. The diagram is written in pencil on an 8-½ x 11 inch clipboard pad, in landscape orientation. The times when EN behaved correctly, and didn't resize the image, was when it brought it in in portrait orientation, and I had to rotate it counterclockwise just once. But the two times when EN resized the image after annotations were when it brought the image in upside-down, and I had to rotate it two times to get the correct orientation. Maybe that's just coincidental, or maybe it's related to the cause of the bug, but I'd have to do too much more testing to sort that out...
As a side note, I also noticed these times how much the size of the image file changed after any kind of annotation (rotation, adding text, etc.). The original scan at 300 dpi color came in about 500 KB. After doing just one 90-degree rotation—and nothing else—the file size increased to about 1.3 MB, despite EN reducing the image from 300 dpi to 72 dpi. After adding a two-word text annotation ("July 2012"), the file size increased more than a MB, to 2.4 MB. So my speculation that EN engineers might have been reducing the resolution to save on storage space seems completely unrelated.
Something seems VERY buggy—and completely unpredictable—with how EN is handling image annotations. Sometimes it reduces image size improperly, sometimes it doesn't. Maybe it's related to how many times the image is rotated, maybe it's not. In any event, the image file size shouldn't more than double every time any kind of annotation is made, even just a simple rotation.
FWIW...]
=======================================
I stumbled on this problem when adding a short text date to a diagram I'd scanned in as a 300 dpi photo using ScanSnap. I needed to scan it as a photo, because I needed the higher resolution to be able to read some of the small details in the diagram (my original scans as a default PDF were not sharp enough). But after adding the date annotation, when I went to zoom in on the image to see the details, they were gone! When I opened the image in Preview to check it out, it opened as a tiny little image, whereas it had previously been a full 8-½ x 11 inch page. Checking the image info in Preview, I saw that it was now a 608 x 785 pixel image, when it was originally 2,533 x 3,267 pixels. Both before & after images showed as 300 dpi. `
It took me a while, and much testing, to figure out what was going on. Eventually, I realized that the reduction in total image size was exactly the same as a reduction from 300 to 72 dpi (72 is 24% of 300, just as 608 is 24% of 2,533, and 785 is 24% of 3,267)—which explains why the annotated image on my screen appeared about ¼ the size it was originally. So, during annotation, Evernote reduced the image's resolution to 72 dpi, but left the image scale info at 300 dpi, causing Mac to now display it at ¼ its proper size. Even worse, because that higher resolution is now gone forever, trying to zoom in on the image or scale it up produces an unreadable, pixelated mess. Experimenting some more, I found that doing any kind of annotation produces the same result: adding a text or graphic annotation, or even just cropping the image, causes Evernote to scale it down to 72 dpi resolution. For a while, I thought it might be a problem with my 5K Retina system, with the Evernote app pinned to one of the non-Retina displays (a problem I've experienced with other apps), but experimentation seemed to rule that out.
This is the first time I've noticed this problem, even though I'm constantly adding images to EN, and frequently cropping &/or annotating them. But more often than not, I don't usually try to blow them up immediately after cropping or annotating, so I just may not have noticed the reduction in resolution before. Most often, I'm using the Evernote iOS app to capture photos of things directly to Evernote. I guess I'd always assumed Evernote was capturing them at full iPhone camera resolution. But looking back of my most recent captures, I see now that EN is bringing all those photos in at 72 dpi instead—what a surprise! But that explains why, when I later cropped or annotated those photos, I never saw the reduced resolution I just found in today's scanned diagram—because the photos had already been reduced to 72 dpi as Evernote captured them. Most of the time this hasn't been a problem for me. But because I'm often captured photos of product labels and the like, assuming that I could later zoom in as needed to read the fine print, I'm wondering now how much information I've failed to capture by not realizing that EN is saving those photos as much lower resolution than I thought it was—even if I've haven't cropped or annotated them.
This behavior strikes me as a bug. I expect Evernote to keep images I import at their original resolution, not to reduce them without warning. I expect that whether I'm scanning in an image, capturing it with my iPhone camera, or importing an existing image file. And it seems EN does do that (expect when using the EN iOS app to capture a picture), unless you then crop or annotate the image. Maybe this unexpected behavior is disclosed somewhere in the documentation, but if it is, then I've missed it. I can imagine why engineers might want to reduce all image resolutions to 72 dpi (to minimize storage requirements). But if this behavior is intentional on Evernote's part, it needs to be disclosed much more prominently to users—especially when cropping or annotating an image is about to cuts its stored resolution to ¼ of what it was, EN should put up an alert dialog asking if the user REALLY wants to do that...before it's too late.
Is this behavior a bug or a feature? If a bug, when can we expect a fix? If it's a feature, I strongly recommend warning users before reducing the resolution of an existing image (after annotating it), and making it clearer in the iOS app what size and resolution will be saved (the Camera preference (Small, Medium or Large) doesn't give enough information, because the size at which a photo is displayed in a note, and the resolution at which it's stored, are two separate parameters).
Running Evernote v6.6.1 on Mac OS X v10.11.3 on iMac (Retina 5K, 27-inch, Late 2015) with 2 additional 27" non-Retina iMacs as 2nd & 3rd displays, and the latest iOS version on an iPhone 6.
Idea
ponceby 1
Just discovered, to my dismay, that when I annotate a high-res image or photo saved in a note—whether adding text, or even just cropping it—Evernote reduces its size and resolution to 72 dpi without warning. Trouble-shooting revealed another disturbing surprise: the Evernote iOS app captures images at only 72 dpi, instead of using the iPhone's full, native high resolution. These surprises caused me real problems today, and make me worry what other images I thought I'd saved at hi-res in Evernote have had their resolutions reduced below what I need, without my knowledge.
This behavior strikes me as a bug that should be fixed. At minimum, if reducing image resolution is an intentional "feature", whenever an image is cropped or annotated, Evernote should warn the user before making it permanent. Evernote should also be more explicit about what resolution the iOS app will actually save when capturing photos with the iPhone camera.
More detail below...
=======================================
[UPDATE 1: OK, now I'm convinced it's a bug, or multiple bugs, but I'm more confused than ever. Since writing my original long post, I went back and rescanned this diagram as a photo, exactly as I'd done before. But this time EN behaved more or less as expected, even with annotations: it still changed the resolution from 300 dpi to 72 dpi, but this time kept the number of pixels at 3,267 x 2,533, and displayed in high-resolution both in EN and in Preview, even after adding a text annotation. Repeated the process several times, and maybe 4 out of 6 times it maintained the correct size through annotations. But at least twice it changed both the resolution and the pixel size as described in my original post.
The only difference I noticed in these multiple attempts related to the page orientation. The diagram is written in pencil on an 8-½ x 11 inch clipboard pad, in landscape orientation. The times when EN behaved correctly, and didn't resize the image, was when it brought it in in portrait orientation, and I had to rotate it counterclockwise just once. But the two times when EN resized the image after annotations were when it brought the image in upside-down, and I had to rotate it two times to get the correct orientation. Maybe that's just coincidental, or maybe it's related to the cause of the bug, but I'd have to do too much more testing to sort that out...
As a side note, I also noticed these times how much the size of the image file changed after any kind of annotation (rotation, adding text, etc.). The original scan at 300 dpi color came in about 500 KB. After doing just one 90-degree rotation—and nothing else—the file size increased to about 1.3 MB, despite EN reducing the image from 300 dpi to 72 dpi. After adding a two-word text annotation ("July 2012"), the file size increased more than a MB, to 2.4 MB. So my speculation that EN engineers might have been reducing the resolution to save on storage space seems completely unrelated.
Something seems VERY buggy—and completely unpredictable—with how EN is handling image annotations. Sometimes it reduces image size improperly, sometimes it doesn't. Maybe it's related to how many times the image is rotated, maybe it's not. In any event, the image file size shouldn't more than double every time any kind of annotation is made, even just a simple rotation.
FWIW...]
=======================================
I stumbled on this problem when adding a short text date to a diagram I'd scanned in as a 300 dpi photo using ScanSnap. I needed to scan it as a photo, because I needed the higher resolution to be able to read some of the small details in the diagram (my original scans as a default PDF were not sharp enough). But after adding the date annotation, when I went to zoom in on the image to see the details, they were gone! When I opened the image in Preview to check it out, it opened as a tiny little image, whereas it had previously been a full 8-½ x 11 inch page. Checking the image info in Preview, I saw that it was now a 608 x 785 pixel image, when it was originally 2,533 x 3,267 pixels. Both before & after images showed as 300 dpi. `
It took me a while, and much testing, to figure out what was going on. Eventually, I realized that the reduction in total image size was exactly the same as a reduction from 300 to 72 dpi (72 is 24% of 300, just as 608 is 24% of 2,533, and 785 is 24% of 3,267)—which explains why the annotated image on my screen appeared about ¼ the size it was originally. So, during annotation, Evernote reduced the image's resolution to 72 dpi, but left the image scale info at 300 dpi, causing Mac to now display it at ¼ its proper size. Even worse, because that higher resolution is now gone forever, trying to zoom in on the image or scale it up produces an unreadable, pixelated mess. Experimenting some more, I found that doing any kind of annotation produces the same result: adding a text or graphic annotation, or even just cropping the image, causes Evernote to scale it down to 72 dpi resolution. For a while, I thought it might be a problem with my 5K Retina system, with the Evernote app pinned to one of the non-Retina displays (a problem I've experienced with other apps), but experimentation seemed to rule that out.
This is the first time I've noticed this problem, even though I'm constantly adding images to EN, and frequently cropping &/or annotating them. But more often than not, I don't usually try to blow them up immediately after cropping or annotating, so I just may not have noticed the reduction in resolution before. Most often, I'm using the Evernote iOS app to capture photos of things directly to Evernote. I guess I'd always assumed Evernote was capturing them at full iPhone camera resolution. But looking back of my most recent captures, I see now that EN is bringing all those photos in at 72 dpi instead—what a surprise! But that explains why, when I later cropped or annotated those photos, I never saw the reduced resolution I just found in today's scanned diagram—because the photos had already been reduced to 72 dpi as Evernote captured them. Most of the time this hasn't been a problem for me. But because I'm often captured photos of product labels and the like, assuming that I could later zoom in as needed to read the fine print, I'm wondering now how much information I've failed to capture by not realizing that EN is saving those photos as much lower resolution than I thought it was—even if I've haven't cropped or annotated them.
This behavior strikes me as a bug. I expect Evernote to keep images I import at their original resolution, not to reduce them without warning. I expect that whether I'm scanning in an image, capturing it with my iPhone camera, or importing an existing image file. And it seems EN does do that (expect when using the EN iOS app to capture a picture), unless you then crop or annotate the image. Maybe this unexpected behavior is disclosed somewhere in the documentation, but if it is, then I've missed it. I can imagine why engineers might want to reduce all image resolutions to 72 dpi (to minimize storage requirements). But if this behavior is intentional on Evernote's part, it needs to be disclosed much more prominently to users—especially when cropping or annotating an image is about to cuts its stored resolution to ¼ of what it was, EN should put up an alert dialog asking if the user REALLY wants to do that...before it's too late.
Is this behavior a bug or a feature? If a bug, when can we expect a fix? If it's a feature, I strongly recommend warning users before reducing the resolution of an existing image (after annotating it), and making it clearer in the iOS app what size and resolution will be saved (the Camera preference (Small, Medium or Large) doesn't give enough information, because the size at which a photo is displayed in a note, and the resolution at which it's stored, are two separate parameters).
Running Evernote v6.6.1 on Mac OS X v10.11.3 on iMac (Retina 5K, 27-inch, Late 2015) with 2 additional 27" non-Retina iMacs as 2nd & 3rd displays, and the latest iOS version on an iPhone 6.
Link to comment
2 replies to this idea
Recommended Posts
Archived
This topic is now archived and is closed to further replies.