Importer Development - Inverted pixels

[Terry Jordan]

I have written an importer for large single file that contains the entire image sequences.  My first implementation just used the ImageStack, but it was brought to my attention that the files may exceed the size of memory, so I looked into VirtualStack.  VirtualStack then lead me to the Raw Importer and the FileInfoVirtualStack.  The raw importer and the FIVStack work perfectly with my data except for one minor issue, the image is flipped vertically.  This is due to the fact that the images in my format are stored using the bottom left corner as the starting point for the pixels.  While it appears that ImageJ assumes the image starting point is the top left.
 
So I need to invert how the pixels are put or read into the stack without having to load all the data into memory.  The solution appears to be either overriding a stack class or adding a function to the class that allows the user to specify the order of the pixels.
 
The second option seems to be the easiest solution, however would require someone on the dev team to add the function to stack class.  If thats not an option can someone provide some instructions on how to implement the new class?
 
Any input on this issue is greatly appreciated.
 
Thanks.

[ctrueden]

Hi Terry,

I have written an importer for large single file that contains the entire
> image sequences.
>

Have you considered writing a Bio-Formats reader class instead?
  http://www.loci.wisc.edu/software/bio-formats
  http://www.loci.wisc.edu/bio-formats/bio-formats-java-library

http://trac.openmicroscopy.org.uk/ome/browser/bioformats.git/components/bio-formats/doc/reader-guide.txt

All Bio-Formats readers are automatically capable of producing ImageJ
virtual stacks, with no extra work on your part.

If you do decide to go this route, the Bio-Formats developers would be
happy to assist with any questions you might have.

Regards,
Curtis


On Fri, Nov 4, 2011 at 10:20 AM, Terry Jordan <[hidden email]>wrote:

> I have written an importer for large single file that contains the entire
> image sequences.  My first implementation just used the ImageStack, but it
> was brought to my attention that the files may exceed the size of memory,
> so I looked into VirtualStack.  VirtualStack then lead me to the Raw
> Importer and the FileInfoVirtualStack.  The raw importer and the FIVStack
> work perfectly with my data except for one minor issue, the image is
> flipped vertically.  This is due to the fact that the images in my format
> are stored using the bottom left corner as the starting point for the
> pixels.  While it appears that ImageJ assumes the image starting point is
> the top left.
>
> So I need to invert how the pixels are put or read into the stack without
> having to load all the data into memory.  The solution appears to be either
> overriding a stack class or adding a function to the class that allows the
> user to specify the order of the pixels.
>
> The second option seems to be the easiest solution, however would require
> someone on the dev team to add the function to stack class.  If thats not
> an option can someone provide some instructions on how to implement the new
> class?
>
> Any input on this issue is greatly appreciated.
>
> Thanks.
>

[Terry Jordan]

I am really not interested in extending the development time for this importer.  Its is already developed for ImageJ for both imagestack (memory) and fileinfovirtualstack (disk), I just need the virtualstack to support flipping the pixel's y coordinates.
 
Thanks.

>>> "Curtis Rueden" <[hidden email]> 11/4/2011 11:42 AM >>>
Hi Terry,

I have written an importer for large single file that contains the entire
> image sequences.
>

Have you considered writing a Bio-Formats reader class instead?
  http://www.loci.wisc.edu/software/bio-formats 
  http://www.loci.wisc.edu/bio-formats/bio-formats-java-library 

http://trac.openmicroscopy.org.uk/ome/browser/bioformats.git/components/bio-formats/doc/reader-guide.txt 

All Bio-Formats readers are automatically capable of producing ImageJ
virtual stacks, with no extra work on your part.

If you do decide to go this route, the Bio-Formats developers would be
happy to assist with any questions you might have.

Regards,
Curtis


On Fri, Nov 4, 2011 at 10:20 AM, Terry Jordan <[hidden email]>wrote:

> I have written an importer for large single file that contains the entire
> image sequences.  My first implementation just used the ImageStack, but it
> was brought to my attention that the files may exceed the size of memory,
> so I looked into VirtualStack.  VirtualStack then lead me to the Raw
> Importer and the FileInfoVirtualStack.  The raw importer and the FIVStack
> work perfectly with my data except for one minor issue, the image is
> flipped vertically.  This is due to the fact that the images in my format
> are stored using the bottom left corner as the starting point for the
> pixels.  While it appears that ImageJ assumes the image starting point is
> the top left.
>
> So I need to invert how the pixels are put or read into the stack without
> having to load all the data into memory.  The solution appears to be either
> overriding a stack class or adding a function to the class that allows the
> user to specify the order of the pixels.
>
> The second option seems to be the easiest solution, however would require
> someone on the dev team to add the function to stack class.  If thats not
> an option can someone provide some instructions on how to implement the new
> class?
>
> Any input on this issue is greatly appreciated.
>
> Thanks.
>

