JPEG+RAW bundles

Sorry if I’m missing the obvious, but can anyone share and clarity on how JPEF+RAW bundles are handled? With the large number of camera that support these dual formats, it’s pretty common.

Are they treated as duplicates, or?

These should be aggregated into to a single Asset. Both files will be copied into your library if you’re using automatic organization, though.

See more here:

Also: if you find a JPEG+RAW pair doesn’t de-dupe properly in your library, please tell me: the current heuristics have required many iterations to get them to be robust, but I’m sure there are still cameras out there that may not dedupe properly. I actually had to iterate on this even between the current released version, v0.9.1, and the upcoming release: https://photostructure.com/about/2020-release-notes/#improved-image-hashing.

So… I know this is old, but I’ve now found a batch of JPG+RAW that are not de-duping.

I have lots that are working great, but these aren’t. Can send you a sample if that would help.

Please do: either via dm or email would be great.

@bdillahu I was able to check out the example pair you sent:

$ ./photostructure info '/home/mrm/Downloads/bd/2019-07-09T21.18.04_P1150141.jpg' '/home/mrm/Downloads/bd/2019-07-09T21.18.04_P1150141.rw2' 
 
{
  fileComparison: 'These files represent different assets: Different cameraId: SerialNumber:X151208100### != InternalSerialNumber:(X15) 2012:08:10 no. 0###',

(I’ve replaced the last numbers with ###s in the interest of privacy)

So: it looks like your camera manufacturer decided to encode your serial number using just InternalSerialNumber with the RW2, and both SerialNumber and InternalSerialNumber in the JPEG.

I hadn’t seen this before: pairs seem to either include both or neither.

To solve this, I’ll extract both, and test for both. This bugfix will be in v1.next (v1.0.1 or v1.1.0).

To let you know, this seems fixed in the latest build!