Ability to process Nikon NEFX files

I’m not sure anyone is right about the technical details of NEXF files (straight from the camera). The info cited here from Nikon is very non-specific about the file contents. The fact that Adobe was able to reverse engineer them suggests that they may be somehow similar to NEF files, but who knows? The original files could be ‘NEF’ files (perhaps packaged together in one container???), but they certainly don’t seem to be by the time they’re exported from whatever program can interpret them.

But the bottom line from @Joanna (why bother with all the limitations of pixel-shift) seems pretty close to the mark. I haven’t tried it yet with my Z6III but may get around to it eventually (with the right non-moving subject)…

Well, the manual clearly calls them a merged pixel shift file (singular)

And, has been pointed out, if the RAW data hadn’t been demosaiced, we wouldn’t have pixels to shift to create the merge.

I still don’t understand how making more then 1 picture with a slightly shifted sensor or cfa can produce a better picture.
Nor do I understand what is saved in that nefx file: more individual raw files or one combined file.
Does NxStudio creates a bitmap image out off several raw files or is it just reading a combined file?
Or is the nefx file coming out off the camera or is it created outside the camera by NxStudio.
I can’t find any exampleof a nefx file on the net. Not even in the Z8 galleries.

George

NxStudio takes a set (up to 32 images) of NEF files and merges them to an NEFX file.

Ditto. Could someone please post a NEFX file on a file share? I’d like to have a root around inside it.


I found this thumbnail of a pixel-shift image…

… I took from this article…

So, it doesn’t take much movement, like the slightest of breezes, to give problems :wink:

That I understood too. Only static subjects.
The camera takes up to 32 pictures with a slightly moved sensor and delivers just normal nef’s. NxStudio merges them and can export the result in different formats among the nefx format.
The examples I’ve seen don’t impress me that much. Maybe difficult to see on the internet.

George

It seems the way to go is to prepare NEFX in NX Studio and then export it in NX to 16-bit RGB TIFF format. You won’t loose anything substantial, I guess. But you need a rock-sturdy camera mount, no vibrations, no changes in lighting, no air thermal flows or haze, and absolutely no movement of the subject. It’s only for labs or something alike. Otherwise you’ll get even more artifacts than with standard demosaicking of a single photo. Maybe 0.001% of users will ever seriously work with it – implemented mostly for marketing purposes (“others have it” syndrome). Maybe an exciting thing to try, but be prepared for failure.

Basically, pixel-shifting is for better color reproduction, with false colors less likely (crosstalk may still cause some problems). You may also get twice more resolution, i.e. 4 times more pixels, if you take at least 16 photos (for Nikon). Maybe museums could use it for reproduction purposes. For Nikon’s implementation, see What Is “Pixel Shift”? and Merge Pictures Taken Using Pixel Shift with NX Studio (there are Z8 and Zf versions too, almost identical). The key statement there is “Since RGB can be overlapped without interpolation, moiré, and color fringing caused by the interpolation process can be reduced, improving color reproducibility in the details”. To get twice higher resolution, you need to take 16 or 32 photos, while to get normal resolution you may use 4, 8, 16, or 32 photos. So you may call it “hardware assisted demosaicking”. NEFX contains demosaicked RGB data, with PhotometricInterprepetation tag value = 2 = RGB. (EDIT: deleted doubtful part about colorspace). (As a side remark, higher gain for Z8 kicks in at ISO 500, while it seems to start at ISO 800 for Z6III.)

Someone has made a LR plugin which may combine the source NEFs “better” than NX Studio – https://www.dpreview.com/forums/thread/4746593 and https://mackman.net/mergeraw/ . I don’t know how it plays with optical corrections, probably it’s a weak point of this solution.

See also a nice example by Hasselblad: https://www.hasselblad.com/h-system/h6d-400c-multi-shot/

For more general discussion on pixel-shift, see https://www.dpreview.com/forums/thread/4747167 . Horshack writes the following there:
Here is a full list of pixel shift benefits, in my order of importance:
- Significant reduction of aliasing/moire
- Improved color resolution
- Significant reduction/elimination of demosaicing artifacts
- More amenable to sharpening without artifacts
- Noise reduction

Nikon docs put it in a similar way:
- Reducing Moiré and Color Fringing
- Improving Color Reproduction of Details
- Improving Resolution
- Reducing Noise

NEFX is basically a NEF format. LibRaw 202502 snapshot uses a very dirty trick to read NEFX – see LibRaw/src/utils/open.cpp at master · LibRaw/LibRaw · GitHub . The “imgdata.idata.filters = 0” code there means the raw data is in standard RGB format, not a Bayer or X-Trans pattern. Maybe DxO will support NEFX in few months…

2 Likes

That is generally what I was expecting

