Bitmap showing as CMYK color space in preflight

[fredl11600511]

Following the advice now being given about when best to convert the RGB color space to CMYK for printing, I changed my preflight defs to flag images which are CMYK prior to ripping to PDF. But preflight is categorizing bitmap images, which show as "black and white" in the links panel (and are truly bitmap when opened in Photoshop) as having a CMYK color space. How can this be?

[Laubender]

Hi fredl11600511 ,

what is the document intent?

Is it print intent? Then it's correct that your preflight is showing an error.

If the intent of your document would be Web Intent or Mobile Intent your preflight would not throw an error on [Black].

What can you do?
Create a swatch with RGB 0,0,0 and color your bitmap graphic with that.

Regards,
Uwe

[Laubender]

Compare the color space of swatch [Black] of a document that is set with Print Intent to a document with Web Intent or Mobile Intent.

Do you see the difference in the Swatches panel?

Note: All 1-bit bitmap images placed are automatically colored with [Black].

Regards,
Uwe

[fredl11600511]

The intent is offset printing.

The images are bitmap in Photoshop, black on or off.

So you're saying that preflight does not recognize bitmap images--an image has to be either RGB, CMYK, spot, Lab or gray? And this is because the default Black in InDesign is CMYK and not RGB? If today's InDesign does a better job than Photoshop of converting RGB to CMYK in ripping PDFs, then why doesn't it have the option of a RGB black? It would seem that the current setup defeats the purpose of preflight, because you can't effectively preflight for CMYK images.

[Laubender]

Hi fredl11600511 ,

InDesign does not convert any placed bitmap images.

It applies a color to the bitmap image.

That color, by default, is [Black].

If [Black] is defined with color space CMYK, and this is the case with every document that is created with Print Intent, your preflight that is defined to flag CMYK elements, will throw an error. That's no bug.

Regards,
Uwe

[fredl11600511]

I understand what you are saying, to a point: Black is defined by InDesign as CMYK, so of course it is flagged if CMYK is not allowed.

Print intent in our docs is defined as "Print." But I'm not understanding how Print Intent has any effect on preflight: if you set preflight to flag CMYK, then it will still flag CMYK regardless of whether you are printing for Web (RGB) or offset (CMYK).

In flagging CMYK, the purpose is simply to allow InDesign to make the conversion from RGB to CMYK when ripping, as is the current advice; obviously it won't need to convert black if it is already in the CMYK color space. The purpose of preflight is to efficiently flag errors, which is useless if black is flagged in searching for images which are CMYK instead of RGB. Perhaps the answer is that it does't affect the RIP if a document has a mix of RGB and CMYK images, but it if InDesign is now the preferred way to convert, it would be nice to know if some images have been converted to CMYK before being placed in InDesign, since prior conversion is apparently no longer the optimum process.

Not trying to argue on this; just trying to better understand how Preflight can be used most efficiently in this regard.

[Laubender]

Hm. I think, you have to understand that InDesign's preflight function is totally decoupled from the various output options you have, like PDF export for example. With PDF export you can decide to leave all placed images as is regarding to color space. Or you can decide to convert to RGB or to CMYK. InDesign's preflight will not flag objects on the page regarding to your current used PDF settings.

If you want clarity you have to preflight an exported PDF for example.

You can do that with Acrobat's preflght functionality.

Regards,
Uwe

[fredl11600511]

Thanks, Laubender. What you say testifies to my point: if Preflight is decoupled from output intent and can't distinguish bitmap because it uses CMYK black then it is useless in regards to functioning so that users can employ it for employing InDesign's strength in ripping PDFs from RGB to CMYK.

But thanks for the info!

[rob day]

When you place a 1-bit  (Black & White) image, its color by default is set to the [Black] swatch, but you can choose a swatch or color with any color mode—CMYK, Lab, RGB, Mixed Ink, or Spot. InDesign doesn’t have a Black & White or Grayscale color space, but it does allow you to placed objects with those modes and color them. As Uwe suggests, what happens to the bitmap’s color depends on your Export>Output settings, and Preflight has no idea what that is going to be.

Here I've placed the same Black and White image three times and assigned different colors, RGB, CMYK [Black], and a Pantone spot:

If I Export to the default PDF/X-4 (No Color Conversion), the 1-bit images will maintain their assigned color modes. Here Object Inspector tells me my red rgb A is indeed an ICCBasedRGB object

If I re-export and force a conversion by setting the Output tab's Destination to a CMYK space, my RGB 1-bit object will get converted accordingly:

[fredl11600511]

The issue I'm focused on is not the export; it's preflighting: using preflight conditions to easily find images placed as CMYK and correct them to RGB, since experts are now saying that InDesign's conversion from RGB to CMYK for print production is the best way to go (rather than converting in, say, Photoshop). Since preflight can't distinguish between the CMYK black that bitmap uses and actual CMYK images (using 4 colors), preflighting for this condition is pointless. If InDesign had an option to use an RGB black as the default black, the issue would be solved. So it's not an issue to be solved, apparently, at this point; it's just a limitation for using Preflght.

[rob day · Accepted solution]

If InDesign had an option to use an RGB black as the default black, the issue would be solved. So it's not an issue to be solved, apparently, at this point; it's just a limitation for using Preflght.

It does: Document Setup>Intent set to Web or Mobile will convert default [Black] and other CMYK swatches to RGB.

But I think you are taking the RGB advice too literally. In the case of 1-bit Black and White images that you want to print as black on press, assigning an RGB black to the bitmap means the image will print as 4-color. The conversion of RGB black will be to the CMYK profile’s maximum black point. So for default SWOP the conversion will be something like this, which could easily cause a registration nightmare on press for 1-bit line art. Similarly you would never want to use an RGB black for small text:

Also once an image is converted to CMYK converting it back to RGB has little or no benefit because the damage has been done. At that point you might as well allow a CMYK-to-CMYK conversion in the RIP.

Placing RGB is more of a convenience than a necessity—it allows you to wait until the final press destination is known before making a device dependent conversion. If the placed CMYK file was converted using the correct press profile, there would be zero need to go back to RGB.

[Stephen Marsh]

But I think you are taking the RGB advice too literally.

I agree Rob.

David Blatner and Claudia McCue wrote the following qualifier (one among many) in their often cited and often misquoted/misunderstood 2014 InDesignSecrets article – “Why You Should Import RGB Images Into InDesign and Convert to CMYK On Export”:

“Similarly, when you’re applying solid colors to objects in InDesign—and those documents are headed for print—you should use CMYK or spot color swatches, not RGB, in the interest of predictable conversion.”

In the case of 1-bit Black and White images that you want to print as black on press, assigning an RGB black to the bitmap means the image will print as 4-color. The conversion of RGB black will be to the CMYK profile’s maximum black point.

These will certainly preview as CMYK within InDesign, however they will only convert to CMYK if the colour conversion is performed during export to PDF in InDesign.

InDesign is rather limited and I suggested long ago that it should either “borrow” the preserve black feature from Acrobat Pro and or have the ability to use DeviceLink ICC profiles which can maintain pure CMYK primary colours.

I prefer to export with no changes to colour and make all necessary colour conversions in Acrobat Pro where with the “preserve black” option found in the colour conversion tool and various preflight profiles and fixes it is possible to cleanly convert to 0cmy100k from an 0r0g0b source.

    Acrobat Pro – Converting CMYK Black PDF Content to CMYK Black

    Acrobat Pro – Converting RGB Black PDF Content to CMYK Black

    Acrobat Pro – Converting CMYK Black PDF Content to RGB

    Acrobat Pro – Grayscale PDF Conversions

    Acrobat Pro – Preflight Fixup to Convert Rich Black to CMYK Black

I personally like Enfocus PitStop Pro which can also cleanly convert, as can specialised PDF workflow software from various prepress vendors, such as Kodak with Prinergy.

[rob day]

These will certainly preview as CMYK within InDesign, however they will only convert to CMYK if the colour conversion is performed during export to PDF in InDesign.

