Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: smilem on January 24, 2015, 01:56:56 pm
-
I gave Adobe ACPU "Adobe color print utility" a try today and NO the adobe did not fix the
margins problem on windows. Still the margins are in inches and you can't set them other than default 1 inch.
So perhaps somebody can enlighten me how this can be the official way to print targets on windows if
nobody fixes this bug since this utility is released thats since Photoshop CS4.
How you suppose to use it?
-
It may not be particularly elegant at positioning targets on the page, but it always gets the important bits on the paper well enough to measure.
-
It may not be particularly elegant at positioning targets on the page, but it always gets the important bits on the paper well enough to measure.
Not so if I use isis and the diamonds gets cut away by wrong positioning. And I can't adjust it because of the bug. Can't adobe hire a better part time student to do the ACPU utility?
-
Not so if I use isis and the diamonds gets cut away by wrong positioning. And I can't adjust it because of the bug. Can't adobe hire a better part time student to do the ACPU utility?
You need to of course consider the diamonds part of the entire image so perhaps playing with page size to 'compensate' for this? I've heard of this bug many times but have never seen it on Mac OS.
What profile package are you using? Doesn't it provide a way of printing the targets directly?
-
You need to of course consider the diamonds part of the entire image so perhaps playing with page size to 'compensate' for this? I've heard of this bug many times but have never seen it on Mac OS.
Yes this is windows only bug.
What profile package are you using? Doesn't it provide a way of printing the targets directly?
The targets are standalone not from any package. The client wants to follow a recommended path for printing targets
that means use a pirated copy of CS4 software or use ACPU utility. Since the utility does not work. I think I will have to direct all my clients to use pirated versions old of Adobe software (portable versions etc.). to print targets.
-
Windows only bug ? Well, ACPU prints my targets nicely off-centre and I'm on a Mac.
My fix was to off-set the file by pasting it into a layer over a white background moving it about, using trial and error (And a bit of measuring) to get it in the right place. A bit tedious to to begin with but once you've done it you've got the file as a template to use again.
-
Windows only bug ? Well, ACPU prints my targets nicely off-centre and I'm on a Mac.
My fix was to off-set the file by pasting it into a layer over a white background moving it about, using trial and error (And a bit of measuring) to get it in the right place. A bit tedious to to begin with but once you've done it you've got the file as a template to use again.
Now that is strange, but very clever way to trick the ACPU. I wonder if this template is universal, or different for every printer?
Could this be considered a fix?
-
The Windows bug is that it doesn't print patch sizes as large as it should. There's a lot of stuff in the LuLa archives about this as well as the Adobe forums. IIRC the difference is that the patch sizes are 3% smaller than if you print a target from Photoshop CS4. I do my profiling using ArgyllCMS with an i1Pro and the readings are OK. Maybe automated systems find this size differential problematic. As noted this bug has been around since ACPU was first put out and Adobe show no interest in fixing it.
Alan
-
Maybe automated systems find this size differential problematic.
For an iSis, that would probably be OK. It's not that picky. And FWIW, it's usually not a good idea to use the minimum patch size if possible with such devices anyway. What you can't do is cut off the diamonds. A kluge of a fix is to simply print the target without any patches so you get the diamond pattern, lay the other print on top in correct alignment, carefully load into the iSis so now your diamonds can be read.
-
Maybe automated systems find this size differential problematic.
Indeed. The DTP-70 won't measure unexpected sized targets, but it's possible* to edit the reference files for the targets so that the autospectro is expecting the data as mis-printed. In it's favour, at least ACPU is consistent in it's resizing.
I'd guess that something similar could be done for the iSIS reference files too, if the resizing proved problematic.
*Previously documented here on Lula
-
Adobe decided to remove this feature from their products so they need to provide a working alternative. That means no gluing printed diamonds to another target to get size right etc. I can't see why they will not fix this, clearly shows that they do not care about color management at all. And we should be grateful for the fact it is working at all.
So the mindset to pay for software to be unable to use it is OK?
I understand now why chromix charges 300Eur for their profiles they are gluing each target to templates and this very tiresome ! :P So is this some kind of conspiracy to not fix your software ? Or stupidity on user part?
-
Adobe decided to remove this feature from their products so they need to provide a working alternative.
I don't think so. Who would print without any color management in Photoshop other than to output a target for a profile (something the profile makers should provide)?
-
I don't think so. Who would print without any color management in Photoshop other than to output a target for a profile (something the profile makers should provide)?
So it's the color profile makers should provide this? Why not OS creators like microsoft?
The point is Adobe made such utility only with allot of bugs, so it's logical that they need to fix them then.
-
So it's the color profile makers should provide this? Why not OS creators like microsoft?
Yes because who else (and why) would you print this data without color management? Targets for building profiles yes, any other reason? As for the OS, at least on Mac, the ColorSync utility will do this. Microsoft? They can't even build system wide color management or a browser that handles it (as far as I know).
The point is Adobe made such utility only with allot of bugs, so it's logical that they need to fix them then.
All software has bugs and I'm sure if ACPU were anything be free, Adobe would fix those Window bugs.
-
I don't think so. Who would print without any color management in Photoshop other than to output a target for a profile (something the profile makers should provide)?
Someone who wants to do color management outside of PhotoShop will want to do this - i.e. when dealing with any image that has already been rendered to the printer colorspace.
-
Someone who wants to do color management outside of PhotoShop will want to do this - i.e. when dealing with any image that has already been rendered to the printer colorspace.
Fine, embed that profile, all will be fine.
They applied the color management outside of Photoshop but now they have to print it untagged in Photoshop? Seems like a stretch. Let's be honest too. We were able to do this from Photoshop 5 to CS4 or CS5 (can't recall which) and Adobe removed it because it was a huge mess thanks to Apple and other's who kept breaking various areas of the print path. Very few users needed the functionality too.
If someone has a untagged target to print, the software that built the target should take on the role of printing it as well, instead of expecting Photoshop to do so. Thankfully, at least on Mac, Apple gave us that ability in the CS utility.
-
All software has bugs and I'm sure if ACPU were anything be free, Adobe would fix those Window bugs.
So you say adobe would fix it if ACPU would be commercial software? I think it should be part of photoshop that is commercial software.
You do know Photoshop allows to work with non-color-managed images, allows to untag profiles etc. The CS4 allowed to print them too. So why not remove the other un-color-managed features from photoshop then? If they leave those then the print feature should be there also.
-
So you say adobe would fix it if ACPU would be commercial software? I think it should be part of photoshop that is commercial software.
I don't disagree, that's just not going to happen. As I said, we had literally years of issues between printer manufactures drivers, Apple and Adobe and Adobe decided one 'fix' was to disable this print path.
You do know Photoshop allows to work with non-color-managed images, allows to untag profiles etc.
Not really. You can't turn off color management in Photoshop. An untagged document is still color managed in terms of an assumed color space (whatever you have set in it's Color Settings dialog for working space) along with the display profile. And like that approach, so is the print path. You can feed it untagged data but it is still going to assume some color space for the RGB or CMYK numbers and deal with them as such.
Even with GWGill's suggestion, (that color management was conducted outside Photoshop), that data has to have an embedded profile OR Photoshop assumes a color space for the numbers that probably isn't correct. So again, why would anyone feed Photoshop an untagged document for output? It isn't designed for this workflow and it's kind of a pointless workflow too. Untagged RGB and CMYK is mystery meat. For color targets, we don't care how the image appears. For actual images, we do and that's why Photoshop forces color management upon it's data.
-
Fine, embed that profile, all will be fine.
Tagging an image with a device link won't work, and even if it did, you may want to use a color conversion engine not available in Photoshop - i.e. you shouldn't be forced to use PhotoShop's color management just because Adobe can't imagine that anyone won't want to use it.
-
Untagged RGB and CMYK is mystery meat.
Only if PhotoShop assumed that it's the be-all and end-all of color management. In a larger context, this need not be the case - the user may know what they are doing, and actually expect PhotoShop to do as they ask.
-
Tagging an image with a device link won't work, and even if it did, you may want to use a color conversion engine not available in Photoshop - i.e. you shouldn't be forced to use PhotoShop's color management just because Adobe can't imagine that anyone won't want to use it.
Sorry, not following you. First we have a non tagged image? It's got a DLP and needs to be printed in PS? What's the issue?
Only if PhotoShop assumed that it's the be-all and end-all of color management. In a larger context, this need not be the case - the user may know what they are doing, and actually expect PhotoShop to do as they ask.
Again I'm not following you as to the issue. We've got RGB or CMYK data that either as a descriptor of the numbers or it doesn't. If it does, no problem and that's not under discussion. If not, how is PS supposed to understand how to treat the data? Can you explain a workflow where someone is opening untagged data in PS just to make a print and how PS is supposed to deal with that data when no color space is associated with the data? Why can't the user Assign the proper profile and make a print, why does the data have to be untagged?
-
I'll give one example when I used a no color management print path in PS in the past (and it was rare). I have an image and a profile and I want to gang up two variations using the same profile but using two different rendering intents. Open image and duplicate. Convert to the print space using the profile (Convert to Profile) with both RI's, gang them up next to each other in the same document and print without further color management. Now I have to simply make two prints. Not a hill worth dying on and I can use the CS utility AFTER ganging up the two images in Photoshop.
-
Again I'm not following you as to the issue. We've got RGB or CMYK data that either as a descriptor of the numbers or it doesn't.
If I take an RGB image, construct a device link to convert it to my printer space (using for instance, ArgyllCMS collink then cctiff to get the best possible gamut mapping and smoothest conversion), then it appears that there is no unambiguous and easy way with recent versions of PhotoShop to do anything further in that printer space and/or print it without risking a further conversion. Yes I could tag it with the printer profile and hope that it's bit for bit identical to the printer profile that PhotoShop thinks the printer is, but the whole issue is simply stupid - I should be able to tell it to do what I want unambiguously - do nothing - exactly the same as when I need to print a profile test chart, without having to second guess what PhotoShop is up to.
If not, how is PS supposed to understand how to treat the data?
It's not - it's meant to do as it's told - print without color management - feed the device numbers to the printer.
Why can't the user Assign the proper profile and make a print, why does the data have to be untagged?
That may well be a workaround to this missing option, if there is a way of assigning what PhotoShop thinks is the printer profile to the file without having to know exactly where that profile is - but if so, why do people keep trying to use ACPU ?
-
If I take an RGB image, construct a device link to convert it to my printer space (using for instance, ArgyllCMS collink then cctiff to get the best possible gamut mapping and smoothest conversion), then it appears that there is no unambiguous and easy way with recent versions of PhotoShop to do anything further in that printer space and/or print it without risking a further conversion.
I don't know about Device Link Profiles but you can send output ready RGB or CMYK through Print. When source and destination color space is identical, you will get the warning to download and use Adobe Color Print Utility. Press Cancel and just go ahead and print. It will output as it should. The issue is untagged data! PS will make some assumption about it. Now can you tag it with say sRGB and pick sRGB as I did with the output ready data? No, but can you do so by tagging it with an output profile? Maybe. But again, the only time one would do this is to print targets, something the folks who's software created the targets should handle.
I'm asking my sources inside Adobe about DLP's. But the tag source and destination output color space does work, I just tested it to my Epson (Convert to Epson output profile, pick that same profile in Print, cancel warning to download ACPU and print).
-
When source and destination color space is identical, you will get the warning to download and use Adobe Color Print Utility. Press Cancel and just go ahead and print. It will output as it should.
Sure - but it's a terrible UI. The user shouldn't have to pull a trick like that - the print workflow should accommodate such things as printing calibration test charts or printing images that are already in the output space with something that is unambiguously and straightforward. Every color managed workflow has to have a way of printing test charts, or you can't make profiles for it, so you can never use it! (Catch 22).
So if you're designing a print workflow (Adobe, Apple & others), don't stuff around trying to make believe that this option isn't needed, do it properly.
The issue is untagged data! PS will make some assumption about it. Now can you tag it with say sRGB and pick sRGB as I did with the output ready data? No, but can you do so by tagging it with an output profile? Maybe.
The correct way to handle test charts (and this is something I know from first hand experience of designing print workflows) is to tag it with a pseudo-space, or (if you like) a wild card space, one that is *always* the output space, no matter what actual profile that happens to be.
But again, the only time one would do this is to print targets, something the folks who's software created the targets should handle.
Not really - that's a hacky workaround for a borked print workflow. For 100% certainty that the profile faithfully reflects any transformation in the workflow, the workflow should be kept constant, not one important element such as the print program being changed to print the test chart.
I'm asking my sources inside Adobe about DLP's. But the tag source and destination output color space does work, I just tested it to my Epson (Convert to Epson output profile, pick that same profile in Print, cancel warning to download ACPU and print).
Right, and can you tag with "the output profile", or did you have to know precisely which ICC profile was going to be used ? If it's the latter, then it's not a very robust UI - it would be easy to get it wrong, and as soon as the printer profile is updated, your test chart is no longer going to work properly.
-
Adobe could have retained the feature in Photoshop or even put it in LR and given it an eplicit button or dropdown menu that says "For Printing Non-Color Managed Targets for Profiling" or something like this. I've done some profiles for friends and I always have to go through a lengthy explanation about the do's and don't's of printing targets for me to read.
-
Sure - but it's a terrible UI.
At least this product actually provides the user a UI! ;)
The user shouldn't have to pull a trick like that - the print workflow should accommodate such things as printing calibration test charts or printing images that are already in the output space with something that is unambiguously and straightforward. Every color managed workflow has to have a way of printing test charts, or you can't make profiles for it, so you can never use it! (Catch 22).
The product doesn't stop you! It pops a dialog that provides two options: One takes you to the ACPU download page, the other is Cancel and you are not forced to stop the print process. They could have done that (grayed out the Print button). You are free to possibly muck up the output to your heart's content.
The correct way to handle test charts (and this is something I know from first hand experience of designing print workflows) is to tag it with a pseudo-space, or (if you like) a wild card space, one that is *always* the output space, no matter what actual profile that happens to be.
Then provide said print workflow. It isn't any more Photoshop's task to print untagged printer targets is it's your product's job to edit layer masks.
-
Adobe could have retained the feature in Photoshop or even put it in LR and given it an eplicit button or dropdown menu that says "For Printing Non-Color Managed Targets for Profiling" or something like this.
They could? They did, for years in Photoshop. It broke all kinds of print workflows most users expect.
I'm still waiting to hear of a valid workflow whereby someone needs to print an untagged target (or dog-forbid image) in this image & color managed pixel editor and why it's Adobe's responsibly instead of the people who built the target in the first place.
-
Tried two hacks, one is a possible solution for those who want to go this route in PS to print untagged targets.
First thing I did was take an existing profile for my Epson 3880, duplicate it, alter internal names in ColorSync utility. Then the Print dialog warning about trying to proceed without color management doesn't appear.
Assign first profile to untagged target.
Select profile with altered name in Print, no dialog because it doesn't think it's the same profile but of course it is.
First I used an Absolute Colorimetric intent for output. Not so great. More data below. Then tried RelCol with BPC. That seems to work in producing a NULL transform but I want to do the measurements again tomorrow for a sanity check. Anyone else here with the means to do so, give it a try.
Printed untagged target in both ACPU and i1Profiler. Measure with iSis and compare. These targets didn't' sit over night to dry so I should repeat the test tomorrow.
ACPU vs. i1P:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.35
Max dE: 1.33
Min dE: 0.02
StdDev dE: 0.20
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.31
Max dE: 0.63
Min dE: 0.02
StdDev dE: 0.14
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.77
Max dE: 1.33
Min dE: 0.64
StdDev dE: 0.13
--------------------------------------------------
All the high dE values are in blues which I've seen in the past when the target needs more time to dry down.
ACPU vs. Photoshop Hack using Absolute:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.84
Max dE: 3.97
Min dE: 0.09
StdDev dE: 0.53
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.70
Max dE: 1.56
Min dE: 0.09
StdDev dE: 0.35
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 1.99
Max dE: 3.97
Min dE: 1.57
StdDev dE: 0.40
--------------------------------------------------
Max dE is high, this time in very dark values.
Much better reports using Relative Colorimteric with BPC to print in PS using this hack. Now we might be getting somewhere!
ACPU vs. Photoshop Hack using Relative Coloimetric with BPC:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.27
Max dE: 0.76
Min dE: 0.01
StdDev dE: 0.14
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.24
Max dE: 0.45
Min dE: 0.01
StdDev dE: 0.11
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.54
Max dE: 0.76
Min dE: 0.45
StdDev dE: 0.08
--------------------------------------------------
--------------------------------------------------
i1P vs. Photoshop Hack using Relative Coloimetric with BPC:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.24
Max dE: 0.83
Min dE: 0.01
StdDev dE: 0.14
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.20
Max dE: 0.42
Min dE: 0.01
StdDev dE: 0.10
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.55
Max dE: 0.83
Min dE: 0.42
StdDev dE: 0.10
--------------------------------------------------
I could supply two printer profiles so anyone who can't alter the internal names of a profile can over-ride the "Use ACPU" warning dialog.
-
One other test I'll measure tomorrow is using the same profile, selecting "Cancel" when asked to go to ACPU download page, print target with RelCol+BPC. IF that works, hack is a bit easier (no need to duplicate and edit profile name). Should work.....
-
The level of support requests for things that didn't work or people who misused the option was the reason it was removed.
Photoshop is many things to many people, but it doesn't need to be everything to everyone. As Andrew has said, the argument is very simple - those who produce such devices should provide the utilities to use them and not rely on a third party product such as PS to use them. Not everyone uses PS and it's a very expensive option if all you need is some way to print targets.
So Adobe provided a free tool - it's supported at an appropriate level for it being free and given the market size who "require" it.
-
At least this product actually provides the user a UI!
If ArgyllCMS claimed to have a GUI, then criticizing for not having a GUI would be fair. But it only claims to be a command line set of tools, and therefore naturally it has a command line UI. Feel free to criticize any details of that you like (tool names, function, choice/order/defaults or arguments etc.), but saying it doesn't have a UI is patently false.
-
Then provide said print workflow.
Sure - go buy a DiceNet/ColorStar/ColorBus RIP (Yes, that may not be easy - they haven't been made for 10 years.).
-
Select profile with altered name in Print, no dialog because it doesn't think it's the same profile but of course it is.
First I used an Absolute Colorimetric intent for output. Not so great. More data below. Then tried RelCol with BPC. That seems to work in producing a NULL transform but I want to do the measurements again tomorrow for a sanity check. Anyone else here with the means to do so, give it a try.
I'd strongly suspect that it is not doing a NULL transform, but running the colors through the A2B of one and the B2A of the other. This is not a loss-less process for a CLUT profile, and for things like CMYK will re-set the separation, making a CMYK test chart useless.
-
If ArgyllCMS claimed to have a GUI, then criticizing for not having a GUI would be fair.
I made no such criticism. I'm simply pointing out there actually is a GUI and further, I disagree about your point: but it's a terrible UI.
I'd strongly suspect that it is not doing a NULL transform, but running the colors through the A2B of one and the B2A of the other. This is not a loss-less process for a CLUT profile, and for things like CMYK will re-set the separation, making a CMYK test chart useless.
I don't know what it's doing and I suspect unless someone like Chris Cox or Dave P from Adobe (who knows the code) tells us, we're speculating. I do know that the dE values suggest that it is possible to print untagged targets though CC2014, not that I'm suggesting it's a good idea. Note that I've said it's a hack. I plan to measure the targets again tomorrow after dry down but even 'wet', it appears the measured numbers match two other products that are made to print untagged targets. And as I've said from the beginning, the folks who need to print untagged targets should look upon those products that built them to print them or find another product that didn't go out of it's way to avoid this workflow. Adobe isn't the least bit unclear that this isn't a task they wish to undertake (nor again should they have to). However, if this hack works, so be it.
-
Sure - go buy a DiceNet/ColorStar/ColorBus RIP (Yes, that may not be easy - they haven't been made for 10 years.).
Perfect, use a 10 year old copy of Photoshop to print the untagged targets. 8)
-
I could supply two printer profiles so anyone who can't alter the internal names of a profile can over-ride the "Use ACPU" warning dialog.
Looks like this is a necessary step as I measured a target printed by canceling the dialog in Print when source and destination is the same, compared it to ACPU. Both targets dried over night. Way off (mostly in blues). Seems for the hack to work, one needs to have two profiles that are identical expect for their internal names so Print 'converts' from source to destination with a null condition. Here's the report:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 3.34
Max dE: 19.73
Min dE: 0.06
StdDev dE: 2.20
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 2.80
Max dE: 5.10
Min dE: 0.06
StdDev dE: 1.10
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 8.15
Max dE: 19.73
Min dE: 5.13
StdDev dE: 3.36
--------------------------------------------------
Here is a report from prints made yesterday, measured today (dry down) using ACPU and the proper Photoshop Hack using two profiles:
--------------------------------------------------
dE Report
Number of Samples: 918
Delta-E Formula dE2000
Overall - (918 colors)
--------------------------------------------------
Average dE: 0.18
Max dE: 0.70
Min dE: 0.01
StdDev dE: 0.10
Best 90% - (825 colors)
--------------------------------------------------
Average dE: 0.16
Max dE: 0.31
Min dE: 0.01
StdDev dE: 0.07
Worst 10% - (93 colors)
--------------------------------------------------
Average dE: 0.39
Max dE: 0.70
Min dE: 0.31
StdDev dE: 0.08
--------------------------------------------------
--------------------------------------------------
So, you really, really have to use PS (CC2014) to print untagged targets? It has to behave just like ACPU (and i1P)? The dE report above illustrates it's doable. An Average dE: 0.18 is what' I'd expect to see from the iSis measuring two different printed targets.
-
Perfect, use a 10 year old copy of Photoshop to print the untagged targets. 8)
And, you can't print a CMYK document with no color management unless you have a CMYK (non-PostScript) printer AFAIK. Anyone here fall into that rare camp?
-
How you suppose to use it?
What happens if you attempt to print a target that is just smaller than letter size, does it still cause the scaling bug?
-
I don't disagree, that's just not going to happen. As I said, we had literally years of issues between printer manufactures drivers, Apple and Adobe and Adobe decided one 'fix' was to disable this print path.
Well I guess the saying that U.S companies bends backwards to please the client is valid for small and medium size companies that do have address provided and phone numbers etc. The larger companies like Adobe is like typical EU company.
Why does it always had to be that some Russian guy or somebody like GWGill has to fix something like this? You do not find it strange? The developer seems just lazy.
Long live opensource and freeware software, at least developers respond and have listed contacts, not like big companies.
BTW actually it is a good business practice to not do any business if company has not listed their contact info.
-
So Adobe provided a free tool - it's supported at an appropriate level for it being free and given the market size who "require" it.
Good to know there is no market for color management because of stupid people that buy any prints shop makes them, but how is that related to software features that could be made simply on/ off via preferences etc. There is no need to remove something just make it possible to switch off.
Then again I image most complaints were from U.S customers that need a "specialist" to hang a print on the wall, because they don't know how.
-
Perfect, use a 10 year old copy of Photoshop to print the untagged targets. 8)
Now you are suggesting the same as I did, only no need to use 10 year old version. Use "PhotoShop CS4 Micro" (google it) version, only ~50MB (not portable installs and expands to ~300mb). BTW thank Russians for it.
-
What happens if you attempt to print a target that is just smaller than letter size, does it still cause the scaling bug?
The ACPU has margins in "inches" and my OS is in "millimeters" the darn thing doesn't even read that correct. How it suppose to work? Now I have no problem to providing measurements in inches but it accepts only default value of 1.
1 inch is about 2.54 cm that is allot if I have make my targets by 5 cm smaller in height and width to print. I use every millimeter to put as much patches as I can, and I expect this to be logical way to use paper, ink, and my time.
-
The ACPU has margins in "inches" and my OS is in "millimeters" the darn thing doesn't even read that correct. How it suppose to work?
Are you serious? You can't figure out how to convert inches into millimeters? ACPU didn't build the target, the application that did can't help you convert units of measurement but it's ACPU's fault? You own Photoshop, try the Image Size command if you can get past using an Adobe product to aid you with the math. I thought you were serious about needing to print an untagged target. In ACPU or otherwise. Now I suspect this entire genesis of this tread is Anti-Adobe.
Let's try again, assuming you really want to print the target in ACPU on Windows. Whatever app built the page, make a target that's smaller than 8.5x11. I recommend 8x10 which can be on an 8.5x11 inch page. FWIW, according to Photoshop's New Document dialog window>U.S. Page when set to MM equals 215.9mm x 279.4mm. Do you need me to supply a screen capture of this dialog?
-
Now you are suggesting the same as I did, only no need to use 10 year old version.
If you have to print CMYK to the unsupported, 10 year old products GWGIll suggests is an excuse for the workflow I asked for to make the case for untagged printing, sure.
-
I have a revelation to you that ACPU does print exactly as Photoshop no color management for RGB images ONLY. However for CMYK images it does not print the same so if you want precision you need to use "Photoshop CS4 Micro" edition or any other old version you own that does have the "No color management" print option.
Here how it looks like:
ACPU CMYK
87
21
100
7
CS3 no color management
100
10
100
0
Original file
100
10
100
0
If somebody wants to print RGB only give opensource/freeware a try use PhotoFiltre 7.2.0.
No install needed just ~5MB app will print RGB files exactly as Photoshop without color management, "No color management"
http://static.infomaniak.ch/photofiltre/utils/pf7/pf7-en-7.2.0.zip
-
I have a revelation to you that ACPU does print exactly as Photoshop no color management for RGB images ONLY
I am aware of that and stated the issue with CMYK output of untagged data to printers below. What does this have to do with the target scaling bug of which some are trying to assist you with? Are you printing CMYK untagged targets?
-
I am aware of that and stated the issue with CMYK output of untagged data to printers below. What does this have to do with the target scaling bug of which some are trying to assist you with? Are you printing CMYK untagged targets?
My client wants to use adobe recommended workflow, that means using ACPU. The targets are RGB.
-
My client wants to use adobe recommended workflow, that means using ACPU. The targets are RGB.
Well WTF are you bringing up CMYK?
Next, why are you not attempting to over-ride what I believe is the scaling bug in ACPU and not printing a target smaller than 8.5x11? 215.9mm x 279.4mm. Further, I told you how to print in the current version of PS and get the same output as using ACPU. You want help and a possible fix to the issues you yourself raised here or not?