In X4, it was possible to overlap RGB transparency over RGB bitmap (for example a RGB[0,0,0] rectangle with gradient transparency over a photo) and make a color proof of the result correctly without merging them both into a new RGB bitmap first. But, X5 cannot color proof it correctly. Any idea? Is this known? It was damn flexible and nice in X4! :(
David Milisock:What this means is that NO SHIFT in display should happen when we convert the base vector fill from RGB to CMYK. RESULT in multi-color model mode none ocurrs, (proper) in soft proof a shift happens (improper). The second reason is that the transparency when applied is alos in gamut for the destination CMYK space and the RGB space so we can shift modes back anbd forth without any display *** as long as we do not soft proof. Hence this is a soft proof error, if it were an rendering order error the problem would appear when we went to CMYK mode with soft proof off.
The second reason is that the transparency when applied is alos in gamut for the destination CMYK space and the RGB space so we can shift modes back anbd forth without any display *** as long as we do not soft proof.
Hence this is a soft proof error, if it were an rendering order error the problem would appear when we went to CMYK mode with soft proof off.
Oh, I read over and over and over and finally I found I have a faulty assumption! You are right! It's only about softproofing and without it, everything seems working properly. I thought I should have soft proof "on" all the time and otherwise it's not taking CMYK profile into account. This was my mistake. So, without using this new soft proofing thing I have no remaining issues so far. Furthermore, I checked this with Acrobat, too and found the softproofing could be quite misleading. Even if I have to use it, I should flatten these effects to RGB bitmaps to expect the softproof show something meaningful. In this case, the rendering order I've mentioned has nothing to do with Corel obviously. There's a problem with soft proofing itself. Thanks for your patience, David!
Thanks for the reply, Yanni. I feel you grabbed what I'm saying because, now David is paying more attention to the mistake in softproof accuracy (also thanks for checking that) which is not even close to this serious issue I'm pointing to.
And yes, of course the same thing is happening to the file you've attached. See, it's not about the files. That code maybe is not touched but something new is obviously not communicating with it. My latest two posts above outline the problem clearly. Is it possible to reach the coders somehow?
coreltom:Because unlike X4, it's now translating RGB transparencies to CMYK **before** applying the effect.
This would be incorrect, X4 either worked in RGB or CMYK mode. If you were in CMYK mode all effects rendered in CMYK from the beginning. Same thing for RGB mode.
The soft proof from X4 was another issue depending on your color management settings. None of the default CM setting from X4 was proper as it used soft proofing. The MS ICM CMM 2 produced errors with some profiles and the Kodak ICM produced errors with other profiles.
Depending on the color engine and the selected CMYK profile an irrevocable error could be induced into CMYK conversion. In CMYK mode with the arrow activated to the monitor was the only way to get a proper CMYK display and a proper CMYK conversion 100% of the time. With this setting CMYK displayed properly only when the files CMYK content resided in the separations printer color space, RGB did not display properly, spot color could be rendered as RGB or CMYK and gray scale was gamma 1.8. There was a default CMYK internal mechanism for CMYK soft proof in CMYK mode. All N color space items (anything with transparency) render CMYK only unless you chose spot color. After the second service pack.
In RGB mode with the arrow activated to the monitor RGB elements in the file that resided in the internal RGB color space displayed properly, CMYK elements would display properly if they resided inthe separation printers color space. Gray scale displayed as gamma 1.8 spot color rendered as RGB. All N color space items (anything with transparency) rendered as RGB unless you chose spot color after SP2.
I have attached another PNG this one with anothe gradient transparency added while in RGB mode. Note how the transparencies alllook alike, the CMYK manually converted whilein CMYK mode, the RGB with Transparency applied while in CMYK mode, your original and the bottom one which is in RGBmode an RGB fill with an RGB transparency applied.
As you can see from the display of these 4 items all display correctly with NO INCORRECT layering. This happens for 2 reasons, one the test vector R0 G0 B0 converts to a TIC 349 which is in gamut for the destination profile.
What this means is that NO SHIFT in display should happen when we convert the base vector fill from RGB to CMYK. RESULT in multi-color model mode none ocurrs, (proper) in soft proof a shift happens (improper).
David Milisock
David, thank you for all these explanations. But, honestly they don't work for me. I would assume it's me who has insufficient knowledge and this is working correctly but after all those files and screenshots and schematics I realized I cannot communicate the source of problem for some reason. Now, I'm already working with X4 without problems and everything is WYSIWYG from head to toe. X5 can wait for a SP but if this won't be changed even in X6 or X7, I can easily say I won't touch to any newer version anymore and switch to X4 until it dies and then Adobe stuff forever. Because, my workflow is not experimental in any way and I'm 100% satisfied with anything I do using X4 CM, no surprises yet. I can only hope one day this report will start to make sense and you'll realize you haven't understood what I'm complaining about. Anyway... good luck everybody!
coreltom:There's a problem with soft proofing itself. Thanks for your patience, David!
It is I that thank you for your help, together we found something that needs addressed, together we shall reap the rewards of the shared knowledge.
To understand completely how X4 and X5 color management work you need to read (if you have insomnia this is a great cure) both my books, the one on X4 which has real interesting color management and the one on X5 which has commercial compatible color management at www.graphictechnology.com
Without understanding how X4 and oldr color management workswith custom X4 settings it's next to impossible to decypher how to utilize X5 color management.
Hi Tom,
The Primary color mode is not meant to control the blending space in X5. It only controls the default color palettes, and the default color mode for export to single color mode filters. The blending color space is controlled based on your file destination. If proofing is off we blend in RGB assuming the monitor as the destination. If Simulate overprints is on we blend in CMYK (since overprinting is an ink based concept). Using Soft Proofing we will blend in RGB or CMYK depending on the color mode of the color profile you are simulating.
Regards,Matt