-
Notifications
You must be signed in to change notification settings - Fork 122
First revision of Panasonic RW2 version 8 Decompressor #790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
917b1b6
abbcb37
be38909
bdff0f0
f9441ee
3c87e16
5f2e74c
0a63255
cb25e4b
e3518cf
8725ab5
9f25f5f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -71,7 +71,7 @@ BitStreamerReplenisherBase<Tag>::establishClassInvariants() const noexcept { | |
} | ||
|
||
template <typename Tag> | ||
struct BitStreamerForwardSequentialReplenisher final | ||
struct BitStreamerForwardSequentialReplenisher | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Had to remove |
||
: public BitStreamerReplenisherBase<Tag> { | ||
using Base = BitStreamerReplenisherBase<Tag>; | ||
using Traits = BitStreamerTraits<Tag>; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -31,6 +31,7 @@ | |
#include "decompressors/PanasonicV5Decompressor.h" | ||
#include "decompressors/PanasonicV6Decompressor.h" | ||
#include "decompressors/PanasonicV7Decompressor.h" | ||
#include "decompressors/PanasonicV8Decompressor.h" | ||
#include "decompressors/UncompressedDecompressor.h" | ||
#include "io/Buffer.h" | ||
#include "io/ByteStream.h" | ||
|
@@ -170,6 +171,16 @@ RawImage Rw2Decoder::decodeRawInternal() { | |
v7.decompress(); | ||
return mRaw; | ||
} | ||
case 8: { | ||
// Most use bps=16, S9 uses bps=12 | ||
if (bitsPerSample != 16 && bitsPerSample != 12) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll probably remove this check. The BPS for V8 files seems to vary a lot, but should all decode fine. |
||
ThrowRDE("Version %i: unexpected bits per sample: %i", version, | ||
bitsPerSample); | ||
PanasonicV8Decompressor v8(mFile, mRaw, *raw); | ||
mRaw->createData(); | ||
v8.decompress(); | ||
return mRaw; | ||
} | ||
default: | ||
ThrowRDE("Version %i is unsupported", version); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More work on crop modes probably needs to be done. RW2 V8 cameras don't seem to crop into raw images the way the old Panasonic cameras did.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, only the older ones seem to actually crop the raw... I'm hoping it'll work out the same as v7, so I just have the "native" sensor crop/aspect in cameras.xml for now. (We never supported the "soft" crop anyway...)
I should be able to help w/ testing this a bit later. We'll need check any other non-standard modes though like high-res etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are your concerns w.r.t high-res mode? I've tested on plenty of high-res shots and not seen any apparent issues.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typically if we have a manual crop value other than (0,0,0,0) in cameras.xml for native mode it might not apply (i.e. crop too much or too little) in high-res mode for some other brands or codec (i.e. sensor and processor) versions... It'll just have to be checked out, that's all... Same for any other sensor readout modes like burst, live composite, multi-exposure etc. (present in earlier models like the S5, don't know if they are also in newer ones).
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My (very) cursory crop tests so far, using LibRaw's
unprocessed_raw
dumps for "native" mode samples only:GH6: (0,0,0,0)
S5M2: (0,0,0,0)
S5M2X: (0,0,0,0)
G9M2: (0,0,0,0)
S9: (0,0,0,0)
GH7: (0,0,0,0)
S1RM2: (0,0,0,0)
These are w.r.t. sizes in e.g. these tags as reported by
exiftool -a -u -s -G1 -H
:Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw, if you're excluding the
<Crop x="0" y="0" width="0" height="0"/>
like you have here, one should be getting the crop from vendor metadata tags (0x0004 SensorTopBorder
,0x0005 SensorLeftBorder
,0x0006 SensorBottomBorder
,0x0007 SensorRightBorder
), so somewhat smaller than the full sensor...Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still not sure I'm following you, but happy to make any code changes needed.
Is this not covered byAre you suggesting that a further crop, on top of the sensor crop, may be necessary for files produced by the other modes?Rw2Decoder::getDefaultCrop()
? That seems to be checking the appropriate tags.Edit: On second look,
Rw2Decoder::getDefaultCrop()
doesn't seem to be called anywhere. CallingmRaw->subFrame(getDefaultCrop());
before returning the raw fromRw2Decoder::decodeRawInternal()
seems to correctly apply the crop. @kmilos Would you like me to push this change, or did you have something else in mind?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This basically boils down to the choice between the vendor crop from metadata, or manual crop values from cameras.xml. Traditionally RawSpeed had a design goal mentioned on the landing page: "RawSpeed does NOT crop the image to the same sizes as manufactures, but supplies biggest possible images." This was foregone for some vendors/models, as it was becoming unwieldy to check, list and handle explicitly all possible modes via cameras.xml.
For the time being, I suggest to implement it like in the v5/v6 decoder: only call
getDefaultCrop()
if<Crop/>
was not present and restore<Crop x="0" y="0" width="0" height="0"/>
in cameras.xml v8 model entries as those seem to be "well behaved" so far...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see. I can add that. Using zero crop on the images I've looked at does reveal some smeary pixels at the edges of the frame. I don't think it is an issue, but want to point it out in-case that biggest image design sentiment has changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!
Let's check it out more closely for all models during this review and then either adjust the manual
<Crop/>
accordingly, or simply drop it for some/all v8 finally.