Log of #mupdf at irc.freenode.net.

Search:
 <<<Back 1 day (to 2018/12/14)20181215 
sebras Robin_Watts: ok, so fz_convert_color() ends up in this situation when it attempts to convert from one ICC profile to our sGray ICC profile. at this point the check for is_gray(ss) && is_cmyk(ds) is false since the destination in this case "Artifex Software sGray ICC Profile" is not cmyk while "Artifex Software sGray ICC Profile" is not gray.01:29.50 
  oh and "ISO Coated v2 300% (ECI)" corresponds to our default cmyk colorspace.01:32.39 
  so mupdf is actually converting CMYK -> gray, but while fz_convert_color() sets the color convertor to icc_conv_color() it doesn't set the color convetors link parameter to anything but NULL because of is_cmyk(ds) is false and is_gray(ss) is false.01:34.12 
  and the default value is CMYK.01:34.26 
  ehm. NULL, not CMYK. :)01:34.35 
  Robin_Watts: so I created this issue on my own in my alternate ICC profile commit. I have consequently made two fixup commits on sebras/master01:51.13 
  I plan to squash them of course.01:51.31 
  however, the handling gray->cmyk as K only..01:51.48 
  it is not evident to me whether that ought to be done before or after checking the alternate colorspace.01:52.15 
  this check is in icc_conv_pixmap() and fz_find_color_converter().01:52.56 
  in icc_conv_pixmap() we also involve the defualt colorspaces.01:53.10 
  prior to my commit the gray->cmyk check appears to have been done after before both the defualt_cs fiddling and obtaining the icc link.01:54.13 
  hence I kept this order.01:54.31 
  and presumably the colorspace for the ICC profile and the altenate colorspace are related, e.g. sRGB and /DeviceRGB making conversion reasonable.01:55.15 
  Robin_Watts: with those fixups it clusters without differences.02:05.23 
  and I'm able to successfully render the output from rastertopwg.02:05.56 
  nice to be able to figure it out.02:08.15 
 Forward 1 day (to 2018/12/16)>>> 
ghostscript.com #ghostscript
Search: