Fix eos imageformat #1031
Fix eos imageformat #1031
Conversation
We use hex format for the same information in other parts of the log file.
This brings my original ptp_unpack_EOS_ImageFormat() documentation up-to-date with new M1/M2 and new 0/1 compression info added with 5Ds, 1DXm2 and R5m2. It also fixes the problem that led to a double entry of e.g. `RAW` in the imageformat config output visible in gphoto#1028 and also in the 1DX sample here: https://github.com/gphoto/libgphoto2/blob/5b7f7c168dd3e86f43b590a7456883e1dec11709/camlibs/ptp2/cameras/canon-eos-1dx.txt#L255-L269
The current `imageformat` with it's table lookup for every RAW+JPEG combination became cumbersome to maintain and outdated. This leads to e.g. lost of unsupported JPEG variants for e.g. the 5Ds, R5m2, 1DX. The used naming also became inconsistent with the addition of the 1DXm2 labels in gphoto@1402f88 This patch adds an (incompatible) new imageformat2 widget as a temporary test to then hopefully replace the existing imageformat. I expect this new implementation to fix all "Unknown value" occurrences of all currently available EOS cameras. I chose to do away with the verbose and arbitrary labels like "Smaller Fine JPEG" and instead tried to mimic the strings that are actually used by the cameras, like 'S2', etc. I added a 'c' for the higher compression versions, along the lines of 'cRAW'. The 'c' could also stand for 'coarse' to describe the blocky curve that is used by the Canons to distinguish between lower and higher Jpeg quality. Here is some sample output from the 5Ds: Choice: 5 cM2 Choice: 6 S1 Choice: 7 cS1 Choice: 8 S2 Choice: 9 S3 Choice: 10 RAW + L Choice: 11 RAW + cL Choice: 12 RAW + M1 Choice: 13 RAW + cM1
|
@msmeissn Thanks for merging this. Do you have an opinion on the idea of replacing |
I think we can do that. I am currently not aware of tooling parsing these directly. |
|
I wouldn't like having abbreviated settings since it makes it difficult to understand what is what. |
I understand your sentiment but my point is that those new labels are in fact not abbreviations of existing settings but rather, the old ones are "invented" terms that did not faithfully mirror the actual settings on the devices. I did a little digging in my memory and the commit history and found that I originally named them like this: "L/Fine" when I implemented the Bottom line: today I think my intention to have those verbose names consistent with other settings failed and might have been doomed to do so, e.g. other settings added later are similar but then still inconsistent (see We could argue over whether |
|
Thanks for going down the memory lane with me, much appreciated. Looking at it from the client-side perspective, making these options/values vendor-specific, forces each developer to create the same spaghetti code for a generic way of accessing them programatically. Why not unify them across the drivers and document the chosen format? |
As I elaborated above, that was exactly my intention 10 years ago but now came to the conclusion that this effort failed and never had a chance. Thy are already vendor specific in two aspects:
I could imagine a kind of "meta" widget that contains a generic subset of sizes and basically contains the "spagetti" code that maps those generic terms to vendor specific ones. Do you have a suggestion how this basic and generic set of formats/sizes could look like? |
TLDR: new
imageformat2widget to later replace current one with consistent and complete support for all formats on all EOS cameras. Details, see commit messages. Example from my 5Ds:Instead of :
@ben5516 and @karlkopf, could you test if
gphoto2 --get-config imageformat2produces something meaningful with your 1DXm2 / 1DXm3 / R5m2 cameras?