[ome-devel] File conversion with RGB separation into multiple files does not work

[Melissa Linkert]

Hi Simon,

Thank you for reporting this.

> For the purpose of my work, I'd need to convert a sequence of JPEG
> images into an OME-TIFF stack using the command line tools. Despite
> the original recording being in gray levels, I thus end-up with a
> sequence of RGB files. I thus wanted to use the -separate option of
> bfconvert to do the job (along with -stitch and -expand) but I've
> noticed the following bug (I've uploaded a test RGB tiff stack under
> QA 11043 that reproduces it):
> 
> So, if I run : "./bfconvert -stitch -expand -separate RGB_test.tif
> RGB.ome.tiff", I get what I would expect (i.e. a 3xN stack with
> R,G&B splitted, N here being the number of planes).
> 
> If I run : "./bfconvert -stitch -expand -separate -channel 0
> RGB_test.tif RGB_R.ome.tiff", I also do get the N stack of only the
> red channel that I would expect (or G or B if specified).

Yes, I confirm that both of those commands work as expected.  Note that
the data type of the file in question means that the "-expand" and
"-stitch" flags will have no effect.

> However, if I run : "./bfconvert -stitch -expand -separate
> RGB_test.tif RGB_%c.ome.tiff", I do not get 3 separated N stacks (as
> I would have expected, at least personally), but I get 3 times the
> same 3xN stack as in my first example.

This seems to work as expected locally.  Three files (RGB_0.ome.tiff,
RGB_1.ome.tiff, and RGB_2.ome.tiff) are created, each with a single Z
stack.  Opening any one of the new .ome.tiff files will result in all
three being opened (so you will see 3C x 3Z planes) because the file
names are all linked internally.

Running "showinf -nogroup" or opening any of the files in software that
does not support OME-TIFF should show just one Z stack, and each file's
images should be different.

> Finally, if I run : "./bfconvert -stitch -expand -separate
> RGB_test.tif RGB_%w.ome.tiff", I end up with the exact same issue as
> above (plus, personally, I would think that the channels could be
> named RGB or some such, instead of 0,1,2).

This also behaves as above for me, i.e. it seems to work as expected.
Could you please confirm that "showinf -nogroup" works and/or indicate
how you are checking the contents of converted files?

Regards,
-Melissa

On Tue, Apr 28, 2015 at 10:45:34AM +1200, Simon Blanchoud wrote:
> Hi all,
> 
> For the purpose of my work, I'd need to convert a sequence of JPEG
> images into an OME-TIFF stack using the command line tools. Despite
> the original recording being in gray levels, I thus end-up with a
> sequence of RGB files. I thus wanted to use the -separate option of
> bfconvert to do the job (along with -stitch and -expand) but I've
> noticed the following bug (I've uploaded a test RGB tiff stack under
> QA 11043 that reproduces it):
> 
> So, if I run : "./bfconvert -stitch -expand -separate RGB_test.tif
> RGB.ome.tiff", I get what I would expect (i.e. a 3xN stack with
> R,G&B splitted, N here being the number of planes).
> 
> If I run : "./bfconvert -stitch -expand -separate -channel 0
> RGB_test.tif RGB_R.ome.tiff", I also do get the N stack of only the
> red channel that I would expect (or G or B if specified).
> 
> However, if I run : "./bfconvert -stitch -expand -separate
> RGB_test.tif RGB_%c.ome.tiff", I do not get 3 separated N stacks (as
> I would have expected, at least personally), but I get 3 times the
> same 3xN stack as in my first example.
> 
> Finally, if I run : "./bfconvert -stitch -expand -separate
> RGB_test.tif RGB_%w.ome.tiff", I end up with the exact same issue as
> above (plus, personally, I would think that the channels could be
> named RGB or some such, instead of 0,1,2).
> 
> I've been digging in the java code for a few days but could not find
> a fix yet. The only interesting point I could sort out is that it
> has to come from quite a low level as writing only one of the 3
> channels does produce the expected output for that channel, and the
> writing of the plane data is called only the required amount of
> times. So there must be some cross-writing between the various
> files.
> 
> I'm working on a Mac OS X 10.10.2 with the latest Bio-Formats from
> the GitHub repository.
> 
> Cheers,
> Simon Blanchoud

> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel