I am having some trouble understanding the intent of the following
comment versus what I observe:
----------
// Read and write raw data. The only way those function would work and
keep consistence with normal read and write
// is to do an additional step of serialization. That means, readRaw
would issue a normal read and then convert the obtained
// data to raw bytes by using the "write" serialization logic. And
vice-versa. I know this may end in situations where
// raw data written does not exactly correspond with the raw data
proposed to cmsWriteRaw data, but this approach allows
// to write a tag as raw data and the read it as handled.
cmsUInt32Number CMSEXPORT cmsReadRawTag(cmsHPROFILE hProfile,
cmsTagSignature sig, void* data, cmsUInt32Number BufferSize)
----------
To me it seems to be saying that cmsReadRawTag will *always* return the
serialized result of a "cooked" tag - ie what
you will get after directly calling cmsReadTag(). And it does this to be
consistent.
However the code isn't doing that because we have
// It is already read?
if (Icc -> TagPtrs[i] == NULL) {
// No yet, get original position
Offset = Icc ->TagOffsets[i];
TagSize = Icc ->TagSizes[i];
...
...
}
Only if we get past that, and some other code, do we reach
-----------
// Already read, or previously set by cmsWriteTag(). We need to
serialize that
// data to raw in order to maintain consistency.
_cmsUnlockMutex(Icc->ContextID, Icc ->UsrMutex);
Object = cmsReadTag(hProfile, sig);
if (!_cmsLockMutex(Icc->ContextID, Icc ->UsrMutex)) return 0;
if (Object == NULL) goto Error;
// Now we need to serialize to a memory block: just use a memory
iohandler
-----------
So this means that if you
1) Write a tag using cmsWriteRawTag
2) Call cmsReadRawTag() - you get back the "raw" data
3) Call cmsReadTag() - you "cook" the tag
4) Call cmsReadRawTag() - you now get back the serialized cooked data
which may differ from (2)
as I have observed with code using the above sequence.
And this seems to me to contradict what the code comment I started with
implies.
For clarity, regarding :-
// I know this may end in situations where
// raw data written does not exactly correspond with the raw data
proposed to cmsWriteRaw data, but this approach allows
// to write a tag as raw data and the read it as handled.
Yes, I get that it means write and read back may differ - but I am
seeing write and read back be inconsistent which
is what I think the comment is saying the implementation will avoid ..
-phil.
|
