For those who don’t want to read all the details of the format analysis here are our conclusions:

Conclusions

With D4s camera Nikon introduced the new file format they refer to as RAW Size S NEF.

• It contains not RGB but YCbCr data much like a JPEG;
• The data is 11-bit;
• The tone curve is applied to the data;
• The in-camera white balance is applied to the data;
• The pixel count is 4 times less than with regular NEF files;
• The color information is shared between two adjacent pixels (in other words, chroma is recorded for each other pixel);
• The file size is insignificantly smaller than full resolution 12-bit lossy compressed NEF;
• Compared to a regular NEFs the data needs additional processing (linearization) while converting it to a TIF/JPEG, that may cause additional problems during the conversion (see Study 3 below) as well as some additional computational errors;
• There is some loss of color accuracy in shadows, which negatively affects the usable dynamic range if color accuracy is important (see Study 2).

If you are want to see how different settings for NEF compression, bits per sample, and Image area affect the file size, the list is in a tab-separated D4s_Modes.txt. The NEF files listed are in http://updates.rawdigger.com/data/D4s/.

If you are interested in the detective story, here goes. We will be using sNEF as a shortcut to Nikon’s “RAW Size S” term.

Deciphering and unpacking sNEF format

Looking into EXIF of an sNEF file shot in FX mode we see the following:

• Image Size is 2464 x 1640 pixels,
• Image Data Length is 12122880 bytes (as given in Strip Byte Counts field).

> exiftool -imagewidth -imageheight -stripbytecounts D4s_NEF_S_FX.NEF

Image Width      : 2464

Image Height     : 1640

Strip Byte Counts            : 12122880

Dividing Image Data length (given in bytes) by the image pixel dimensions we can see that for each pixel there are 3 bytes, or 24 bits: 12122880/2464/1640 = 3. From the camera specifications, the file is uncompressed and 12-bit. For such a file to contain RGB data one pixel should be represented by 12x3 = 36 bits instead of 24. That means we are dealing with something else but not an RGB file.

The next hypothesis we are going to check is that the file contains YYCbCr data, i.e. the luminance component (luma, or Y) is recorded for each pixel while the color-difference components Cb and Cr (called chroma) are recorded for each other pixel  – in other words each set of color-difference components is shared between 2 pixels. If it is the case, for each two pixels we should have 12x2 bits of luma and 12x2 bits of chroma for the total of 48 bits or 6 bytes, which is averaged to 3 bytes per pixel – the number we are after.

To check if our hypothesis holds water let’s take a totally black frame (ISO 100, Auto WB mode1, Picture Control set to Neutral modified with sharpness parameter set to 0, camera set to Adobe RGB space, the viewfinder and the lens are closed, lens set to the smallest aperture f/22, shutter speed set to the shortest    1/8000 s).

From the EXIF we can read the offset of the RAW image:

> exiftool -stripoffsets Black_AutoWB1.NEF

Strip Offsets       : 813568

Bringing the file into a hex editor and entering the offset (813568=0xC6A00) to position the cursor onto the start of the RAW data we start trying to make sense of the data. Let’s examine a small chunk of data, the first 24 bytes that according to our hypothesis should contain first 8 pixels of the image (vertical dividers are to split those 24 bytes into the groups of 6 bytes; each group presumably contains data for two sequential pixels):

01 00 00 00 08 80 | 00 00 00 00 08 80 | 01 20 00 00 08 80 | 00 00 00 00 08 80

YYCbCr hypothesis suggests that in each 2-pixel group represented by 6 bytes we should have two 12-bit luma values that need to be very close to each other (because luma hardly varies significantly in the black frame), and the next two 12-bit values for CbCr chroma channels containing values very close to neutral. We can see this condition met with the following permutation of nibbles (4-bit aggregations):

n0n1 n2n3 n4n5 n6n7 n8n9 n10n11 => n3n0n1 n4n5n2 n9n6n7 n10n11n8,

which is sort of logical as the file is recorded using little endian. What we have after applying the above alchemy recipe is:

001 000 800 800 | 000 000 800 800 | 001 002 800 800 | 000 000 800 800

After unpacking the whole image data this way we can see that the luma is represented mostly with 0s and 1s (which is expected for the black frame), while the chroma channels are mostly 0x800=2048 (meaning 2048 should represent neutral value for chroma channels). The results are presented on the histogram below:

Figure 1

