While the object-oriented interface and calling convention for xff objects is suitable in most situations (e.g. a method that alters an object by, for instance, adding a volume-of-interest to a VOI file), there is the occasional need to create a temporary working copy of an object which, once the task is completed, can be discarded. Alternatively, it might be desired to create a derivate object (e.g. a VMR with a spatial filter applied) without changing the source object.
In both these situations, the obj.CopyObject call brings the desired solution.
AFT::CopyObject - copy object to new
FORMAT: copied = obj.CopyObject;
No input fields
Output fields:
copied xff object with own storage in global xffcont
TYPES: ALL
% load a VMR vmr = xff('new:vmr'); % create a copy (does NOT YET double the allocated memory!) smoothed = vmr.CopyObject; % smooth VMRData smoothed.VMRData = uint8(floor(smoothdata3(double(vmr.VMRData), [2, 2, 2]))); % histogram of differences hist(vmr.VMRData(vmr.VMRData ~= 0) - smoothed(vmr.VMRData ~= 0), 100);
Just as mentioned in the example above, due to Matlab's internal (and genially coded) logic, the memory requirements of a copy object are almost 0 (only the pointers in the global struct need a new copy). Only when a member in the copied object (in this case the VMRData field) is altered, will the memory manager of Matlab allocate a new chunk of memory. This is particularly useful if the copied object is only created because some text or other minor alteration is made for compatibility reasons for internal processing!