Phase One P25+ support

[kmilos]

Resolves darktable-org/darktable#16539

[LebedevRI]

@kmilos thank you!
Crop needed serious adjustment though, the usual "glitchy pixels at the edge thing" was visible.

[kmilos]

Crop needed serious adjustment though, the usual "glitchy pixels at the edge thing" was visible.

That's still unfortunate, this was not too far off (maybe 2px on each side) from the vendor embedded crop...

[LebedevRI]

By this, do you mean the one in your diff, or the correct one?
If former, ouch. If latter, i always round up to a full CFA and overcrop by one full CFA.

[kmilos]

The one in my original patch - vendor has 26,21 for top left, I started w/ 26,20 (tightest possible). So 26,22 or 28,22 should've worked in theory (w/ -12,-12 bottom right instead of my tight -10,-10)...

Could have something to do w/ native portrait readout of the sensor? Border artifacts still there if you bypass the orientation module?

Otherwise I guess we could still open a tracking issue for dt demosaic (or whatever module in the pipeline)?

[LebedevRI]

Could have something to do w/ native portrait readout of the sensor? Border artifacts still there if you bypass the orientation module?

At least here demosaic happens first, so that can't be it.

Otherwise I guess we could still open a tracking issue for dt demosaic (or whatever module in the pipeline)?

Since tighter crop fixes it, and rawprepare actually resizes the image and drops cropped-off pixels,
i don't really see how this could be a demosaicer bug...

[kmilos]

Since tighter crop fixes it, and rawprepare actually resizes the image and drops cropped-off pixels,
i don't really see how this could be a demosaicer bug...

And I don't really see why supplying all the valid pixels wouldn't work either, unless there is something funny going on w/ border processing somewhere... (E.g. related to stride, vector length etc.) @jenshannoschwalm again, sorry

[LebedevRI]

Since tighter crop fixes it, and rawprepare actually resizes the image and drops cropped-off pixels,
i don't really see how this could be a demosaicer bug...

And I don't really see why supplying all the valid pixels wouldn't work either, unless there is something funny going on w/ border processing somewhere...

But how do we know that all the pixels as specified by that vendor tag are the valid pixels?
Perhaps the tag is just wrong, or perhaps we are missing some custom "opcode" handling.

Since tighter crop fixes it, and rawprepare actually resizes the image and drops cropped-off pixels,
i don't really see how this could be a demosaicer bug...

And I don't really see why supplying all the valid pixels wouldn't work either, unless there is something funny going on w/ border processing somewhere... (E.g. related to stride, vector length etc.) @jenshannoschwalm again, sorry

But again, if there was a bug, i don't really see why tightening the crop would magically fix it.
(rawprepare actually does crop the buffer, unless it no longer doesn't)

[kmilos]

But how do we know that all the pixels as specified by that vendor tag are the valid pixels?

Dump from rstest or LibRaw's unprocessed_raw, inspect w/ some contrast stretch/histogram equalisation. I.e. bypass rawprepare and demosaic in dt itself.

i don't really see why tightening the crop would magically fix it.
(rawprepare actually does crop the buffer, unless it no longer doesn't)

As mentioned, changes stride?

[LebedevRI]

i don't really see why tightening the crop would magically fix it.
(rawprepare actually does crop the buffer, unless it no longer doesn't)

As mentioned, changes stride?

In all 8 demosaic algos, including passthrough?

[kmilos]

In all 8 demosaic algos, including passthrough?

Could also be elsewhere in the pipeline as I said, not necessarily demosaic... Some underlying tiling/LOD logic?

Anyhow, just find it weird this keeps popping back.

If you're happy w/ the workaround of tweaking the crop, we'll just keep doing that.

[jenshannoschwalm]

I will have a close look after this has landed in dt master.