Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

random data in areaDetector TIFF header #519

Open
mp49 opened this issue Nov 11, 2024 · 1 comment
Open

random data in areaDetector TIFF header #519

mp49 opened this issue Nov 11, 2024 · 1 comment
Labels

Comments

@mp49
Copy link
Contributor

mp49 commented Nov 11, 2024

I came across an issue with the TIFF file writing plugin in ADCore. I am adding parameters from my areaDetector driver to the NDAttributeList, using an XML file like:

<?xml version="1.0" standalone="no" ?>
<Attributes>
  <Attribute name="SizeX" type="PARAM"  source="SIZE_X" datatype="INT"     description=""/>
  <Attribute name="SizeY" type="PARAM"  source="SIZE_Y" datatype="INT"     description=""/>
</Attributes>

And this should produce a TIFF header that includes:

Tag 65012: SizeX:1024
Tag 65013: SizeY:1024

However, I mostly see the integer data are corrupted, like:

Tag 65012: SizeX:4742400410323518464
Tag 65013: SizeY:4742400410323518464

I think I’ve tracked it down to the TIFF file writing plugin. When 64-bit integer support was added, the existing 32-bit support was removed, and we treat all integers the same:

In NDFileTIFF.cpp:

switch (attrDataType) {
            case NDAttrInt8:
            case NDAttrUInt8:
            case NDAttrInt16:
            case NDAttrUInt16:
            case NDAttrInt32:
            case NDAttrUInt32:
            case NDAttrInt64:
            case NDAttrUInt64: {
                pAttribute->getValue(attrDataType, &value.i64);
                epicsSnprintf(tagString, sizeof(tagString)-1, "%s:%lld", attributeName, value.i64);
                break;
            }
              ……

However, the attribute data is read via ‘getValue’ using a void pointer and I think that’s causing an issue – converting data types without a proper type cast. I was able to solve it by restoring the 32-bit support:

switch (attrDataType) {
            case NDAttrInt8:
            case NDAttrUInt8:
            case NDAttrInt16:
            case NDAttrUInt16:
            case NDAttrInt32:
            case NDAttrUInt32: {
                pAttribute->getValue(attrDataType, &value.i32);
                epicsSnprintf(tagString, sizeof(tagString)-1, "%s:%d", attributeName, value.i32);
                break;
            }
            case NDAttrInt64:
            case NDAttrUInt64: {
                pAttribute->getValue(attrDataType, &value.i64);
                epicsSnprintf(tagString, sizeof(tagString)-1, "%s:%lld", attributeName, value.i64);
                break;
            }
              …..
@MarkRivers
Copy link
Member

I have created an alternative pull request for this: #520

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants