[vtkusers] Bug in vtkTIFFReader reading multi-paged tiff file
Maarten Beek
beekmaarten at yahoo.com
Fri Jan 17 14:26:55 EST 2014
Setting the opacity in the callback would enable me to check the order in which they were added to the renderer:
if( m_pWidget->m_pDrrActor && m_pWidget->m_pTIFFActor )
{
vtkPropCollection* props = m_pWidget->m_pRenderer->GetViewProps();
props->InitTraversal();
vtkProp* prop = NULL;
while( prop = props->GetNextProp() )
{
if( prop == vtkProp::SafeDownCast(m_pWidget->m_pDrrActor) )
{
m_pWidget->m_pDrrActor->SetOpacity(1.0);
m_pWidget->m_pTIFFActor->SetOpacity(0.5);
break;
}
if( prop == vtkProp::SafeDownCast(m_pWidget->m_pTIFFActor) )
{
m_pWidget->m_pTIFFActor->SetOpacity(1.0);
m_pWidget->m_pDrrActor->SetOpacity(0.5);
break;
}
}
}
Didn't solve to problem though....
I have made an algorithm that adds an alpha value to the tiff image:
vtkImageIterator<T> inIt(inData, outExt);
vtkImageIterator<float> outIt(outData, outExt);
int numIn = inData->GetNumberOfScalarComponents();
float alpha = self->GetAlpha();
// Loop through ouput pixels
while( !outIt.IsAtEnd() )
{
T* inSI = inIt.BeginSpan();
float* outSI = outIt.BeginSpan();
float* outSIEnd = outIt.EndSpan();
while( outSI < outSIEnd )
{
// now process the components
for( int i = 0; i < numIn; ++i )
{
*outSI = static_cast<float>(*inSI);
++outSI;
++inSI;
}
*outSI = alpha;
++outSI;
}
inIt.NextSpan();
outIt.NextSpan();
}
in order to go through vtkImageActor::HasTranslucentPolygonalGeometry() successfully.
Didn't solve it either.
I checked an older app of me in which I overlayed a transparent binary image on top of its original image. This worked fine using vtkActors. But in the example both images had the same extent and the order of the actors was predetermined.
Maarten
On Thursday, January 16, 2014 5:30:47 PM, David Gobbi <david.gobbi at gmail.com> wrote:
On Thu, Jan 16, 2014 at 3:13 PM, Maarten Beek <beekmaarten at yahoo.com> wrote:
> I think I want to blend 50/50, so I could set the opacity accordingly in a
> callback initiated by a StartRender event?
You can set the opacity anywhere. You just have to make sure that the opacity
is set correctly, and you have to make sure that the images are in the
correct order. The thing about the images being in the correct order
is non-negotiable. You have to do it. Playing with depth isn't going
to help. The images actually have to be rendered in the right order
(an opaque image first, and a 50% opacity image after).
> I have played around with vtkImageStack; I seemed to get only the first (or
> last) image of the stack or (with transparency) all images blended
> together... I want one image of the stack blended with another (2d) image.
> Secondly, I thought creating 100 actors and adding them to a stack was quite
> slow.
Were you setting layer numbers (in the vtkImageProperty) for the images that
you added to the stack? Were you setting VisibilityOff for the images that you
didn't want to show, and setting the correct Opacity for the images that you
wanted to blend?
David
> On Thursday, January 16, 2014 4:58:53 PM, David Gobbi
> <david.gobbi at gmail.com> wrote:
> On Thu, Jan 16, 2014 at 2:45 PM, Maarten Beek <beekmaarten at yahoo.com> wrote:
>> vtkImageActor::HasTranslucentPolygonalGeometry() seems to want image data
>> of
>> type unsigned char and 2 or 4 components in order to do transparency. I'm
>> using vtkImageShiftScale to get unsigned char and am working on an
>> algorithm
>> to add an alpha component to my one component tiff data. Curious if this
>> does the trick.
>
> I strongly suggest that you use vtkImageSliceMapper and vtkImageSlice
> to display your images instead of using vtkImageActor.
>
>> I can understand the order is important if one of the actor is opaque, but
>> why would this still be important when both are 50% transparent.
>
> That's not how alpha-blending works. If both images are 50%, then the
> frontmost image is displayed at 50%, and the second image gets 25%,
> and the background gets the remaining 25%. That's how translucency
> works, both in real-life and in computer graphics.
>
> If you want to blend images 50/50, then the frontmost image should have
> 50% opacity and the backmost image should have 100% opacity.
>
>> In my app the loading of each image is initiated through a button. I would
>> like to create an app which is independent of the order in which the user
>> clicks these buttons.
>
> Order is crucial. That's why I recommend that you use vtkImageStack.
> It makes it possible to explicitly set the layer number for each image.
>
> - David
>
>
>
>> On Thursday, January 16, 2014 3:25:11 PM, David Gobbi
>> <david.gobbi at gmail.com> wrote:
>> Are you using vtk-master (or perhaps a vtk 6.1 release candidate)?
>> The TIFF reader had a serious multi-frame bug in older versions.
>>
>> First, note that the vtkTIFFReader doesn't just give you the raw data
>> from the files, it seems to pass it through a lookup table sometimes.
>> And I'm not sure exactly how it deals with alpha, and to be honest,
>> I wouldn't trust it.
>>
>> I'm really not sure what you mean when you say "The order of adding
>> the actors to the renderer matters, but I try to avoid this by using
>> transparency." The order in which you add images is _crucial_ when
>> you are using transparency.
>>
>> Are you using the vtkImageStack? It's a class that is designed
>> specifically to handle layered rendering of images.
>>
>> David
>>
>>
>>
>> On Thu, Jan 16, 2014 at 12:40 PM, Maarten Beek <beekmaarten at yahoo.com>
>> wrote:
>>> Hi David,
>>>
>>> Is it possible to show all images in a multi-paged tiff transparently?
>>>
>>> Only when I show the 1st image (page), I see a 2nd 2d image (both are
>>> transparent).
>>> As soon as I move to another tiff image (page), the 2d image disappears.
>>> It
>>> returns when I move back to the 1st tiff page.
>>>
>>> The multi-paged tiff is one component, and I am thinking of an algorithm
>>> to
>>> add an alpha component, but can hardly believe this would be required...
>>>
>>> The order of adding the actors to the renderer matters, but I try to
>>> avoid
>>> this by using transparency.
>>>
>>> Moving one image in front of the other by changing its z-coordinate using
>>> vtkImageActor::SetPosition() doesn't help.
>>>
>>> Maarten
>>>
>>>
>>>
>>> On Friday, November 8, 2013 4:36:06 PM, Maarten Beek
>>> <beekmaarten at yahoo.com>
>>> wrote:
>>> Hi David,
>>>
>>> Using VTK 6.0.0, sorry ;-)
>>>
>>> Should I send you the tiff file so you can play with it?
>>>
>>> Now I seem to have your attention:
>>>
>>> - How do I display a multi-page tif? I don't seem to see the different
>>> images using a vtkImageSlice.
>>>
>>> - What would be good values for the window and level parameters? I am
>>> using
>>> window = range[1]-range[0] and level = 0.5*(range[0]+range[1]) which
>>> works
>>> ok for this multi-page tif, but gets me nowhere when I try to display a
>>> drr.
>>>
>>> Thanks - Maarten
>>>
>>>
>>>
>>>
>>>
>>> On Friday, November 8, 2013 4:23:23 PM, David Gobbi
>>> <david.gobbi at gmail.com>
>>> wrote:
>>> Hi Maarten,
>>>
>>> Which version of VTK are you using? I believe that this bug has been
>>> fixed in the master branch by a commits in the following topic merge:
>>> http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=7e3d5270
>>>
>>> It was not fixed in time for VTK 5.10, however.
>>>
>>> David
>>>
>>>
>>> On Fri, Nov 8, 2013 at 2:12 PM, Maarten Beek <beekmaarten at yahoo.com>
>>> wrote:
>>>> Hi all,
>>>>
>>>> vtkTIFFReader crashed for me while loading a multi-paged tiff file.
>>>>
>>>> The crash occured in vtkTIFFReader::ReadGenericImage(), because
>>>> this->OutputExtent was not set (still NULL).
>>>> The scalar type for the image I was loading was unsigned short, so it
>>>> happened at line 1368.
>>>>
>>>> I changed void vtkTIFFReader::ReadVolume(void* buffer) into void
>>>> vtkTIFFReader::ReadVolume(void* buffer, int outExt[6]) and added the
>>>> line
>>>> this->outputExtent = outExt.
>>>>
>>>> This solved my crash.
>>>> I am not sure I am on to something, but thought to let you know.
>>>>
>>>> Maarten
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140117/d42082ba/attachment.html>
More information about the vtkusers
mailing list