[dscho]

Dear Terry,

On Fri, 4 Nov 2011, Terry Jordan wrote:

> I am really not interested in extending the development time for this
> importer.  Its is already developed for ImageJ for both imagestack
> (memory) and fileinfovirtualstack (disk), I just need the virtualstack
> to support flipping the pixel's y coordinates.

You will probably realize in a while that a little time spent now on
converting it into a Bio-Formats importer will save you a lot of time
later. Because invariably you _will_ end up "reinventing the wheel", i.e.
rewriting large parts of what Bio-Formats provides for free. And you
_will_ end up fixing bugs in those parts of your code.

I say this because I think that the only way to fix your problem is to
reimplement what Bio-Formats did for such file formats.

Hth,
Johannes

[Bill Mohler]

How about just inverting the order of your pixel arrays as you read them
in through your importer?


On 11/4/11 1:55 p.m., Johannes Schindelin wrote:

> Dear Terry,
>
> On Fri, 4 Nov 2011, Terry Jordan wrote:
>
>> I am really not interested in extending the development time for this
>> importer.  Its is already developed for ImageJ for both imagestack
>> (memory) and fileinfovirtualstack (disk), I just need the virtualstack
>> to support flipping the pixel's y coordinates.
> You will probably realize in a while that a little time spent now on
> converting it into a Bio-Formats importer will save you a lot of time
> later. Because invariably you _will_ end up "reinventing the wheel", i.e.
> rewriting large parts of what Bio-Formats provides for free. And you
> _will_ end up fixing bugs in those parts of your code.
>
> I say this because I think that the only way to fix your problem is to
> reimplement what Bio-Formats did for such file formats.
>
> Hth,
> Johannes
>

[ctrueden]

Hi Bill (& Terry),

How about just inverting the order of your pixel arrays as you read them in
> through your importer?
>

The problem is that ImageJ's built-in support for virtual stacks uses the
"FileInfo" idea where you just specify the offsets to your planar data,
pixel type, length of scanline, etc., and let ImageJ take care of actually
reading in the planes. In the case of a virtual stack, it does this on
demand. So as Terry says, for this approach to work with his data, he needs
FileInfo to support Y coordinate directionality. Windows BMP is famous for
being similarly "upside down."

Maybe there is a feature of ImageJ's virtual stacks that would allow Terry
to do what he wants with no changes—I don't know. Or maybe Wayne will add
support for inverted Y coordinates. Obviously, that would be the least work
for Terry.

I agree with Johannes's point that implementing a reader in the Bio-Formats
framework can ultimately save time, although in Terry's case he has already
done the work as a FileInfo, so he's probably right that switching to BF at
this point would extend his development time. But it would make his file
format accessible from a much larger collection of software packages (see
http://www.loci.wisc.edu/bio-formats/applications for a partial list).

Anyway, in ImageJ2 we will have a special IOPlugin for file format readers
& writers, which provides a more structured contract for implementing these
things. And of course it will give you virtual stacks for free, too.

Regards,
Curtis


On Fri, Nov 4, 2011 at 1:02 PM, Bill Mohler <[hidden email]> wrote:

> How about just inverting the order of your pixel arrays as you read them
> in through your importer?
>
>
>
> On 11/4/11 1:55 p.m., Johannes Schindelin wrote:
>
>> Dear Terry,
>>
>> On Fri, 4 Nov 2011, Terry Jordan wrote:
>>
>>  I am really not interested in extending the development time for this
>>> importer.  Its is already developed for ImageJ for both imagestack
>>> (memory) and fileinfovirtualstack (disk), I just need the virtualstack
>>> to support flipping the pixel's y coordinates.
>>>
>> You will probably realize in a while that a little time spent now on
>> converting it into a Bio-Formats importer will save you a lot of time
>> later. Because invariably you _will_ end up "reinventing the wheel", i.e.
>> rewriting large parts of what Bio-Formats provides for free. And you
>> _will_ end up fixing bugs in those parts of your code.
>>
>> I say this because I think that the only way to fix your problem is to
>> reimplement what Bio-Formats did for such file formats.
>>
>> Hth,
>> Johannes
>>
>>