Does that signify anything? In this case I have a copy of the photo from Google Photos takeout (1.73 MB) as well as the original file from my phone (3.85 MB) and the file path of the Google Photos version is in bold.
I suspected that it might have signified the “best” version of the photo, but in that case, shouldn’t that be the one with the larger file size as it’s not compressed as heavily?
ImageMagick says that the quality of the original is 92, while the quality of the Google-ified version is 87.
IMO if I have two versions of the same image, one of which is more compressed, PhotoStructure should prefer the less compressed version. I could always just manually compress it if I wanted to, whereas I can’t “un-compress” the other version. I don’t know whether Google’s compression has resulted in small artifacts in the image so I’d prefer using my phone’s or camera’s original file.
I’m not a betting man, but if you look at those original images at 400%, I’d put $10 on you not being able to see any JPEG artifacts or reduction in image quality (typical JPEG compression artifacts include posterization and disjoint blocks in 8x8 pixel segments).
The heuristics to pick the “best” variant are a bit more nuanced: I want to pick up recent image edits, if there are any, but only if that edit is not on a substantively smaller-resolution image.
Compression rate and file size don’t actually correlate to more data or improved image quality. JPEGs can be saved at higher quality levels than the original image and then “win,” in other words.
(Ideally there would be some metric of “image quality” that I could just use directly in the sort criteria).
The thing is that I do see a difference on some photos (but not all). The colour sometimes seems slightly different between the two, too (maybe Google did some auto enhancements).
That makes sense.
In my case, I know I have two copies - the original (larger), and the Google Photos compressed version (smaller). I might just write a script to go through all the photos (using the PhotoStructure database) and delete the smaller version.
Yeah, Google’s auto-photo-enhance feature (esp. in the Google+ era) certainly did that. Which do you think are better; are you picking the google version, or the original?
(You saw the “list” tool, right? If you think up other tooling or args that would be nice, it’s super easy to add stuff there…)
OK, so it seems like your heuristics preferences are slightly different than the ones I implemented.
I just implemented a new variantSortCriteria library setting. The info tool in v0.9 exposes a fileSortCriteria field, and v1.0 renamed it to match the new setting (variantSortCriteria).
# +-----------------------+
# | variantSortCriteria |
# +-----------------------+
#
# How should PhotoStructure pick the "best" asset file variant for a given
# asset? You may reorder the default fields. Only "resolution", "fileSize",
# "mtime", "schemeIdx", "isCover", "count", and "isBrowserSupported" are
# understood: other field names will be ignored. If you change this value, you
# must "rebuild" your library, or at least "resync this asset" to apply the
# change one-off.
# (env: "PS_VARIANT_SORT_CRITERIA")
#
# variantSortCriteria = [
# "resolution",
# "mtime",
# "schemeIdx",
# "fileSize",
# "isCover",
# "count",
# "isBrowserSupported"
# ]