I‘m not seeing that with the default PDF/X-4 (No Color Conversion) example in my #9. The 1-bit image exports as CMYK 0|0|0|100 the same way any fill or text with the default [Black] swatch would. I think this is a case of trying to fix something that isn’t broken.

I might be misunderstanding the OP’s 1-bit image usage, but I’m assuming it is for something like a black and white logo, which you would typically want to export as black only, and that certainly can happen in an all RGB image workflow.

There might be a case such as a 1-bit image with a large area of black where you want the fill to be a rich black (i.e, 45|30|30|100), but I would do that by building a rich black swatch and applying it to the 1-bit art. The rich black values will export unchanged with either the default PDF/X-4 preset, or the Destination set to Document CMYK, or by setting Color Conversion to Convert to Destination (Preserve Numbers), which protects all native CMYK colors and swatches.

[rob day]

If today's InDesign does a better job than Photoshop of converting RGB to CMYK in ripping PDFs, then why doesn't it have the option of a RGB black?

Also, that’s not quite right. Assuming the destination profiles, color intents, and Black point Compensation are set the same in both apps the conversions will be virtually identical—InDesign’s conversion will not be better. Making a single conversion on export to the final CMYK destination is a significant time saver, but doesn't necessarily improve quality.

ID lets you mix color modes on a page. To make an RGB black just make a new swatch with the Color Mode set to RGB 0|0|0

[Test Screen Name]

The thing about the black plate, K, CMYK black, is that it isn't just used in CMYK. It is also the greyscale plate, used in single colour printing, for black text as well as bitmaps. There are strong and sound reasons to keep black or greyscale things on the K plate EVEN IF intending to work only in RGB. For example, in printing (to desktop, copier, or anything else), it's much more likely to be a true black than a rich black, which may improve quality and reduce costs.

This is, it seems to me, a classic case of the tail wagging the dog - as we often see with preflight. Here is a perfectly good file that is useful in every way, but fails preflight. What is broken and must be fixed? Obviously the app/design, rather than the preflight. No, in my view the preflight is checking for the wrong things. Preflight isn't the boss, it's a tool you can use to help you get results, and which needs informed tuning. If this can't be tuned out, then the preflight is missing a key feature and needs a software fix.

[Derek Cross]

In InDesign choose PDF/X-4 to convert your RGB images to CMYK.

Also tick, in the Export Adobe PDF dialogue box, Crop Marks and Use Document Bleed Settings.

(Unless your printer has given you a different spec.)

[fredl11600511]

I want to thank all of you for taking the time, making the effort to reply in detail as you have. It's been helpful and an education. I do think the preflight could be made more useful so that users can ferret out mixed color spaces (e.g., some CMYK, some RGB) in a document without being concerned that bitmap black is being picked up as CMYK when it is only K; it would seem that the conversion results would then at least be uniform, since it would be applied at whatever stage (e.g., InDesign, Pit Stop) to all images, not just the ones not already converted to CMYK.

[rob day]

I do think the preflight could be made more useful so that users can ferret out mixed color spaces (e.g., some CMYK, some RGB) in a document without being concerned that bitmap black is being picked up as CMYK when it is only K;

But InDesign doesn’t have a distinct K space. For print intent documents, [Black] is actually 0|0|0|100 CMYK, and not 100%K.

Protecting [Black] from a conversion can be handled on export by setting the Color Conversion to Convert to Destination (Preserve Numbers).

That option protects all native CMYK colors and swatches, but converts any RGB colors, or CMYK objects with conflicting embedded profiles to the chosen Destination space.

If for some reason you wanted to force a CMYK-to-CMYK conversion of native swatches and colors, while still protecting the default  [Black] swatch, that can be done via Edit>Convert to Profile...

[Test Screen Name]

"But InDesign doesn’t have a distinct K space. For print intent documents, [Black] is actually 0|0|0|100 CMYK, and not 100%K"

But it doesn't need to be distinct space, InDesign is more than capable of checking the other channels are zero.