A7RIII pixel shift and RT

Unfortunatelly, Sony does a lot (digital scaling - interpolated PDAF pixels) to interfere with RT’s ability to detect motion :frowning: … at least this is the case with non-pixelshift files … lets hope things are better on pixelshift …

Well, let’s hope. Without motion correction, pixel shift will lose a lot of effectiveness in landscape work. Anyway, thanks for looking into this. Let me know if there’s anything else I can do to help.

@ron please see:

We’re still missing the ARQ file.

The file is manually copied from card/camera, without using any software like Nikon Transfer, and hasn’t been modified in any way.

While that requirement cannot be met for this type of file, I think it would be beneficial to have it nevertheless.

Hi,

The ARQ file is in filebin with the 4 source images and also a TIFF:

https://filebin.net/ab6mn0uztsyvpohy

@ron yes, but you need to agree to the terms on the RPU site.

@agriggio made great progress decoding arq files and making the 4 frames in an arq file accessible in rt :fireworks:
Next step is to bring this frames in the correct order to pixel shift combine them correctly. That’s my part…

1 Like

OK, I’ve uploaded the ARQ file to RPU as well, and I checked the checkboxes.

Thank you!

Again @agriggio was faster :slight_smile:

Here are some screenshots:
Left is amaze, right is pixel shift

Even motion correction works (though based on wrong constants)
Left is amaze, right is pixel shift without motion correction

Left is pixel shift without motion correction, right is pixel shift with motion correction

2 Likes

So, just to complete, here’s a patch for dcraw (v9.27) to do ARQ pixel shift (without any motion correction though):

diff --git a/dcraw.c b/dcraw.c
--- a/dcraw.c
+++ b/dcraw.c
@@ -2743,6 +2743,26 @@
   free (data);
 }
 
+
+void CLASS sony_arq_load_raw()
+{
+  int row, col, bits=0;
+  ushort samples[4];
+
+  while (1 << ++bits < maximum);
+  for (row=0; row < raw_height; row++) {
+    for (col=0; col < raw_width; col++) {
+      int c = col + ((shot_select >> 1) & 1);
+      int idx = row * iwidth + col;
+      read_shorts(samples, 4);
+      image[idx][0] = samples[0];
+      image[idx][1] = (ushort)((((float)samples[1]) + ((float)samples[2])) * 0.5f);
+      image[idx][2] = samples[3];
+    }
+  }
+}
+
+
 void CLASS samsung_load_raw()
 {
   int row, col, c, i, dir, op[4], len[4];
@@ -6272,6 +6292,17 @@
 		   if (!strncmp(make,"OLYMPUS",7) &&
 			tiff_ifd[raw].bytes*7 > raw_width*raw_height)
 		     load_raw = &CLASS olympus_load_raw;
+                   if (!strncmp(make,"SONY",4) &&
+                       !strncmp(model,"ILCE-7RM3",9) &&
+                       tiff_samples == 4 &&
+                       tiff_ifd[raw].bytes == raw_width*raw_height*tiff_samples*2) {
+                       load_raw = &CLASS sony_arq_load_raw;
+                       colors = 3;
+                       is_raw = 1;
+                       filters = 0;
+                       iwidth = raw_width;
+                       iheight = raw_height;
+                   }
 	}
 	break;
       case 6:  case 7:  case 99:

Here’s a 1:1 crop, compared to Sony:

Sony

Dcraw

It’s obvious that Sony’s software applies (quite a bit of) sharpening (deconvolution?) to extract that level of detail. Here’s for instance how we can improve on dcraw’s result with Imagemagick (using convert -sharpen 0x2.5):

1 Like

…and of course, with RT we can even go overboard :stuck_out_tongue_winking_eye:

1 Like

Yikes, that’s WAY overboard. :smile:

But your previous posting is very important. I compared your dcraw-generated image to a straight non-pixel-shift image–and I’m not seeing any real difference. So if Sony is cooking them with plenty of sharpening and saturation increase, then maybe pixel shift is not all it’s cracked up to be. I could just as easily apply those changes to the original RAW file–just tried it right now, and I’m not seeing any real difference.

Sadly, Imaging Edge provides no options to turn such things off, so we cannot test a “straight” conversion.

Well, if you take a look at @heckflosse’s post above, you can see that there are advantages in pixelshift – for example, the false colours are gone. But I agree that the difference is much less striking than what the recent articles about Sony’s pixel-shift made people believe… I think that Sony’s tool is trying hard to make people go “wow” :slight_smile:

Have a look at this region of your shot:
left is Amaze demosaic of first frame, right is pixel shift without motion correction

Edit: both are without sharpening

Agreed. There’s a false color advantage. I suspect it generally wouldn’t be important enough to make me go through the trouble of pixel shift, though. (Usually I shoot landscapes, not magnets…)

Sony’s tool does induce some “wow”, and that seems primarily due to the extra sharpening at this point.

Your example was shot at F11. For pixel shift I wouldn’t use anything > F8 to get maximum detail.
The biggest advantages of pixel shift are to avoid interpolation artifacts and to reduce noise on high iso shots.

:rofl: +1 for the “Quote of the week” section.

1 Like

I can re-shoot them at wider aperture and/or higher ISO when I get home. If you have some preferred combinations, let me know.

BTW, here’s a better dcraw patch (hopefully without heap overflows this time :grin:)

diff --git a/dcraw.c b/dcraw.c
--- a/dcraw.c
+++ b/dcraw.c
@@ -2743,6 +2743,26 @@
   free (data);
 }
 
+
+void CLASS sony_arq_load_raw()
+{
+  int row, col;
+  ushort samples[4];
+
+  for (row=0; row < raw_height; row++) {
+    for (col=0; col < raw_width; col++) {
+      read_shorts(samples, 4);
+      if (row < iheight && col < iwidth) {
+        int idx = row * iwidth + col;
+        image[idx][0] = samples[0];
+        image[idx][1] = (((unsigned)samples[1]) + ((unsigned)samples[2])) >> 1;
+        image[idx][2] = samples[3];
+      }
+    }
+  }
+}
+
+
 void CLASS samsung_load_raw()
 {
   int row, col, c, i, dir, op[4], len[4];
@@ -6272,6 +6292,17 @@
 		   if (!strncmp(make,"OLYMPUS",7) &&
 			tiff_ifd[raw].bytes*7 > raw_width*raw_height)
 		     load_raw = &CLASS olympus_load_raw;
+                   if (!strncmp(make,"SONY",4) &&
+                       !strncmp(model,"ILCE-7RM3",9) &&
+                       tiff_samples == 4 &&
+                       tiff_ifd[raw].bytes == raw_width*raw_height*tiff_samples*2) {
+                       load_raw = &CLASS sony_arq_load_raw;
+                       colors = 3;
+                       is_raw = 1;
+                       filters = 0;
+                       iwidth = raw_width;
+                       iheight = raw_height;
+                   }
 	}
 	break;
       case 6:  case 7:  case 99:

BTW @ron, any chance that you could submit a couple of shots of that colour target so that we can generate nice input colour profiles for the A7RIII? Here’s a description of the procedure in case you are interested:

http://rawpedia.rawtherapee.com/How_to_create_DCP_color_profiles#Shooting_the_color_target