This is down to a bug in the code that identifies the image - it seems that when a JPEG is rotated using the EXIF information rather than actually rotating the pixels, it returns the wrong width and height - and so instead of scaling it to 450 wide it goes smaller. Unfortunately fixing this is tricky as the problem is with the underlying tools not the Voice code.
However, the CMS stores a few different variations of the image size - and so I've now changed the custom includelet to use a larger version. This is good as it'll make the image look good on high res screens. (it's still affected by this same bug, but should generally look much better!)
There's actually a "trick" to insert the original image into a page, which you can learn about here.
I had also been considering whether Voice should always serve up a larger version of images - the 450 pixel width is a bit of a throwback to when screens were smaller and bandwidth was lower. Maybe we should always be serving up images 1000 or so wide, and letting the responsive HTML display it nicely.
Let me know what you think!
Cheers
Joe
Thanks, Joe, that seems to have fixed it.
I use Faststone for image viewing and basic primping such as cropping, but I think that at any point when saving the image, Faststone sorts out the EXIF information, so once saved, a portrait image behaved properly, whereas an original image from the camera stumbled over the bug and lost resolution.
Cheers,
Norman