Typically the chroma channels are encoded in such a way that neutral value is represented by the middle-of-the-road code. That is for a 12-bit coding which spans from 0 to 4095 the value of 2048 is middle and we can be fairly certain that it represents neutral value. Values larger or smaller than 2048 represent non-neutral colors; and the color becomes progressively more saturated with the increase of the delta between the chroma value for the pixel and 2048.

The result we have just obtained seems to support our hypothesis. The next step is to unpack some regular shot by separating a 2 pixel group of Y₁Y₂CbCr into two fully defined pixels Y₁CbCrY₂CbCr, and converting YCbCr to RGB using the following trivial set of equations:

R = Y + (Cr-2048)

G = Y – (Cb-2048) – (Cr-2048)

B = Y + (Cb-2048)

The resulting image is:

Figure 2

Now the things are really starting to take shape: the colors are in the correct order, neutral patches are indeed looking neutral (by the way it means that the YCbCr data is indeed recorded after applying the white balance to source RGBG data coming from the sensor). However, the image is dark in spite of the presence of the fully blown-out highlights, like those specular spots on the chrome ball. We can also note that the fully blown-out areas are intensively purple. The contrast of the image is close to what we can expect from a high gamma coding, which means that not only white balance, but also a tone curve is embedded into the YCbCr data.

Now we know enough to implement initial support for the sNEF format in RawDigger. What we can add at this stage is unpacking, as well as display and statistical analysis of the luma and chroma channels for this format.

Normalizing for the brightness and saturation

The camera specifications suggest that sNEF files are encoded in 12 bits. Normally it means that the maximum in the luma channel is 2^12-1=4095. Insufficient brightness of the image, which nevertheless contains fully blown out areas, suggests otherwise: full 12 bits are not used for luma channel. Hence we need to find what the actual maximum is.

For this matter we shot several fully blown-out frames and studied them in RawDigger. Indeed that maximum value in the luma channel does not reach 4095 and is also dependent on the white balance setting in the camera. The lowest maximum value of 2392 was obtained when the camera white balance was set to 2500K, while the highest, 2549, corresponds to while balance setting of 10000K. This way we can say that the luma data is coded with log₂(2549) ≈ 11.32, or in other words the coding uses slightly more than 11 bits instead of full 12.

Normalizing the luma channel Y to 2549, we can see the brightness much closer to the reality:

Figure 3

Now after we iterated the brightness, let’s try to figure out the saturation. For now it is low. Most of the cases the saturation is low when the range in chroma channels is smaller than the coding allows. Once again, we need to normalize the chroma values through defining the maximums. We find some reassurance to the idea that the chroma range is narrower than 0..4095, because we have already established that it is the case for luma.

To find the maximums we will use red and blue color separation Lee filters to shoot a color target (X-Rite ColorChecker Digital SG), which spans approximately through Adobe RGB gamut, varying exposure to achieve maximums for chroma channels.

Resulting images suggest that the chroma channels range is very slightly wider than 2048±1024, which, by the way, also closely corresponds to 11 bits.

Figure 4. Shot through 25 Tricolour Red, Cr channel

Figure 5: Shot through 47B Tricolour Blue, Cb channel

Now, normalizing the chroma channels to 1024, here is what we have:

Figure 6

As we can see the saturation is improved. If you want to exclude the slightest possibility of color clipping your image converter may use the range of 2048±1280 for chroma channels (please see scYCC-nl). That will cause a slight drop in saturation, but it can be easily compensated and one of the accurate ways of doing it is by using a color profile.

Normalizing for Hue

As we have just seen the YCbCr data already has a white balance and tone curve applied to it. This suggests that YCbCr data is a sort of an intermediate in the sequence that normally results in a JPEG image. If indeed it is a case we can try to substitute our trivial formulae for deriving RGB from YCbCr for the one that is normally used while unpacking JPEGs to RGB (sYCC color space, considering that in our case the middle value is 128 instead of 2048):

R = Y + 1.40200*(Cr - 2048)

G = Y - 0.34414*(Cb - 2048) - 0.71414*(Cr - 2048)

B = Y + 1.77200*(Cb - 2048)

It is important to note that YCbCr is actually a representation of a certain RGB color space. If you need to define the conversion to some particular color space like Adobe RGB, you can derive the coefficients for the formulae based on the chromaticity of the color space or you can use regression to calculate the coefficients.

Let’s see how the image looks now:

Figure 7

We got the color close but we still need to address the magenta highlights.

