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
