Ink limit bug in new Indesign (18.5)?

[Matthew A]

I am used to checking for 'zeroed' ink limit in InDesign, for retouched images where the edges shoudl be white...

~ Typically you do this by settign the ink limit to 1%, then lookign for any red patches to indicate where there is still ink / colour hanging around.

On the new Indesign this seems to be broken— I can check an area which DEFINITELY HAS NO INK — ie reads 0/0/0/0 cmyk and it still shows up red in Indesign!

[rob day]

Hi @Matthew A Is the object that has no ink % an image file? If so what file format are you placing? Can you share the file?

[rob day]

Not sure if this is the same as your problem, but I can replicate by setting the document’s or image’s Intent to Absolute Colorimetric when the image’s embedded profile conflicts with the document’s profile.

Is your image in CMYK mode and does its embedded profile match the InDesign document’s CMYK profile?

[Matthew A]

Thanks for looking at this @rob day 

I think this is a bug — I found a solution but it doesnt seem to make sense :).

Bear in mind the two documents I am inspecting here (see below) are both scans from the same scanner, retouched so the surrond is full white, SAME colour profile etc etc. One shows no ink correctly, the other shows ink where there is none.

— after looking at the .psd files themselves the ONLY difference is that one file (the one Indesign cant read correctly) still had the base layer set as PS' usual 'background'...

... while the other file (viewed correctly by Indesign) was set to 'Layer 0' or whatever PS calls a file when you double click a layer to free up the background layer.

Both layers on both files were full opacity with no masking — yet wierdly Indesign read the one with 'Layer 0' as the bottom layer not 'Background' as having 'transparency: yes' — and this was the file that Indesign read correctly in terms of ink levels...  

—

So the solution for the moment seems to be that you have to work with fiels that dont have the default locked background layer present if you want Indesign to correclty read ink levels. This is, as far as I can tell, incorrect behaviour and a bug.

[rob day · Accepted solution]

Does it happen if you assign or convert the .PSD’s embedded RGB profile to a Display class editing profile like AdobeRGB or sRGB?

Also, what Rendering Intent is the conversion set to? The Intent can be set in Object>Image Color Settings..., Edit>Assign Profiles..., or Color Settings...

Did you try deleting your Caches file, and if that has no affect reset your Preferences?

If you Export to a PDF/X preset with the Output>Destination set to Document CMYK are the white pixels in the PDF showing as something other than 0|0|0|0 CMYK in AcrobatPro’s Output Preview?

InDesign’s Separation Preview shows what the conversion to DocumentCMYK is expected be, not the actual pixel values, so the source and destination profiles would come into play.

[Matthew A]

Hi @rob day  — apoligies for the slow reply here — i CAN confirm that converting the Epson profile to a standard Adobe RGB helps — ink limit starts to work as expected after converting...

thanks!

[rob day]

yet wierdly Indesign read the one with 'Layer 0' as the bottom layer not 'Background' as having 'transparency: yes'

Also, that is expected behaviour, if there isn’t a visible bottom Background layer, InDesign considers the .PSD as Transparent even when Layer 0’s visible pixels are opaque: