[vtkusers] undo changes to binary vtkImageData

[David Gobbi]

>From Java you can get a vtkDataArray from the vtkImageData using
data.GetPointData().GetScalars(), but then it would be up to you to convert
the vtkDataArray into a java array and compute the difference.  You would
also have to find a Java function to do the compression, since
vtkDataCompressor doesn't have any methods that can be used from Java.

 - David


On Fri, Jan 28, 2011 at 8:43 PM, Jonathan Morra <jonmorra at gmail.com> wrote:

> So I'm in Java and I just realized that GetScalarPointer() isn't mapped to
> Java.  Is there an alternative?
>
>
> On Fri, Jan 28, 2011 at 7:11 PM, David Gobbi <david.gobbi at gmail.com>wrote:
>
>> On Fri, Jan 28, 2011 at 7:45 PM, Jonathan Morra <jonmorra at gmail.com>wrote:
>>
>>> I have a binary vtkImageData that a user can modify through some tools I
>>> provide them.  However, the user has requested an undo stack be made so they
>>> can go back through their changes.  In my case, storing a new binary
>>> vtkImageData every time the user changes it costs too much memory (these are
>>> large 3D volume sets).  Is there a way to store a difference between two
>>> binary vtkImageData's?  Ideally I'd like to have just one vtkImageData which
>>> is the current image and then a stack of vtkImageDifferences (I made that
>>> class up) which are themselves small, but say how to go to either the next
>>> or previous state of a binary vtkImageData.
>>>
>>> Does such a method exist?
>>>
>>
>> No, but it shouldn't be too hard to do this.  You can get a pointer to the
>> data by calling GetScalarPointer() on the image data.  The size of this data
>> (in bytes) will be product of the Dimensions, the NumberOfScalarComponents,
>> and the ScalarSize.
>>
>> So, you should easily be able to compute a bytewise difference between two
>> images.  There's no reason to write a new filter for this, since it's just a
>> simple for() loop.  Then, you can use vtkDataCompressor::Compress() to
>> compress the diff so that it can be efficiently stored.  By doing everything
>> bytewise, you don't have to worry about different datatypes, and you
>> shouldn't lose anything in terms of efficiency.
>>
>> If the image changes in size, then you could store a compressed copy of
>> the full image rather than dealing with the difficulty of diffing images of
>> different sizes.
>>
>> I hope this helps.
>>
>>   - David
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20110128/05e42a52/attachment.htm>