SplitCFA

[NKV]

Hello everyone.
I start writing the SplitCFA module. The module extract 4 ( [ R ] [ G ] [ G ] [ B ] ) sub images from CFA Bayer to 4 files( names [ 0 ] [ 1 ] [ 2 ] [ 3 ] ).

Why I do it? Because: I think it's good idea to split every 1 RAW file to 4 images, calibrate it separately, up-sample(x2 or x3) it for Drizle purpose, register all to one image and integrate to 3 images and finally create one RGB image.

Best regards,
Nikolay.

v.1.0.1 Now the module can: Add files from many sub-folders, extract four sub images and write four images to original folders. Also, the module can be applied to Views.  And any type of images (mono, RGB, RAW, Fits, any bittiness).

v.1.0.2 New checkbox: create sub-folder tree structure in output folder. So the module can collect all images from sub-folders and write similar folders structure to other place.
v1.0.3 New checkbox: create sub-folder for every CFA Bayer chanel ( [ /CFA0 ] [ /CFA1 ] [ /CFA2 ] [ /CFA3 ] ).

SplitCFA source code in official distribution.

MergeCFA
v.1.0.0 Released

MergeCFASource Code

MergeCFA binaries:
Linux 64
Win 64

[Juan Conejero]

Hi Nikolay,

Great project. Let me know when it is ready for release. If it's before a couple of weeks we can include it in the final 1.8.0 distirbution.

[NKV]

Hi Juan,
The module is very simple and I hope very stable. I tested in on Win7 64 and 32 and Ubuntu 64.
So please review the code and include it to final 1.8.0 distribution.
Source code available in first post.

Best regards,
Nikolay.

[NKV]

v.1.0.2 New checkbox: create sub-folder tree structure in output folder. So the module can collect all images from sub-folders and write similar folders structure to other place.

[Astrocava]

I have tested it and worked fine with my 350D images. Now I can forget about my pixelmath formulae to do the same. Thanks.

Will try it with DSS and dither feature to see differences with normal workflow.

Sergio

[NKV]

v1.0.3 New checkbox: create sub-folder for every CFA Bayer chanel ( [ /CFA0 ] [ /CFA1 ] [ /CFA2 ] [ /CFA3 ] ).

[pfile]

does it make sense to add the ability to specify a bayer pattern, just for the purpose of naming the output files? i can see how one might lose track of what channel is what.

of course adding this makes the tool somehow less generic, implying that you need to know the bayer pattern in order to apply this process, which you don't of course.

maybe just the ability to name each channel something oher than CFA[0..3]?

rob

[NKV]

does it make sense to add the ability to specify a bayer pattern, just for the purpose of naming the output files? i can see how one might lose track of what channel is what.

There are one easy way to understand what is what: in RAW format preferences set option " Create RAW Bayer image (RGB)" and apply SplitCFA to one RAW image. 
You will got result similar to this:

maybe just the ability to name each channel something oher than CFA[0..3]?

Just change "postfix" for filename .

[pfile]

whoops, i had looked at the wrong screenshot. sorry about that.

[Juan Conejero]

Hi Nikolay,

