| | <<<Back 1 day (to 2017/07/30) | 20170731 |
| mvrhel_laptop | Morning Robin_Watts | 15:48.39 |
| | So the changes for doing Gray to K are on my blend_spot branch | 15:48.58 |
| Robin_Watts | mvrhel_laptop: Ah, cool. Will pull them in now. | 15:49.14 |
| mvrhel_laptop | If you want to merge that in then we can see what is rendering wrong and I can work on those. Also I can look at doing the changes need for proper overprint/transparency interaction | 15:49.52 |
| Robin_Watts | ok, so robin/spots has that merged in, together with my latest changes. | 15:52.44 |
| | With mudraw, you now have a -S option. | 15:52.55 |
| | oops. | 15:53.03 |
| | With mudraw, you now have a -O option. | 15:53.07 |
| | -O 0 means "No spot rendering, no overprint" | 15:53.20 |
| | -O1 means "Overprint simulation" | 15:53.33 |
| | -O 2 means "Full spot rendering" | 15:53.42 |
| | So -o out.psd -S 2 is what you want to test, probably. | 15:54.01 |
| | but png etc looks good too now. | 15:54.15 |
| | ok, so the I row is wrong when doing overprint simulation to PNG | 15:58.40 |
| mvrhel_laptop | Robin_Watts: so is it -S or -O | 16:00.01 |
| Robin_Watts | -O, sorry. | 16:00.13 |
| | -S was already used, but my brain is rebelling. | 16:00.22 |
| mvrhel_laptop | ok :) | 16:00.23 |
| | I have to help get some people out the door here. will run this in a minute | 16:02.51 |
| Robin_Watts | mvrhel_laptop: Ok, so when you get back... | 16:04.07 |
| | Running the altona page to .psd produces something that looks pretty good to me. | 16:04.23 |
| | Running it to .png produces something where there are problems between deviceK and composite K. The start of Row C and Row I show it. | 16:05.25 |
| | I got it to save a .psd from the cmyk+spots rendering it does internally (before it converts it down to the png), and that is wrong too, so it's not the spot -> spotless conversion that goes wrong. | 16:06.33 |
| mvrhel_laptop | Robin_Watts: ok. That it interesting. I would have expected the issue to be there since internally things should appear the same | 16:44.37 |
| Robin_Watts | Indeed. | 16:44.49 |
| | I have a file cutdown to just those 5 paths. looking now. | 16:45.00 |
| | 6 paths :) | 16:46.33 |
| mvrhel_laptop | This is the technical altona file? | 16:47.19 |
| Robin_Watts | yeah. | 16:47.24 |
| | Ok, so the color conversion is very different. | 16:47.34 |
| | When going to .psd the conversions in resolve color give pure cmyk values. | 16:48.09 |
| | When going to a .png the conversions give "muddy" cmyk values. | 16:48.23 |
| | i.e. rather than being 0.5 0 0 0 I get 0.498 .01 .1 0 etc. | 16:48.44 |
| mvrhel_laptop | which row is this? I do see an issue in row X going out to psd | 16:50.12 |
| Robin_Watts | mvrhel_laptop: C1 shows it. | 16:50.31 |
| mvrhel_laptop | Robin_Watts: ok. If you want to give me the cut down file, I can work on that issue | 16:50.53 |
| Robin_Watts | C1.pdf in my homedir | 16:51.13 |
| mvrhel_laptop | ok | 16:51.18 |
| Robin_Watts | I'll have a look at row X... | 16:51.28 |
| mvrhel_laptop | I bet row X is a screw up in DeviceGray to K also | 16:52.07 |
| | hmm maybe not | 16:52.25 |
| | ok so C1 has a nice interaction with CMYK (k only) Gray and a Black Sep | 16:54.31 |
| Robin_Watts | So C1, plots 5 rectangles, C, M, Y, k, K | 16:55.19 |
| | When going to a .psd they really are C, M, Y, K, K (i.e. all 1 component) | 16:55.36 |
| | When going to a .png they are C+m+y,c+M+k,c+m+Y,C+M+Y,K | 16:56.06 |
| mvrhel_laptop | when you write C+m+y are you saying that it was not pure C? | 16:58.46 |
| Robin_Watts | yes. | 16:58.52 |
| mvrhel_laptop | ok I should be able to find this easily | 16:59.07 |
| Robin_Watts | The color given by the conversion in resolve_color is "muddy" | 16:59.18 |
| | rather than pure. | 16:59.23 |
| mvrhel_laptop | ok | 17:05.55 |
| | I think I know what is going on | 17:05.59 |
| Robin_Watts | anything that's going to be a bugger to fix ? | 17:06.39 |
| mvrhel_laptop | Well, the issue is that the destination space is set to DeviceCMYK. What we need to do is check for an output intent and if we have a CMYK based output intent we should set it to that. This would be during the device set up | 17:10.00 |
| Robin_Watts | mvrhel_laptop: During push_group_for_separation you mean? | 17:10.37 |
| mvrhel_laptop | ah yes | 17:10.43 |
| Robin_Watts | I see the problem with X1. | 17:10.49 |
| | The k value of the color is non zero, but when converted to a uint8_t it's zero. | 17:11.08 |
| mvrhel_laptop | how is that? | 17:12.42 |
| Robin_Watts | cos it's 0.000001 or something. | 17:13.01 |
| | but actually, fixing that didn't solve it. | 17:13.12 |
| | Ahem. Run what you build, Robin, run what you build... | 17:13.43 |
| | Balls, that makes it worse :) | 17:14.11 |
| mvrhel_laptop | :) I found the spot where I can fix C1.pdf | 17:15.48 |
| | in fz_clone_pixmap_area_with_different_seps | 17:15.57 |
| | I have the output intent there so I can make the adjustment | 17:16.30 |
| | in the call to fz_new_pixmap_with_bbox | 17:16.46 |
| | so that it has the proper color space | 17:16.51 |
| | Robin_Watts: I will have to finish this up in a bit. I have to run ethan to bus and then go to a dr. appt. If you are gone when I get back, just leave me a list of things to look at. This C1.pdf will be a quick fix. I can also look at the overprint/transparency interaction as there are a few corner cases there that I want to review. And also I want to look over the Altona Visual file | 17:19.03 |
| Robin_Watts | cool. | 17:19.14 |
| | I've just fixed this one. | 17:19.19 |
| mvrhel_laptop | nice | 17:20.51 |
| | what was it? | 17:24.10 |
| Robin_Watts | It was the fact that float f; if (f != 0) ... is not the same as float f; if ((uint8_t)f != 0) ... | 17:25.21 |
| mvrhel_laptop | wow | 17:28.29 |
| | ok back soon | 17:28.46 |
| Robin_Watts | mvrhel_laptop: how goes it? | 23:11.27 |
| mvrhel_laptop | Robin_Watts: good. just sitting down to look at your fixes | 23:11.55 |
| Robin_Watts | My fix was very simple, it's possible it is too simple. | 23:12.17 |
| mvrhel_laptop | no that is basically what I was going to do | 23:13.08 |
| | The only issue I can think of is this | 23:13.31 |
| | There is a new PDFX version coming out that allows DeviceN output intents | 23:13.50 |
| | It is likely both gs and mupdf will have a few hiccups with supporting thatt | 23:14.14 |
| | If and when we run across one (maybe the ghent folks will make one) we can worry about it then | 23:14.41 |
| | I will do a check of overprint and transparency interaction | 23:15.19 |
| Robin_Watts | cool. | 23:19.20 |
| | Tomorrow I plan to make bmpcmp play nice with psd+spots. | 23:19.40 |
| | and then try to machine compare gs and mupdf rendering the altona files. | 23:20.09 |
| mvrhel_laptop | sounds good | 23:23.00 |
| | although gs has a few issues.... | 23:23.07 |
| Robin_Watts | well, this will hopefully allow us to spot them more clearly. | 23:23.30 |
| | There is some discussion going on the on lcms2 mailing list. | 23:23.43 |
| mvrhel_laptop | oh I dont think I am on that | 23:23.54 |
| Robin_Watts | I might write something about lcms2.8.art there tomorrow. | 23:23.59 |
| | (Other people talking about optimisations etc) | 23:24.08 |
| mvrhel_laptop | nice | 23:24.23 |
| Robin_Watts | Hmm. We seem to have dropped my #include optimisations from lcms2 at some point. | 23:25.18 |
| | yeah, chrisl updated a version last november, and dropped all that out :( | 23:26.40 |
| | I might pull that back in. | 23:27.01 |
| mvrhel_laptop | I may try to fix the issue that exists in gs | 23:31.25 |
| | Forward 1 day (to 2017/08/01)>>> | |
Log of #mupdf at irc.freenode.net.