Testing the screen to print path....was An open letter...
Testing the screen to print path....was An open letter...
- Subject: Testing the screen to print path....was An open letter...
- From: tom lianza <email@hidden>
- Date: Wed, 21 May 2008 07:16:39 -0400
Hi guys,
With respect to Lar's comment
"It seems the user needs something that can verify the system live,
including hardware deviations.
As far as I understand, this is one of the major problems. "
I agree with the "live" part, but the fact is most high end inkjet
printers using the proper media, are very stable. The part that is very
unstable is the stability of "settings". A good example in Mac OSX
pre-leopard is saving print settings in the application print dialog,
hitting the print button and then have the OS dialog show your current
printer, but with accessing the print settings from the last printer.
That's a major problem for users. Even if they do everything correctly,
the operating system kills the quality.
Realistically, I don't expect that we will see uniform handling of meta
data for a long time. This is probably a good issue for the
Architecture Working group inside the ICC. I'll forward this to Ann at
Lexmark. Jan-Peter, keep in mind that for most endusers, there is no
print file. The data passes directly from the application to the
printer driver. If you have a rip or spooler, that is a different
question.
The key featured that we are looking for at X-rite are:
1. a consistent, reliable, and uniform mechanism to set a printing
condition (both programmatically and from an end user perspective).
2. a consistent and uniform mechanism to enable profiling of a device.
3. a simple test mechanism to show the train is working.
James Vogh (X-rite) has developed a simple test mechanism which we are
currently putting together for limited distribution for testing. We
will show this at the ICC meeting. This test system consists of two
files with an embedded profile and test profile to be assigned to
printer for output. The files are jpeg and tiff. When imported into an
application, they immediately show which rendering intent, if any was
selected. Clearly, if none were selected, the image is not color
managed. This is somewhat similar to the work Lars did for the ICC
with the encoded images to test for color management. I heartily
recommend that you all go to the ICC website and check out the "Is your
system Version 4 ready?" section.
When output to the printer, using the test profile, the rendering
intent, if any, on output is indicated. On a single printed page you
see how color data is managed on input and how it is handled on output.
It is important to realize that the testing profile is very specific to
the test image. Normal printing through the test profile will lead to
some very weird results.
In two days of testing we found that most viewers handle jpeg
differently than tiff, if they handle color management at all. I was
able to print to an OKI data laser printer that has no CM options by
assigning the profile at the OS level (Windows XP) and printing through
a well designed windows app Picture Window Pro. This was an application
that showed great handling of V2 profiles, using OS level color
management . This little test showed that the state of color management
is very immature and that the some applications do it correctly and many
do not do it correctly. That is why this simple target is a good test.
It validates the screen to print chain unambiguously. The problem with
a target like this is that it generates a lot of user questions as
well. One reason that we are not just posting these files, yet, is that
we need to understand the support issues and we need to have it
validated by some ICC experts. It also has be designed for easier
interpretation. I would hope these targets become available to all by
July, given no major problems in testing.
The point to made here is that we are actively trying to solve this
issue and we are making progress.
Regards,
Tom
Jan-Peter Homann wrote:
Hello Lars, Tom and list
In the print chain, we have the possibility of colormanagement at:
- application level
- OS / Graphics API level
- printer driver level
The main idea og my proposal is transparency what happens in this
chain by embedding meta-data into the print file:
- the application creating the print data writes into the meta-data
what the application did concerning colormanagement
- the OS / Graphics API handling the meta-data, does the same
- the printer driver is able to print this meta-data incl.
informations for colormanagement on printer-driver in a control slug
So by just activating the control slug, the user can easily see what
happens in the print chain concerning colormanagement.
The certification is mainly about, that the applications, the OS /
Graphics API and the printer driver are able to handle this meta-data.
This is the core idea of my last letter.
An additional idea is the place for the management of
- printer profiles for different media / driver settings,
- the driver settings itself and t
- he place where the colormanagement for the print chain happens.
The association of printer profiles and printer driver settings should
be done at the printer driver and not in the OS and not at application
level.
The vendor should have the possibility to deliver standard profiles
for his standard settings and the user should be able to print without
any colormanagement for a given setting and to attach his own profile
to a setting if he wants.
If an application does the colormanagement for the print chain by
itself, the application should be able to read out the profile
currently valid for a printer driver setting and deliver
colormanagement print data wich MUST NOT further be color managed by
the OS/Graphics API or the printer driver.
Such functionality could in general be certified and in daily practice
be controlled via the meta-data in the control slug on the print-out.
Regards
Jan-Peter
Lars Borg wrote:
Jan-Peter,
Let's uplevel. You're assuming a certification process would solve
the problem in the field. Would it? I don't think so.
A certification process would only tell us it is possible to get
correct output, not that we're getting correct output right now.
A certification process doesn't verify that Joe's system is correct
right now. Maybe his paper is too moist, or an ink nozzle is
performing below par.
It seems the user needs something that can verify the system live,
including hardware deviations.
As far as I understand, this is one of the major problems.
Lars
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden