Color Management and other new developments in Ghostscript
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Leung, Hin-Tak
The Ghostscript team has a few on-going or soon-to-complete development efforts which would be of great interest to the free graphics community. We have done some major work with ICC-profiles which is about to be merged into trunk for release in August (hopefully.) We have also integrated freetype as a font-renderer, and made under-the-hood improvements in the form of clist and going towards multi-threaded rendering. In the embedded/small-memory-footprint application area, we have been working on mupdf. These are just a few highlights.
 Hi. How many of you have not heard of GoScoop? Okay. Well, you have used it, I'm sure. I'm going to talk about color management and free type 2 and some of the latest development in GoScoop. Most some of you probably have no Ralph Giles. He's not here, and I'm here, so mostly I'm here because he's not here. My involvement with GoScoop is quite recent, but I was interested in for about 15 years ago, and so I spent a lot of time learning CJK, latex around that time and post-coop, and then gradually doing reverse engineering printer protocols. And if you've got a USB wireless device on your Linux system which is made by RealTek, then that kind of module actually had my name on it. So I've gone slightly deep in the hardware side of things. That's me. So GoScoop is a document conversion and rendering engine. It's essential to Linux printing pipeline, so if you could print I'm sure you'll use it somehow and you don't know it yet. It's dual license. Under GPL it has a proprietary license as well. We actually sell that technology to some printer manufacturers. Some fax machine manufacturers and also do commercial consulting as well. The source code is available. Apparently 20 years ago when Peter L. Deutsch met Richard Stolman, Richard Stolman actually managed to get Peter L. Stolman to write down and say GoScoop has to be available under free license forever and ever. So we are committed to having it under GPL forever and ever, basically. It runs on all major operating systems including windows of course and some embedded environment of course. That's how we make some of the money. Some of the clients. I wasn't too sure what the audience are so I prepared my slide in a way that would cover quite a wide audience but I'm going to skip over some of the slides as I go along. This is how the GoScoop infrastructure works overview. You can take multiple language as input, multiple document format. PDF and PostScript are what you normally have. Most people would be only aware of what happens up there so you would have Firefox open office and say other things and then you would send your document through down here to Cubs and then store as PostScript and then render through the graphic library and then send to the printer drivers. Some people would be using that workflow to send to the fax device and if you're using ImageMagic you would probably be doing PostScript down to GoScoop and then use some of the roster formats down here. We can use a lot of fonts formats when you have got a PDF or PostScript file which hasn't got embedded fonts inside. We can enter with various fonts to load it on demand. The screening technology on this side is for rendering. You know most computer work on an RGB model where an additive color model where you've got red, green, blue but when you are actually printing you would be actually putting cyan, magenta, blue color dots on your media. So you actually have to reverse the color and say back in the black and white days you would have black dots but you try to put a gray scale on your media and then you would try to space your black dots around so that it would have a smooth appearance. That's what that screening technology is about on that side. So the color space part of GoScoop is actually a later let on. We support all the major color space PostScript level 3 device, gray device, RGB device, CMYK various device independent color space and PDF, some of the ITC based color space. Most PCLs is RGB based and assumed to be S-RGB and when we're talking about XPS then most of it is defined by color profiles. Now GoScoop supports all of that. But there's a cache there. The GoScoop project actually started about 20 years ago when most printing was still black and white. So in those days you would be somewhere down here where you send in your black dots and it comes out and sends to your printer. We gradually put in the color rendering. I think the process color model is the first thing to put in first. So you invert your RGB color into a CMYK model and you try to have an accurate color reproduction down here. So you put in a color rendering dictionary which map the internal color representation in GoScoop to a color value that is closer to what the printer understands before you map it to process color. Then gradually we put in the input color space there where you have a scanner RGB image from a camera which comes with a color profile and it maps through to CIE lab color space. So for each image pixels the workflow could actually a color value would be transformed multiple times for each pixel. So you've got one, two, three, four, quite a few steps there. Because they were gradually add on over time over the last 20 years so it's become quite inefficient. For the last 18 months Michael, I can't pronounce his surname, one of our guys has been working on integrating, collapsing all the color mapping transforms into one transform to go from the input color value to the output color value and actually keeping track of how things should be transformed in the middle. That's a major improvement because well as you saw earlier we could be transforming per pixel three, four times before you get to the printer and that's quite slow. If you can collapse the step all the way through you can speed up the workflow quite a lot in that way. So it's actually a very exciting development and it's just been merged into trunk on Monday. So if you check out your CVS, no S subversion today then you will get it. I'm going to scoot over some of that. So this is how the command line interface works. You could pass in source profiles the device profile and search directions and other settings. As a side effect of this work of matching of integrating, collapsing the color transform and supporting color profile input in a more native way, we also support what you call the PDF rendering intent which is a per image setting in your PDF. Say you could embed an image in your PDF and then send to the printer and the printer probably have a different color characteristic compared to your input. Say when you're printing on fabric for example the silk or cotton probably can't absorb some color too well so you won't be able to render the color as you want it from the input. You can declare when that limitation happens what you want to do with the rendering as a per image setting in a PDF so there are four in the PDF specification which is relative color metric and absolute color metric perceptual saturation. One of them is for you actually map the white point so you transform the entire color curve up and down to shift it slightly and the other one you just clip just remove the extreme colors and two others is implementation specific and you try to compress the color or expand it so that you get visually pleasing result or for saturation so you actually try to get extreme colors to get the most striking result and that's quite useful for graphics design when you want to catch other people's attention. Now I'm going to show you some bucks actually that when color rendering goes wrong. This is one particular example you can actually download it from this URL. This is the correct image but if you actually render it through Excel and then transform it back you actually have a red color over there and what happened there is that the PDF writer somebody make that PDF up and say okay this is an image that has got a slight color thing but I want you to map the color so that the white point actually go to white so to correct it afterwards. So in the new architecture I suppose this is probably not quite to the users. For certain color workflow you can actually have render twice as fast. This is actually the son of the main engineer. For another type of image this is actually the worst case scenario the CIE lab image where actually for each pixel you will map through about 3-4 stages and in the new architecture we actually map one scan line by one transform so it would render about three times as fast compared to a month ago. I just talked about rendering intent. Again, well last week in Chunk if you have got a PDF which have rendering intent in per image it does nothing basically just ignore it and say well I don't understand it so I just ignore it. So all four images exactly the same last week. Now this is what happens if you check out the code now. This is, I think this is these two are closer to the original and saturation is where you go for extreme colors to catch your attention. But that's another one. I think Michael actually make up the color rendering intent so that they are slightly weird just to illustrate the point. This is just a time and curve for various different type of PDFs for rendering. So for different kind of images you can actually get a 30% twice or three times in rendering speed. As a side effect of that work for the last 18 months we now support version 4 of the ICC profile as well. Also the rendering intent per graphic object which I just illustrated earlier. Now where can I get it? Well this is where you can get it over the subversion repository. It was just merged on Monday so we can't go back anymore. It's due to get out in August if we are lucky. So I like to have some guinea pigs. We have already looked at most of the regression difference so this basically works. I've actually bundled some source snapshots and also some windows binary installers under my directory. If you want to try it out if one of use windows and don't want to check out the subversion repository. So this is one big part of work that has been going on for 18 months. Now in the last open printing summit which was only a month ago since we are finishing the color rendering profile work actually Tim from Red Hat has asked, cups already support per queue ICC profiles. You could actually configure your print queue that saved for the same physical printer. You can have different print queues with different ICC profiles and you can embed your profiles per print jobs as well. He actually asked can I have some favorite bits of profile that some user use. For example you would have your, some user might have their own monitor and or preview or the cheaper printers next to their computer and you want to match that color to a network printer. So it's a frequently user setting that you want to cater for. And the user might have a stash of expensive or very rarely used media in his drawer. He only take it out when he need to do some presentation. So that's actually a useful use case where a user might actually want to upload a profile that he like to use for, recall for his own jobs without sending it over and over. And we would like some input for the user interface design as well. So this is what is going to happen in the next six months or something. Okay. We also support various phone technologies as well. In the last, actually two or three months we have integrated free type two. Now I'm going to show you how things could go wrong with phone rendering as well. This is the original PDF. Now this is what happens when you sent it through Go script 8.63 and then view it with XPDF3. So you've got something very smudgy there and something is completely gone and a glimpse is slightly misrenders. And also that is totally messed up. But actually that part is an XPDF but nothing to do with us. But those are. So up to 8.71 we actually have our own in-house phone renderer because free type is actually a little bit younger than Go script. But you actually saw three different problems which is as much as to do a stroke with. What happens over there in the previous graph was a mass problem. And also Apple has a pattern which just expired for two type bytecode instructions. So actually 8.71 last week is actually not too bad. It's only have sort of two slide problem. That's actually a pattern bytecode instruction problem. And the other one is actually an echo back viewing artifacts which I've already written down that you can switch off the text moving to get rid of that effect over there. So it's actually a viewing problem. Now one less known feature of Go script is it can render by band to minimize memory footprint mostly at the moment. It's actually doing it by default now. So it actually automatically switch on. But we don't do a parallel rendering yet. It's actually an ongoing effort. But you could actually try it out if you want to switch it on to play with it a little bit. I'll skip over that. Okay we have got a little project on the side which we sell to some of the embedded market. Commercial we call it Go slide but internally it's based on what you call a MIU PDF. It's a lightweight PDF viewer which is optimized for small memory footprint for anti-alliance graphics for high resolution rendering at low resolution devices. And we are talking to Debian to ship it but mostly because it's basically a commercial enterprise we have been concentrating on Windows and arms development at the moment. There is an existing X11 GUI but it sucks a little bit. So if any of you want to play with it a little bit that's fine by me. It's under GPL and also commercializing things as well. So for commercializing you can talk to the commercial guys but if you want GPL it's GPL. Okay done. That's the last slide.
 Hi. How many of you have not heard of GoScoop?  Okay. Well, you have used it, I'm sure.  I'm going to talk about color management and free type 2  and some of the latest development in GoScoop.  Most some of you probably have no Ralph Giles.  He's not here, and I'm here, so mostly  I'm here because he's not here.  My involvement with GoScoop is quite recent,  but I was interested in  for about 15 years ago, and so  I spent a lot of time learning CJK,  latex around that time and post-coop, and then gradually  doing reverse engineering printer protocols.  And if you've got a USB wireless device on your Linux system  which is made by RealTek,  then that kind of module actually had my name on it.  So I've gone slightly deep in the hardware side of things.  That's me.  So GoScoop is a document conversion and rendering engine.  It's essential to Linux printing pipeline, so if you could print  I'm sure you'll use it somehow and you don't know it yet.  It's dual license.  Under GPL it has a proprietary license as well.  We actually sell that technology to some printer manufacturers.  Some fax machine manufacturers  and also do commercial consulting as well.  The source code is available. Apparently  20 years ago when Peter L. Deutsch met Richard Stolman,  Richard Stolman actually managed to get Peter L. Stolman to  write down and say GoScoop  has to be available under free license  forever and ever. So we are  committed to having it under GPL forever and ever, basically.  It runs on all major operating systems  including windows of course and some embedded  environment of course. That's how we make some of the money.  Some of the clients.  I wasn't too sure what the audience are so I prepared my slide  in a way that would cover quite a wide audience but I'm going to  skip over some of the slides as I go along.  This is how the GoScoop infrastructure  works overview. You can take multiple  language as input, multiple document  format. PDF and PostScript are what you  normally have. Most people  would be only aware of what happens up there  so you would have Firefox open office  and say other things and then  you would send your document through down here to Cubs  and then store as PostScript and then render  through the graphic library and then send to the printer drivers.  Some people would be using that workflow to send  to the fax device and if you're using ImageMagic  you would probably be doing PostScript down to  GoScoop and then use some of the roster formats  down here. We can  use a lot of fonts formats when you have got a  PDF or PostScript file which hasn't got embedded fonts inside.  We can enter with various fonts  to load it on demand. The screening technology on this  side is for rendering.  You know most computer work on an RGB  model where an additive color model where you've got red, green, blue  but when you are actually printing you would be  actually putting cyan, magenta, blue color dots on your  media. So you actually have to reverse the color and say  back in the black and white days you would have  black dots but you try to put a gray scale on your  media and then you would try to space your black dots  around so that it would have a smooth appearance. That's what that screening  technology is about on that side.  So the color space  part of GoScoop is actually a later  let on. We support all the major color space  PostScript level 3 device, gray device, RGB device, CMYK  various device independent color space and  PDF, some of the ITC based color space.  Most PCLs is RGB based and assumed to be  S-RGB and when we're talking about XPS then  most of it is defined by color profiles. Now GoScoop supports  all of that.  But there's a cache there.  The GoScoop project actually started about  20 years ago when most printing was still black and white.  So in those days you would be somewhere  down here where you send in your black dots and it  comes out and sends to your printer. We gradually put  in the color rendering. I think the process color model  is the first thing to put in first. So you invert your  RGB color into a CMYK model  and you try to have an accurate  color reproduction down here. So you put in a color rendering dictionary  which map the internal color representation  in GoScoop to a color  value that is closer to what the printer understands  before you map it to process color.  Then gradually we put in the input color space  there where you have a scanner  RGB image from a camera which comes  with a color profile and it maps through to  CIE lab color space.  So for each image pixels  the workflow could actually  a color value would be transformed multiple times  for each pixel. So you've got one, two,  three, four, quite a few steps there.  Because they were gradually add on over time over the last 20 years  so it's become quite inefficient.  For the last 18 months  Michael, I can't pronounce his surname, one of our guys  has been working on integrating, collapsing all the  color mapping transforms into one transform  to go from the input color value to the output color  value and actually keeping track of how things should be transformed  in the middle. That's a major improvement because  well as you saw earlier we could  be transforming per pixel three, four  times before you get to the printer and that's quite slow.  If you can collapse the step all the way through  you can speed up the workflow quite a lot in that way.  So it's actually a very exciting development  and it's just been merged into trunk on Monday. So if  you check out your CVS, no S subversion  today then you will get it.  I'm going to scoot over some of that. So this is how the command line  interface works. You could pass in source profiles  the device profile and search directions  and other settings. As a side effect of  this work of matching  of integrating, collapsing the  color transform and supporting  color profile input in a more native way, we also support  what you call the PDF rendering intent which is a  per image setting in your PDF.  Say you could embed an image in your PDF  and then send to the printer  and the printer probably have a different color characteristic  compared to your input. Say  when you're printing on fabric for example  the silk or  cotton probably can't absorb some color too well  so you won't be able to render the color as  you want it from the input. You can declare when  that limitation happens what you want to do with the rendering  as a per image setting in a PDF  so there are four in the PDF specification  which is relative color metric and  absolute color metric perceptual saturation.  One of them is for you actually map the white point  so you transform the entire color curve up and down to shift  it slightly and the other one you just clip  just remove the extreme colors  and two others is implementation specific  and you try to compress the color or  expand it so that you get visually pleasing result or  for saturation so you actually  try to get extreme colors to get the most striking result and that's  quite useful for graphics design when you want to catch other people's attention.  Now I'm going to show you some bucks actually  that when color rendering goes wrong.  This is one particular example you can actually download it from  this URL.  This is the correct image but if you actually render it through  Excel and then transform it back you actually have a red color  over there and what happened there is that  the PDF writer somebody make that PDF  up and say okay this is an image that has  got a slight color thing but I want you to map the  color so that the white point actually  go to white so to correct it afterwards.  So  in the new architecture  I suppose this is probably not quite to the users.  For certain color workflow you can  actually have render twice as fast.  This is actually the son of the main engineer.  For another type of image  this is actually the worst case scenario  the CIE lab image where actually for each pixel  you will map through about 3-4 stages  and in the new architecture we actually map one scan line  by one transform so it would  render about three times as fast compared to a month ago.  I just talked about rendering intent.  Again, well last week in Chunk  if you have got a PDF which  have rendering intent in per image  it does nothing basically just ignore it and say  well I don't understand it so I just ignore it.  So all four images exactly the same  last week. Now this is  what happens if you check out the code now.  This is, I think this is  these two are closer to the original  and saturation is where you go for extreme colors to catch  your attention. But that's another one.  I think Michael actually make up the color rendering intent  so that they are slightly weird just to  illustrate the point. This is just  a time and curve for various different type of  PDFs for  rendering. So for different kind of images you can actually get  a 30% twice or three times in rendering speed.  As a side effect of that  work for the last 18 months we now support  version 4 of the ICC profile as well.  Also the rendering intent per graphic object  which I just illustrated earlier. Now  where can I get it? Well this is where  you can get it over the subversion  repository. It was just merged on Monday  so we can't go back anymore. It's due  to get out in August if we are lucky.  So I like to have some guinea pigs.  We have already looked at most of the regression difference  so this basically works. I've  actually bundled some source snapshots and also some windows binary  installers under my directory. If you want to try it out if one of  use windows and don't want to check out the  subversion repository. So this is one  big part of work that has been going on for 18 months.  Now in the last  open printing summit which was only a month ago  since we are finishing the color rendering profile work  actually Tim from Red Hat has  asked, cups already support  per queue ICC profiles. You could actually  configure your print queue that  saved for the same physical printer. You can have different print queues with different  ICC profiles and you can embed your profiles  per print jobs as well. He actually asked  can I have some favorite  bits of profile that some user use. For example you would have  your, some user might have their own monitor  and or preview or the cheaper printers next to  their computer and you want to match that color to a network printer.  So it's a frequently user setting  that you want to cater for.  And the user might have a stash of  expensive or very rarely used media in his drawer.  He only take it out when he need to do some presentation.  So that's actually a useful  use case where a user might actually want to upload  a profile that he like to use  for, recall for his own jobs without sending it  over and over. And we would like some  input for the user interface design as well. So this is what is going  to happen in the next six months or something.  Okay.  We also support various phone technologies as well.  In the last, actually two or three months we have  integrated free type two. Now  I'm going to show you how things could go wrong with phone rendering  as well. This is the original PDF.  Now this is what happens when you  sent it through Go script 8.63 and then view it  with XPDF3. So you've got something very smudgy  there and something is completely gone and a  glimpse is slightly misrenders. And also  that is totally messed up. But  actually that part is an XPDF but nothing to do with us.  But those are.  So up to 8.71 we  actually have our own in-house phone renderer  because free type is actually a little bit younger than Go script.  But you actually saw three different  problems which is as much as to do a stroke with.  What happens over there in the previous graph was  a mass problem. And also Apple has a pattern  which just expired for two type  bytecode instructions.  So  actually 8.71 last week is actually  not too bad. It's only have sort of two slide problem. That's actually  a pattern bytecode instruction problem. And the other one  is actually an echo back viewing artifacts  which I've already written down that you can switch off the text  moving to get rid of that effect over there. So it's  actually a viewing problem.  Now one less known  feature of Go script is it can render  by band to minimize memory footprint  mostly at the moment.  It's actually doing it by default now.  So it actually automatically switch on.  But we don't do a parallel rendering yet. It's actually an ongoing  effort. But you could actually try it out if you want to  switch it on to play with it a little bit.  I'll skip over that.  Okay we have got a little project on the  side which we sell to some of the embedded  market. Commercial we call it Go slide  but internally it's based on what you call a  MIU PDF. It's a lightweight PDF viewer which is optimized for  small memory footprint  for anti-alliance  graphics for high resolution rendering at low resolution devices.  And we are talking to Debian  to ship it but mostly because  it's basically a commercial enterprise we have been  concentrating on Windows and arms development at the moment. There is  an existing X11 GUI but it sucks  a little bit. So if any of you want to  play with it a little bit that's fine by me.  It's  under GPL and also commercializing things  as well. So for commercializing you can talk to the commercial guys  but if you want GPL it's GPL. Okay done.  That's the last slide.
Color_Management_and_other_new_developments_in_Ghostscript_0_155.png Color_Management_and_other_new_developments_in_Ghostscript_156_623.png Color_Management_and_other_new_developments_in_Ghostscript_624_3467.png Color_Management_and_other_new_developments_in_Ghostscript_3468_8255.png Color_Management_and_other_new_developments_in_Ghostscript_8256_8351.png Color_Management_and_other_new_developments_in_Ghostscript_8352_8435.png Color_Management_and_other_new_developments_in_Ghostscript_8436_12611.png Color_Management_and_other_new_developments_in_Ghostscript_12612_13139.png Color_Management_and_other_new_developments_in_Ghostscript_13140_16871.png Color_Management_and_other_new_developments_in_Ghostscript_16872_17339.png Color_Management_and_other_new_developments_in_Ghostscript_17340_17423.png Color_Management_and_other_new_developments_in_Ghostscript_17424_21083.png Color_Management_and_other_new_developments_in_Ghostscript_21084_22415.png Color_Management_and_other_new_developments_in_Ghostscript_22416_25427.png Color_Management_and_other_new_developments_in_Ghostscript_25428_25535.png Color_Management_and_other_new_developments_in_Ghostscript_25536_28223.png Color_Management_and_other_new_developments_in_Ghostscript_28224_29147.png Color_Management_and_other_new_developments_in_Ghostscript_29148_31247.png Color_Management_and_other_new_developments_in_Ghostscript_31248_31290.png