-
Notifications
You must be signed in to change notification settings - Fork 175
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
cmsOpenProfileFromMem() successfully returning a profile for corrupted profile #157
Comments
FYI: rendering intent in this profile equals 0x10000, which is invalid. |
Thanks @boxerab. It would be nice to have a more generic function to detect profile corruption, since I imagine there may be many other ways a profile can be corrupted. A single function which each each of these corruption possibilities (or most of them) would be worthwhile. |
Yes. libpng seems to have such a routine - you could use that as a guide for a sanity check on profile. |
The .jp2 image in http://www.fnordware.com/j2k/jp2samples.html seems to have a corrupted embedded profile. Little CMS opens this profile without complaint, and cmsOpenProfileFromMem() returns a profile object.
In the end though, the profile is so broken that the loaded image looks terrible.
Being able to load what is loadable though is still useful. For instance, for this particular case, the JP2 header of this file has no color space information so the profile helps us to at least determine that the image is RGB. But after this, I would like to be able to detect that the rest of the profile is bogus and either drop it with a warning or maybe a popup asking the user what to do, or whatnot (this is for GIMP).
In this issue where we have been discussing it with OpenJPEG developers, they proposed to get the profile info, and if the size is zero, then the profile might be corrupted: uclouvain/openjpeg#1103 (comment)
But we are not sure if a valid profile couldn't have no profile description tag as well, could it?
How do you propose to detect such a profile corruption so that we know if we should drop it (or at least interactively propose to drop it)?
The text was updated successfully, but these errors were encountered: