darktable-org / darktable-org/rawspeed

Probable overscanning of sony ILCE-7M4 APS-C cropped RAWs

Open
#520 13 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
456
Forks
147
PR merge metrics
No merged PRs in 30d

Description

Hello, I have noticed 100% of my APS-C cropped images getting out of darktable show lines of corrupted pixels on the right of the images (before rotation corrections)

I have found this interesting thread: https://www.dpreview.com/forums/thread/4637906
This seems to suggest that at least some generations of proprietary tools have struggled in a very similar fashion with this camera body, specifically with APS-C crops.

Visually it looks like we are simply overscaning the image beyond where there is actually information.

What's interesting is in any case we read more information than Sony presents in its in-body JPGs

Here is the in-body JPG for an uncropped picture (I disabled in-body lens distortion correction):

https://ibb.co/qxz5SvP

Same picture, out of darktable 4.4.2 built against rawspeed commit 2f1e3143875b7834322daa0b7bdbd5aec0ded932 (17 sept develop HEAD) (I went to the original step in the history stack to remove as much processing as possible)

https://ibb.co/128p7M5

Now the cropped ones:

in-body JPG for APS-C cropped image:

https://ibb.co/LQ9jtxL

And the exact same picture straight out of darktable (same build):

https://ibb.co/BgMpcYt

In all cases, we read much more data around the edges than Sony does, and in the APS-C crop format, we appear to be actively overscanning the right bound on the image (but are fine vertically)

One interesting note, using digikam quickly (libraw), I noticed they suffer from a similar overscan on both the cropped and uncropped file (rawspeed reads correctly uncropped files but libraw overscans them).

I was going to compare pixel counts on the in-body camera and the raw file exports, but I don't trust how different settings in the body might affect pixel counts on the in-body JPGs.

Here is the link to a google drive containing all versions including actual raw .ARW files:

https://drive.google.com/drive/folders/1sSbFRuQuxJi14ZYcVAzrMeM2At-hOtFV?usp=sharing

One even more interesting note is that the google drive preview for APS-C crops seems to suffer from the exact same symptom.
Maybe my camera is causing this at a very low level? But it would be extremely strange that the dpreview thread would outline the exact same issue.

If it's not an incorrect RAW decoding, might it be a commonplace firmware bug that nobody noticed before?

UPDATE: in case it ends up being relevant, I'm using firmware 2.00 from Sony

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the reported behavior with the Sony ILCE-7M4 ARW files in the linked Google Drive and compare rawspeed's output with the corresponding in-body JPGs. Done means determining whether APS-C cropped RAWs are overscanned on the right and documenting or correcting the decoder behavior so corrupted edge pixels are not included.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
reverse-engineering
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.