Affinity Photo and colorsync issue, maybe
I do believe this is a colorsync issue. Well, also my issue. You know, between the ears. I am using Affinity Photo. Getting to the point, when exporting as .tiff, the .tiff opened in PS CS5 does not look like what is in the Affinity Photo application. This never happens to me when using LR 6.4 and command E to finished of the size of the image file. Academically speaking, I thought the Affinity Photo application, when exported and opened in PS CS5 would to the same thing. Even in Affinity Photo print dialogue, the pdf image does not look like the image in the Affinity Photo window. I think I’ve tried every combination of settings in Affinity Photo. I just don’t know what else to do. Appreciate everyone’s advise. Cheers, David David B. Miller, Pharm. D., member Millers’ Photography dba Spinnaker Photo Imaging Center 3809 Alabama Street Bellingham, WA 98226-4585 360 739 2826 david@spinnakerphotoimagingcenter.com <mailto:david@spinnakerphotoimagingcenter.com>
AP is a nice program for lots of reasons, but color management isn't one of them. Their implementation of colorsync is a kludge at best. I've written to them extensively to point out a few of their shortcomings in that area, and I think they know it's bad but won't admit that it's broken until they have it fixed in a future release. At least that's my hope. They're releasing a Windows version very soon, so that's a major revision and hopefully we'll see some improvements on both platforms. They have a help blog but not many people there deal with color management. I stopped using AP because of their clumsy profiling, but I don't remember having the same issue you've got. Just make sure that when you open your file in PS that you assign the same working profile that was used in AP. It might not be embedding the correct one. -----Original Message----- From: Millers' Photography L.L.C. Sent: Thursday, March 24, 2016 11:31 PM To: colorsync-users@lists.apple.com Subject: Affinity Photo and colorsync issue, maybe I do believe this is a colorsync issue. Well, also my issue. You know, between the ears. I am using Affinity Photo. Getting to the point, when exporting as .tiff, the .tiff opened in PS CS5 does not look like what is in the Affinity Photo application. This never happens to me when using LR 6.4 and command E to finished of the size of the image file. Academically speaking, I thought the Affinity Photo application, when exported and opened in PS CS5 would to the same thing. Even in Affinity Photo print dialogue, the pdf image does not look like the image in the Affinity Photo window. I think I’ve tried every combination of settings in Affinity Photo. I just don’t know what else to do. Appreciate everyone’s advise. Cheers, David David B. Miller, Pharm. D., member Millers’ Photography dba Spinnaker Photo Imaging Center 3809 Alabama Street Bellingham, WA 98226-4585 360 739 2826 david@spinnakerphotoimagingcenter.com <mailto:david@spinnakerphotoimagingcenter.com>
On Mar 24, 2016, at 10:58 PM, John Castronovo <jc@technicalphoto.com> wrote:
AP is a nice program for lots of reasons, but color management isn't one of them.
You may be right. But, honestly, ArgyllCMS is so far superior to anything and everything else out there that it doesn't even occur to me to use anything else for color management...and, as such, I'm completely unaware of any limitations or faults Affinity Photo might have in that regards. So long as you don't use Affinity Photo (or Photoshop or anything else) to change an image's profile -- including for printing or to save for Web or the like -- then there isn't even the potential for problems. Use Argyll to convert the image to your preferred working space, do all your edits in the photo editor in that space, save in that space, and then use Argyll again to convert the image to the necessary output space. Your colors will thank you. Cheers, b&
On Mar 25, 2016, at 11:14 AM, Ben Goren <ben@trumpetpower.com> wrote:
ArgyllCMS is so far superior to anything and everything else out there
to what do you attribute this? it seems that cmm code for performing transformations must be very similar across most implementations; perhaps, all deriving from some common ancestor [seminal icc code?]: type & quality of profiles is what should make the difference [no?]. i’m amazed that cmm benchmarks do not exist [or, do they?]—in the way, e.g., engineers measure characteristics of other component types.
On Mar 25, 2016, at 9:01 AM, edward taffel <etaffel@me.com> wrote:
On Mar 25, 2016, at 11:14 AM, Ben Goren <ben@trumpetpower.com> wrote:
ArgyllCMS is so far superior to anything and everything else out there
to what do you attribute this?
Graeme Gill, its author.
it seems that cmm code for performing transformations must be very similar across most implementations; perhaps, all deriving from some common ancestor [seminal icc code?]: type & quality of profiles is what should make the difference [no?].
No. The ICC has a file format standard. The basic idea of the fundamental math is nearly trivial; it's all just matrix multiplication, basically. But there's all sorts of room for creativity and interpretation in how you're going to weight this and filter out that and account for this other, and that's what makes or break a CMM. And, remember: there's more to color management than just making ICC files: there's the sample generation algorithms, the colorimeter and spectrometer device management, linearization routines, and on and on and on. Most CMMs seem to just do things by the numbers. The text says this is what the transformation should be, and the results pass the "sniff" test; check that box on the marketing materials and move on to the next feature. Graeme instead has put insane amounts of time into investigating edge cases, figuring out why this-or-that is close but not perfect, and so on. And it shows. It probably doesn't hurt that he's forgotten more about color than most of the rest of us will ever know in the first place. Cheers, b&
edward taffel wrote:
it seems that cmm code for performing transformations must be very similar across most implementations;
CMM != Profile creator.
perhaps, all deriving from some common ancestor [seminal icc code?]: type & quality of profiles is what should make the difference [no?].
No such example code has existed, until quite late in the ICC story. While the ICC profile defines how profiles are to be interpreted, it does not define how things such as device measurements are to be converted to profiles, nor how gamut mapping are to be implemented etc. And this is a good thing, as this allows different approaches for different situations, and progress to be made in the quality of profiles, etc. Even in the execution of basic profile conversions, there is subtle room for differences. Is the implementation fixed point or floating point ? Is higher accuracy carried through each step of a transformation, or is it truncated at each step ? etc. Even CMM's sometimes have some unexpected quirks - BPC for instance, or slope limits applied to power curves, etc. Graeme Gill.
On Mar 26, 2016, at 3:39 AM, Graeme Gill <graeme2@argyllcms.com> wrote:
edward taffel wrote:
it seems that cmm code for performing transformations must be very similar across most implementations;
CMM != Profile creator.
yes, of course: i meant the algorithms applied by a configured fsm.
On Mar 25, 2016, at 11:14 AM, Ben Goren <ben@trumpetpower.com <mailto:ben@trumpetpower.com>> wrote:
ArgyllCMS is so far superior to anything and everything else out there
to what do you attribute this?
Graeme Gill, its author.
…
Graeme instead has put insane amounts of time into investigating edge cases, figuring out why this-or-that is close but not perfect, and so on.
such enthusiasm engenders interest.
Even in the execution of basic profile conversions, there is subtle room for differences. Is the implementation fixed point or floating point ? Is higher accuracy carried through each step of a transformation, or is it truncated at each step ? etc.
i gather then, you claim superior precision, & this may account for ben’s superior results; but, what of the ‘edge cases’ ben mentions? are these obviated by precision? i have found that colorsync may fail to match a color it reported out-of-gamut, i.e. transforms the coordinates, but the transformed color remains out-of-gamut. when i first encountered this [four years ago], claudio wilmanns made me aware of ‘edge conditions’; i tried to discover heuristics to cope—back-burner that! can you enlighten us as to the handling of ‘edge cases’? regards, edward
Even CMM's sometimes have some unexpected quirks - BPC for instance, or slope limits applied to power curves, etc.
Graeme Gill.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/etaffel%40me.com
This email sent to etaffel@me.com
edward taffel wrote:
i gather then, you claim superior precision, & this may account for ben’s superior results; but, what of the ‘edge cases’ ben mentions? are these obviated by precision?
I'm not sure where you gather any such thing from my general statement about CMM's. Ben will have to explain what he implies by "edge cases" - that term could apply to a multitude of different aspects of color management.
i have found that colorsync may fail to match a color it reported out-of-gamut, i.e. transforms the coordinates, but the transformed color remains out-of-gamut.
You'll have to be more precise in what you are referring to. Reported to be out of gamut using what operation ? Transformed in what direction - device to PCS, PCS to device, what ?
can you enlighten us as to the handling of ‘edge cases’?
Precisely what do you mean by edge cases ? Graeme Gill.
On Mar 27, 2016, at 12:27 AM, Graeme Gill <graeme2@argyllcms.com> wrote:
Ben will have to explain what he implies by "edge cases" - that term could apply to a multitude of different aspects of color management.
And that's exactly the sense in which I meant it. Regulars on the ArgyllCMS list will be familiar with how often somebody posts about trying to do something obscure and off-the-wall that isn't working right or optimally or otherwise as expected. Sometimes it's PEBCAK, but it also often results in changes in the next release. And, while some of those changes are limited to just that particular situation, some of them also improve everything overall. Cheers, b&
On Mar 27, 2016, at 3:27 AM, Graeme Gill <graeme2@argyllcms.com> wrote:
edward taffel wrote:
i gather then, you claim superior precision, & this may account for ben’s superior results; but, what of the ‘edge cases’ ben mentions? are these obviated by precision?
I'm not sure where you gather any such thing from my general statement about CMM’s.
please don’t get me wrong, graeme: i view ben’s comments as very encouraging, & assumed your general statement an intimation of possible rationale for “ArgyllCMS is so far superior to anything and everything else out there”.
Ben will have to explain what he implies by "edge cases" - that term could apply to a multitude of different aspects of color management.
i have found that colorsync may fail to match a color it reported out-of-gamut, i.e. transforms the coordinates, but the transformed color remains out-of-gamut.
You'll have to be more precise in what you are referring to.
Reported to be out of gamut using what operation ?
Transformed in what direction - device to PCS, PCS to device, what ?
colorsync is negotiated [by a programmer] via ColorSyncTransformConvert the operation is configured in the first argument, ColorSyncTransformRef, created by CSEXTERN ColorSyncTransformRef ColorSyncTransformCreate (CFArrayRef profileSequence, CFDictionaryRef options); /* * profileSequence - array of dictionaries, each one containing a profile object and the * information on the usage of the profile in the transform. * * Required keys: * ============== * kColorSyncProfile : ColorSyncProfileRef * kColorSyncRenderingIntent : CFStringRef defining rendering intent * kColorSyncTransformTag : CFStringRef defining which tags to use * Optional key: * ============= * kColorSyncBlackPointCompensation : CFBooleanRef to enable/disable BPC * * options - dictionary with additional public global options (e.g. preferred CMM, quality, * etc... It can also contain custom options that are CMM specific. * * returns ColorSyncTransformRef or NULL in case of failure */ in my example the profile sequence was: 1) source -> kColorSyncTransformDeviceToPCS 2) kColorSyncTransformPCSToDevice -> destination to get the gamut-check operation assign kColorSyncTransformGamutCheck to kTransformTagKey in the destination transform dictionary.
can you enlighten us as to the handling of ‘edge cases’?
Precisely what do you mean by edge cases ?
i don’t mean anything by it; ben mentioned
Graeme instead has put insane amounts of time into investigating edge cases, figuring out why this-or-that is close but not perfect, and so on.
i assumed edge a synonym for boundary [perhaps falsely]. i understand boundary to mean geometry [convex hull] containing a color space: a boundary case, e.g., when a cmm attempts to transform [clip] a color into destination gamut but hits just outside or on the boundary. best regards, edward
Graeme Gill. _______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/etaffel%40me.com
This email sent to etaffel@me.com
On Mar 28, 2016, at 8:10 AM, edward taffel <etaffel@me.com> wrote:
i assumed edge a synonym for boundary [perhaps falsely]. i understand boundary to mean geometry [convex hull] containing a color space: a boundary case, e.g., when a cmm attempts to transform [clip] a color into destination gamut but hits just outside or on the boundary.
See my other response; you read more into it than I intended. "Edge case" is a generic term for scenarios not typically encountered. Cheers, b&
On Mar 28, 2016, at 12:17 PM, Ben Goren <ben@trumpetpower.com> wrote:
On Mar 28, 2016, at 8:10 AM, edward taffel <etaffel@me.com> wrote:
i assumed edge a synonym for boundary [perhaps falsely]. i understand boundary to mean geometry [convex hull] containing a color space: a boundary case, e.g., when a cmm attempts to transform [clip] a color into destination gamut but hits just outside or on the boundary.
See my other response; you read more into it than I intended. "Edge case" is a generic term for scenarios not typically encountered.
ok
On Mar 27, 2016, at 2:01 PM, Ben Goren <ben@trumpetpower.com> wrote: trying to do something obscure and off-the-wall that isn't working right or optimally or otherwise as expected. Sometimes it's PEBCAK
like what?
edward taffel wrote:
please don’t get me wrong, graeme: i view ben’s comments as very encouraging,& assumed your general statement an intimation of possible rationale for “ArgyllCMS is so far superior to anything and everything else out there”.
Not my words.
Ben will have to explain what he implies by "edge cases" - that term could apply to a multitude of different aspects of color management.
i have found that colorsync may fail to match a color it reported out-of-gamut, i.e. transforms the coordinates, but the transformed color remains out-of-gamut.
Practical gamut checks are typically not very precise. The ICC profile has a gamut tag, but it is a notoriously inaccurate representation, and seems to be rarely used. Many systems use a "round trip check" instead. Take the PCS color, convert to device space via the B2A table and back to PCS via the A2B. If the delta E is over a threshold, then regard it as out of gamut. The use of B2A tables and an arbitrary threshold makes the check imprecise. If ColorSync is either using the gamut tag or doing a round trip check, then it would be no surprise for some colors to be regarded as "out of gamut", even after converting it to device space and back to PCS, since B2A tables have a degree of inaccuracy, particularly near the gamut boundary, which could lead to a noticeable round trip delta E. Doing a precise gamut check is more work. The ArgyllCMS xicclu tool for instance will do a precise gamut check when doing an "-fif" lookup (inverse A2B table lookup). This is "accurate" in the sense that it determines whether the color is in the A2B table somewhere to a high numerical precision. A subtlety for > 4 color profiles is that a color may not be reproducible in the B2A table, even though it is present in the A2B table, due to smoothness/interpolation continuity constraints. (For the purposes of the discussion I've also ignored any consideration of ink limits.) Graeme Gill.
On Mar 29, 2016, at 9:57 PM, Graeme Gill <graeme2@argyllcms.com> wrote:
i have found that colorsync may fail to match a color it reported out-of-gamut, i.e. transforms the coordinates, but the transformed color remains out-of-gamut.
Practical gamut checks are typically not very precise. The ICC profile has a gamut tag, but it is a notoriously inaccurate representation, and seems to be rarely used.
Many systems use a "round trip check" instead. Take the PCS color, convert to device space via the B2A table and back to PCS via the A2B. If the delta E is over a threshold, then regard it as out of gamut. The use of B2A tables and an arbitrary threshold makes the check imprecise.
If ColorSync is either using the gamut tag or doing a round trip check, then it would be no surprise for some colors to be regarded as "out of gamut", even after converting it to device space and back to PCS, since B2A tables have a degree of inaccuracy, particularly near the gamut boundary, which could lead to a noticeable round trip delta E.
Doing a precise gamut check is more work. The ArgyllCMS xicclu tool for instance will do a precise gamut check when doing an "-fif" lookup (inverse A2B table lookup). This is "accurate" in the sense that it determines whether the color is in the A2B table somewhere to a high numerical precision. A subtlety for > 4 color profiles is that a color may not be reproducible in the B2A table, even though it is present in the A2B table, due to smoothness/interpolation continuity constraints. (For the purposes of the discussion I've also ignored any consideration of ink limits.)
thanks for your detailed reply, & making us aware of gamut-check w/ xicclu . the scenario i mentioned occurs in the context of user specified/edited synthetic color, & this incurs frequent gamut-check calls from a ui control; but i’ll [try to] set up a batch test on sample data for evaluation of xicclu ‘-fif’, & look forward to seeing the results.
Graeme Gill. _______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/etaffel%40me.com
This email sent to etaffel@me.com
John, simply taking an existing image file and dragging it so PS as well as AP, this same image file looks different in the two applications. Dragging into LR, still looks the same as in PS. Cheers, David
On Mar 24, 2016, at 10:58 PM, John Castronovo <jc@technicalphoto.com> wrote:
AP is a nice program for lots of reasons, but color management isn't one of them. Their implementation of colorsync is a kludge at best. I've written to them extensively to point out a few of their shortcomings in that area, and I think they know it's bad but won't admit that it's broken until they have it fixed in a future release. At least that's my hope. They're releasing a Windows version very soon, so that's a major revision and hopefully we'll see some improvements on both platforms. They have a help blog but not many people there deal with color management. I stopped using AP because of their clumsy profiling, but I don't remember having the same issue you've got. Just make sure that when you open your file in PS that you assign the same working profile that was used in AP. It might not be embedding the correct one.
-----Original Message----- From: Millers' Photography L.L.C. Sent: Thursday, March 24, 2016 11:31 PM To: colorsync-users@lists.apple.com Subject: Affinity Photo and colorsync issue, maybe
I do believe this is a colorsync issue. Well, also my issue. You know, between the ears.
I am using Affinity Photo. Getting to the point, when exporting as .tiff, the .tiff opened in PS CS5 does not look like what is in the Affinity Photo application.
This never happens to me when using LR 6.4 and command E to finished of the size of the image file. Academically speaking, I thought the Affinity Photo application, when exported and opened in PS CS5 would to the same thing.
Even in Affinity Photo print dialogue, the pdf image does not look like the image in the Affinity Photo window.
I think I’ve tried every combination of settings in Affinity Photo. I just don’t know what else to do.
Appreciate everyone’s advise.
Cheers,
David
David B. Miller, Pharm. D., member Millers’ Photography dba Spinnaker Photo Imaging Center 3809 Alabama Street Bellingham, WA 98226-4585 360 739 2826 david@spinnakerphotoimagingcenter.com <mailto:david@spinnakerphotoimagingcenter.com>
Kind Regards David Miller, Pharm. D. dnmiller4@yahoo.com
On Mar 25, 2016, at 11:41 AM, Millers' Photography L.L.C. <digitalimaging@dnmillerphoto.com> wrote:
John, simply taking an existing image file and dragging it so PS as well as AP, this same image file looks different in the two applications. Dragging into LR, still looks the same as in PS.
On this end, all is fine. Tagged image in ProPhoto RGB preview identically in Photoshop CC 2015 and Affinty Photo 1.4.1 Andrew Rodney http://www.digitaldog.net/
On Mar 25, 2016, at 10:54 AM, Andrew Rodney <andrew@digitaldog.net> wrote:
On Mar 25, 2016, at 11:41 AM, Millers' Photography L.L.C. <digitalimaging@dnmillerphoto.com> wrote:
John, simply taking an existing image file and dragging it so PS as well as AP, this same image file looks different in the two applications. Dragging into LR, still looks the same as in PS.
On this end, all is fine. Tagged image in ProPhoto RGB preview identically in Photoshop CC 2015 and Affinty Photo 1.4.1
Indeed, it seems to me that perhaps David's image is not tagged or that there's something else causing it to get tagged with a different profile. David...have you confirmed that the both applications think that the image is in the same space...? b&
participants (6)
-
Andrew Rodney
-
Ben Goren
-
edward taffel
-
Graeme Gill
-
John Castronovo
-
Millers' Photography L.L.C.