darktable-org / darktable-org/rawspeed
Probable overscanning of sony ILCE-7M4 APS-C cropped RAWs
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):
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)
Now the cropped ones:
in-body JPG for APS-C cropped image:
And the exact same picture straight out of darktable (same build):
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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