RAW: Show original media information in cards view details

[Rolf-Smit]

First of all, thanks for building such an amazing photo manager/viewer. So far I really love this. I would not mind spend some time on implementing this requested feature myself, but I do need some guidance (since I'm far from familiar with the code base).

Problem Sidecar clone information shown instead of original RAW information
When I first downloaded this tool, I was happy to read that this tool aims to provide one of the best RAW photo viewing experiences. Since my photo archive consists mostly out of RAW photo's this is exactly what I was looking for. My RAW photo's (originals if you will) are my main source of truth. So I added a few folders as a test and I was expecting PhotoPrism to create thumbnails for these RAWs as well as larger JPEG clone for viewing, and this is exactly what PhotoPrism is doing.

However PhotoPrism basically sees the cloned large JPEG (sidecar) as the main and primary image. This leads to a weird situation where:

1. Size information shown is from the Sidecar, not my actual RAW photo.
2. Resolution information shown is from the Sidecar, not my actual RAW photo.
3. When clicking on the camera details I see the cloned version first in the details view, but I'm actually interested more in the raw version.

This is all pretty counter intuitive, since I was expecting the Sidecar photo's to just be technical things to allow browser to display RAW photo's. But it seems to act more like those clones are suddenly what I as a user am actually browsing through, and while that is technically true, from a user perspective what I really would like to do is browse through my actual collection of photo's. That clones are needed to display them should just be a technical thing.

Solution: Show RAW information if available, instead of Sidecar information

I think multiple improvements can be made here, but they can be done in small steps, I personally believe a first nice step would be to:

Change the card details to (if available) use the information from the actual RAW photo, instead of the Sidecar photo that exists purely for viewing (and maybe downloading purposes if you need a quick JPEG copy).

I already started looking at some code and I believe only changes in the front-end are needed, more specifically:

Change getPhotoInfo() so that it checks if there is a RAW original in the Files, and if there is, use size and resolution information from the RAW instead of the cloned (and potentially smaller) copy.

photoprism/frontend/src/model/photo.js

Line 682 in 5add962

getPhotoInfo() {

As mentioned I'm more than happy to help, and make these changes myself. But I need some guidance. Let me know what you think and if this is an acceptable change.

Describe alternatives you've considered

Using the Library Files view, however this view:

• Does not show thumbnails for RAW photo's
• Does not show the same camera details for RAW photo's as is done in for example the Album view.
• Is basically not comparable to all other ways of viewing photo's, it seems to serve a whole other purpose.

I will create a separate feature request for improvements to the Library Files view.

[lastzero]

This is because PhotoPrism cannot read/decode RAW files directly (otherwise we would have to reinvent the wheel aka Darktable/RawTherapee).

Currently, when JPEGs are created from RAW files, they are assumed to have the same resolution. However, if for some reason this is not the case, you are correct and the resolution displayed is different from the actual resolution in the RAW file. If Exiftool provides RAW resolution details, you should find them in the Files tab of the Edit Photo dialog.

[Rolf-Smit]

Thanks for the quick response @lastzero. Maybe I didn't explain the situation well enough, I totally understand why we need a clone in JPEG format:

• To read information from
• To create thumbnails from
• To allow RAW photo's to be displayed
• To avoid reinventing the wheel

The resolution is in my case not the same (between the RAW and JPEG) because I configured it that way. The reasons for this is that creating a copy in the same resolution for my whole library would end-up costing hundreds of gigabytes (I calculated this after I found out this was happening in the first place, based on the average file size reduction from RAW to JPEG in full resolution).

So yes, resolution should normally be the same. But lets assume for a moment the resolution was the same, the size (in disk-size) will never be the same, so it will also be an issue for people that accept the full-resolution copies.

I'm not asking to reinvent the wheel, I'm just asking to use those JPEG clones where needed (to overcome technical limitations such as viewing a RAW in the browser), but to otherwise display the actual real data from the actual file in my own library (and not data from a technical copy). Or at least make this an option.

So to me this changes makes a lot of sense:

Change the card details to (if available) use the information from the actual RAW photo, instead of the Sidecar photo that exists purely for viewing (and maybe downloading purposes if you need a quick JPEG copy).

And with information I'm referring to information that will be different between the RAW and the JPEG by definition: resolution and disk size. All other information should be the same in the clone, and thus fine to show to the user directly from the JPEG.

I'm willing to help building something like this.

[Rolf-Smit]

Here are some screenshots, to better explain the inconsistency about the data displayed.

When clicking on the camera details in a card, I get to see a lot of info about my photo. This info is all correct compared to the original RAW photo, even the megapixel count (Resolution) is shown correctly:

But when browsing my photo's and looking at the card, not the RAW info is shown, but info about the cloned JPEG:

[lastzero]

Yes, that makes sense, since the front end actually displays JPEG files and not the original RAW file. Suppose you also created a B&W JPEG from a RAW image and used the mono filter, you would only see that version in the results with the resolution of the JPEG file (since the RAW and other JPEG versions may have color and many other properties that do not match your search filter).

[lastzero]

Another example would be if you were grouping by similarity or size and you had different JPEG versions (red, green, black, white, small, large, cropped). Either you will see only one version in the results or the other versions will be sorted incorrectly.

Ultimately, for your use case, you want a different kind of view/search that ignores related sidecar images and shows unique main media files only (displayed using the selected primary JPEG).

[lastzero]

The timeline view will do that, by the way. We just need to take care of a few other things before we get to that! See roadmap.

[Rolf-Smit]

Thanks for explaining. I think we just have a different vision on how that automatically created JPEG version of the RAW file should be treated.

I basically see 2 different copy types:

1. Self created: For self created edits (self created copies) of a certain photo, for example a B&W copy, it does indeed make sense to also display those and use the information from that file (since like you mentioned it can be quite different).
2. Automatically generated: A for technical reasons created copy of the RAW photo, because RAW photo's cannot otherwise be displayed or analyzed.

Most other photo managers I've used in the past left the for technical reasons created copies (type 2) away from the user, from the users perspective there is only the original file (and optionally self created Type 1 copies), but the thumbnails or bigger copies that where created for technical and performance reasons are not something the user usually sees.

From the perspective of PhotoPrism the automatically created copy (type 2) is basically treated in exactly the same way as type 1 (self made copies). It is not seen as just "technical" or "thumbnail", it an actual "new" photo. How I now understand it, that seems to be a design choice?

But this makes me think, what about a system wide setting to hide that "technical copy"? But still use it in the background for displaying purposes, analyzing purposes etc. So that from a users perspective there is only the original file and self created copies/edits?

[lastzero]

Thanks for explaining. I think we just have a different vision on how that automatically created JPEG version of the RAW file should be treated.

Multiple sidecar JPEGs can also be indexed, searched and displayed. This is not supported by every tool. For example, selecting the best shots right when the files arrive from the camera is a completely different use case. I would do that with Adobe tools designed for that. They mostly work as you describe/expect.

Note our work on PhotoPrism doesn't leave any time for taking/editing photos, so my experience as user of such tools is very limited lately :D

From the perspective of PhotoPrism the automatically created copy (type 2) is basically treated in exactly the same way as type 1 (self made copies). It is not seen as just "technical" or "thumbnail", it an actual "new" photo. How I now understand it, that seems to be a design choice?

Yes, that's partly because creating these JPEGs is very expensive in terms of CPU and memory. Also, you want to keep them for long-term preservation, since in 20 years there may not be any programs that can read the specific RAW formats.

So if you don't have full resolution JPEGs, your (complete) images are gone and you're left with a low resolution/low quality version.

Of course we can add (even more) configuration options and change the architecture, but for now it is designed that way and cannot be changed quickly.

[graciousgrey]

I just added this issue to the ideas on our roadmap. That's a totally valid use case and feature request. Just not a quick win :)

[Rolf-Smit]

Before I open another issue, would adding thumbnails/previews to RAW files in the Library file browser (based on Sidecar clones/copies) make any sense? Instead of showing a svg of a camera?

[graciousgrey]

The library section is meant to show single files. It is not meant to browse through your library. All other views show photos (that may consist out of multiple files). In case we would add preview images for raw/xmp/yaml files you would have the same thumbnail multiple times in a row. This might be confusing. Also with the svgs the user clearly sees what kind of file is in the library.

If you want a way to browse through your hierachical library this issue might be interesting for you #1536

[Rolf-Smit]

The library section is meant to show single files. It is not meant to browse through your library. All other views show photos (that may consist out of multiple files). In case we would add preview images for raw/xmp/yaml files you would have the same thumbnail multiple times in a row. This might be confusing. Also with the svgs the user clearly sees what kind of file is in the library.

personally I would just show previews for RAW files, but not for any meta data files such as xmp or yaml. Basically how most file browsers (Finder on Mac or Explorer on Windows) work.

If you want a way to browse through your hierachical library this issue might be interesting for you #1536

Thanks, that looks like a very useful feature indeed.

[Rolf-Smit]

@lastzero @graciousgrey

Today I happened to notice that for video files, the information shown in the cards is actually the original file information (the "raw video file") not the information from the Sidecar file. Basically how I would expect it to work as well for RAW/original image files.

So that leads to the following current behavior in PhotoPrism:

For "raw" video files:

• Cards show the size of the original file
• Cards show the resolution of the original file
• Cards use the thumbnail generated from the Sidecar file

For RAW image files:

• Cards show the size of the Sidecar file
• Cards show the resolution of the Sidecar file
• Cards use the thumbnail generated from the Sidecar file

[graciousgrey]

personally I would just show previews for RAW files, but not for any meta data files such as xmp or yaml. Basically how most file browsers (Finder on Mac or Explorer on Windows) work.

We could do it this way. But it should be an optional setting as for people with existing jpgs it will look like if there are many duplicates. Also we need to optimize this view performance wise. #1536 will probably be done first.

[graciousgrey]

@Rolf-Smit --> Previews for RAW files within Originals will be part of the next release: #2273

[lastzero]

@Rolf-Smit Sorry this didn't make it into yesterday's release! However, it is now implemented and can be tested with your development preview build (or by building the code in our preview branch).

[lastzero]

@graciousgrey @Rolf-Smit An updated preview build including these changes is now available for testing:

• Displaying details in the Cards View should work for all common file types, except if you sort by similarity, as the image content of RAWs cannot be analyzed (only the related JPEG can, which is why it is created in the first place).
• Animated images such as APNGs and GIFs should be thoroughly tested since they might be categorized as a live photo and not an animation. If this is the case, it is unrelated to this issue, but should still be fixed.

[lastzero]

Below is a screenshot of the camera lens details as well as the size and format of the original RAW files (instead of JPEG) being displayed in the search results:

[Rolf-Smit]

This is awesome! I tried it in the preview build already for the last couple of days and it seems to work as expected.