Phase One Quadrant Correction Continuation

[dim162]

In Darktable, darkroom, the phaseone IIQL from the p65+ is cut in 4 equal rectangles with different slight tint & luminosity, the exports too. I don't have the problem with Capture One & Rawtherapee. The problem exist within Dt 2.7 & 2.6.2, in ubuntu studio 18.04, 18.10, 19.04. I put the raw in a dropbox folder. < https://www.dropbox.com/sh/lahqwwd8aahmzb2/AABOqKXcWTIXgCC0YR45cEAza?dl=0 >

[LebedevRI]

Yep, still happens in dt master / rs develop. In essence this is continuation of #118. Please can you contribute that CF028114.iiq to RPU ?

[dim162]

RPU? Sorry, I'm not aware. Use the CF028114.iiq as you wish, it is at least the minimum that I can do. I made a noise and a color profile.

[LebedevRI]

Sorry, should have just posted the link - https://raw.pixls.us/

[dim162]

Ha! Ok. I posted a full set the 2018-09-21, not the CF028114.iiq which shows clearly the problem. If you need specific image, i can do it.

[LebedevRI]

Yes, please upload that single image to RPU. I'm not sure any of the existing samples show this issue, so it will be good to have one.

[dim162]

It's done.

[LebedevRI]

Yep, thanks!

[dim162]

I'm impatient! The result with Darktable 3.0 + Gimp 2.10.14 under Ubuntu studio, are so impressive, i can forget the software & just do my stuff

[LebedevRI]

So i've took a look, and there is a lot of Phase One-specific corrections not being done for that file:

• RawSpeed:correction 0x402 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x404 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x405 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x406 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x407 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x408 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x40b unimplemented - in dcraw, Red+blue flat field
• RawSpeed:correction 0x410 unimplemented - in dcraw, All-color flat fields
• RawSpeed:correction 0x413 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x41a unimplemented - in dcraw, whole image Polynomial curve
• RawSpeed:correction 0x41c unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x41e unimplemented - in dcraw, Quadrant multipliers
• RawSpeed:correction 0x41f unimplemented - in dcraw, Quadrant linearization
• RawSpeed:correction 0x420 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x421 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x422 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x423 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x424 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x425 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x426 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x427 unimplemented - unknown, not in dcraw
• RawSpeed:correction 0x428 unimplemented - unknown, not in dcraw

But even then, if one tries to convert that raw via dcraw itself, all that quadrant-ness is still there, meaning in this case it's one of the unknown corrections.

[dim162]

I tried with rawdigger/fastrawviewer (win10) & ufraw, rawtherapee (ubuntu studio), i can't see the pattern.

[LebedevRI]

Thanks for checking, that is an interesting data point.

[dim162]

It took me sometimes & now i'm sure at 98%, the quadrant appears when i shoot on card (Lexar, Sandisk, Fuji all 5 different cards) & not when i tethered the Ph1 645DF/P65+ through capture1 (Win10 & Macosx).

[dim162]

I was too confident, the problem stay the same tethered or not. Sorry. Dt 3 is incredible

[dim162]

Is there a problem to solve the bug?

[esox13]

As far as I know, I'm also a P65+ user, the sensor of this digital back is made of 4 smaller sensors, I suppose Capture One correct this. But Also Lightroom and any other raw editing software.

[dim162]

Is it possible to switch to libraw, instead of rawspeed?

[cytrinox]

I've tested this with rawtherapee, I see the same "cross" as in you example. Even with a manual build of current libraw master, the resulting TIFF is not corrected. Do you have any open-source tool/library where you can reproduce an output that is really corrected?

[dim162]

I've tried with rawtherapee/Art & another QII, i don't have the "cross", even with the first IIQ. I put the new set in dropbox https://www.dropbox.com/sh/lahqwwd8aahmzb2/AABOqKXcWTIXgCC0YR45cEAza?dl=0.

Le jeu. 3 mars 2022 à 18:19, Daniel Vogelbacher @.***> a écrit :

I've tested this with rawtherapee, I see the same "cross" as in you example. Even with a manual build of current libraw master, the resulting TIFF is not corrected. Do you have any open-source tool/library where you can reproduce an output that is really corrected?

— Reply to this email directly, view it on GitHub https://github.com/darktable-org/rawspeed/issues/207#issuecomment-1058287842, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACP3YAE3SJB764XKLWL4EQ3U6DYD3ANCNFSM4JLYB5QA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[dim162]

As the bug is not corrected in Rawspeed, is it possible to support the PhaseOne P65+ digital back, through LibRaw?

[cytrinox]

@dim162 Quadrant Correction is implemented in https://github.com/dnglab/dnglab, maybe this is an alternative workflow for you.

[dim162]

Thank you! It is an alternative, but it doubles the space kept by images. I hope that a solution will be integrated inside Dt