Blockquote
3-color nefx image

So Nefx is like a half-baked raw file : demosaicking is unnecessary since already replaced by pixel shift algrithms. I would expect Nefx to provide the advantage of the native sensor color space, no compression artifacts, no color balance applied yet, no lens correction applied yet, deep quantization. It would indeed be a good starting point for DxO to process.

So, the D850 can internally ‘process’ 10 images into one RAW file?

Really? Everyone is telling me you simply cannot do that.

If anyone doubts the abilities of Pixel Shift, I suggest you try it.
Yes, everything has to be absolutely bolted down, including wooden floors.
Find the sharpest aperture of your sharpest lens. I could justify the Nikon Plena 135mm, 'cos it’s my job. Which is true edge to edge sharp at f4. Mounted on a Z8.
Pop something like an A4 engraving on a copy stand or easel. Make sure you are absolutely square on with nice soft even lighting.
Take the best pic you can.
Now, set it to take the 32 frame PixeShift.
Process them and compare the single frame to the same area of the massive image. If they aren’t chalk and cheese, somethings wrong.

Up to 10 images - as can the D810. You can also specify the blend mode as Average, Lighten or Darken.

This first shot shows a single RAW file with 5 short exposures of 1/400sec, which are visible as lines on the sandbank, as the tide came in…

The next shot is also a single RAW file with 5 exposures of 5secs, superimposed in camera, with a variable pause between shots to optimise the amount of peak of the waves.

This functionality is very useful for fireworks, where a single firework is not necessarily very interesting but, when you combine 7 or 8…

Since I am not prepared to spend that much money on a new camera, just for a single test, how about making the NEF files and and the resultant NEFX file available, on a file share site, for me and other folks to examine? :wink:

I’ll have to ask my client if it’s OK, but shouldn’t be a problem

1 Like

If you’d rather not publish the link in the forum, then you could always send it to just me via a direct message.

Do you want all 32 or would one of the 32 work… along with the NEFX file?

Maybe just a couple, just to see what the difference is for each shift.

I just did a test with 32 of Z8 photos (45mpx, about 50 MB files, 14-bit raws losslessly compressed) merged into one NEFX (CA corrections applied) with doubled resolution (ca 180mpx), resulting in 915 MB file. Used NX Studio to export it as 16-bit uncompressed TIFF, over 1GB file (btw, NXS process alone used over 10GB RAM). Exiftool shows for the full image subfile: PhotometricInterpretation = 2 (RGB), 3x14 bits samples per pixel, 16512x11008 pixels, compression=NEF but in fact data is a continuous stream of original 14-bit values (no alignment to 8 or 16-bit boundaries). PhotoLab 8.6/Win reads the TIFF file without any problems, but not the NEFX file, even if you rename it to NEF. PL complains about possibly corrupted EXIF data – probably it looks for a subfile with PhotometricInterpretation=CFA, but there’s none of course. Personally, I would use the TIFF export made by NX Studio. I may publish here some specific info from exiftool, if you wish.

BTW, I’ve edited doubtful part of my previous post about colorspace in NEFX. Probably RawDigger histogram could tell more – if a daylight “normal” photo shows much higher values in green, it’s probably in camera’s native colorspace,
but (more probably??) it’s in the colorspace specified as target in the camera.

EDIT: Some more details.

Main differences in metadata for the full-resolution subfile between the original NEFs and NEFX respectively:
PhotometricInterpretation: CFA vs RGB
SamplesPerPixel: 1 vs 3

Full resolution subfile for both original NEFs and shows Compression = 34713 = ‘Nikon NEF Compressed’, see EXIF Tags . Probably this value tells the parser to look in MakerNotes for the compression actually used. The ‘NEFCompression’ tag [0x0093] in Nikon MakerNotes is set to 3 = ‘Lossless’ for NEFs, while for NEFX it is set to 10 = ‘Packed 14 bits’ (see Nikon Tags ). So, NX Studio 1.9 does not bother itself with Huffman encoding when generatin NEFX and just uses a “raw bitstream” (disregarding byte boundaries). That’s why NEFX files are so big.

That’s what I was hoping to look at in ExifTool and why I asked @mike to make a couple of files available.

Still awaiting client OK!

Here’s output of “exiftool -s -a -ee -g” with some private data removed. Please let me know, if you want it run with different options.
WZ8_3513_merged.NEFX.et.txt (19.2 KB)
Note that StripByteCounts*8 = ImageWidth*ImageHeight*3*14 (bits) for the full resolution image, so the “compression” in NEFX is just putting 14-bit numbers straight one after another rather than on byte or word boundaries, i.e. 5.25 bytes are used for each pixel.

I am glad that you mentioned this! It turns out that even my nine-year-old D500 can do the same trick.

Regards, Joseph