A color conversion defect has been identified in Enfocus PitStop 25.

[wushy]

An issue with PitStop 25: when converting the RGB images in this PDF to CMYK mode, the images turn completely white

[JimmyHartington]

On my 25.11 it convert fine.
https://d.pr/f/nmVAqV+

What are your color settings and action list or global change settings.

[wushy]

Sorry for the mistake, I’ve uploaded the wrong file. Please test with this one instead.

[JimmyHartington]

Now I see the same behavior.
How is file 222 processed after 111. Because it has a lot of paths instead of just an image.
See this wireframe preview:

[JimmyHartington]

I have used the object browser of Pitstop Pro to look into the file.
In file 222 above the image, there is a clipping path.
And it seems to "hide" the image when it is converted to CMYK.
I can not seem to tell why. Normally I would say it is something with overprint or transparency.
But I can not see that on the clipping object, so I hope somebody smarter than me will chime in.

Here is a video of me converting the image to CMYK and removing the clipping path with help from the object browser.
https://d.pr/v/o5NPgM
By the way the object browser is an underrated tool. One I often forget is there. But it is good for analysing a file like this.

[wushy]

I suspect the issue is also related to the clipping path. Meanwhile, I’ve noticed another odd detail: the image is compressed with the "JPEG+ZIP" compression method.

[bens]

There's something in the page content stream that sets the "current transformation matrix" to "0 0 0 0 A B" (A and B don't matter, they're translations). If you want to check for yourself you can use Enfocus Browser or Acrobat's "Browse Internal PDF Structure" - but you'll have to search a bit, it's quite a long content stream.

That "0 0 0 0" means all objects that follow have a width and height of 0. It looks like that really confuses PitStop. As far as I can see it only applies to one object, but at some point PitStop applies it to the image as well. You can see this by saving and re-opening the file after converting the image to CMYK. If you find the image again after that (e.g. using the object browser) and check its size and resolution, you'll see they're both 0 (or 0.0001, which is the minimum PitStop will show).

I suggest you send this file to Enfocus support so they can check whether this is a bug.

As for a workaround: if you remove everything outside the media box you'll also remove the problematic object, which should let you convert the image without losing it.

By the way the object browser is an underrated tool. One I often forget is there. But it is good for analysing a file like this.

The object browser is a great tool. It could use some love though, there are some weird behaviours sometimes.

[wushy]

Thanks to the tip from the poster above, I’ve found the issue is fixed by first applying the action "Remove invisible objects without fill and stroke", then converting the images to CMYK.

[JimmyHartington]

Glad you got it to work.
Still hope you will send the file to Enfocus, so they can investigate the error.

[loicaigon]

Yes please, it's important to report things when you feel something is awkward.
Sometimes one will find a workaround and feel like it is not worth it, but this is by letting us know that we can possibly fix and improve for every single user