Thanks for all the replies!!! I don't know why you're so concerned with this CSF file. These presets for color settings are really meant for people who don't know what this means, and can't make informed decisions. It's just a way to put these people in the right ballpark. It's not important. I guess I was just trying to understand the CSF files, as they were the first and most prominent download on the Idealliance page. I'd never used CSF files before, so just wasn't completely clear on if they did anything more than just apply settings. And I figured there must be a reason Idealliance was recommending the CGATS profile, even though it wasn't obvious where to find it or how it differed from the GRACoL profile. So that was the base for my initial confusion. I have now created my own custom CSF files for each app we use, using the GRACoL 2013 v2 profiles so there will be no incompatibility issues. Thanks again for the solid assistance here! ... View more

Hi Neil, thanks for the response! Here's where I got the files, though not sure if it's only viewable in the US: Idealliance GRACoL. And this conversation only applies to using print shops that 'say' they are G7 Certified and calibrated to GRACoL standards, which more are these days we're finding. - So I'm curious if the profiles we see (e.g., 'CGATS21_CRPC6.icc') are embedded in the .CSF file?!? I can't find them on my drive, or select them individually in the CS apps for CMYK workspace or soft-proofing. They only 'show up' when I choose the CSF to use. I downloaded the separate ICC profiles for 2013 GRACoL & SWOP. But the title of the one for GRACoL Coated is 'GRACoL2013_CRPC6.icc'. That's what I expected to see when choosing the GRACoL Coated CSF file. - Is that possibly the same profile as 'CGATS21_CRPC6.icc', just with a different title?? As I added the others manually to my profiles directory, I am able to choose them as CMYK working space. And when I DID try using the new profiles in Illustrator, and went to create a PDF/X-4 to place in InDesign, I got a warning about having to convert v4 ICC profiles to v2. When I examined the PDF, it did list the output intent profile as 'modified'. - Is this due to working in CS6 and not CC2017?? I think due to seeing that warning, and to the confusion about how things are showing up, I stuck with good 'ol GRACoL 2006 profile for current job which is due out this week. But I do still want to understand about using the newer CSF/ICC files for other projects. I especially like that there is now an Uncoated profile, where with 2006 bundle there is not. THANKS!!! ... View more

Thanks again for the help! I've been playing with it a bit, and reducing the green slider in the 'Visual Match' area allowed me to get the hue much closer after a few tries. Unfortunately, the calibrating takes a loooong time, so hard to make quick minor tweaks. So now the hue is much closer, but the colors on screen are just overall more saturated. This affects how some of the light quarter-tones appear. I tried setting the Contrast Ratio all the way down to 150:1, but not sure how much that's doing. Would setting a custom Gamma value allow for better contrast adjustment in the midtones, allowing it to appear less 'contrasty' or 'saturated'?? I'd have no idea where to go on that one... THANKS! ... View more

You're going to have to adjust using trial and error. OK, thanks. And since you just happen to be familiar with SpectraView, and it's still pretty new to me, do I just select one of the target settings in the drop-down, click to edit, then click to edit white point?!? Then make changes to the 'y' value (to increase green, should I go up or down?!?). And lastly, once done, calibrate the monitor to this tweaked setting?? I appreciate any insight here, as I've only ever done a more straight-forward calibration. Thanks! ... View more

Calibration of the Magenta/Green axis is the 'opposite' of White Balance which is Yellow/Blue. Not all software products provide this level of control. SpectraView does! In custom white point, you have control over x/y axis where y is green. OK, that makes sense. So, as editing the x/y coordinates is totally new to me, could you give a very rough 'guestimate' of what I'd need to do to cause a roughly 2-4% reduction in magenta?!? I know you can't give anything close to concrete, but even knowing whether to increase or decrease it, and by .5 or 50, would get me going in the right direction. Thanks again for the continued help here! ... View more

Hi. Thanks for the replies. I did mention in my last post (a couple above) about my viewing conditions and that my soft-proofing is usually pretty good when working with a vendor that is actually color-managed well (not all are!), as we do majority offset press jobs. I'm not saying that. I'm saying that is always a possibility and that you need to calibrate the display for a visual match of the soft proof as outlined in the video. So it's looking like I need to try creating a new monitor profile, choosing different target values, to try to get my monitor to better match these proofs, correct?? The video talks mostly about correcting for level differences, which in my case are not the problem (levels match pretty well). So I'm left with just white point, correct?? I'm just thinking that adjusting color temperature for white point is going to shift things warmer (more yellow) or cooler (more blue). But I need to just reduce magenta in the midtones, which I don't think those moves would do. - Any tips on how I would specify my target when creating the profile to specifically reduce magenta?!? In SpectraView, I did try editing my current monitor profile, then clicking to edit White Point. I see the 'Visual Match' area where I could adjust RGB values, but it's grayed out so I can't do anything. Would boosting green here theoretically reduce magenta for me if I could adjust those things??? Thanks again!!! ... View more

Hi, thanks for the reply and the great video tutorials. I'll have to go through them more in-depth when I have a moment. My monitor has been calibrated (using SpectraView II and the i1 Display) to a target of D50 / 90 cd/m2. We've found that this provides the most consistent overall match for most offset printing we do with shops that are G7/GRACoL calibrated. I also keep a more standard sRGB profile setup for doing web work. And while, unfortunately, we do not have a viewing booth setup here (these proofs would be too large anyway), we do use very high quality daylight-balanced CFL bulbs with a high CRI value for our lighting. We also have large frosted front windows that get very good non-direct daylight (SoCal) most of the time that we can walk over to (so kind-of a giant lightbox). So I'm hopeful that our viewing conditions, while maybe not 100% accurate, should be pretty darned close for what we're doing (as is generally the case). And I doubt that creating a monitor profile with a drastically different white point would compensate for the primarily magenta shift we're seeing, though I of course may be wrong. As mentioned, the overall levels DO look pretty accurate. It's just a specific hue shift. - So you're saying that the profile they sent us may have tables that incorrectly affect the display on screen?? - If so, is this something they would have had to handle when creating the output profile?? - Any way we can modify it every-so-slightly to get better on-screen soft proofing??? Thanks again for any input here!!! ... View more

