On 31 Jul 2012, at 14:59, Maria, Marti wrote:
because I extract the CurveSets from the original tag.
[…]
other data (like CurveSet) are indeed extracted from the read pipeline and
inserted in the new one
Here is the issue. Two pipelines are sharing same stage. When one is set
free, the other got corrupted. Just make a copy with cmsStageDup and all will
be solved.
Making the copy is very counter productive, since updating a tag would mean
in that way that all data is at least copied 3 times:
- from read tag to duplicated tag
- from duplicated tag to modified tag
- from modified tag to written tag (because the write will copy again)
cmsReadTag() returns a pointer to the tag object, then you make copy , modify
the copy and when you write it, the original object is discarded. After
writing you can free your modified copy.
This is for creating profiles, which is not a resource or time critical
operation.
Please consider following scenario: You read AtoB0 and got a pointer. Then
you modify the contents of this pointer and write it to AtoB1. Now you want
to create AtoB2, so you read again AtoB0,,, but wait, you don’t get what is
in the profile but AtoB1, since you modified the pointer Is that what you
want? Otherwise, you would need to read and parse the structure from disk
each time. Wouldn’t be better to read it just once and do caching? What if
the profile is reused thousands of times in color transforms?
Marti,
I follow your design principles, no problem. Yes, you need this flexibility.
But it is counter productive for my very specific setup
Does this also mean that if I update the sample data in a CLUT that I need
to copy the pipeline first ?
The procedure is always same. You read the pipeline with cmsReadTag(), what
you get should be treated as const. If you want to change a tag, make a copy
of the original, modify the copy and then write the copy over the original.
OK
That might indeed be a problem: the update will overwrite the link, and
release the memory that was assigned to the tag,
but the original tag still has the original data pointers, which the code
might try to copy on save (or something like that).
I’ve tried and it works ok. When you overwrite a linked tag, it gets just
“unlinked” and the original is preserved.
I have seen that too now (after implementing the link-check)
Let’s go for an example, AtoB0 is the original and AtoB1 points to the same
space that AtoB0
We have two possibilities
a) You write AtoB0: Then you replace the original. AtoB1 will still
point to AtoB0, and you got both tags changed
b) You write AtoB1: Then you replace the link, AtoB0 will keep its
original data and a brand new AtoB1 will be created. It no longer is linked
to anything.
I have fixed it now with a check on the link, because in the setup that it is
used in my case, the user only sees a number of shared tags, and he does not
know which one is the original, and which one is the link. As such, checking
the link, and if it is a link updating the referenced tag is the right thing to
do.
(and as confirmed, that works correctly)
Frank
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