SplitCFA is now ready for inclusion in the 1.8.0 Ripley release (I'll send you the source code by private email). Thank you for a new nice and useful tool.

This tool brings up an important development topic that I want to comment briefly here: recursive directory search. In SplitCFA, you implement a recursive search to find DSLR raw and OSC FITS frames.

Recursive directory search operations are potentially dangerous. When they are used just to load or analyze files, the potential risks are normally not very high. However, imagine that you are gathering files as part of a file copy, move or delete task. In such cases the risks are extremely high, and if not well designed and implemented, a failing file search routine can lead to an unrecoverable disaster.

Since the topic is of special importance, here is a PCL routine that implements recursive directory search in a secure way. Note that the security checks are not just to protect the search operation (some of the checks look for theoretically impossible conditions under normal operation), but to protect it from mistakes that we developers/programmers can make---and do make, no matter how experienced we are.

Code: [Select]

/*
 * Secure recursive directory search routine.
 */
static
void SearchDirectory_Recursive( StringList& foundFiles, const String& whereToFind, const String& baseDir )
{
   if ( whereToFind.Has( ".." ) )
      throw Error( "Attempt to climb up the filesystem in file search operation: " + whereToFind );
   if ( !whereToFind.BeginsWith( baseDir ) )
      throw Error( "Attempt to walk on a parallel directory tree in file search operation: '" + whereToFind
                 + "'; expected to be rooted at '" + baseDir + "'" );
   if ( !File::DirectoryExists( whereToFind ) )
      throw Error( "Nonexistent directory in file search operation: " + whereToFind );

   String currentDir = whereToFind;
   if ( !currentDir.EndsWith( '/' ) )
      currentDir += '/';

   StringList directories;
   FindFileInfo info;
   for ( File::Find f( currentDir + "*" ); f.NextItem( info ); )
      if ( info.IsDirectory() )
      {
         if ( info.name != "." && info.name != ".." )
            directories.Add( info.name );
      }
      else
      {
         String ext = File::ExtractExtension( info.name ).LowerCase();
         if ( ext == ".cr2" || ext == ".fit" || ext == ".fits" || ext == ".fts" || ext == ".nef" || ext == ".dng" )
            foundFiles.Add( currentDir + info.name );
      }

   for ( StringList::const_iterator i = directories.Begin(); i != directories.End(); ++i )
      SearchDirectory_Recursive( foundFiles, currentDir + *i, baseDir );
}

static
StringList SearchDirectory( const String& whereToFind )
{
   StringList foundFiles;
   try
   {
      SearchDirectory_Recursive( foundFiles, whereToFind, whereToFind );
   }
   ERROR_HANDLER
   return foundFiles;
}

This routine can easily be modified to make it more flexible (e.g., to search for an arbitrary set of file extensions), or to adapt it to different requirements. The important thing is that a mistake such as:

Code: [Select]

void DeleteThem( const String& whereToDelete )
{
   StringList filesToDelete = SearchDirectory( whereToDelete );
   for ( StringList::const_iterator i = filesToDelete.Begin(); i != filesToDelete.End(); ++i )
      DestroyItWithoutCompassion( *i );
}

// ...

DeleteThem( ".." );
will not cause what you are thinking on right now. But better don't try it, though, just in case

On a side note, I have included .nef and .dng files besides .cr2, so SplitCFA can also work with Nikon cameras and other brands that use the DNG format. This should probably be extended to cover other camera formats as well.

[Ignacio]

Why I do it? Because: I think it's good idea to split every 1 RAW file to 4 images, calibrate it separately, up-sample(x2 or x3) it for Drizle purpose, register all to one image and integrate to 3 images and finally create one RGB image.

Interesting module, thanks, but I dont see why this workflow would be better. Spitting color channels in this way you lose spatial information. The resulting frames have 1/4 the size, and even if you upsample x2, that process is blind, in the sense that it ignores completely valuable information on the other elements of the bayer matrix. Good debayer interpolation methods use that information.

From the point of view of calibration, I don't think it should make any difference, with the exception of dark optimization.

What I think would be interesting, is to have a splitting module that keeps the original size of the frame, giving 3 "monochrome" frames, one for R one for GG and one for B, with data in the corresponding pixels, and zero in the rest. Then, I would like to have a StarAligment module that registers to the luminance of the original frames, but then applies the geometric/interpolation transformations to the corresponding split frames (in this way spatial info is not lost). Then one would integrate the R, GG and B registered stacks and recombine into a color image (this last part is not obvious as there could be information holes that need to be filled with some form of interpolation/normalization).

I keep coming back to this idea of "pseudo-debayering" after integration 

best
Ignacio

[NKV]

The resulting frames have 1/4 the size

It's good... for H-Alpha with colour camera. 

What I think would be interesting, is to have a splitting module that keeps the original size of the frame, giving 3 "monochrome" frames, one for R one for GG and one for B, with data in the corresponding pixels, and zero in the rest.

Really need? Use SplitRGB or ChanelExtraction 

Any way, SplitCFA simple instrument which available in other software. I think it's good to have it in PI too.

[Ignacio]

It's good... for H-Alpha with colour camera. 

Ah, for H-alpha could be useful. Is the result different to using super-pixel and then rgb channel extracion?

Really need? Use SplitRGB or ChanelExtraction 

Yeah, you are right, thanks for pointing it out. Now I only need to get SA to get the geometries from the luminance and apply them to the R,GG,Bs, but I guess that all the holes in those are hard to deal with during interpolation.

Thanks,
Ignacio

[NKV]

Ah, for H-alpha could be useful. Is the result different to using super-pixel and then rgb channel extracion?

You are right, exactly same result.

[rlange]

Hi, splitCFA is fine  , but if i you it what i have to do afterwards with the result-files?

OK, then I stack cfa[0] RED
ok I stack CFA [1] GREEN
ok I stack CFA[3] BLUE

what about the second green-channel CFA[2] ?

Have I stack this also? If yes sepately or together with the first green-channel  ( double amont of green files?)?

Thanks