File caching and image rotation

[ibgb]

This is several observations, issues, questions about file caching.

One thing I notice on Mac OS is that with sufficient RAM the system will do file caching. So this makes me wonder if I need photo mechanic/photo mechanic plus to do file caching. Right now I have set the preferences to 512 MB, and I like the OS do most of the file caching.  Q1) Why not?

The other thing that involves file caching is image rotation. I have lots of JPEG's from scanned slides, and of course there is no indication of their orientation. If I go through a directory and rotate the images in the contact sheet, then select them and to the lossless rotation, there is still the little rotation arrow in the upper left corner of the image in the contact sheet.

So for regular photo mechanic if I empty caches, quit and then come back in those rotation arrows are gone, and if I select the rotated images, there are none.  Q2) Maybe a note to empty caches, quit and return after the rotation is finished?

However, if I use photo mechanic plus and open up the directory in a new contact sheet I still see the rotation arrows, and the images in the contact sheet with the arrows can be selected. Of course this could be rather confusing when you're going through trying to orient the images correctly. So now I use only the regular photo mechanic for correctly orienting the images in the contact sheet. I would have thought that emptying the caches in quitting would've cleared out the rotation arrows, but maybe there is some interaction with the database or catalog index.  I also thought that opening up a new contacts sheet in either program would give similar results, but with rotation the context sheets are different.
Q3) Should they be the same?

latest PM/PM+, Mac os 10.14.6

[Kirk Baker]

This is several observations, issues, questions about file caching.

One thing I notice on Mac OS is that with sufficient RAM the system will do file caching. So this makes me wonder if I need photo mechanic/photo mechanic plus to do file caching. Right now I have set the preferences to 512 MB, and I like the OS do most of the file caching.

The disk cache in Photo Mechanic has nothing to do with the OS's unified disk cache.  The disk cache in PM is caching scaled representations of images that you're browsing.  Loading from that cache is much faster than hitting up the original image and decoding it/scaling it/etc.  We wouldn't offer it if it didn't improve performance.

The other thing that involves file caching is image rotation. I have lots of JPEG's from scanned slides, and of course there is no indication of their orientation. If I go through a directory and rotate the images in the contact sheet, then select them and do the lossless rotation, there is still the little rotation arrow in the upper left corner of the image in the contact sheet.

Sounds like a bug that we'll have to fix.

However, if I use photo mechanic plus and open up the directory in a new contact sheet I still see the rotation arrows, and the images in the contact sheet with the arrows can be selected. Of course this could be rather confusing when you're going through trying to orient the images correctly. So now I use only the regular photo mechanic for correctly orienting the images in the contact sheet. I would have thought that emptying the caches in quitting would've cleared out the rotation arrows, but maybe there is some interaction with the database or catalog index.  I also thought that opening up a new contacts sheet in either program would give similar results, but with rotation the context sheets are different.

The metadata change that affects PM6 (where it is ignored) is causing the Catalog to not be updated with the changed metadata.  Both issues will need to be fixed.

Thank you for reporting this to us.

-Kirk

[Kirk Baker]

I have fixed the problem and it should appear in the next build.

-Kirk

[ibgb]

Hello,

Another thing that I have noticed is that the PM rotation rewrites the width, height. It seems to reorient images differently than the exiftool.

When I look into an image, let's say with 5000 horizontal or width pixels, and 3000 vertical or height pixels, and then rotate the image 90 deg using PM, I wind up with an image that has usually no orientation parameter but the image will have 5000 vertical or height pixels and 3000 horizontal or width pixels. If I rotate the same image using the exiftool, then that would leave the horizontal and vertical number of pixels the same as the original image, but insert in orientation parameter, e.g. 90° CW. Wouldn't it be easier to just insert an exif orientation parameter?


I was looking at this because some of the images I rotated, and then I rotated again because they were not displayed as rotated or some bug/issue--they initially display in the preview.app incorrectly. These have the 5000 height pixels and 3000 horizontal pixels so they should display vertically, but they also have an orientation parameter of 270° clockwise. If I use the  exiftool to set the orientation parameter to one, or normal, then they display correctly, i.e. vertically.

[Kirk Baker]

Another thing that I have noticed is that the PM rotation rewrites the width, height. It seems to reorient images differently than the exiftool.

When I look into an image, let's say with 5000 horizontal or width pixels, and 3000 vertical or height pixels, and then rotate the image 90 deg using PM, I wind up with an image that has usually no orientation parameter but the image will have 5000 vertical or height pixels and 3000 horizontal or width pixels. If I rotate the same image using the exiftool, then that would leave the horizontal and vertical number of pixels the same as the original image, but insert in orientation parameter, e.g. 90° CW. Wouldn't it be easier to just insert an exif orientation parameter?

Which rotation operation are we talking about here?  If you do a hard rotation (Tools->Apply Rotation to JPEGs...) then the pixels are actually rotated, the width and height are swapped, and the orientation tag is reset to no rotation.  All programs capable of decoding and presenting a JPEG will display the image correctly, even if they are ignorant of the orientation tag.

Soft rotation (using the rotation arrows and not following up by a hard rotation) in Photo Mechanic only adjusts the orientation tag, and no image data is modified, nor are the width and height modified.

I was looking at this because some of the images I rotated, and then I rotated again because they were not displayed as rotated or some bug/issue--they initially display in the preview.app incorrectly. These have the 5000 height pixels and 3000 horizontal pixels so they should display vertically, but they also have an orientation parameter of 270° clockwise. If I use the  exiftool to set the orientation parameter to one, or normal, then they display correctly, i.e. vertically.

Sounds like given the data that the Preview.app was doing the right thing.

-Kirk

[ibgb]

I was doing a hard rotation, as that seemed to be the only way to come back into a directory and have the contact sheet display images in the correct orientation. If I just use the arrows, next time I open that directory the images display in their original non rotated contact sheet display.

"Soft rotation (using the rotation arrows and not following up by a hard rotation) in Photo Mechanic only adjusts the orientation tag, and no image data is modified, nor are the width and height modified."

With soft rotation PM doesn't write out an exif orientation tag in the original file, does it?

So many programs do not honor the exif orientation parameter? Is that why PM does re-write the pixels without using an exif orientation parameter?

[Kirk Baker]

I was doing a hard rotation, as that seemed to be the only way to come back into a directory and have the contact sheet display images in the correct orientation. If I just use the arrows, next time I open that directory the images display in their original non rotated contact sheet display.

"Soft rotation (using the rotation arrows and not following up by a hard rotation) in Photo Mechanic only adjusts the orientation tag, and no image data is modified, nor are the width and height modified."

With soft rotation PM doesn't write out an exif orientation tag in the original file, does it?

No.  PM will update the orientation tag if it exists.  If the tag doesn't exist then PM will update the orientation in memory only as there is no place to write the data.  Where did these images come from that they don't have an orientation tag already?

So many programs do not honor the exif orientation parameter? Is that why PM does re-write the pixels without using an exif orientation parameter?

Only if you use the "Apply Rotation to JPEGs..." feature will the image data be modified.

-Kirk

[ibgb]

"Where did these images come from that they don't have an orientation tag already?"

They are scanned slides, using VueScan to make JPGs. It does not write the tag. Maybe I should use exiftool and first add add an orientation tag, then PM it. Learn something new every day, if I am lucky. Thanks.