Support Panasonic RW2 v7 formats #412
Conversation
Codecov ReportBase: 59.02% // Head: 58.56% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## develop #412 +/- ##
===========================================
- Coverage 59.02% 58.56% -0.47%
===========================================
Files 221 223 +2
Lines 13354 13459 +105
Branches 1845 1851 +6
===========================================
Hits 7882 7882
- Misses 5331 5436 +105
Partials 141 141
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
|
You ported our (LibRaw) code, please don't forget to mention it in copyright section |
GH5M2 (darktable-org/darktable#9370) is actually v6, but w/ just 14b mode, while only 12b is currently implemented by rawspeed. GH5S is a v5 where dual 12b/14b is already supported. |
|
@LibRaw No worries. I can't take credit for reverse engineering that decodes the block. Feel free to use the readability improvements. @kmilos You're right about the GH5M2, but I think it needs 12 bit support not 14 bit. I was thinking about tackling that issue as well since I have some extra free time. I don't own that camera, but I can test some samples and make sure my S5's files don't break. I thought there was a G* series camera that used the v7, but I think I'm mistaken. GH6 uses a new v8 format. |
jdneumeyer77
changed the title
|
@jdneumeyer77 This format is so simple that no reverse engineering was needed, just accurate look into RAW data. |
Does LGPL really require the |
|
I have not asked about this specific form, just about 'mentioning' |
|
I was just following existing conventions. v6, which looks to be ported as well, had the Good to know that's a simple format. I'm not familiar bayer sensor data. So I wouldn't know. I don't typically work with binary formats nor C++. I'll have to dig into it sometime to better understand what it is doing. Edit: Ok I think I understand it clearer. now. Sensor data before this step is 14/12 bit pixels written out in big endian. It's read as byte chunks. In order to convert it the next 14/12 bits read and converted into little endian which is stored it in the next largest type size (2 bytes ushort). |
It's quite possible that I mixed them up. In any case, one of the two is missing for V6. |
|
@jdneumeyer77 so i'm finally looking into this, and i'm a bit troubled More importantly, in the original comment you wrote:
... but there is only a single (High resolution (sensor shift) mode 96 MP) affected sample. |
|
@LebedevRI this is for several cameras. I believe S1 and S1H have the same features and use this format. The S1R uses a different sensor, but I think it uses this format as well for hi-res/live composite/etc.. I'm not sure if Gx series series uses this format for building images like hi-res mode. I'll upload samples for live composite and multiple-exposure from my camera. I'll check if I can open hi-res samples from the S1/S1H/S1R to verify those as well. It's been working great for my camera the last couple weeks. |
At a bare minimum, that is indeed what i would like to see (on RPU) before merging this. It would be really good to have appropriate samples from other affected cameras. |
|
@LebedevRI Ok. I've added two quick samples for live composite and multiple-exposure modes. They aren't much larger than normal raw files. This issue indicates someone uploaded a high res sample for S1R. The sample doesn't appear on RPU. I did manually check if it's v7 format and it is with a sample I found elsewhere. It works locally. Same with a hi-res sample of the S1. No samples available, but I found a sample raw elsewhere. It also works.
This PR includes support for both 12 bit and 14 bit. A comment from Libraw source code says they've not encountered a 12 bit file in this format yet. |
Thanks you, that'll do.
My point is that it's dead code if we don't have any evidence any such raws were ever produced. |
I'm waiting for GH5M2 support which uses 12bit according to some comments. Not sure if this is in the scope or where GH5M2 support is tracked. There's only one other issue here mentioning this camera: #367 and one for darktable: darktable-org/darktable#9370 @LebedevRI can you look at this too or does it make sense to create a separate issue? |
|
As #367 mentions, that camera produces yet another format, v8, this adds support for v7. |
GH5M2 is v6, GH6 is v8... |
|
@pgassmann GH5M2 uses v6 with 12 bit. I don't own the camera, but once I get time I can port that code over as well in a separate PR. @LebedevRI I'm all for removing dead code, but it seems like Panasonic added 12 bit later for v6. Not sure if it was a similar case where there weren't any cameras that produced v6 12 bit at the time, so the support was excluded/ripped out. Also I tried a few other tests such as using electronic shutter (ec) or ec + noise reduction with hi-res mode to see if they produced 12 bit. I know some manufactures bin to 12 bit using electronic shutter mode. Still produced 14 bit raws. So at least with my camera I can't produce 12 bit. I'll ask a friend to test and provide examples from S1R in different modes like multiple-exposure and using ec. |
|
Thanks! |
|
@jdneumeyer77 thank you! This should not have taken this long. |
Thank you. How much time does it take to port that code over? Is it worth a speparate issue to track this in rawspeed or is darktable-org/darktable#9370 enough? That one is currently assigned to @LebedevRI |
Support 12 and 14bit V7 RW2 raw format.
I tested various files from my Panasonic S5 in various modes that produce this format:
I ported some code from Libraw. Plus, I cleaned it up a bit to make the bit manipulation easier to understand and came up with an easy way to support both 12 bit and 14 bit. My camera produces only 14 bit. Even Libraw mentions having never seen 12 bit in the wild.
This should address: darktable-org/darktable#8338 darktable-org/darktable#9768 #246 . It might fix others as well.
I believe there are already samples available. I mimicked the existing fuzzers, but I'm not sure how they work. Nor am I sure of other automated tests that could be enabled. Happy to add those.