Dicomwrite, how to overcome limits of 32-bit?

I am reading a DICOM file, anonymising specific fields in metadata, and applying a mask to remove certain parts of the image. This runs fine on most of my data, but for some of the larger files I run into an error:

% Error using dicomwrite>checkDataDimensions (line 808)
% Images must contain fewer than 2^32 - 1 bytes of data.
% Error in dicomwrite (line 193)
% checkDataDimensions(X);
% Error in dicomanon (line 162)
%     dicomwrite(X, filename_out, metadata, ...
% Error in test_anonymising_mallus_vjan30 (line 229)
%             dicomanon(Filename_read,Filename_save,'keep',List_fields_to_keep,'update',Vals_study);

The files in question do exceed the 2^32-1 limit, however I am using the 64-bit version of MatlabR2018b. Looking more closely at the dicomwrite and checkDataDimensions function, I see there is a specific section that checks the size and sends an error when the size is too large. I've tried amending or removing this function (under the assumption that this is a remnant of 32bit), but anytime I run the code matlab just uses the old un-altered dicomwrite function, so I must be doing something wrong here...?

function checkDataDimensions(data)

% How many bytes does each element occupy in the file?  This assumes
% pixels span the datatype.
switch (class(data))
case {'uint8', 'int8', 'logical'}

    elementSize = 1;
    
case {'uint16', 'int16', 'double'}

    elementSize = 2;
    
case {'uint32', 'int32'}

    elementSize = 4;
    
otherwise

    % Let a later function error about unsupported datatype.
    elementSize = 1;
    
end

% Validate that the dataset/image will fit within 32-bit offsets.
max32 = double(intmax('uint32'));

if (any(size(data) > max32))
    
    error(message('images:dicomwrite:sideTooLong'))
    
elseif ((numel(data) * elementSize) > max32)
    
    error(message('images:dicomwrite:tooMuchData'))
    
end

NB: I've seen a similar question asked before without answer, but I was hoping someone would be able to help now as the 64 bit versions of Matlab are commonly used.

https://uk.mathworks.com/matlabcentral/answers/224465-why-is-dicomwrite-limited-to-2-32-1-bytes-of-data

Many thanks,

[Walter Roberson]

? My post in that thread about the technical limitations was an answer . It might not have been the answer you wanted to hear, but I do not think that it is the role of Mathworks to invent a new dicom standard .

Answer 1

[Guillaume]

As far as I know, the 2^32-1 limit is intrinsic to the DICOM format. The length in bytes of all objects is always encoded as a 32-bit integer, so no object can be longer than 2^32-1. Since DICOM is an international standard there is nothing that matlab can do about it. Certainly, the bitness of matlab is irrelevant here, it's the format that limits you here.

I don't know enough about dicom to tell you if it's possible to split an object too big into several objects.

[Walter Roberson]

2^32-2 it turns out

A bit more detail at

https://groups.google.com/forumit /m/#!topic/comp.protocols.dicom/-tO2v2aH010

Short summary: DICOM cannot handle larger images except as lossy compression , or as multiple compressed fragments each of which was under the limit. However because the compressed version has to be convertible to uncompressed the multi fragmented version cannot always be transferred . Also row and column limits are 16 bits and if you need more than 4gb you might be up against that limit as well .

[Tim Hoogenboom]

Thank you both for your responses, but there is still something I don't quite understand. I get that DICOM has limits in what it can handle, but if I try the following code on a DICOM file I already have, I get the same error.

x = dicomread(file);

dicomwrite(x);

Does this mean that the file originally is in a compressed format? or somehow multi-fragmented (it is a video, so perhaps frames are stored somehow seperately) as you mentioned, and dicomread changes this to create a file that is larger than original?

[Walter Roberson]

Try

dinfo = dicominfo(file);
x = dicomread(dinfo);
dicomwrite(x, newfilename, dinfo);