[V2] Optional full image processing in darkroom

[TurboGit]

New version on top of #15893 which fixes the snapshots & duplicates when changing the full image processing mode.

[jenshannoschwalm]

Perfect.

[elstoc]

I'm not sure about calling it "export view scaling" - it feels like a description of "why you might use it" rather than "what it is"? I can see the intention but I guess I might go for something that emphasises that we're processing the whole image (which incidentally will look just like a full export) and makes clear any performance implications. I haven't thought of anything decent yet but just wanted to throw it out there for consideration.

[jenshannoschwalm]

I would be happy with any better naming being not technical. I guess only a few users understand the implications of roi concept.

"High quality processing" as we have in export?

[TurboGit]

@jenshannoschwalm

"High quality processing" as we have in export?

Works for me.

As we are at it, would it makes sense to use this new dev support for the export high quality processing? Or does it something different?

[jenshannoschwalm]

As we are at it, would it makes sense to use this new dev support for the export high quality processing?

The button is only visible in darkroom and as this implies a significant-to-huge amount of processing we should leave it that way. Or are you thinking about the export pipe?

Or does it something different?

No. Same processing way. But for export we have a different roi_out and might upscale.

Three more points. We haven't yet made up our mind about

1. "How" do we scale for output? Should we scale while still being in linear space? I experimented with scaling done as pre-down-scale before sigmoid/filmic and also before colorout (my initial draft pr on this topic) with certainly different results. Not sure what is the best way color-maths wise.
2. We thought about some additional post-scale sharpening.
3. Not fully sure about fast pipe mode.

Those might require further changes so i would suggest to merge this rather soon as is represents the current pipeline processing and we might get more precise feedback on "what happens to my colors". For me the new thing is not only about inspecting export output but also about what might be bad processing design in the current pixelpipe.

[jenshannoschwalm]

@TurboGit tested this right now in-depth. Unfortunately it doesn't fix: we want to compare a snapshot taken without full processing vs "current state" meaning you just switched it on. Use -d pipe to watch for either downscaling in demosaic or finalscale.

Wouldn't this be right? (We see the displacement though ...)

diff --git a/src/iop/finalscale.c b/src/iop/finalscale.c
index a1a99b2746..abcfd070d1 100644
--- a/src/iop/finalscale.c
+++ b/src/iop/finalscale.c
@@ -58,12 +58,12 @@ dt_iop_colorspace_type_t default_colorspace(dt_iop_module_t *self,
   return IOP_CS_RGB;
 }
 
-static inline gboolean _gui_fullpipe(dt_dev_pixelpipe_iop_t *piece)
+static inline gboolean _gui_fullpipe(dt_dev_pixelpipe_iop_t *piece, dt_iop_module_t *self)
 {
   return piece->pipe->type & (DT_DEV_PIXELPIPE_FULL
                               | DT_DEV_PIXELPIPE_PREVIEW2
                               | DT_DEV_PIXELPIPE_IMAGE)
-    && darktable.develop->late_scaling.enabled;
+    && self->dev->late_scaling.enabled;
 }
 
 void modify_roi_in(dt_iop_module_t *self,
@@ -100,7 +100,7 @@ void modify_roi_in(dt_iop_module_t *self,
                                piece->buf_in.height));
   roi_in->scale = 1.0f;
 
-  if(_gui_fullpipe(piece))
+  if(_gui_fullpipe(piece, self))
   {
     roi_in->x = 0;
     roi_in->y = 0;
@@ -188,7 +188,7 @@ void commit_params(dt_iop_module_t *self,
                    dt_dev_pixelpipe_iop_t *piece)
 {
   piece->enabled = piece->pipe->type == DT_DEV_PIXELPIPE_EXPORT
-                  || _gui_fullpipe(piece);
+                  || _gui_fullpipe(piece, self);
 }
 
 void init_pipe(dt_iop_module_t *self,

[TurboGit]

we want to compare a snapshot taken without full processing vs "current state" meaning you just switched it on

I'm not sure. I want to compare snapshot vs current dev in the exact same mode so with or without full image processing for both. It makes no sense to me to compare otherwise, that's like ISO 12646 mode to me, we have it for the snapshot and the dev at the same time. Don't you agree? Did I missed some use case?

EDIT: Another way to say it, this mode is not a develop step so not part of the snapshot history.

[jenshannoschwalm]

Maybe we misunderstand here.

As @s7habo pointed out, it might be nice to do a snapshot without full data, switch full mode on and see the difference while moving the snap-line around. The patch would make this working.

Personally I don't care that much, my patch might even make the snap tool more confusing.

So probably let's go with what we have....

[TurboGit]

Personally I don't care that much, my patch might even make the snap tool more confusing.

Yes, that's my fear too as now for every history step we could have two versions.

To me the way to compare with and without the full image processing is by enabling / disabling the mode by clicking on the new button.

So yes, let's settle with what we have.

As a side note I plan starting merging the 4.8 work on master the coming week-end or next week.

[TurboGit]

"High quality processing" as we have in export?

Yes, I'll change the label.

[jenshannoschwalm]

Go ahead :-)

[TurboGit]

Merging now :)

[jenshannoschwalm]

Release note:

Implemented a toggle switch for the darkroom mode forcing the pixelpipe processing to use the whole image data instead of just the area displayed. This allows the user to inspect processed data without errors introduced via internal scaling and equals what we get by exporting in "high quality resampling" mode.