| | <<<Back 1 day (to 2017/07/27) | 20170728 |
| Robin_Watts | lights the octarine candle and performs the mvrhel summoning ritual... | 15:13.34 |
| | Morning. | 15:48.57 |
| mvrhel_laptop | Morning | 15:49.48 |
| Robin_Watts | so, some Altona questions... | 15:50.26 |
| | U10 shows an 9x9 Image in an ICC based space. | 15:50.48 |
| | The alternate space is DeviceGray. | 15:50.55 |
| mvrhel_laptop | ok | 15:51.12 |
| Robin_Watts | Currently I don't overprint it, and it looks wrong. | 15:51.23 |
| | so should I overprint ICC stuff with an DeviceGray alternate ? | 15:51.45 |
| | yeah, that looks a lot better. | 15:52.51 |
| mvrhel_laptop | ICC based color objects should not be overprinted. They should be transformed with standard color management. So that image should be printed with composite CMYK | 15:53.37 |
| Robin_Watts | New out.psd in my homedir on casper. | 15:53.48 |
| | Along with a ref.psd which is what we get from gs. | 15:53.56 |
| mvrhel_laptop | ok. Let me grab them | 15:54.06 |
| | So I still need to fix the gray to K | 15:57.08 |
| Robin_Watts | yeah. That'll account for a lot of differences. | 15:57.28 |
| | but even without that, I think the image ones are pretty good now. | 15:57.41 |
| | This rendering has us treating ICCBased profiles with a /DevGray alternate as overprintable. Without that U10 goes wrong. | 15:58.29 |
| | I've updated robin/spots. | 15:58.48 |
| | No changes to the project files today, so no need to reimport. | 15:59.00 |
| mvrhel_laptop | ok | 16:00.14 |
| | I don't understand "This rendering has us treating ICCBased profiles with a /DevGray alternate as overprintable. Without that U10 goes wrong." | 16:00.40 |
| | So what is going on with H and some of the other white fills? | 16:01.20 |
| | Those are Device Gray with a value of 1 | 16:01.33 |
| Robin_Watts | Dunno. I've been concentrating on images today. | 16:01.41 |
| | but I can't spot any images that go wrong now, so that might be my next port of call. | 16:02.04 |
| mvrhel_laptop | ah ok | 16:02.13 |
| Robin_Watts | OK, so do you agree that U10 looks correct ? | 16:02.16 |
| mvrhel_laptop | image do look good | 16:02.17 |
| Robin_Watts | (and I think text is good too) | 16:02.27 |
| mvrhel_laptop | let me look at U10 closely | 16:02.45 |
| | hold on | 16:02.46 |
| Robin_Watts | If you are interested... I have a version of this file with all the image and text calls commented out. | 16:03.38 |
| mvrhel_laptop | CMYK values all seem correct | 16:03.54 |
| Robin_Watts | so I can go in and just reenable the particular ones I want for a given test. | 16:04.04 |
| | Takes a bit of trial and error to enable the right one, but it's MUCH faster than cutting the file down each time. | 16:04.32 |
| | ok, there is now a broken.psd in my home dir too. | 16:06.33 |
| | That is the output without the last commit on robin/spots | 16:06.45 |
| | The last commit on robin/spots says "If this ICC space has a DeviceGray alternate, then set the DeviceGray flag" | 16:07.25 |
| mvrhel_laptop | So I don't understand that one | 16:08.14 |
| Robin_Watts | U10 and U11 are directly affected by that change. | 16:08.23 |
| mvrhel_laptop | Device Gray should be mapped to Pure K | 16:08.24 |
| | what is the Device Gray flag doing | 16:08.37 |
| | I would have thought that would indicated that Gray gets mapped to K | 16:08.47 |
| | that is not happening here | 16:08.51 |
| | and we don't want that to happend | 16:08.56 |
| | or even happen | 16:09.01 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=blob;f=source/fitz/draw-device.c;h=301cfe8280dc1db56acfeda024d7541abf113108;hb=37b3127fda295c41afadc6064fc0d78817fe2e9c | 16:10.39 |
| | look at line 1550 onwards. | 16:10.43 |
| | This is where I'm being asked to plot an image. | 16:11.03 |
| | The image isn't in the matching space, so I have to convert it to the required space to feed it to the plotters. | 16:11.21 |
| | And the source space is not a device_n one. | 16:11.39 |
| mvrhel_laptop | ok. lets back up for a second | 16:11.40 |
| Robin_Watts | waits. | 16:11.56 |
| mvrhel_laptop | Lets say you have an image that is defined by an ICC profile and the target pixmap you are going to has a different ICC profile. | 16:12.17 |
| | It should not matter if it is GrayICC, RGBICC or CMYKICC | 16:12.36 |
| | you have to do the same thing | 16:12.45 |
| Robin_Watts | Indeed, it does not. Like 1551 converts it. | 16:13.06 |
| mvrhel_laptop | so the image in U10 is ICC gray based | 16:13.59 |
| | so 1551 should convert it to CMYK | 16:14.26 |
| Robin_Watts | Yes. | 16:14.34 |
| mvrhel_laptop | and there should not be any special handling or dependency on a DeviceGray flag | 16:14.55 |
| | am I missing something? | 16:15.02 |
| Robin_Watts | Now, when we arrive here in the code, we know we have overprint enabled, so eop points to an overprint bitmap (currently all zeros) | 16:15.11 |
| mvrhel_laptop | eop stands for.... | 16:15.30 |
| | enable overprint? | 16:15.35 |
| Robin_Watts | eop = overprint bitmap | 16:15.44 |
| | the name is eop for hysterical raisins. I should rename it. | 16:15.55 |
| | but a bit being 0 means "just copy the color in unchanged to this component" | 16:16.50 |
| | and 1 means "don't alter this component" | 16:16.58 |
| mvrhel_laptop | I see. You were blowing away the spot colors before | 16:17.25 |
| Robin_Watts | so if we don't do anything in if at line 1552, we get broken.psd | 16:17.27 |
| | In my new code, we go in there, and we check to see if the colorspace is device gray or cmyk. | 16:18.01 |
| | If it is, and we are plotting to a CMYK output, we arrange not to overwrite the spot colors | 16:18.43 |
| | Hmm. Maybe the key thing is not that this is devicegray. Maybe I should be doing this for ALL process only colorspaces ? | 16:19.40 |
| | (i.e. I'm doing the right thing, but for the wrong reason?) | 16:19.54 |
| mvrhel_laptop | Certainly if the image is RGB based you are not going to do it. I am a little surprised that the device gray is behaving this way | 16:23.55 |
| Robin_Watts | If I get an RGB image, and I plot that with OP=1, should that blow away spot colors? | 16:25.04 |
| mvrhel_laptop | yes I would think so. overprint should not be working with RGB drawing | 16:25.54 |
| Robin_Watts | mvrhel_laptop: Well, I am confused. You can see that what I have works, but it would seem to be contrary to what you say the spec is. | 16:27.05 |
| mvrhel_laptop | let me check the spec again... | 16:27.06 |
| Robin_Watts | does the same. | 16:27.13 |
| mvrhel_laptop | hmmm I guess I am wrong | 16:28.21 |
| | So yes it is not just device gray | 16:29.08 |
| | when we do the conversion of the image to cmyk, it should just leave the spots alone | 16:29.30 |
| | And that is what adobe is showing on the altona file | 16:30.02 |
| Robin_Watts | ok. I propose to leave what I have alone then, and if we hit a case where it goes wrong, we'll worry about it then. | 16:30.29 |
| mvrhel_laptop | Robin_Watts: ok but I do have a problem setting this color space as FZ_CS_DEVICE_GRAY | 16:32.44 |
| | its not. It was ICC | 16:32.52 |
| Robin_Watts | it's an ICC space still. It just has the flag set of "Treat this as DeviceGray". | 16:34.15 |
| mvrhel_laptop | if FZ_CS_DEVICE_GRAY is set, we will end up doing a conversion to K and not composite | 16:34.20 |
| | once I code that up | 16:34.25 |
| Robin_Watts | Ah, ok. | 16:34.26 |
| | Can you think of a better test? | 16:34.35 |
| | If I don't set that flag, what test should I use to get this right? | 16:34.47 |
| mvrhel_laptop | well if the source image was not a devicen, then it would have to of been gray, rgb or cmyk. Is that correct? | 16:36.56 |
| Robin_Watts | yeah. | 16:37.25 |
| | So: !devicen && cs->n == 1 ? | 16:37.53 |
| mvrhel_laptop | hmm of course how is a devicen image with cyan magenta treated | 16:37.55 |
| Robin_Watts | I see the problem with the H row. resolve_color is still infected with my old broken understanding of OPM | 16:38.35 |
| mvrhel_laptop | Robin_Watts: if the original pixmap had just process colorants, would s = 0? | 16:41.08 |
| Robin_Watts | yes. | 16:41.21 |
| mvrhel_laptop | I would think a test on that would be what we would want | 16:41.34 |
| | s = 0 and fz_colorspace_n(ctx, model) == 4 | 16:42.08 |
| | That would imply that we are going to CMYK and the original image was process only | 16:42.38 |
| Robin_Watts | So you're saying that an rgb input pixmap plotted to CMYK with OP and OPM=1, would leave the spots alone, but would blow the CMYK away. | 16:42.52 |
| mvrhel_laptop | lets look at the altona file.... | 16:43.09 |
| | so V is RGB ICC based | 16:43.34 |
| | V10 clearly leaves spots alone | 16:44.23 |
| | in AR | 16:44.27 |
| | hmm lab images... | 16:44.57 |
| Robin_Watts | But not in gs. | 16:45.06 |
| mvrhel_laptop | basically any case where the source is ICC it leaves it alone | 16:45.09 |
| | then gs is wrong... | 16:45.12 |
| | and I need to fix that | 16:45.14 |
| Robin_Watts | ok,so I'll try that fix in a mo. | 16:45.29 |
| mvrhel_laptop | Robin_Watts: perhaps a better test is this | 16:46.16 |
| | no actually s==0 is the test | 16:47.04 |
| | so s==0 && fz_colorspace_n(ctx, model) == 4 | 16:47.19 |
| Robin_Watts | If it's not devicen, and we are plotting to cmyk, then protect the spots. | 16:47.28 |
| mvrhel_laptop | yes | 16:47.35 |
| | if eop :) | 16:48.05 |
| | That is what the altona file is showing | 16:48.42 |
| | So gs is screwing this up | 16:50.08 |
| Robin_Watts | I think that might remove the need to know about DeviceGray. | 16:50.14 |
| mvrhel_laptop | in a significant way | 16:50.21 |
| Robin_Watts | which is nice (simplifying is always nice) | 16:50.29 |
| mvrhel_laptop | Robin_Watts: no we will still need that to know to convert to pure K | 16:50.31 |
| Robin_Watts | ah, ok. | 16:50.38 |
| | I'm being dragged out of the house soon :( | 16:54.53 |
| | So the H row... | 16:55.00 |
| | those are stuff plotted with g 0 | 16:55.33 |
| | oops, 1 g | 16:55.44 |
| | so that's a color with component values of 0, so according to OPM I'm choosing not to write it. | 16:56.16 |
| mvrhel_laptop | so OPM should not be in effect right | 16:57.02 |
| | its only used if we are drawing with CMYK | 16:57.30 |
| Robin_Watts | ah, that might be it. | 16:57.53 |
| | CMYK or deviceN ? | 16:58.53 |
| mvrhel_laptop | only cmyk according to spec | 16:59.02 |
| Robin_Watts | ok, that looks really good now. | 17:03.36 |
| | I've pushed everything to robin/spots. | 17:03.41 |
| | and there is a new out.psd there now that looks pretty much perfect I think. | 17:03.57 |
| mvrhel_laptop | awesome | 17:04.39 |
| Robin_Watts | oh, no, some of the H row is still missing. | 17:05.03 |
| mvrhel_laptop | I have to run wifes car to shop. so I will update now and then work on the device gray to k stuff | 17:05.04 |
| Robin_Watts | or rather... I'm blowing away spots when I shouldn't be. | 17:05.52 |
| | I will work on that tomorrow or monday. | 17:06.36 |
| | We are very close though, I think. | 17:06.45 |
| mvrhel_laptop | yes I think so | 17:07.05 |
| | nice job! | 17:07.09 |
| Robin_Watts | Fixed! | 17:10.40 |
| | Thanks for all your help on this. | 17:11.02 |
| mvrhel_laptop | no problem. I will update and push on | 17:12.58 |
| | did you track down the shading issue I emailed you about? | 17:13.08 |
| Robin_Watts | mvrhel: For the logs: Yes, all fixed. | 18:10.04 |
| icem | Robin_Watts, I forgot: where did you say I could download the source for "MuPDF 1.12"? | 22:39.19 |
| icem_ | sorry got d/c | 22:41.25 |
| | Robin_Watts, what program do I need to compile? | 22:44.41 |
| Robin_Watts | icem_: What program do you want? | 22:44.55 |
| icem_ | I wanted "MuPDF" latest version for windows | 22:45.31 |
| Robin_Watts | Then clone our git repository, open platform/win32/mupdf.sln in visual studio, let it update if it needs to, and then build. | 22:46.23 |
| icem_ | ok thanks | 22:46.32 |
| Robin_Watts | Make sure you use the --recursive flag to git clone. | 22:46.55 |
| | and the output will be in platform/win32/{Debug,Release}/mupdf.exe as appropriate. | 22:47.21 |
| icem_ | do you have the exact link to clone the git? | 22:47.57 |
| Robin_Watts | It's on the front page of mupdf.com | 22:48.26 |
| icem_ | homepage | 22:48.26 |
| | ah ok | 22:48.29 |
| | Robin_Watts, by "clone" do you mean "snapshot"? | 22:49.22 |
| Robin_Watts | nope. by clone I mean clone. | 22:49.33 |
| icem_ | ok | 22:49.44 |
| Robin_Watts | If you just want a snapshot, then you can download that from one of the links at: http://git.ghostscript.com/?p=mupdf.git;a=shortlog | 22:50.17 |
| | but that won't give you the submodules. | 22:50.25 |
| | Easier to clone properly. | 22:50.29 |
| icem_ | is this it? https://github.com/ccxvii/mupdf | 22:52.20 |
| Robin_Watts | That is a mirror. It's not the one listed on the front page of mupdf.com] | 22:55.38 |
| | It might do, it might not. | 22:55.45 |
| | If you try to use that and have problems, I'll tell you to use the one on the front page of mupdf.com, so why not just use the one on the front page of mupdf.com ? | 22:56.14 |
| icem_ | I don't want to take up your time, but I'm not sure how to clone the git (I'm getting VisualStudio community edition right now...) | 22:58.44 |
| Robin_Watts | icem_: Step one: install git for windows. | 22:59.00 |
| | Step two: Use the command on the frontpage. | 22:59.18 |
| icem_ | ok cool | 22:59.41 |
| | Robin_Watts, once I compile the program will it also give the "GL" version as well? | 23:34.39 |
| | that's weird (I don't see a "Build" option in VS) | 23:37.32 |
| | *I needed to migrate | 23:49.28 |
| | Forward 1 day (to 2017/07/29)>>> | |
Log of #mupdf at irc.freenode.net.