In order to understand what causes the unwanted magenta-pinkish tint on highlights we need to study the YCbCr data close to the clipping point. To do so let’s take two shots with the same exposure settings, one as NEF 14-bit uncompressed and the other in sNEF mode. Our target will be a neutral gray step wedge, Sekonic Exposure Profile Target. We have chosen this target because it is very neutral and the 1/6 EV step between patches is the smallest among ready available targets. The exposure settings is such that the lightest gray patch A (the leftmost in the row, marked with the red selection rectangular; the specification sheet for the target refers to it as #2) is very close to clipping on the NEF 14-bit uncompressed shot.

Figure 8

Filling the table with the data from the both shots we got the following (the patches are named left to right; the first column is the patch name, the next three columns – Y, Cb, CR – are averages, extracted from the sNEF shot, and the last four columns – R, G, B, G2 –  are averages from the 14-bit uncompressed NEF):

As we see for the 14-bit uncompressed NEF, none of the R, G, B, G2 channels reach the maximum of 15615 (2^14-1-768 = 15615, where 768 is the black level). However the chroma channels Cb and Cr on the patch A have the values that differ significantly from the values on the other patches: for Cb we have 2053 instead of 2042..2044, and for Cr we have 2070 instead of 2052..2054.

To check that the patch A is truly following the neutrality pattern of the other patches let’s take a shot of the same target reducing the exposure by 1 EV. Here is what we have got:

Now the Cb and Cr values for the patch A are very close to Cb and Cr values extracted from the rest of the patches. It means that the patch A does not differ in neutrality from the other patches, and the skewed values on the patch A we got from the first shot indicate the loss of color linearity. We additionally checked the target with spectrophotometer and its readings confirm that the patch A is no different from the other patches in terms of color.

The results we have just obtained mean that the loss of color linearity is caused by the high brightness level, even before the clipping point – as soon as the luma component exceeds approximately 2100 the color information becomes fairly meaningless.

On a side note, if you look at the histograms of the 14-bit uncompressed NEF you will see that the histograms of all the channels on the patch A have normal bell-shaped curves and no clipping. The only indicator that things start to go wrong is that G/R and G/B ratios for the patch A are different from the corresponding ratios for the other patches. It is the common case. For this particular camera at base ISO the practical exposure limit before the white balance starts to be skewed in highlights is 1/3 EV below the clipping point.

Looking at the tables above we can deduce that the sNEF format is designed in such a way that the luma channel should be clipped to 2047 at the conversion stage. However RawDigger is not a converter. Not only the ultimate accuracy of the tone and color are not the goals here but also it would be counter-productive to limit our users in researching unmodified data. That is why we decided to raise the limit for the luma channel, setting the clipping point at 2549 (which helps in preserving the luminosity details in the extreme highlights), but to avoid magenta highlights we will still be neutralizing the chroma channels by forcing them to 2048 as soon as the luma channel exceeds 2047:

Figure 9

We can see that unwanted colorization of highlights is now gone.

Data linearization

To change white balance and apply exposure correction in converters without seriously modifying the innards of the raw converter it is often convenient to have linear RGB data. We have just demonstrated that if starting from sNEF YCbCr data we naturally come up with non-linear RGB. In order to facilitate processing in converters we need to linearize data in LibRaw, which is the foundation of RawDigger.

Generally speaking the YCC format does not imply that the Y component is necessarily non-linear. It can be linear and in this case the one stop change in exposure causes 2x change in luma. When luma is coded linearly the resulting RGB data is also linear. If the luma component is coded non-linearly with a tone curve applied the resulting RGB data will be also non-linear.

To be sure we are going to shot Kodak Q13 gray step wedge. Kodak datasheet specifies that the step between the patches on the gray scale is about 1/3 EV. If the data is coded linearly the histogram will show approximately 3 picks per 1 EV.

Opening the shot in RawDigger we select the step wedge (red rectangular marks the selected area) and additionally put a sample (green square) onto the brightest patch A to align the histogram to the maximum of the brightness of the scale:

Figure 10

Let’s study the histogram of the luma channel Y (displayed in white):

Figure 11

We can see that each stop contains 6-7 peaks instead of 3-4. It means that the luma channel is non-linear, and the tone curve in use compresses the data approximately 2 times.

To restore the linearity in RGB we can use gamma ≈2, which will clip the luma channel close to its design range.

If we want to avoid luma clipping we can construct our own linearization curve by shooting the gray step wedge in both 14-bit uncompressed NEF and sNEF modes. We need to make several shots in order to have data enough to accommodate for 11 or even 14 stops (that is if you believe that the data below 11 stops from raw data maximum is reliable). The exposure for the first shot taken in 14-bit uncompressed mode needs to be such that the average values for the green channels of the lightest patch are about 1/6 EV below the saturation. If you are using Q13 the next shots may be -3 EV and -6 EV below; and to accommodate for 14 bits one more shot with -9 EV is needed. Since the curve is composite, that is there is one curve for all channels, it can be constructed either as Y -> G_linear or as G(YCC) -> G_linear, and then applied to all RGB channels derived from sNEF data.

Finally, after performing the linearization, we are ready to support RGB render of sNEF files in RawDigger:

Figure 12

Now we can study some features of the sNEF format.

Study #1: does Picture Control affect sNEF data?

This question is triggered by the discovery that sNEF data depends on the in-camera white balance setting. It is possible that other camera settings may change the image data in sNEFs. We will be looking into two settings – picture control and the choice of the in-camera color space, which can be either Adobe RGB or sRGB.

Having fixed the exposure values and using stabilized lights we have shot the X-Rite ColorChecker Digital SG applying wildly different Picture Control settings in the camera, and varying the setting for in-camera color space. In spite of the fact that the embedded JPEGs look very different the difference between sNEF shots does not exceed 0.175 deltaE94, which is negligible.

The conclusion is that neither Picture Control nor the choice of a color space does affect sNEF data.

Study #2: comparing color in shadows between 14-bit uncompressed NEF and sNEF modes

With the 11-bit data representation in sNEF mode it is interesting to see how it holds color in shadows.

To preform the comparison we decided to shot similarly exposed pairs in sNEF and 14-bit uncompressed NEF modes. The target was X-Rite ColorChecker Digital SG. This target spans for about 6.5 EV. The first pair of shots was in ETTR mode (2/3 EV higher than in-camera exposure meter suggested). The second pair was one stop below the first, the third pair – 2 stops below the first, and the forth pair was 2 2/3 stops below the first. All shots were processed through the “recommended developer”, Nikon Capture NX2. The data was extracted and compared through CIE94 formula using BabelColor PatchTool.

The table below summarizes the difference within the pairs:

The table shows the tendency of the difference between 14-bit uncompressed NEF and sNEF files increasing with the exposure decrease. Already at ETTR–2EV (which corresponds 8.5 EV scene) the difference becomes significant. It is worth noting that the difference lays not so much in luminosity L* but mostly in color channels a* and b*. For the ETTR–2 2/3 EV exposure (that is for the scene that has a little less than 9 stops of the dynamic range) the difference exceeds 2 deltaE while 1 deltaE is considered to be “just noticeable difference” (JND).

Study #3: changing white balance on a sNEF may cause a problem

The more the data format deviates from the common practice, the more problems can it cause during the image processing. We are using Adobe software just for illustration purposes; however, other converters may have similar problems as well.

Let’s take 3 shots of the same scene in sNEF mode. The light is the same between the shots, so is the exposure. The first shot is taken with the custom white balance. For the second shot we set the camera white balance to 2500K, while for the third this setting is 10000K.

First we convert the sNEF files to dng format using DNG Converter 8.4 Release Candidate, and next we open them in ACR CS5. We are setting the initial exposure compensation to -0.5 EV to get the correct reading of the green channel on the first patch of the white balanced shot. To monitor what is going on we add color samples to patches 1, M and B:

Figure 13. Shot with a custom white balance

Figure 14. Shot with white balance set to 2500К

Figure 15. Shot with white balance set to 10000К

Applying the white balance values from the first shot to two other shots we can see a very significant overexposure causing the patches up to #3 to blow out. To compensate we need to apply about -1 EV of the additional negative exposure compensation…

Figure 16

 

Figure 17

… and only after that the readings from the samples become close.

The effect is caused by normalization problems and it is not guaranteed that the fine details in highlights are fully restored after additional negative exposure compensation is applied on top of the overflow.

Once again, we used Adobe software in this example just for illustration purposes; any raw converter, and that includes Nikon's own, can cause some problems while working with sNEF files. If you are using sNEF format it is probably a good idea to test how the raw converter of your choice copes with the task and what additional workflow steps may be necessary to obtain high quality results.

---

The Unique Essential Workflow Tool

for Every RAW Shooter

FastRawViewer is a must have; it's all you need for extremely fast and reliable culling, direct presentation, as well as for speeding up of the conversion stage of any amounts of any RAW images of every format.

Now with Grid Mode View, Select/Deselect and Multiple Files operations, Screen Sharpening, Highlight Inspection and more.