I found an interesting development in the past few days since upgrading my phone to Nougat (Android v.7), in case it's helpful to anyone. - Every shot I take with the Lightroom camera (Auto/Pro/HDR) stores a copy of the file in: 'Internal Memory > DCIM > Lightroom Camera' (as originally noted). But NOW (since upgrading I'm pretty sure), those copies show up in my default Samsung 'Gallery' app! The thing that surprised me, and I'm pretty sure this is new, is that it can read & display the DNG's now (not just JPEGs)! I'm not certain if this is handy or annoying yet, but at least when I delete them from the Gallery app, it deletes these file copies (not the originals in LR directory, though). Still, this should be an option in LR preferences to help keep all these large file copies under control if you don't desire this behavior. For me, I would generally want to do editing to the images (only possible with DNG's in LR Mobile), then export out JPEGs from these for the Gallery app. This process does work OK. I really hope Adobe can refine this process or a lot of people who use the LR Mobile camera are going to run out of space on their phones pretty quickly, and possibly not even realize why (or how to correctly delete). ... View more

Hi, thanks for the response. Can you direct me to the other forum you're referencing?? I would love to know if there's a better place to post questions like this. Thanks! ... View more

Hi. Yeah, there are differences between the iOS & Android versions. And I'm sure there are differences in the underlying file structure where the actual DNG's are stored as well, especially in how that ties into 'default' iOS/Android camera locations. In LR Mobile on Android, when long-pressing a photo in the main 'Lightroom Photos' collection (default - I've never created any additional ones), you only get the 'Remove' option. The problem with this, though, is that it removes the photo from LR Mobile so you no longer see it or know of it's existence. BUT the actual DNG file(s) (2, including the '_proxy.dng') are still on the phone eating up storage space (60MB+ for each DNG+Proxy for me). And with crazy long filenames, in a really hard-to-find directory, and no native viewer for DNG files, it is incredibly tough for the average user to find and delete all these unwanted files! Hopefully Android will be updated to have both options (Remove + Delete), with clear descriptions of what each actually does to the physical files. It can be confusing to correlate actual physical DNG files with what's 'catalogued' in LR or added to 'collections'. There's sometimes a disconnect. Fortunately for me (and not the person in the other thread), using the online version and choosing 'Delete' does exactly what I was desiring (e.g, removes it from LR AND deleting file(s). I think the terms 'Delete' and 'Remove' should be sufficient to let people know what they do, but again, it's a bit confusing sometimes. Thanks! ... View more

Hi Michael, I'm on v.2.3.3, which is latest version for Android. Maybe we'll get some more of the features you're seeing eventually, but I've seen apps have a fair amount of differences between iOS & Android. HOWEVER, I was able to figure out a way to do the deletions relatively efficiently. It looks like my photos were syncing with the cloud (that must be an automatic setting). When I logged-in to my account online and checked the Lightroom photos area, I saw all of my photos and the ones I had rejected were a bit faded back. So it was simple for me to see them and select them, and there I DO have a delete option. When I deleted photos there, it did both remove them from LR Mobile AND removed the actual corresponding files (both DNG & _proxy.DNG). I did notice that the images were also syncing with my Desktop LR at home. I believe when I selected any photo there and chose something like 'Remove from all synced collections', it appeared to also remove it from LR Mobile and delete the corresponding files there. It did NOT delete the files in Desktop LR, though, but I could do that later. I think I'll get in the habit of quickly 'Rejecting' any photos I don't want, and then checking online to delete those, especially before they sync over to the Desktop. Thanks for all the help and tips here! ... View more

Hi Michael. Thanks again for the response. It looks like you definitely have additional menu items that must not be available on the Android version of LR Mobile. That's a bummer. Especially leaving off something as vital as a 'Delete' option. Odd, though, as Android offers much more access to actual files & directory structures. - Any Android users have a workaround for easily deleting actual image files?? The worst part is that there are usually 2 versions of each image, the full-size .dng (around 40MB each), and an additional '_proxy.dng' (around 20MB each). So every shot I take can consume over 60MB! And if there's only a couple 'keepers' out of a dozen shot, we're talking 100's of MB in wasted space, even after they're 'Removed' from LR. I'll have to see if syncing and trying to do things from LR Desktop can help at all... Thanks! ... View more

Hi Michael. Thanks for the reply. I'm guessing LR Mobile is probably a bit different from iOS to Android. But it's looking like you're implying that the only way to really 'remove' images from your mobile device may be through syncing and then doing things from Desktop LR, correct?? I hadn't really desired to clutter up my Desktop LR with the mobile images with syncing, as I use those for different purposes. I would never do any important editing on a phone, only stuff to share quickly on social media outlets. I'm really only using LR Mobile for the HDR camera feature (which is pretty amazing!). I'll have to try syncing when I get home and see if this does actually allow physically deleting all the image files on the phone when I do it as you're explaining. Then, it's much easier to delete images in LR Desktop. Just seems like a hassle just to delete photos on the phone. Out of curiosity, when you setup the 'Auto-Add' feature to import photos taken with your built-in camera, does that just import 'copies' of the images?? Wondering if when you stop syncing to clear out the mobile collection (which includes your auto-imported images), if this just deletes copies brought into LR Mobile, or the original image itself?!? It would guess only a copy... - Any LR Mobile on Android users have a different workflow for managing the actual (large) image files??? ... View more

Thanks for the reply! I only have the one 'Lightroom Photos' collection. I've never created any additional collections in LR Mobile. And when I'm looking at the photos in this one 'Lightroom Photos' collection, if I long-press any image, these are the only options I get: - Save to Gallery (with settings) - Share (with settings) - Copy to... - Move to... (grayed out) - Remove - Set as Cover (grayed out) - Slideshow Wondering if you're on iOS and have different options than I do, or if these features are accessed only from Desktop LR if syncing (I never set that up, but not sure if it just does it automatically). Any other ideas??? ... View more

Does anybody use Adobe Lightroom Mobile for taking pics and have storage concerns?!? ... View more

Thanks for all of the helpful dialog! It's sort of looking like there is no clear winner when it comes to choosing the best conversion solution. I wasn't so much worried about this job, it's more to understand for the future so we would have a clearly defined methodology. - And for the sake of understanding, if we're usually printing on uncoated stock but WITH a U/V coating, would coated PMS values be closer than uncoated in this scenario? I wish our conversions were a bit more consistent like the example Lou was stating (only 2 primaries being used, with only one really shifting). But in our case, we are seeing 2 or 3 of the primaries changing, sometimes pretty radically. So it makes it a bit tougher to 'average out' I guess. But IN THEORY, would this be the order of preference for conversion? 1) Use the LAB conversion with accurate press profiles provided 2) Use Pantone Bridge PC conversion 3) Use the older Pantone CMYK conversion (default in InDesign and Illustrator) THANKS AGAIN! ... View more

Thanks for the detailed reply. Yeah, we usually don't deal with spot colors, but on occasion we have logos that are specified as spot color (as they may be used in spot or process jobs) so we have to make it work. It's discouraging the discrepancy in color numbers achieved, and as you noticed, the Pantone conversion number appears much more blue. But this color is dark so it may not show as much. The other color in this specific job, though, is PMS 631C which is a much lighter cyan color. The LAB conversion gives me: 68C, 7M, 16Y, 0K. The Pantone conversion is: 67C, 0M, 12Y, 2K And the Bridge conversion is: 73C, 0M, 11Y, 0K So it looks like the Pantone and Bridge conversions might be a bit more 'pure', but that 7% Magenta can make a pretty big difference in how the color swings on press. It almost feels like just picking numbers out of a hat with this! With this job, I'm trying the LAB conversion numbers as this printer is ganging the job anyways, so we've already warned the client not to expect much as far as color control. But they're cheap, so that's what the client wanted. I'm much more concerned about future jobs where the client is much more demanding. And where it really comes into play is when we design a logo for a company and we need to send them master files in different color spaces (PMS, CMYK & RGB) so they can use them for different purposes. Which conversion process is going to be safest???? THANKS AGAIN! ... View more

Well, I got the 'official' workflow from the printer. This is what they say concerning their internal systems: We profile after we calibrate our press. So we get our press up to Gracol dot gains with standard density's using software that adjust our plate curves. We created the press profile using Profile Wizard Pro (kodak software). The swatches were read with an eEyeOne device. This is the profile that we were originally sent and that we used for the InDesign document as well as any conversions. Our Epsons have thier own profiles from the manufacture for their paper. There is calibration software that makes sure that the Epson profiles are printing true (ProoferClient). This would probably be the profile that the RIP converted our files to when they allowed the RIP to 'convert or color manage' the files. This was done on our second InDesign proof and final PDF proof (created from InDesign CS4). These looked pretty much identical. We also received the 'post-RIP' files that were converted, and the color numbers definitely have been altered from what was in the file. But these are also definitely MUCH more accurate to our screen/soft-proof than when they let InDesign handle the color management (and the RIP did NOT convert the numbers). The solid colors (elements generated in InDesign) are almost spot-on, about as good of a color match as we have gotten. The photos are decent, but not quite as accurate. But they are better than the file that was color managed from InDesign. ====================== So it's still a bit hazy to me what the 'best' or 'most proper' workflow should be, from our images & InDesign files, through delivery, to proofing, and eventually to press. Seems like there are the potential for profiles and/or conversions at any place along the path: Images => InDesign Master file & elements => PDF => RIP for Proofing Device => Output for Press. Is there any reference that really clearly describes a 'best-case' workflow in a simple and understandable method, including specifics for incorporating the various Adobe products (Photoshop images, Illustrator EPS', InDesign master files, Acrobat PDFs), and different proofing/press stages. It's understandable why color management is still not completely integrated into a lot of print workflows. In our experience there are relatively few true 'experts' who completely understand the best way to implement a total strategy, and can get it to work all the way to press. So people do 'half-color-managed' workflows, or miss an important step or two. In our case here, I know a 'bit', the pre-press guy I was working with knows about the same as me, maybe a bit less. So we do our best to piece as much together as possible and get the job done. A lot of times, we either adjust colors in the document to compensate for color differences, or even more commonly, adjust color on press to try to get a better final product. THANKS A LOT! I hope through all the confusion in this thread (mostly on our end, or Adobe's), some clarity will come through that can help others in our position. ... View more

Well, I just spoke with the pre-press guy who's running all these proofs. He told me that he does indeed send the PDF file directly to the RIP. So that was my misunderstanding. But he did also say that the difference we got in the two InDesign proofs was NOT because of a different setting in the InDesign print dialog like I thought (setting 'Postscript Printer Handles Color'). It was instead because of a change he made directly on the RIP to have the RIP color manage the files. For the second InDesign proof, he apparently set something in the RIP to have it manage the color or convert the embedded profiles, not sure exactly what. But this is what produced the best color. So we are now having him output one last proof from our PDF exported from CS4. With this PDF, though, he will do the same thing with the RIP to have it handle the color management or conversions. This was NOT done on the very first PDF that was output. I wish I knew more details about exactly what he was 'changing' on the RIP itself, but I don't right now. I think we are both doing our best to understand this process as well as possible right now. And all of your help has been INVALUABLE! Our print rep was just here picking up the proofs and saw me making a post, and is convinced you must get paid by Adobe or somebody to help out so much. I do hope you are compensated in some way for sharing your knowledge. What you sow you will reap however - and that is good... THANKS! ... View more

Ah, OK. Thanks for the quick reply! I must still be a bit confused (which is why I've been posting questions ). So if the printer does submit the PDF file directly to the RIP (and not print from Acrobat), then this must be what they did the first time (and on the little test proof we sent over Friday). But the solid tones (which have the same values in the PDF as in the native InDesign file), don't look as accurate as the latest InDesign proof. Images do look similar, though, I suppose. - So when he printed from InDesign, using 'Postscript Printer Handles Colors', what does this do differently from sending the converted PDF straight to their RIP? - 'Should' these files be completely identical technically? This is the last test we'll be able to run (this is #4 when it should have only been 1). So I guess we'll just have to go for it and choose between the CS4 generated PDF or the native InDesign file using 'Postscript Printer Handles Color'. I just so hope that I can fully understand this whole process someday... THANKS!!! ... View more

THANKS as always for the great responses! I will read through that PDF to get a better understanding of what's going on. I have a couple quick questions for another proof we're about to run. I made a PDF from InDesign CS4, using the same 'Convert to Destination (Preserve Numbers)' as our first PDF. This does NOT appear to cause the color shift issue we had been having. So apparently Adobe fixed that issue, whatever it was. So our printer also ran a 3rd proof for us over the weekend from our InDesign files where they allowed their RIP to handle the color conversions instead of InDesign (Postscript Printer Determines Color' in the print dialog). The first InDesign file they ran, where I thought the colors weren't as good, was using 'Let InDesign Determine Colors' in the print dialog. So in the latest proof, the solid colors (everything produced within InDesign) look spot-on. I can't imagine we'd get any better color match here. The photographs, however, were better than the first round, but possibly swung too far the other direction (too much magenta now instead of too little). These photographs were converted to their profile in Photoshop. But now I'm wanting them to try one last proof from our PDF exported from InDesign CS4 (now that the color shift issue is not a problem). However, I also want the colors to be as spot-on as the last InDesign file we got. - So in Acrobat, with my latest PDF from CS4, how should it be sent to their RIP? - From the Advanced tab in Acrobat, for color profile, should it use 'Output Intent' (which is their profile); 'Same as Source (no color management)'; or 'Printer/Postscript Color Management'? I'm imagining to get the same results as the InDesign file, we would use 'Postscript color management'. And you were right, at least in this lastest PDF. Everything appears to be DeviceCMYK. THANKS!!! This is just tediously challenging to figure out completely. ... View more

To clarify none of the content of the PDF has ICC profiles, everything is Device with the output intent. It is completely normal to have Device N and Device CMYK together in the same output. OK, sorry. I was looking at the images in Acrobat's preflight. The images are listed with a base color space of either "ICC based color space: ACE_0308_80_VEL_AM.icc" (our printer's profile), or "DeviceN color space: "Cyan" "Yellow" "Black". And even under the 'Color Spaces' drop-down, there are listings for: 'DeviceCMYK color space'; 'DeviceGray color space'; 'DeviceN color space'; as well as 'ICC based color space: ACE_0308_80_VEL_AM.icc'. So I assumed it meant these profiles were what was 'attached' to each of these images somehow. I guess I'm not reading the preflight info correctly (or understanding correctly)?!? ----------------------- Unfortunately, though, we just got the second proof back from the printer. This one was output from our InDesign file directly, not from PDF. And all images had been converted in Photoshop to their profile (using Relative Colorimetric, not sure what process Export to PDF uses).  And while we definitely don't have the problem with the color shift behind the dots, the overall color is not quite as accurate as it was with the PDF : ( I didn't expect any difference at all in color, but the second proof is definitely a bit lighter in magenta, both in images and solid tones. It's slight (maybe 3-5%) but still noticeable, especially in certain skin tones. So we're a bit stuck now. I think we're going to run a quick small test from a PDF exported from InDesign CS4 and see how this does, but if that doesn't work I guess we'll just have to push magenta on press or alter images (do not want to do this). Thanks again for all of the helpful explanations! Do you get paid from Adobe or any industry color management consortiums?!?!? You should ; ) ... View more

OK, thanks for all the investigation you've done on this! It's been most helpful. I spoke with the printer today, and he looked at the PDF that is generated by the Prinergy system (directly from the PDF I sent), and he did see the issue that we saw on the proof. So with all of the conversions and stripping of profiles that RIPs may do to a file, I just think the PDF is not going to be safe enough for us to use. I'm having him output our InDesign file now with all images converted to their profile in Photoshop. We'll see how this compares to the PDF-generated proof. I did look at your solution of specifying spot colors & using ink manager, but even with this, the end images are still using different profiles (even though they look OK on screen). The images that would generally cause the 'problem' are using the CMYK/printer's profile as the color space, but images that weren't initially causing issues on screen (using less color channels) are using DeviceN color space. So I think this just presents extra issues that the RIP needs to figure out, and in our case didn't figure them out correctly. So I think until we get ID CS4 (assuming that this does actually fix the problem), we'll stick with sending InDesign files or choosing 'No Color Conversion' on PDFs. ------------------------------ But now back to the actual topic... If you don't know who the end printer will be, you should at least know the stock. And the quantity should tell you if it will be web or sheetfed (more than likely) On the IDEAlliance website there are three really good default CMYKs to use. I will try to find the link to the webpage. One is a GRACOL for Sheetfed Coated, the others are SWOP profiles for web publications, also coated. Uncoated gets a little trickier. If it's a normal uncoated sheet you are probably OK using US Web Uncoated or US Sheetfed uncoated, I believe both have a TIL of 260%. Newsprint is a different story. Do you do any newsprint work? So I think what you are suggesting is that if we don't have an end printer's profile when starting a job is: A) Try to assign a profile that is at least closer to the end intent than the ancient default US Web Coated SWOP v.2 or B) If it's not too much hassle, do what we did this time and 'assign' the printer's profile when we get it, then re-adjust any colors to get back to where they were intended (if they actually shift much anyway). I think I may already have a GRACOL and newer SWOP profiles that we can use. I'm sure these would be better than the default US Web Coated SWOP (although most printers are used to dealing with this anyway). Most of the jobs we run these days are sheetfed, uncoated, and with U/V. ... View more