Several months ago, I filed a bug report for this issue which causes imread to intentionally damage image content.
This bug affects R2018b to at least R2020b. I am not sure if the issue has ever been resolved, since TMW doesn't publish all bug reports, and this particular one was never published. In the course of trying to answer a user's question, I wanted to know if the bug was still in the newer versions.
Since I don't have access to anything newer than R2019b, I figured it would suffice to use the forum RTE to run a test to see if the issue had been resolved. The results I'm getting are even more egregiously erroneous than the bug described above.
[mypicture theonlymap] = imread('LCTdissimilarity_unused_gct.gif','frames','all');
theonlymap
theonlymap =
0 0 0
0.0039 0.0039 0.0039
0.0078 0.0078 0.0078
0.0118 0.0118 0.0118
0.0157 0.0157 0.0157
0.0196 0.0196 0.0196
0.0235 0.0235 0.0235
0.0275 0.0275 0.0275
0.0314 0.0314 0.0314
0.0353 0.0353 0.0353
image_section = permute(mypicture(1,1,:,:),[1 4 2 3])
S = imfinfo('LCTdissimilarity_unused_gct.gif')
S =
Filename: '/users/mss.system.D24Ykr/LCTdissimilarity_unused_gct.gif'
FileModDate: '06-Aug-2021 00:21:16'
FileSize: 964
Format: 'GIF'
FormatVersion: '89a'
Left: 1
Top: 1
Width: 100
Height: 100
BitDepth: 8
ColorType: 'indexed'
FormatSignature: 'GIF89a'
BackgroundColor: 1
AspectRatio: 0
ColorTable: [256×3 double]
Interlaced: 'no'
DelayTime: 50
DisposalMethod: 'DoNotspecify'
As you can see, the returned data is completely wrong. Not only is imread() returning bad data, imfinfo() is too. That color table that imfinfo()/imread() is returning is a simple 256-step linear ramp from 0 to 1. That color table came out of thin air. Neither imread() nor imfinfo() acknowledge the existence of any frames other than frame 1. The fact that imfinfo() reports the wrong file size makes me wonder if the file were damaged, but if the file were somehow damaged when uploaded, I don't see how it could have been read without throwing an error and with such a perfectly wrong color table. This really smells like the solution to the prior bug was to simply remove the functionality to correctly handle multiframe gifs. The behavior is the same with all images I've tested.
Now I don't know if this is a problem with just this web-version of R2021a, or if it affects regular installations as well. If it does, then I need to file a bug report. If anyone is using something newer than R2020b, I'd appreciate if you could help me verify this behavior. The attached script and image file should return data as described by the comments therein.
EDIT: ... well I guess this isn't going anywhere, but now that I think about it, I have no idea how I'd even file a bug report on a version I don't have access to anyway (since I'd need the version dump and I can't reply with any amount of inevitable troubleshooting correspondence). I guess if it's broken now, it's just gonna stay broken.
Disclaimer: I checked the webdocs to see if there were some dramatic changes to intended usage, but I didn't notice anything. If there is some change that explains this and I'm just doing it wrong, feel free to call me out on it.
