DNG output slightly cropped

I’m having a problem with output being cropped on the right side when using DNG compared to Sony ARW.

What I’m trying to achieve is to reduce the size of the RAW files from my new Sony A7RM3 because they are huge (especially compared to my trusty Canon EOS 400D that served me almost 13 years and counting ;-)).

I used the DNG converter in digiKam which reduced the size to half the size of original.

Next I applied the pp3 file used for processing ARW to the DNG. Lens Profile set to None. The result looks almost exactly the same, except the DNG file is slightly cropped on the right side when in the landscape orientation. I tried to change the “Border” setting in the “Demosaicing” tab to 0, but it has negligible effect. In fact, the output jpeg has the same height, but the width differs by 32 pixels (7956x5312 for ARW, 7924x5312 for DNG)

I’m still not sure whether this is a problem in RawTherapee, my settings or the DNG itself. So far I err on the side of this being a bug in RT, because I tried dcraw and while it’s output is slighly different (I’m assuming it’s applying some lens correction), it contains the data on the cropped border. I would be grateful for some pointers before reporting bugs anywhere.

I used current RawTherapee from git: 5.8-3049-gd053f0245

Attached are 100% crops from the top right corner. I can also provide the RAW files, but they are huge (~80 MB for ARW and ~40 MB for DNG).

RawTherapee neutral + some sharpening Sony ARW:

RawTherapee neutral + some sharpening DNG:

dcraw (same output for ARW and DNG):

Hello, why don’t you load your photo directly in RT and resize it from there?

Sorry, I should’ve been more specific. I’m not talking about size as in dimensions but as in file size.

Sony ARW files are little over 80 MB per file, while DNGs are around 40 MB per file. So for archival purposes I would prefer to store DNG files, assuming I can get identical output from them. Which I don’t at the moment. When processing DNG files I lose the little bit on the right.

OK, clear. What I notice when I convert a nef to dng in Digikam is that the horizontal dimension (not the vertical one), is 44 pixels smaller than the nef. I don’t see any crop though. This has to do, if I remember well, with pixel interpretation and rounding.

As a side note, this dng is only slightly smaller than my nef.

I understand that your camera can shoot in compressed raw. It will take up half the uncompressed raw and save you from converting to dng.
No solution for you?
Look at this:


For not knowing if the translators have translated well… I summarize:

Why don’t you shoot with compressed raw?

Because the camera compressed RAW uses lossy compression, while DNG is lossless.

Yes, only the new A1 and A7M4 have lossless ARW compression…

Can you please share the output of exiftool -a -u -s -g1 for the original ARW and converted DNG?

Here it is:
exifarw.txt (95.8 KB)
exifdng.txt (35.1 KB)

I see that there is a difference in ImageWidth – 8000 px for ARW and 7968 px for DNG. The 7968 seems more correct, because that is what I get from dcraw and is closer to the “uncropped” output I get from rawtherapee when processing ARW.

These are the interesting bits, for the ARW:

ImageWidth                      : 8000
ImageHeight                     : 5320
DefaultCropOrigin               : 8 8
DefaultCropSize                 : 7952 5304
SonyCropTopLeft                 : 0 8
SonyCropSize                    : 7952 5304

and for the DNG:

ImageWidth                      : 7968
ImageHeight                     : 5320
DefaultCropOrigin               : 8 8
DefaultCropSize                 : 7952 5304

It does indeed seem the DNG contains 32 pixels less on the side(s) and the crop might be different (e.g. different relative origin), so the DNG was not entirely “lossless” in that regard, although the output sizes are identical (7952x5304).

You could do one step better than dcraw: you could use rawpy to get to the uncropped raw pixel array (see raw_image()) to convince yourself where the offset is exactly.

1 Like

He has an R3, not an S3. The R3’s compressed raw is lossy.

Edit: Looks like someone else pointed that out.

As far as rawpy - on my TODO list is using rawpy to perform ARW->DNG conversion. I keep on procrastinating on that one…

Well, I think not even 7SM3 has lossless if we go by the official specs (although I did see it mentioned on the web; but again, no such samples on RPU). It does have the same processor as 1 and 7M4, so… future firmware upgrade maybe?

Interestingly, Adobe’s DNG converter seems to do a better job preserving the raw pixels:

ImageWidth                      : 8000
ImageHeight                     : 5320
DefaultCropOrigin               : 8 8
DefaultCropSize                 : 7952 5304

Please archive the original raw files and not DNGs. Disks are cheap!

You seem to be onto something. Maybe the DNG’s are not as lossy as I thought :-D. I’ll investigate using rawpy.

I don’t see any good reason to buy twice as much storage when I don’t need to. It’s just more unnecessary disks being made. Also, I’ll rather save that money for some nice lens or camera accessory. Also, DNG is standard, ARW is not.

You don’t really know what the DNG conversion is doing and often times it is a lossy operation. Sometimes the dng is already demoasiced. But if that is what you want to do, then go for it.

1 Like

I checked using rawpy and compared the raw_image of ARW and DNG. DNG file is really missing those 32 pixels on the right. Thank you for the help!

For the record, I’ve created a bug report at the KDE bugtracker: 444442 – Conversion from Sony ARW to DNG loses pixels on the right side of the image (what a nice bug number, I now wish I waited to get all fours :smiley: )

This is why I only convert my ARW files when I have a specific reason to - usually hdrmerge or some other multi-exposure combination approach. Too many risks of accidentally corrupting something - 95%+ of the time the metadata you lose is OK, but - not always.

That’s what bzipped tarballs are for if storage is THAT much of a problem. For me, stills on a rustspinner hasn’t been problematic. It’s my video that really takes up space.