Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

Is NEF truly RAW?


Rick Hull

Question

this may be information for all, or well known by many, but I have been unable to uncover this,

so I am hoping the experts here can enlighten me.....

 

although NEF is called RAW by Nikon, I suspect there is some level of processing going on?

my biggest concern is that the Bayer array, and the pixel values associated with each, and hence with that individual color, is NOT maintained in the NEF file? This is how data would be represented in a FITS file, and how I get my data from an SBIG CCD camera. If it were a true RAW, I think it would be easy to find a NEF to FITS converter / translator, but have not been successful.

 

I suspect that NEF is more a highly compressed, perhaps lossless true, but compressed file format;

whereby all pixels have been resampled and assigned an interpolated RGB color value per pixel ?

Since the algorithm is unknown, and even if so, can it be undone, this resampling already creates a loss of fidelity when one goes to register and stack several sub-frames, let alone the loss of corrective efficiency one would hope to achieve by dark frame subtraction.

 

Am I correct in these suspicions? Or am I missing some understanding? Please help.

Link to comment
Share on other sites

  • Answers 12
  • Created
  • Last Reply

12 answers to this question

Recommended Posts

I use a Nikon d7100 and have no problem using DSS to stack my images. But that's the only thing I use it for. Do NOT, try any image manipulation in DSS. Open the 32 bit autosave file in PS and have at it !


I would have to disagree with that. I do a significant amount of preprocessing in Deep Sky Stacker, much of which includes aligning the RGB channel peaks and a histogram stretch before saving the initial *.TIF file, which then gets loaded into Photoshop for the brunt of the work before a final pass through Lightroom for finishing touches.

I have found that loading the initial Autosave.TIF stack out of Deep Sky Stacker results in memory errors, as well as a host of processing difficulty if done that way. 

Link to comment
Share on other sites

A TIFF File would be a "Processed File", requiring one to take an original NEF File and perform a suite of modifications on it:  debayering, levels/stretch, white balance, saturation.  All of these modifications (even if "neutral"/"default" values) create artifacts which effect the success of the Calibration and Stacking  processes.

Tiff is a great 16-bit file format for saving an AP Image AFTER Calibration and Stacking, but the original NEF Raw files are much better for Input Data to these Stacking processes.

 

S3igell,

 

   I guess my question was in relation to the output from my D800.  So, I can select TIFF or I can select RAW (NEF).  RAW actually gives me more pictures on my SD card... is there any benefit to using the TIFF over the RAW?

 

Thank you for answering my question. I really appreciate it.

 

Chris

Link to comment
Share on other sites

You have a leg-up on the Canon DSLRs, which only offer output in RAW and JPG (although we have 3x native sizes of RAW available to us).

You should select RAW, unless you NEED to perform AP Image Registration and Stacking in an App which cannot handle the D800 NEF files.  With the NEF output, you KNOW that the AP Image App is getting the Raw Data.  With even the In-Camera TIFF Conversion, Stretching and Saturation are going to be applied, as well as possibly Noise Reduction and Sharpening - all of which are detrimental to the data which AP Image Stacking Apps need for their most accurate work.

 

So, unless you absolutely positively NEED to have TIFF, collect your AP Exposures in NEF RAW.

Link to comment
Share on other sites

NEF data is RAW data, at least as RAW as Nikon chose to support as output from their Cameras.  This "RAW" data is acceptable to all kinds of Image Processing Software, and is treated and manipulated and processed the same as other RAW data from Canon CR2 or Sony ARW or other brands data.

 

There are a number of Apps which can output FITS data from NEF, just as there are for CR2 to FITS:  MaximDL, PixInsight, DSS, RAWTRAN, PhotoShop with ACR and FITS plugin, even GIMP has a FITS plugin, others.

 

Is there any reason that you question the NEF data ??  Other than that you are more familiar with the FITS File output from whichever SBIG-supporting Apps you are most familiar ??

 

FYI:  For those of us used to CR2 and NEF RAW formats, FITS is simply a "container format" which is used within the Scientific and Imaging Communities to hold data of all sorts (sometimes Image data, sometimes metadata, and sometimes other measurements or coordinates or raster data or...)

Link to comment
Share on other sites

s3;

 

yes I agree, Nikon did whatever they damn well pleased to do.

 

I am attempting to stack and process 40 - 60 light subframes from 180mm images,

using TIFFs converted by dcraw64 gives a poorly shifted color balance, which I try to correct in CCDStack by with as yet mixed results

using DSS, yields very poor and muted colors

I do not have the money for Maxim or PixInSight

my understanding of PS is using ACR really does a TIFF translation, so if FITs plugin is used, it seems a double translation is happening,

if we assume the NEF keeps the original pixel to color channel map as put out my the sensor, if not then this is still happening, just in different locations

GIMP is 8 bits, so worthless for astro

I have not heard about RAWTRAN, will research it

 

I have a STF 8300c which I use on various scopes, and achieve great results using CCDSoft for control, CCDStack and PS for processing.

It is the DSLR which I am trying to also master, and if I had a Canon, think this would have happened much sooner and easier, but a Nikon 7100 is what I am dealing with.

Rick

Link to comment
Share on other sites

Sorry if this sounds derogatory, but your Real Issue seems to be that you are having some difficulty working through the Calibration and Processing of a Stack of Images which were taken by a Nikon DSLR.

 

That doesn't mean there is any problem endemic in the NEF file format or its contents.

 

As your comfort-level seems to center on CCDStack, there is little that I can help you as I'm unfamiliar with the workflow for that piece of software.

 

For DSS, I can confirm that it DOES successfully handle NEF input files (just as it does CR2 and ARW and TIFF and FITS).  The immediate results of DSS will look rather "unimpressive" at first, because DSS produces a very linear 16-bit rendition (actually 32-bit internally - but in a format very few other Apps can handle) until you perform Stretching and Saturation processing (either in DSS or your favored Image Processing Tool).  There are numerous DSS "How-To" postings on various Astronomy Forums as well as DSS's own Wiki.  

But, in basic terms:  

1) Use the RGB/K tab of the DSS Image Tool, checking "Linked Settings", sliding the Left (Dark/Shadow) slider to the right and the Center (Mid-point) slider to the left until you get a reasonably broad Bell-Curve Histogram with the "S-Curve" bisecting its right-hand side, then Apply.

2) Use the Saturation tab of the DSS Image Tool, selecting 20%, then Apply.  Increase to 30% or 40%, if image handles it.

3) Save frequently.

4) Return to the RGB/K tab for additional Stretching, if image handles it.

5) Use the Luminance tab to tweak the Midtone graph crossover curve.

6) Save, and continue Image Processing in your chosen App.

Link to comment
Share on other sites

s3;

 

ok, thanks for the briefing

 

actually I have never used DSS, but my friend who owns the Nikon has gone thru the tutorials,

and I will confirm if this is the way he handles it

 

I have used CCDStack and PS extensively to process the SBIG CCD camera images.

 

So thanks for your comments, and pointing in a direction.

Link to comment
Share on other sites

A TIFF File would be a "Processed File", requiring one to take an original NEF File and perform a suite of modifications on it:  debayering, levels/stretch, white balance, saturation.  All of these modifications (even if "neutral"/"default" values) create artifacts which effect the success of the Calibration and Stacking  processes.

Tiff is a great 16-bit file format for saving an AP Image AFTER Calibration and Stacking, but the original NEF Raw files are much better for Input Data to these Stacking processes.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use