Show some love to the scientists out there; gamut warning please

[wooly_bugger]

We biologists are also making our own RGB composite images from scratch all the time, and this type of functionality is critical.  Our workflow often begins with a series of 12 or 16 bit grayscale images that are 'massaged' into 8 bit images and, ultimately, RGB composite images.  Therefore, the ability to copy/paste into the channels of an RGB image, as well as some form of channel mixing is very useful. I get the impression from other discussions that channel functionality is broken for the moment, but will be fixed.

 

Where we really suffer, however, is in sending our data to scientific journals for print publication.  Since art directors often have little idea what our composites are really supposed to look like (the color or contrast of a mitotic spindle, anyone??), we are stuck (as image nonprofessionals) trying to proof our images on our own a bit before we send them off.  Just have a look at any major scientific journal to see the lack of image workflow training (that is, we don't get any image workflow training...).  Since we don't get access to the publishers icc profiles or anything useful to a commercial imaging professional, we have to play with generic CMYK conversions and/or soft proofing tools to ensure our microscopy images fit more or less into a generic CMYK gamut.  So we get self-taught in adjusting saturation and hue of our RGB images to make this work out...  At least, some of us are self taught.  Others simply send their raw, saturated RGB composites off and don't care about the printed result.  Of course, I'm supposed to be focused on my cell biology work (at least, that is what I'm paid for), and not so much on image colorspace workflows (in my copious spare time).  In the old days, we would take actual photos of our specimens, and include a hardcopy with our manuscripts.  That way, we never had to talk to the art directors, and vice versa.  But I digress...  

 

While it is true that the scientific journal publishers as a whole expect me to send them straight up RGB images for publication, we still need a way to ensure that they will likely look halfway reasonable in print form.  The art directors at the respective journals may or may not have patience for a lot of back and forth with us scientists over our images.  For this reason, we would very much appreciate some form of 'out of gamut' warning and (at least generic) CMYK conversion to help make our publication workflow less frustrating.

[billtils]

All the publishers I have dealt with seem to care about is "it must be 300 dpi", or, as the old BBC comedy "The Rag Trade" had it, never mind the quality, feel the width ...

[TomM1]

We biologists are also making our own RGB composite images from scratch all the time, and this type of functionality is critical.  Our workflow often begins with a series of 12 or 16 bit grayscale images that are 'massaged' into 8 bit images and, ultimately, RGB composite images.  Therefore, the ability to copy/paste into the channels of an RGB image, as well as some form of channel mixing is very useful. I get the impression from other discussions that channel functionality is broken for the moment, but will be fixed.

 

Where we really suffer, however, is in sending our data to scientific journals for print publication.  Since art directors often have little idea what our composites are really supposed to look like (the color or contrast of a mitotic spindle, anyone??), we are stuck (as image nonprofessionals) trying to proof our images on our own a bit before we send them off.  Just have a look at any major scientific journal to see the lack of image workflow training (that is, we don't get any image workflow training...).  Since we don't get access to the publishers icc profiles or anything useful to a commercial imaging professional, we have to play with generic CMYK conversions and/or soft proofing tools to ensure our microscopy images fit more or less into a generic CMYK gamut.  So we get self-taught in adjusting saturation and hue of our RGB images to make this work out...  At least, some of us are self taught.  Others simply send their raw, saturated RGB composites off and don't care about the printed result.  Of course, I'm supposed to be focused on my cell biology work (at least, that is what I'm paid for), and not so much on image colorspace workflows (in my copious spare time).  In the old days, we would take actual photos of our specimens, and include a hardcopy with our manuscripts.  That way, we never had to talk to the art directors, and vice versa.  But I digress...  

 

While it is true that the scientific journal publishers as a whole expect me to send them straight up RGB images for publication, we still need a way to ensure that they will likely look halfway reasonable in print form.  The art directors at the respective journals may or may not have patience for a lot of back and forth with us scientists over our images.  For this reason, we would very much appreciate some form of 'out of gamut' warning and (at least generic) CMYK conversion to help make our publication workflow less frustrating.

 

Files can be converted to CMYK from the Document menu.

Soft proofing happens with the soft proof adjustment layer. The resulting settings box has a "Gamut Check" check box.

[Leafdancing]

If any help to you, the Affinity Team have posted a video on soft proofing here 

and is on their twitter page too if you scroll down a little way https://twitter.com/macaffinity .

[ronnyb]

I really don't understand why soft proofing is in the Layers / adjustment palette... Doesn't this belong under the View menu instead? I would love to understand the logic of using Proofing as an adjustment layer...

[csp]

your problem is easy solved with an calibrated monitor ( http://www.xrite.com ) and a small gamut color workspace like srgb.   gamut warning is missguiding anway in most cases.  if you don't know the destination cmyk space and the rendering intent the use everything is guesswork.  when your images are printed in europe you could use the  eci cmyk profiles for softproofing. 

[wooly_bugger]

Thank you for the info, especially to TomM1 for pointing out how to use the adjustment layers feature to help me establish a new workflow that works in affinity photo.  I admit that I will have to get used to not having PS-like color saturation and hue tools to squeeze my images into CMYK compatible color space, but after playing around I have been able to make suitable adjustments.  Affinity Photo should, therefore, make a better replacement for PS than say, pixelmator, for our purposes.

 

Our workflow starts with 16 bit grayscale images (tiff) of very dim objects that then get stretched with the help of custom LUT's (e.g. HiLo LUT, for those in the know) and some noise processing.  Conversion to 8 bit grayscale then happens (in Aff Photo, I have to export the 16 bit image first, say as a .png, in order for the new 'levels' and gamma settings to survive the conversion to 8 Bit.  The resulting RGB image contains non-overlapping image data in each color channel.  The color choices (e.g. separate LUT for each 'channel') are arbitrary and the images are not recognizable subjects and look fairly abstract.  For this reason, we don't have to be very accurate in testing whether our images can be converted to a (perceptual) CMYK print process.  We really only want to avoid obvious posterization artifacts that resist 'perceptual' conversion.   For anyone interested, here is an example (not my own) of a very abstract data image that was published despite obvious out of gamut posterization in the green channel http://jcb.rupress.org/content/208/4/382.1.full   In this case, the poor CMYK conversion does not impact the interpretation of the data or the science and I wouldn't be surprised if the authors have no idea why the posterization occurred, nor may they even care.  The image, nonetheless, shows what it needs to.  Such images are commonplace and point out a huge difference to the commercial image industry;  we are not being paid for the images, and they need not be approved by a client.  Their purpose is mostly to illustrate a point.  Unfortunately, I just happen to be OCD enough  to want to avoid such artifacts in my own work despite the fact that the color fidelity of my printed images is not terribly important.  

 

As much as it would be nice to solve these issues with a calibrated monitor and/or software (e.g. xrite),  our scientific peers simply do not expect or demand high quality images.  As a result, we can ill afford to invest much time, effort, and expense to do this properly (as most members of this forum would be inclined to do).  By the way, this is also the reason why a subscription fee for PS is untenable for most scientists.  Although it would be nice if as a department, or college, we had a central imaging core with this expertise, software, and hardware, most of us scientists are on our own. You can probably count on one hand the number of science departments or biotech companies that have such a (publishing workflow) resource available; most imaging cores are just rooms full of pricey microscopy hardware with an occasional staff biophysicist.  Being expert in the publishing workflow is not in their job description.  Since the image data is only one fraction of the work we pursue and publish (typically, a boatload of other quantitative data are illustrated by a representative image), we operate on a 'need to know' basis, rather than on a 'best tool for the job' basis, when it comes to getting our images published.

 

Apologies for the soapbox rant, but sometimes I feel compelled to try to communicate some of the day to day issues of science professionals to folks out there in the real world.  I very much appreciate the comments at this forum and really just wanted to let the developers know that there is a community of scientists out there that are actively looking for an alternative to (aging) stand-alone PS installs as well as a community that has the patience to help us with our specialized issues.

 

Thanks again,