Tim Waugh | 2 Dec 2010 17:43
Picon
Favicon
Gravatar

Epson Stylus D78

Hi,

I have an Epson Stylus D78 and it works well with Gutenprint when used
as a D68.  This is the Device ID:

# lpinfo --include-schemes=usb -l -v
Device: uri = usb://EPSON/Stylus%20D78
        class = direct
        info = EPSON Stylus D78
        make-and-model = EPSON Stylus D78
        device-id = MFG:EPSON;CMD:ESCPL2,BDC,D4,D4PX;MDL:Stylus
D78;CLS:PRINTER;DES:EPSON Stylus D78;
        location =

Is it just a case of adding a new printer entry for this printer,
copying the settings from those for the D68 and using the new Device ID,
or do I need to do something else?

Tim.
*/

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
(Continue reading)

Dmitriy Chaplygin | 8 Dec 2010 23:50
Picon

Drop size calibration. New section.

Hello Robert!
Here:
http://lists.freedesktop.org/archives/openicc/2008q1/001294.html
You described two processes of calibration:
1) To calibrate light inks:
2) To calibrate drop sizes:

 And in the end of the letter you asked a question: "Would a more detailed writeup on this be of interest to other people?"

Just now, after almost three years, I would like to answer it. I know at least in some ten people which for certain if read this letter, very strongly would ask you to describe calibration processes more in detail.
If it is possible with examples and about a script files for yours testpattern the generator.

Generally, after perusal of all branch "Drop size calibration", the impression was added that at that point in time to time at you should appears xRite i1 or other spectrophotometer. And, for this reason you did not begin to continue to describe calibration process "manually", that is "by eye"

It is assured that you at present time already have a waste algorithm specified above calibration processes. You could not share algorithms of these processes.

Generally, process of adjustment of press IMHO consists from:
1) Calibration
    1.1 Drops
    1.2 Lights
2) Linearization + determination per-channel ink limit
3) Determination TotalInkLimit
4) Profiling

2) the point with success dares with the help argyllcms (many thanks Graeme Gill)
3) while dares only in a manual mode. By the way, can be at you as there is a technique of a finding of this value?
4) the point concerning RGB and CMYK as with success dares with the help argyllcms. At CMYK + spotColors I use ProfileMaker as the unique decision for profiling multichannel, for example a C (vividM) YK + RedGreenBlue + Orange (I still plan to translate the R800 to this pigment InkSet)


And here the decision 1) point remains under the big question. The precise detailed technique is not present. We very much would like that you shared this technique!

In advance are very grateful!

Development team WinGP ((Gutenprint for windows and GimPrint plugin for Photoshop)
http://code.google.com/p/wingp/


--
Yours faithfully,
Dmitriy Chaplygin.
C уважением,
Дмитрий Чаплыгин.
+7 (495) 979-8412
Skype: Chapa75
ICQ: 3167277

------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
Gernot Hassenpflug | 9 Dec 2010 14:09
Picon

question about raster format ESC (F command

Hi,

I am analysing output from a Windows print by a Canon MP450 printer,
trying to figure out what the sub-channel (cmy) values are in an
inkset consisting of CMYKcmy inks. The CMYcmy inks have 4-bits per
color (with 4 levels), K has 1 bit (2 levels), no compression.

In the printjob, multiraster is selected, there are 16 "lines per
block" detected, and for this mode all 7 colors used as shown by the
ESC (L command.
Aside: for this inkset, the sub-channel character has 0x60 added to it.

The final order of the inks in the raster format is then shown as CMYKcmy.

After that the ESC (F command contains raster lines of data, with the
number of bytes for each ESC (F command shown in brackets.

What I do not understand is how the lines per block relate to the
bytes in the ESC (F command. Can anyone shed light on how this is
supposed to work?
My thinking is that the 7 inks can fit into 4+4+4+1+4+4+4 bits = 3.125
bytes, and that each ESC (F command then contains some multiple of
this with padding at the end.

Any recommendations on where to get more insight much appreciated.

ESC (I select data transmission (len=1): multi raster
ESC (J select number of raster lines per block (len=1): 16
ESC (e advance (len=2): 33
ESC (L set component order for F raster command (len=7): found valid
color char: C
found valid color char: M
found valid color char: Y
found valid color char: K
unknown color  0xc3
subtracting 0x60 from color char to give: c
unknown color  0xcd
subtracting 0x60 from color char to give: m
unknown color  0xd9
subtracting 0x60 from color char to give: y
=> CMYKcmy
ESC (F raster block (len=232):
ESC (F raster block (len=1910):
ESC (F raster block (len=226):
ESC (F raster block (len=702):
ESC (F raster block (len=10536):
ESC (F raster block (len=10934):
ESC (F raster block (len=9091):
ESC (F raster block (len=594):
ESC (F raster block (len=5171):
ESC (F raster block (len=592):
ESC (F raster block (len=2629):
ESC (F raster block (len=28221):
ESC (F raster block (len=29060):
ESC (F raster block (len=26948):
ESC (F raster block (len=594):
ESC (F raster block (len=5185):
ESC (F raster block (len=586):
ESC (F raster block (len=2723):
ESC (F raster block (len=28239):
ESC (F raster block (len=29080):
ESC (F raster block (len=27231):
ESC (F raster block (len=592):
ESC (F raster block (len=5170):
ESC (F raster block (len=586):
ESC (F raster block (len=2776):
ESC (F raster block (len=28258):
ESC (F raster block (len=29077):
ESC (F raster block (len=27207):
ESC (F raster block (len=448):
ESC (F raster block (len=3859):
ESC (F raster block (len=446):
ESC (F raster block (len=2084):
ESC (F raster block (len=21203):
ESC (F raster block (len=21838):
ESC (F raster block (len=20490):

Regards,
Gernot

------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
Alastair M. Robinson | 9 Dec 2010 21:11
Picon

Re: Drop size calibration. New section.

Hi :)

On 08/12/10 22:50, Dmitriy Chaplygin wrote:

> Just now, after almost three years, I would like to answer it. I know at
> least in some ten people which for certain if read this letter, very
> strongly would ask you to describe calibration processes more in detail.
> If it is possible with examples and about a script files for yours
> testpattern the generator.

Robert kindly posted some more detail a few months later in this message:
http://sourceforge.net/mailarchive/message.php?msg_id=20871714

I'll forward the message to you complete with attachments, off-list.

All the best
--
Alastair M. Robinson

------------------------------------------------------------------------------
Dmitriy Chaplygin | 11 Dec 2010 11:28
Picon

Full calibration InkJet printer. Drops.

At the moment I'm doing calibration Epson 1410.
Thanks Alastair M. Robinson again for your letter!

With this letter and what I read I could (probably:) calibrate dropsizes. 
1. At 1440x1400ov I got the following ratios: a small drop to a large (DropSize1) - 0,105; average drop to a large (DropSize2) - 0,33. Do I understand (interpret) that 0.105 - this value tells us how many times the Small drop less Lagre; 0,33 - this value tells us how many times the Small drop less Lagre. If so, then why in testpattern (ex2.test) Robert made another strip ratio of the average drop in the Large, easy to control the correctness of the Small to Large?
In general, whether it is possible instead of manual methods of Robert to try to apply the possibility of instrumental calibration droplet size, which is in Gplin? If possible, how to interpret the obtained with Gplin values, that is how they relate to the parameters in modelXML DropSizeX =?


--
Yours faithfully,
Dmitriy Chaplygin.
C уважением,
Дмитрий Чаплыгин.
+7 (495) 979-8412
Skype: Chapa75
ICQ: 3167277

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
Robert Krawitz | 11 Dec 2010 23:51
Picon
Favicon

Large format Epson printers

I now have an Epson 3880 (that my wife bought me for Chanukah) up and
running.  Some observations:

1) escputil was working erratically at best with it.  I've gotten it
   working, but it's possible (although I judge it unlikely) that the
   change will cause problems with some very old printers.

   I've also changed the -e command to get the names of the colors
   from the printer if they're not listed in the model file.  It
   should therefore be possible to remove them from existing model
   files, but I'm not going to do so unless someone reports a problem
   with a particular printer.

   Also, the part numbers for the magenta cartridges are printing out
   incorrectly (their names aren't being decoded correctly).

2) The ink drop tuning is significantly off at 1440x720 and below (and
   the R2880 drop sizes, which aren't much different, are no better).
   At 2880x1440, the output's OK but the density is too low.  That's
   consistent with with the tuning of the R2400, which also uses 3.5
   pl drops (the R2880 uses 3 pl drops).  The base density of the
   R2400 at 5760x1440 DPI is 0.293, which is equivalent to 0.586 at
   2880x1440; the base density of the 3880 is 0.479.  That suggests
   that a density setting of 1.22 should work; in practice, 1.2
   appears to be a bit too high (there's a little bit pooling in the
   red and green at that level).

I want to consult with Edmund about fixing this.  If anyone has
linearized the printer at lower resolutions, changing the tuning will
throw that off.

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
edmund ronald | 12 Dec 2010 00:03
Picon

Re: Large format Epson printers

On Epson Enhanced Matte (or Archival matte, I forget) I use my Epson
3880 with the 4880 GP driver, and push the density to max (9). I then
color manage it, and get results equivalent to the native driver,
except for slightly less gamut in the reds. In order to color manage I
would be prepared to trade off linearity for gamut. Of course, as with
any color managed printer I am aiming at a gamut that would make
non-color managed prints from sRGB  look too colorful.

Edmund

On Sat, Dec 11, 2010 at 11:51 PM, Robert Krawitz <rlk <at> alum.mit.edu> wrote:
> I now have an Epson 3880 (that my wife bought me for Chanukah) up and
> running.  Some observations:
>
> 1) escputil was working erratically at best with it.  I've gotten it
>   working, but it's possible (although I judge it unlikely) that the
>   change will cause problems with some very old printers.
>
>   I've also changed the -e command to get the names of the colors
>   from the printer if they're not listed in the model file.  It
>   should therefore be possible to remove them from existing model
>   files, but I'm not going to do so unless someone reports a problem
>   with a particular printer.
>
>   Also, the part numbers for the magenta cartridges are printing out
>   incorrectly (their names aren't being decoded correctly).
>
> 2) The ink drop tuning is significantly off at 1440x720 and below (and
>   the R2880 drop sizes, which aren't much different, are no better).
>   At 2880x1440, the output's OK but the density is too low.  That's
>   consistent with with the tuning of the R2400, which also uses 3.5
>   pl drops (the R2880 uses 3 pl drops).  The base density of the
>   R2400 at 5760x1440 DPI is 0.293, which is equivalent to 0.586 at
>   2880x1440; the base density of the 3880 is 0.479.  That suggests
>   that a density setting of 1.22 should work; in practice, 1.2
>   appears to be a bit too high (there's a little bit pooling in the
>   red and green at that level).
>
> I want to consult with Edmund about fixing this.  If anyone has
> linearized the printer at lower resolutions, changing the tuning will
> throw that off.
>

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
Robert Krawitz | 12 Dec 2010 01:49
Picon
Favicon

Re: Large format Epson printers

On Sun, 12 Dec 2010 00:03:30 +0100, edmund ronald wrote:
> On Epson Enhanced Matte (or Archival matte, I forget) I use my Epson
> 3880 with the 4880 GP driver, and push the density to max (9). I then
> color manage it, and get results equivalent to the native driver,
> except for slightly less gamut in the reds. In order to color manage I
> would be prepared to trade off linearity for gamut. Of course, as with
> any color managed printer I am aiming at a gamut that would make
> non-color managed prints from sRGB  look too colorful.

If you're going to max the density adjustment and use 2880x1440, then
whatever I do isn't going to make a difference.  In any event,
retuning the drop sizes shouldn't affect gamut; it's just the
relationship between drop sizes I want to adjust.

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
Dmitriy Chaplygin | 12 Dec 2010 12:54
Picon

Calibration -> Linearization -> Profiling -> Printing

Calibration Linearization profiling. Complete the process. Setting up Print Ink-Paper.

Consists of the basic steps:

1. Calibration:

A drop size. (Yet visually - testgenerator patterns Robert)
- Finding the values DropSize1 (DropSize2).
2.2 Lights. (Visually or instrumentally (Gplin))
- Finding the parameters a) Value (visually or instrumentally), b) Transition (viz. a) DensityScale? (Vis. and / or Instr.?)

2. Pre-Linearization - Linearization - the definition of the limits per channel (fully instrumental - ArgyllCMS may hand an additional constraint ink limits after argyll)

2.1. Construction of the curves pre-linearization
- CyanDensityCurve? MagentaDensityCurve? ....... RedDensityCurve? and so on. with subsequent submission to the mediaXML or printrc (stay there).
2.2. Finding the limits for channels, Inc.
- CyanDensity and so on. (See Section 2.1)
2.3. Construction of linearization curves
- CyanDensityCurve MagentaDensityCurve ....... RedDensityCurve and so on. with subsequent use of these curves with argyll applycal.exe first at printtarg, then entering these curves in the profile or the use of curves in the application profile in tiff. (This stage is interesting opportunity to verify the results of 2.1 and 2.2, and if they are satisfactory - 2.3, we can not do that! Likely to cut by hand, Inc. limits are not necessary.)

3. Determination TotalInkLimit? (Visually).

- Finding values InkLimit?. Printing multiple strips from 0 to C100M100 and C100M100Y100 and C100M100K100. In practice it might be enough 3 - 5 iterations.

4. Profiling. (Instrumentalno. ArgyllCMS)

4.1 Preliminary Profile
4.1 Profile

5. Photo Print - WinGP, PhotoPrint?, Gplin (DeviceN) and so on.

5.1 "Manual"
- Building devicelink for each photo with tiffgamut and collink -> WinGP
5.2
IN ADDITION ...!


--
Yours faithfully,
Dmitriy Chaplygin.
C уважением,
Дмитрий Чаплыгин.
+7 (495) 979-8412
Skype: Chapa75
ICQ: 3167277

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
_______________________________________________
Gimp-print-devel mailing list
Gimp-print-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
Robert Krawitz | 12 Dec 2010 21:24
Picon
Favicon

Retuning of Stylus Pro printers

I've retuned the drop sizes and densities on the 3880, yielding much
better results at 720 and 1440x720 DPI.

I added resolutions of 1440x1440 and 2880x2880 DPI while I was at it.

--

-- 
Robert Krawitz                                     <rlk <at> alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 

Gmane