P: Add Color Space to Metadata Viewer

@richardplondon I absolutely see your point regarding the workflow! I just tested it with a couple of images and it absolutely makes sense. Now I am able to carry over the name which was always a chore to include and the image retains all of its attributes and the file gets added to Lr seamlessly. Thank you All. 

As I commented, if your workflow relies on border layout within the Print module and then Print to File - you cannot control the output filename image by image - only the same across the whole batch plus a number suffix - plus it's a clean slate so far as EXIF and XMP.

Hence the other method mentioned, centred around using Export and postprocessing to apply the borders / whatever - that option can in principle implement whatever graphical design you please, also will preserve per-image metadata if you want, with individually meaningful filenaming as you define, image by image.

However as to your case example in italic - crop marks for a smaller sheet within a larger sheet - this sounds to me more like a job for a page layout or a prepress app - unless you can kludge it by overlaying a graphic to define those crop marks within an otherwise conventional LrC page layout.

Thanks @richardplondon - I'm guessing that appending the Profile name to the file name will be the cleanest fix for me, unless Lr adds colorprofile to the EXIF viewer. Once the print-ready file is created we do not change / re-edit the original TIFF provided by the artist. We keep it with our edit history for record keeping but don't have use for the file otherwise.  

Ultimately what I want to achieve is to allow for assistants to easily verify image-paper-printer profiles on the fly. I could manually get what I need via KWs but those may get deleted, altered... the EXIF data is permanent and will only change if the file is replaced.

On the other hand this may also be an opportunity to re-evaluate the lack of versatility Lr has when creating custom borders. Right now the print module only allows users to add even photo borders up to 36pts. Some of my artists will want a 16x20 paper with a centered 11x17in wide image for example, and unless I create a saved print I will not be able to achieve the desired border from the UI - say I will print on a 17x22in sheet and have crop marks set for a 16x20 cut with the printed image being 11x17 centered in the 16x20. 

Thanks again!

I must say I have two areas of reservation:

• the re-importing of your saved print-ready file back into the Catalog - if someone else may be needing to do something external with this, can that usage not happen using this same file directly - naming the Print to File suitably to convey the info on profile and renderintent - and skip the import? Otherwise, if the output is going to happen from inside the Catalog, why not skip making the intermediate file and use the virtual proof copy directly for final output to device or to file? 
• Any Print to File operation creates a bare 'digital print' without the rich individualised metadata that the Catalog holds. All kinds of notes fields and keywords etc that may be of great use later, are simply left off. So that's a restriction on this as a means of putting on borders etc. I wonder if an Export postprocessing method could suit better instead. Either subcontracting the job out on the fly (necessarily, this is non-WYSIWYG) to a utility such as ImageMagick, or (say) to a PS Action encoded as a Droplet. Any workflow related metadata you want to express within the Catalog, will this way survive into your external ready to print file. That info can be made use of by yourself or by assistants using e.g. Bridge maybe. And no need for the print ready file  - if you are not postively manipulating it further in LrC - to import back to the Catalog. If you want to output directly again, you can repeat the export which for repeatability and standardisation I suggest benefits from a named custom Export preset. 

Just some thoughts - good luck finding a robust and simple answer.

Thank you all for your candid replies! I guess I didn't elaborate much on my workflow so here it goes: I manage a large catalog of images to print from various artists that require cutom border creation and I do export print ready files with these borders in order to have them handy as orders come through. So here is my flow and the reason why I would find it handy for Lr to display the ICC profile of the images.

1. I softproof image files using the develop module with the printer profile I intend to print

2. Once I am happy with the proof (I make sample prints to verify) I use the print module to create the custom borders / frame the image on the paper as requested. In many cases it is a bulk process so I'll have 5-10 soft-proofed images to apply borders to.

3. I use the print to FILE (wished there was a TIFF version here as well) and save using the Profile I intend to print the file with. I could just use AdobeRGB here but since this is a ready-to-print output I like to append the printer profile I used to soft-proof.

4. Once the images are saved I import them into Lr and use them as needed. 

The challenge is that unless I specifically note it on the name (which may be the fix), my lab assistants will not have a an easy / handy way to verify the paper and rendering intent used to print/save the file. This is why I see it handy for LR to pro-actively display the appended color profile of the image file. 

Again this workflow may be unique to me, but if you are printing / managing hundreds of files for others it may help just add this to the EXIF data viewer on the Library module.

Thanks again!!!

Agree with the others. Unless you actually convert to a print output color space outside LR, there is no reason to be doing this or tagging it in LR. Any document (raw or rendered) can be printed with the conversion taking place at the time of print. Just as you can and would do in modern versions of Photoshop.

A Proof Copy is useful as it 'records' this color space with output-specific edits and also honors the rendering intent you select, so keep track of them for additional printing of that output-specific image and edits. That's all you need to track.

Nitpicking; raw does have a color space. Not Colorimetric, not tagged with any kind of (ICC) profile that anyone could use or search for. Another reason why LR doesn't need to concern itself or the user with print output color spaces (from raw).

One option is: if you use Soft Proofing in LrC specific to your printer profile, and then opt to have a proofing copy made (this is prompted for anyway, if you make any adjustment) - this proofing copy will inherit the name of the chosen profile, as its Copy Name. This exposes that info searchably within the Catalog and also, if you make this Copy Name part of your filenaming template, shows for exported images. Of course those exported images would then need to have had this same profile selected at output, for such naming not to be potentially misleading!

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

LR doesn't make the ICC profile of a non-raw visible. You can use the Metadata Viewer plugin to view all metadata stored in a single file, including the profile. You can use the Any Filter plugin to filter  by profile, e.g. 

(You can use smart collections to search by the color profile using the Source Color Profile criterion, but you won't be able to see the full name of the stored profiles.)

You should keep your files in a standard color space, like Adobe RGB or sRGB.

There is no need to convert files to the printer color space, choose the correct ICC profile in Lightroom's Print module, and the file sent to the printer will be converted by the printer driver.

The original remains untouched, in its original color space.

In case you are printing raw files, they do not have a color space.