Another long shot - any chance that windows printing is interpreting the
unsigned short as a multi-byte character type (equivalent of the issues
when printing unsigned char pixels) - try casting to int when displaying to
see if it changes anything.
On Thu, Dec 14, 2017 at 8:22 AM, Gib Bogle <***@auckland.ac.nz> wrote:
> I modified the VectorImageToImageAdaptor example to get this:
>
>
> typedef itk::RGBPixel<unsigned short> PixelType;
> typedef itk::VectorImage<PixelType,2> ImageType_u16;
> ImageType_u16::Pointer image;
>
> typedef itk::ImageFileReader<ImageType_u16> ReaderType;
> ReaderType::Pointer reader = ReaderType::New();
> reader->SetFileName(filename);
> reader->Update();
> image = reader->GetOutput();
>
> int width = image->GetLargestPossibleRegion().GetSize()[0];
> int height = image->GetLargestPossibleRegion().GetSize()[1];
> int depth = image->GetLargestPossibleRegion().GetSize()[2];
> printf("Image dimensions: width, height: %d %d\n",width,height);
> printf("NumberOfComponentsPerPixel: %d\n", image->
> GetNumberOfComponentsPerPixel());
>
> typedef itk::VectorImageToImageAdaptor<PixelType, 2> ImageAdaptorType;
> ImageAdaptorType::Pointer adaptor = ImageAdaptorType::New();
> adaptor->SetExtractComponentIndex(0);
> adaptor->SetImage(image);
>
> itk::Index<2> index;
> index[0] = 3084;
> index[1] = 3072;
>
> std::cout << adaptor->GetPixel(index) << std::endl;
>
>
> The size of the image is reported correctly (4656x4656) but although the
> number of components is shown as 4, GetPixel returns three values (2 0 0),
> at a location where I know (from ImageJ) that the green channel has a pixel
> value of more than 2000.
> ------------------------------
> *From:* Richard Beare <***@gmail.com>
> *Sent:* Wednesday, 13 December 2017 7:57 p.m.
> *To:* Gib Bogle
> *Cc:* DÅŸenan ZukiÄ; insight-***@itk.org
> *Subject:* Re: [ITK-users] [ITK] Getting info from a very big image file
>
> I guess there are a number of things you might want to check out.
> 1) Viewers that can handle 16 bit colour channels in tiffs - my guesses
> would be itksnap, imageJ. Looks like you've succeeded with imageJ
>
> 2) Extracting a single channel - VectorImageToImageAdaptor
>
> Can't see what is wrong with your code, but check the minimum as well, and
> also confirm the pixel type with tiffinfo - perhaps it is signed?
>
> On Wed, Dec 13, 2017 at 4:46 PM, Gib Bogle <***@auckland.ac.nz> wrote:
>
>> I just needed to put "itk::" before RGBPixel. I still don't know how to
>> get the R, G and B channels. Are they in separate buffers?
>> ------------------------------
>> *From:* Insight-users <insight-users-***@itk.org> on behalf of Gib
>> Bogle <***@auckland.ac.nz>
>> *Sent:* Wednesday, 13 December 2017 5:57 p.m.
>> *To:* DÅŸenan ZukiÄ
>> *Cc:* insight-***@itk.org
>> *Subject:* [FORGED] Re: [ITK-users] [ITK] Getting info from a very big
>> image file
>>
>>
>> Hi Dzenan,
>>
>>
>> I did:
>>
>> #include "itkRGBPixel.h"
>>
>> typedef RGBPixel<unsigned short> PixelType;
>>
>> but VS2010 tells me "Error: RGBPixel is not a template"
>>
>>
>> Cheers, Gib
>> ------------------------------
>> *From:* DÅŸenan ZukiÄ <***@gmail.com>
>> *Sent:* Wednesday, 13 December 2017 4:22 p.m.
>> *To:* Gib Bogle
>> *Cc:* Lowekamp, Bradley (NIH/NLM/LHC) [C]; Matt McCormick;
>> insight-***@itk.org
>> *Subject:* Re: [ITK-users] [ITK] Getting info from a very big image file
>>
>> Why don't you try reading it with:
>> tyepdef RGBPixel<unsigned short> PixelType;
>>
>> Embedded thumbnails might be ignored by the reader, it is definitely
>> worth a shot trying Brad's suggestion.
>>
>> Regards,
>> DÅŸenan
>>
>> On Tue, Dec 12, 2017 at 6:36 PM, Gib Bogle <***@auckland.ac.nz>
>> wrote:
>>
>>> Thanks Brad. The situation is complicated by the fact that there are 3
>>> channels (three colours). Tiffsplit is able to split the file into 396 127
>>> MB TIFFs and 396 thumbnail TIFFs. Irfanview can open one of the TIFFs, and
>>> it tells me that it is 4656x4656 and 48 bitsperpixel. That is, it contains
>>> 3 16-bit images of that size. Nothing is displayed in Irfanview - I'm
>>> rather surprised that it could open it at all.
>>> I'll try using that example, but the double complication of the
>>> included thumbnails and the 3 colours might stymie it.
>>>
>>> Cheers, Gib
>>> ________________________________________
>>> From: Lowekamp, Bradley (NIH/NLM/LHC) [C] <***@mail.nih.gov>
>>> Sent: Wednesday, 13 December 2017 3:51 a.m.
>>> To: Matt McCormick; Gib Bogle
>>> Cc: insight-***@itk.org
>>> Subject: Re: [ITK] [ITK-users] Getting info from a very big image file
>>>
>>> Gib,
>>>
>>> I have not tested this, but the LSMImageIO is derived from the
>>> TIFFImageIO, and LSMImageIO::Read does just call TIFFImageIO. So the
>>> chances are very good that it supports streamed reading.
>>>
>>> I updated the TIFFImageIO to support stream reading of the individual
>>> pages in the TIFF stack some time ago.
>>>
>>> You may find the following example useful to determining if the
>>> functionality is there:
>>> https://github.com/InsightSoftwareConsortium/ITK/blob/master
>>> /Examples/IO/ImageReadExtractWrite.cxx
>>>
>>>
>>> You can see the usage of âUpdateOutputInformationâ followed by the
>>> ExtractImageFilter, this can be a very powerful and efficient pattern for
>>> working with large images. The ExtractImageFilter can be used to create a
>>> 3D to 2D image from itâs input volume.
>>>
>>> Brad
>>>
>>>
>>> On 12/11/17, 10:56 PM, "Matt McCormick" <***@kitware.com>
>>> wrote:
>>>
>>> Hi Gib,
>>>
>>> Call
>>>
>>> reader->UpdateOutputInformation();
>>>
>>> instead of
>>>
>>> reader->Update();
>>>
>>> to get the LargestPossibleRegion populated without loading the pixel
>>> buffer.
>>>
>>>
>>> The image IO has to support streaming to read in only a
>>> RequestedRegion -- unfortunately, I do not think the LSMImageIO
>>> supports this at this time.
>>>
>>> HTH,
>>> Matt
>>>
>>> On Mon, Dec 11, 2017 at 10:44 PM, Gib Bogle <***@auckland.ac.nz>
>>> wrote:
>>> > Hello,
>>> >
>>> >
>>> > I am wanting to work with a 50 GB LSM file (3D). The first step
>>> is to be
>>> > able to get the image info: width, height and depth. I have code
>>> that works
>>> > on a small LSM file
>>> >
>>> >
>>> > im_u16 = reader->GetOutput();
>>> > width = im_u16->GetLargestPossibleRegion().GetSize()[0];
>>> > height = im_u16->GetLargestPossibleRegion().GetSize()[1];
>>> > depth = im_u16->GetLargestPossibleRegion().GetSize()[2];
>>> >
>>> >
>>> > but I see that to do this the whole image must be loaded into
>>> memory. When
>>> > I start the program running with the big file I can see that it is
>>> going to
>>> > exceed the host machine's 32 GB. Is there a way to get the image
>>> dimensions
>>> > without loading the whole image? What I am hoping to do is split
>>> the file
>>> > into 2D TIFF files - is there any way to extract a 2D slice
>>> without reading
>>> > the whole image? Or will I be forced to run on a machine with
>>> more than 50
>>> > GB of RAM?
>>> >
>>> >
>>> > Thanks in advance for any suggestions.
>>> >
>>> >
>>> > Best regards
>>> >
>>> > Gib
>>> >
>>> >
>>> > The ITK community is transitioning from this mailing list to
>>> > discourse.itk.org. Please join us there!
>>> > ________________________________
>>> > Powered by www.kitware.com
>>> >
>>> > Visit other Kitware open-source projects at
>>> > http://www.kitware.com/opensource/opensource.html
>>> >
>>> > Kitware offers ITK Training Courses, for more information visit:
>>> > http://www.kitware.com/products/protraining.php
>>> >
>>> > Please keep messages on-topic and check the ITK FAQ at:
>>> > http://www.itk.org/Wiki/ITK_FAQ
>>> >
>>> > Follow this link to subscribe/unsubscribe:
>>> > http://public.kitware.com/mailman/listinfo/insight-users
>>> >
>>> The ITK community is transitioning from this mailing list to
>>> discourse.itk.org. Please join us there!
>>> ________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.php
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/insight-users
>>> The ITK community is transitioning from this mailing list to
>>> discourse.itk.org. Please join us there!
>>> ________________________________________
>>> Community mailing list
>>> ***@itk.org
>>> http://public.kitware.com/mailman/listinfo/community
>>>
>>>
>>> The ITK community is transitioning from this mailing list to
>>> discourse.itk.org. Please join us there!
>>> ________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.php
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/insight-users
>>>
>>
>>
>> The ITK community is transitioning from this mailing list to
>> discourse.itk.org. Please join us there!
>> ________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://www.kitware.com/products/protraining.php
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/insight-users
>>
>>
>