The serialization part is now complete. That is, lcms2 should be able to read all tags it understands on all profiles in the wide world. Since it understands all tags that are, or have been part of any ICC spec, present or past, a lot of profiles should be readed by current code.
I have been lately worried about stability and qualification. If lcms2 want any success, it should be tolerant with ill-formed profiles. I say tolerant, not permissive, because crafted profiles may be used by the bad guys to introduce exploits. We don't want wargames again, right?
I have compiled along the +10 years of lcms life, a "Zoo" of profiles. This collection includes actually about 1500 assorted profiles, going from the widely distributed v2 sRGB to rare corner cases, like devicelinks holding 12-ink separations. Not to be very common.
Some of those profiles are broken. Well, not completely broken. They have slightly malformed tags, like colorants using a bad type, descriptions with wrong char count, bad sizes in the header...
To check how well lcms2 may deal with that, I wrote a small program that runs across every single profile in the Zoo and then reads every tag in the profile. The code should reject the unuseable tags and behave nicely if some information can be recovered. It cannot in anycase segfault or leak resources.
So, keeping my fingers crossed, I executed the program and ... almost! one segmentation fault. Ok, it was a bug, fixed. Run it again and .. success! no memory leaks, lots of tags discarded and a cool "all is ok" printf'd at the end. Pfew!
Subscribe to:
Post Comments (Atom)
Have you thought about making hardness tests by deliberately introducing errors in the profiles by poking a random byte in the profile binary before letting lcms read it?
ReplyDeleteA good idea, but... some profiles may be more "sensible" than others using this technique. Just take SWOP for example, each AToB tag is 41478 bytes, BToA are 145588 and the gamut tag is 37009. All together are 556729 (two A2B luts are collapsed on same table) The profile size is 557168, then there is a 99.92% of chance that the byte changed belongs to one of those tables. That is, a color is changed but no vital area is destroyed. On smaller profiles like sRGB that's a different story, and your idea is very good on those, so many thanks!
ReplyDelete