| | <<<Back 1 day (to 2017/06/21) | 20170622 |
| Robin_Watts | Morning tor8. | 09:18.18 |
| tor8 | Robin_Watts: morning. | 09:18.54 |
| Robin_Watts | So, what's left to do before we can commit? | 09:19.34 |
| tor8 | so, we're up to 8ed3963a87b7d9a24bc5e5a59d9bab2dc750f02f on robin/lcms with our and mvrhel's latest changes? | 09:19.58 |
| Robin_Watts | Yes. | 09:20.23 |
| tor8 | on my list there are only 4 items left | 09:20.30 |
| | the fz_ensure_pixmap_is_additive and writepixmap color_param fixmes | 09:20.50 |
| | the "what is different fz_init_color_params and fz_default_color_params?" entry | 09:21.07 |
| Robin_Watts | The plan is to leave fz_ensure_pixmap_is_additive and writepixmap for now. | 09:21.25 |
| tor8 | and fz_cmm_init_profile, and fz_cmm_init_link error handling (should they not throw on errors instead of return error codes?) | 09:21.37 |
| | fair enough | 09:21.43 |
| Robin_Watts | Then experiment with removing the need to only hold additive pixmaps once the branch is in. | 09:21.45 |
| | fz_init_color_params, I thought we covered yesterday. | 09:22.09 |
| tor8 | and finally, what happens with existing code if you don't change it. does color management get turned on or is that something you have to do a manual step for? | 09:22.10 |
| | yes, I saw the discussion about premul alpha | 09:22.29 |
| | one somewhat awkward idea is to hold CMYK inverted | 09:22.48 |
| | and also separation and deviceN | 09:23.03 |
| | then premultiplied alpha math works out | 09:23.09 |
| Robin_Watts | fz_init_color_params says "set this structure to the initial (default) values" | 09:24.41 |
| | fz_default_color_params says "get the 'current' defaults from the context" | 09:24.50 |
| | The initial default values never change. | 09:25.15 |
| tor8 | do we ever expect the 'current' defaults in the context to change? | 09:25.54 |
| | I'm not sure that's a good idea | 09:26.01 |
| Robin_Watts | tor8: People have the option to set the defaults in the context once, and it's carried forwards everywhere. | 09:26.26 |
| | (every draw device that is created will use the context defaults if it's not explicitly set) | 09:27.00 |
| tor8 | afaict there is no function for setting the defaults | 09:27.13 |
| | and if you were to set one, wouldn't it be part of the draw device arguments? | 09:28.10 |
| | or is that the completely wrong place for it? | 09:28.25 |
| Robin_Watts | tor8: The lack of a function for setting the defaults is a problem :) | 09:28.33 |
| tor8 | nah, it just means we can safely remove the designed functionality that was never used :) | 09:28.53 |
| Robin_Watts | We *could* ditch the context defaults entirely. | 09:28.58 |
| tor8 | I think we should ditch them. global values that affect rendering is something we're moving away from (see your AA commit, etc) | 09:29.21 |
| Robin_Watts | but then people would have to manually set any non-standard defaults every time they create a draw device. | 09:29.22 |
| | My AA commit still has global values. | 09:29.38 |
| | They act as the defaults for the draw device to use if they aren't overridden :) | 09:29.51 |
| tor8 | yes, for backward compatibility? | 09:29.53 |
| Robin_Watts | yeah. | 09:30.03 |
| tor8 | we should deprecate them (add fz_warn) and remove them in a few releases | 09:30.21 |
| Robin_Watts | tor8: OK, so for the color_params, move them out of the context, and into the draw device. | 09:37.32 |
| | and add some options to allow them to be set. | 09:37.42 |
| tor8 | I'm going to make the fz_default_color_params return the same as fz_init_color_params | 09:37.49 |
| Robin_Watts | then we can remove fz_default_color_params. | 09:37.59 |
| tor8 | then we can think about how to change the defaults for the draw device | 09:38.04 |
| | I suspect the color_parms might need to go through the interpreter though | 09:38.39 |
| Robin_Watts | The color_params normally come from the interpreter. | 09:38.55 |
| | but some interpreters may choose to pass NULL. | 09:39.04 |
| tor8 | maybe the same way we set the default colorspaces we can add a device call to set the color params | 09:39.13 |
| Robin_Watts | In the case where we get passed NULL, we use whatever the defaults are. | 09:39.20 |
| | tor8: the default colorspaces are set in the context! | 09:39.34 |
| | tor8: Oh, I see. | 09:39.53 |
| | You mean a device call to say "use these as default color_params from now on". | 09:40.14 |
| tor8 | Robin_Watts: no, the default colorspaces are set with the fz_default_colorspaces struct which is in one device call that's called from the PDF interpreter to set the DefaultRGB etc spaces in th resource dict | 09:40.18 |
| | yes, that's what I mean. | 09:40.31 |
| Robin_Watts | OK, I shall let you play with that. | 09:40.40 |
| | Anything else on your list I can be looking at? | 09:40.48 |
| tor8 | I think those three items are the last ones. there's a few commits on tor/master as well that need to go in. | 09:41.44 |
| | I'll rebase them on top of the lcms work | 09:42.18 |
| | as a bigger design thing, I wonder if we can simplify the use of the default_colorspaces struct into something passed by value to remove the need to reference count it | 09:44.11 |
| | sorry, I mean "passed on the stack" | 09:44.34 |
| Robin_Watts | All those lgtm. | 09:46.09 |
| | Passed by value would be bad. | 09:47.40 |
| | Passed by reference with no reference counting sounds doable though. | 09:47.56 |
| | I'm not convinced that saves us anything of worth though, and it would be 'less standard' when compared to the rest of the code. | 09:48.29 |
| tor8 | it could save us a few mallocs and try/catch cases cleaning them up | 09:49.28 |
| | but you're right, it's probably not worth bothering with | 09:49.35 |
| | okay, rebased tor/master and new lcms commits on tor/lcms | 09:50.10 |
| Robin_Watts | I just see one lcms commit, after all the other non-lcms commits, is that right? | 09:53.34 |
| tor8 | yes, there should be the 'unsigned icc_lookup' and 'immutable' commits for lcms | 09:54.29 |
| | the others are non-lcms | 09:54.33 |
| | hmm, looking at color-lcms.c | 09:54.48 |
| | it doesn't seem to do much error checking for lcms function calls | 09:55.05 |
| Robin_Watts | I don't like that default_color_params immutable commit :( | 09:55.10 |
| | Ah, what the hell, it's a stepping stone to being right. | 09:57.32 |
| tor8 | I'm not sure it even makes sense to change most of the color_params outside of the interpreter | 09:57.36 |
| | overprinting is not something I anticipate being useful as a global option :) | 09:57.56 |
| Robin_Watts | For interpreters that don't have an opinion on such things, I can see the caller wanting to have control. | 09:58.30 |
| | Really? overprinting has always struck me as being something that's much more tied to the target device than the source file. | 09:58.59 |
| tor8 | isn't overprinting a poor man's transparency? | 09:59.17 |
| | the only thing I can imagine wanting to change is the rendering intent | 09:59.36 |
| | I don't even know what the 'bp' is supposed to be | 09:59.45 |
| Robin_Watts | tor8: black point compensation. | 09:59.52 |
| | It's a new PDF 2.0 thing. And that is the sum of my knowledge about it. | 10:00.13 |
| tor8 | ah, that's why I can't find it. | 10:00.26 |
| | I still can't get over the crap formatting in the PDF 2.0 document... | 10:00.42 |
| | ...so I'm still using the adobe PDF 1.7 spec | 10:00.57 |
| Robin_Watts | I thought overprinting was more to do with how well given colorants overlaid one another in the device. | 10:01.02 |
| | Me too. | 10:01.04 |
| tor8 | IIRC overprinting is a saturated add for subtractive colorants | 10:01.24 |
| Robin_Watts | Suppose we have a pixel with colorant values b[0..n] | 10:03.44 |
| | and we are overprinting a color c[0..n] to it. | 10:04.01 |
| | r[i] = c[i], for non zero c[i], and 0 otherwise, I think. | 10:04.36 |
| tor8 | could be something as simple as that yes, and more difficult to reproduce using normal transparency blends | 10:05.04 |
| kens | overprinting is cheap transparency, you just dopn't erase what's already there (for CMYK devices and CMYK drawing) | 10:05.04 |
| Robin_Watts | Oh, so that's exactly wrong. | 10:05.26 |
| kens | I seem to remember overprint mode adds something, I can't recall what | 10:05.29 |
| Robin_Watts | r[i] = c[i] for non zero c[i], and b[i] otherwise. | 10:05.47 |
| kens | You just add the new components to the existing compenets like otr8u said | 10:06.23 |
| | tor8^ | 10:06.29 |
| | Its only supposed to work with CMYK output and CMYK colours | 10:06.55 |
| | transparency, I'm not so sure about | 10:07.02 |
| | Can't recall how the beldning space fits in | 10:07.14 |
| | OK so ovedrprint mode determines what happens if a component is 0 | 10:07.44 |
| | One way a component of 0 erases the colour, the other way it does nothing | 10:07.58 |
| | If overprint mode is 0 then a compnent of 0% erases the existing value. If overprint mode is 1 then a component of 0% leaves teh existing value unchanged | 10:08.50 |
| | Non-zero components add to the existing value | 10:09.12 |
| Robin_Watts | right, so one way is a saturated add, and one way isn't. | 10:09.41 |
| kens | Well both are a saturated add for non-zero components | 10:09.59 |
| | It only affects the interpretation of 0 | 10:10.14 |
| Robin_Watts | right, but one way removes the existing colorants that aren't touched, and the other way doesn't. | 10:10.45 |
| kens | Yes | 10:10.52 |
| | Though I wouldn't put it like that. 0% doesn't mean untouched | 10:11.08 |
| | Or more accurrately perhaps, mode determines whether 0% means untouched or not. | 10:11.33 |
| | In any event, you seem to have the idea | 10:11.56 |
| Robin_Watts | Why is 0% not untouched? | 10:12.23 |
| kens | If overprint mode is 1 then it is untouched, otherwise its erased | 10:12.53 |
| Robin_Watts | Ah, right yes. | 10:13.04 |
| | tor8: Updated lcms and lcms_squashed branches. | 10:13.30 |
| tor8 | Robin_Watts: okay, one more commit on tor/lcms then. | 10:39.01 |
| | if that looks good I think it's time to consider merging to master | 10:39.14 |
| Robin_Watts | I just did a clusterpush and we've sprouted a couple of warnings.... | 10:39.45 |
| | will fix. | 10:39.48 |
| | I'm not convinced that having fz_lcms_fin_link print Free link:: link = 0 is hugely helpful. | 10:42.42 |
| | Nor am I convinced that any of these prints with " ... %p \n" wouldn't be better as "... %p\n" | 10:43.23 |
| tor8 | it might help in discovering mismatched init/fin pairs | 10:43.26 |
| | I just left them as they were, I don't like the way the messages are formatted either | 10:43.53 |
| | but I'm not expecting to be the one using them to debug this :) | 10:44.04 |
| Robin_Watts | tor8: fz_new_icc_link now leaks, I think. | 10:44.45 |
| tor8 | ah, yes | 10:45.13 |
| Robin_Watts | if fz_cmm_init_profile throws... | 10:45.16 |
| tor8 | will fix | 10:45.24 |
| | fix on tor/lcms | 10:48.34 |
| Robin_Watts | hexdump is new for lcms isn't it ? | 10:50.24 |
| tor8 | no, we introduced it before the lcms branch | 10:50.36 |
| | but it was intended for lcms | 10:50.42 |
| | are you considering moving the hexdump commits to before the lcms branch starts? | 10:51.15 |
| Robin_Watts | No. | 10:51.29 |
| | I was just hoping to get the lcms branch warning free. | 10:51.39 |
| | and I'm getting a signed/unsigned thing in there. | 10:51.47 |
| | I'll introduce a transient commit to fix it. | 10:52.06 |
| tor8 | oh yeah, that fix is a bit staggered | 10:53.28 |
| Robin_Watts | I'm going to squash your last 2 commits together. | 10:54.18 |
| tor8 | please do | 10:54.27 |
| Robin_Watts | OK, branches updated. Just got to get rid of this warning. | 11:01.08 |
| | OK, hopefully that's the warning sorted. Just clustering now. | 11:10.46 |
| | cock. let's try that again. | 11:11.57 |
| | tor8: OK, I'm just doing a quick bmpcmp for sanity, but I reckon lcms and lcms_squashed are ready to go. | 11:20.11 |
| | (at least as far as the actual lcms commits, that is) | 11:20.27 |
| | If you can just look at the post-squashed commits, I'll test and commit those one at a time after lcms goes in. | 11:20.55 |
| | tor8: ^ | 11:29.58 |
| | tor8: ass. Something got broken. | 11:31.27 |
| | See my bmpcmp, number 208. | 11:31.40 |
| | and, I think 120. | 11:32.14 |
| | I don't remember 289 either. | 11:32.57 |
| | or 367 | 11:34.06 |
| | or 373 | 11:34.15 |
| | bisecting now. | 11:37.28 |
| tor8 | Robin_Watts: hardcoding AA_BITS=8 in libmupdf.vcproj in the Harfbuzz commit looks like an accident | 11:53.20 |
| Robin_Watts | tor8: It is. | 11:53.30 |
| | I found a problem that's causing diffs. | 11:53.40 |
| tor8 | the fz_hb_malloc defines need to go in the Makethird file too | 11:53.45 |
| Robin_Watts | In the cal rework, when we read the Matrix, you were testing for array_len != 9 when it should be == 9. | 11:54.09 |
| tor8 | I'd rename the Separations.java functions to toggleSeparation and isSeparationEnabled, but that's just me | 11:56.12 |
| | d'oh! | 11:56.13 |
| Robin_Watts | tor8: OK, branches updated, tests running now. | 11:57.41 |
| | I've got to have lunch and take puppy for injections, but will fix that stuff afterwards. | 11:58.05 |
| | If the tests pass I'll push the lcms stuff. | 11:58.16 |
| | Thanks. | 11:58.17 |
| tor8 | Robin_Watts: cool! | 11:58.40 |
| maxuppp | hi | 12:26.25 |
| mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 12:26.25 |
| maxuppp | quick question, what's the equivalent of mutool draw on debian? | 12:26.51 |
| | mutool doesn't have a draw command there, and mudraw doesn't work eitger | 12:27.50 |
| kens | Is this building from the MuPDF source or using some package ? | 12:28.19 |
| maxuppp | package, mupdf-tools | 12:29.31 |
| kens | Umm, well I'm no expert, but I think you might have to ask the package maintainer that question. Though if you let us know the version you are using its possible someone (not me) might be able to help if you stick around, its lunch time at the moment | 12:30.26 |
| tor8 | IIRC debian is shipping a very old version of mupdf | 12:30.57 |
| maxuppp | damn devs, always wanna eat... | 12:31.04 |
| kens | Debian is 'stable' and so always ships old stuff :-) | 12:31.17 |
| maxuppp | i use arch, sometimes i feel spoiled on updates... | 12:31.50 |
| tor8 | maxuppp: which version of the mupdf-tools package do you have? | 12:31.52 |
| | it could possibly be called 'pdfdraw' as well, if it's an ancient version | 12:32.10 |
| maxuppp | one sec | 12:32.26 |
| kens | claims 1.9a on here | 12:33.25 |
| maxuppp | yeah 1.9 seems right | 12:33.42 |
| | although there's no --v ;) | 12:33.48 |
| kens | Jessie is on 1.5 apparently | 12:33.57 |
| tor8 | yeah, I see 1.5 on my debian | 12:34.11 |
| kens | wheezy is on 0.9 O.O | 12:34.27 |
| maxuppp | lol | 12:34.34 |
| kens | stretch buster and sid all on 1.9a | 12:34.46 |
| tor8 | maxuppp: so, in order of ascending age it could be: 'mutool draw', 'mudraw', or 'pdfdraw' | 12:35.19 |
| | they might have renamed pdfdraw way back when to mupdfdraw perhaps, I can't really recall | 12:35.39 |
| maxuppp | alright, i'll relay that to my colleague | 12:35.46 |
| kens | Or the packager broke it, and none of the above :-) | 12:35.51 |
| maxuppp | i won't touch debian with a stick :D | 12:35.52 |
| tor8 | best to just look in /usr/bin/ | 12:35.54 |
| maxuppp | by the way, it's a great tool you're making | 12:36.20 |
| tor8 | thanks. | 12:36.31 |
| maxuppp | the best amongst pdf rippers i'd say, and i've tried a lot | 12:36.41 |
| Robin_Watts | tor8: closer, but no cigar. 456 is wrong now. | 12:39.43 |
| | I'll bisect when I'm back from the vets. | 12:40.31 |
| maxuppp | there seems to be only mudraw, which doesn't support the txt target | 12:54.06 |
| | only renders to images it appears | 12:54.15 |
| kens | Can't comment really, its not my area | 13:00.23 |
| | Perhaps they didn't want to have dependencies and it would need X I htink | 13:00.43 |
| tor8 | maxuppp: the text target is a newer feature that was introduced after the tool was joined with the 'mutool' suite | 13:08.04 |
| | maxuppp: to get text output with the old 'mudraw' tool you need to use the -t option | 13:08.42 |
| maxuppp | it works | 13:29.29 |
| | thanks, to all | 13:29.34 |
| Robin_Watts | tor8: OK, pushing... | 14:18.12 |
| tor8 | Robin_Watts: did you figure out the problem with 456? | 14:21.15 |
| Robin_Watts | tor8: yeah, fixed. | 14:21.24 |
| | silly typo in one of the tidying commits. | 14:21.34 |
| | Oh, you asked earlier... by default stuff runs non-color-managed, | 14:22.27 |
| tor8 | clamp_lab_icc? | 14:22.53 |
| Robin_Watts | You need to call fz_set_cmm_engine(ctx, &fz_lcms_engine); to turn color management on. | 14:22.57 |
| | yeah. | 14:22.58 |
| tor8 | I think it would be useful to turn it on by default | 14:23.11 |
| Robin_Watts | mudraw turns it on by default. | 14:23.21 |
| | Turning it on by default means it's harder to build without including lcms. | 14:23.50 |
| | The way it is now, if it's not used it drops out at link time. | 14:24.03 |
| | mvrhel_laptop: Morning. lcms stuff is committed. | 14:55.20 |
| mvrhel_laptop | Morning Robin_Watts. Great! | 14:58.10 |
| | Robin_Watts: so when we do a cluster push does it test with or without lcms or both? | 15:00.56 |
| sebras | I just read the logs, cool! | 15:01.10 |
| Robin_Watts | mvrhel_laptop: with. | 15:02.14 |
| mvrhel_laptop | ok good deal | 15:02.40 |
| sebras | Robin_Watts: origin:sebras/lcms has a patch needed for this to build in android. | 15:07.51 |
| Robin_Watts | sebras: grabbing now. | 15:08.00 |
| sebras | Robin_Watts: I just tested it locally and it seems to work. if you lgtm I'll push it. | 15:08.08 |
| Robin_Watts | tor8: I fixed the harfbuzz commit. | 15:08.12 |
| | sebras: lgtm. Thanks. | 15:08.49 |
| | tor8: If you lgtm, then I'll push the last 2 commits, and we'll be sorted. | 15:10.49 |
| | mvrhel_laptop, sebras, tor8: So I just nobbled every single call to fz_ensure_pixmap_is_additive, and ran the cluster. | 15:54.17 |
| | Anyone want to guess how many diffs? | 15:54.24 |
| mvrhel_laptop | 0 | 15:54.35 |
| Robin_Watts | yeah. | 15:54.40 |
| | mvrhel_laptop: You said yesterday that you had questions for me about the way mupdf does transparency? | 15:56.05 |
| mvrhel_laptop | Robin_Watts: so I wanted to chat with you for a sec about DeviceN | 15:56.07 |
| sebras | Robin_Watts: nobble v 1: deprive of by deceit; 2: make off with belonging of others; 3: take away to an undisclosed location against their will and usually in order to extract a ransom; 4: disable by drugging | 15:56.14 |
| | Robin_Watts: I need to refer back to wordnet to get what that meant. :) | 15:56.31 |
| Robin_Watts | number 4 in that definition :) | 15:56.44 |
| sebras | Robin_Watts: I guess we're not talking about option 4. | 15:56.45 |
| Robin_Watts | where the drug is "a C++ style comment" ;) | 15:57.08 |
| sebras | Robin_Watts: :)( | 15:57.14 |
| mvrhel_laptop | Robin_Watts: So for proper handling of spot colors in transparency, we will need to want to allow Gray, RGB and CMYK color spaces to have additional spot colors. Toward that end, I would like there to be a num_spots entry in the color space which is populated with how many spot colors we need to worry about in the group (this would be the number of spots on the page). Also it would be... | 15:58.55 |
| | ...idea to always have such data organized in chunky form as Gray + spots, RGB + spots, and CMYK + spots | 15:58.57 |
| | s/idea/ideal/ | 15:59.05 |
| | s/need to want/want/ | 15:59.25 |
| Robin_Watts | fz_pixmaps currently have n = number of components, alpha = number of alpha components (0 or 1). | 16:00.02 |
| | You're suggesting adding s = number of spots. | 16:00.35 |
| | so n-s-a = 3 for rgb spaces. | 16:00.49 |
| mvrhel_laptop | I was thinking of adding that in the color space, but being in the pixmap makes more sense | 16:01.16 |
| | but yes | 16:01.21 |
| | n-s-a =3 for rgb | 16:01.26 |
| Robin_Watts | just trying to think that through... | 16:02.30 |
| | Plotters etc shouldn't care, because it's just another orthogonal colour component. | 16:03.29 |
| | blending may be more interesting. | 16:03.40 |
| | separable stuff is no problem. | 16:03.44 |
| mvrhel_laptop | well that is were it is needed | 16:03.48 |
| avih | are plotters still a thing? last time i saw one was more than 20 years ago. are they still used in the signs/print industry? | 16:04.16 |
| Robin_Watts | non-separable would need to take different measures for an n-a = 3 space. | 16:04.22 |
| | avih: different meaning of plotters. | 16:04.29 |
| | plotters = my name for the core bits of code in MuPDF that paint pixel values into pixmaps. | 16:05.06 |
| avih | oh | 16:05.16 |
| mvrhel_laptop | I got confused by that terminology at first too | 16:05.29 |
| Robin_Watts | Sorry. | 16:05.35 |
| | It comes from epage. | 16:05.45 |
| avih | cute. your earlier statement about them also fit the definition i assumed :) | 16:05.45 |
| mvrhel_laptop | plotters have a pretty distinct definition in graphic arts | 16:06.20 |
| avih | that's the one i meant https://en.wikipedia.org/wiki/Plotter | 16:06.51 |
| Robin_Watts | We might have a grey + 2 spots pixmap, and we'd need to handle blends differently than with an rgb pixmap. | 16:06.59 |
| mvrhel_laptop | yes | 16:07.07 |
| Robin_Watts | Yes, well, some overloading of terminology is unavoidable. | 16:07.12 |
| mvrhel_laptop | that is why we need to know how many spots exist. This is what was needed in gs. Essentially the process components (Gray, RGB and CMYK) and handled quite differently | 16:08.02 |
| | They are color managed and blended differently | 16:08.12 |
| | blending is different depending upon the blend mode | 16:08.26 |
| Robin_Watts | mvrhel_laptop, sebras, tor8: Ok, so I just ran another test where I made fz_ensure_pixmap_is_additive crash... and I do see SEGVs. | 16:08.30 |
| | mvrhel_laptop: Makes sense to me. | 16:08.46 |
| | Ok, so I think it's doable. | 16:08.56 |
| mvrhel_laptop | Robin_Watts: ok I may have a transparency question in a minute. let me first see if I can figure out what mupdf is doing in this one case... | 16:09.27 |
| | oh | 16:11.10 |
| | ick | 16:11.16 |
| sebras | Robin_Watts: I'm not sure why that is surprising..? fz_ensure_pixmap_is_additive() was being called in a few cases before the lcms stuff. | 16:11.22 |
| | Robin_Watts: I'm not sure what it looks like after. | 16:11.31 |
| Robin_Watts | sebras: The point is that I first nobbled fz_ensure_pixmap_is_additive to do nothing - hence you'd expect changes in the cluster results. | 16:12.06 |
| sebras | Robin_Watts: not necessarily. | 16:12.41 |
| | Robin_Watts: maybe we don't have sample files illustrating cases where it is used..? | 16:12.57 |
| | Robin_Watts: so for tiff that would be CMYK-based TIFF files I guess. | 16:13.14 |
| mvrhel_laptop | ok actually I see what is going on. This should be fine. So it looks like every drawing pushes a group of the appropriate size. This is where things diverged from what gs does with its fill rectangle stuff. OK. | 16:13.53 |
| | This is actually a little easier likely to work with | 16:14.04 |
| Robin_Watts | mvrhel_laptop: For knockout? | 16:14.51 |
| mvrhel_laptop | That is if I change the blend mode a new group is pushed. Not knockout | 16:15.02 |
| | Lets say a draw rectangle1, and rectangle2 | 16:15.23 |
| | blend mode with rectangle1 is normal | 16:15.46 |
| | blend mode with retangle2 is multiply | 16:15.54 |
| | gs would only push a single group and do rectangle fills blending appropriately as it does the fills | 16:16.17 |
| | mupdf appears to push a group for rectangle1 (sized for the path size) and push a group for rectangle2 | 16:16.53 |
| | with the appropriate blend mode | 16:17.06 |
| | when they are popped, they are blended | 16:17.12 |
| Robin_Watts | Yes, all blending in mupdf happens at the close of a group. | 16:17.17 |
| | But (while we're talking about this) knockout is slightly different. | 16:17.36 |
| mvrhel_laptop | so group pushes and pops don't correlate with pdf gropus | 16:17.47 |
| | groups | 16:17.49 |
| | or they do, but there are going to be extras | 16:18.01 |
| Robin_Watts | For knockout we push a group, draw, and blend back for EVERY operation. | 16:18.02 |
| | mvrhel_laptop: That sounds right. | 16:18.14 |
| mvrhel_laptop | Robin_Watts: ok explain knockout to me a bit more wiith and example please | 16:18.43 |
| | s/wiith and/with an/ | 16:18.53 |
| Robin_Watts | OK, so suppose we have a file that draws a red background. | 16:19.12 |
| | then it starts a knockout group, and draws a transparent blue circle, and a transparent green triangle that overlaps the blue circle. | 16:19.47 |
| mvrhel_laptop | ok | 16:20.16 |
| Robin_Watts | With knockout we should never see any of the blue circle through the green triangle, right? | 16:20.19 |
| mvrhel_laptop | correct | 16:20.31 |
| Robin_Watts | The draw device implements that by starting a group before the blue circle, drawing the blue circle, and then blending it back. | 16:21.13 |
| | then starting a new group before the green triangle, drawing the green triangle, then blending it back. | 16:21.30 |
| | The cunning bit is that the background for those groups is taken from group n-2, not group n-1. | 16:22.02 |
| mvrhel_laptop | yuck. Why not just go into knock out mode drawing what you need in the current pixmap | 16:22.19 |
| | there is the issue with isolated vs non-isolated | 16:23.08 |
| Robin_Watts | mvrhel_laptop: Because all our plotters work on the basis of combining the background with the current color. | 16:23.10 |
| mvrhel_laptop | what about an isolated knockout group? | 16:23.33 |
| Robin_Watts | not destination = background + current | 16:23.33 |
| | for an isolated knockout group, we start with an empty backdrop, not the n-2th one. | 16:24.16 |
| | look in draw-device.c for fz_knockout_begin | 16:24.44 |
| mvrhel_laptop | I think there are some inefficiencies in there | 16:24.51 |
| Robin_Watts | oh, it's definitely not the most efficient way of working. | 16:25.07 |
| | but the alternative is to complicate the normal case of the plotters. | 16:25.31 |
| mvrhel_laptop | normal being no transparency or normal being non-knockout group | 16:26.00 |
| Robin_Watts | And given how infrequent transparency is (and knockout groups even more so) | 16:26.05 |
| | yes. | 16:26.08 |
| mvrhel_laptop | normal being no transparency or normal being non-knockout group | 16:26.20 |
| Robin_Watts | normal being "no transparency or non-knockout" :) | 16:26.32 |
| mvrhel_laptop | ah | 16:26.38 |
| | hehe | 16:26.40 |
| Robin_Watts | i.e. knockout groups are rare. | 16:26.48 |
| mvrhel_laptop | actually, in the isolated knockout case, that would really be handled quite similar to normal while you accumultate your drawings | 16:27.23 |
| Robin_Watts | I was very pleased when I got this stuff working. | 16:27.57 |
| mvrhel_laptop | One down side I do see is that mupdf is a little more heavy in its memory use for transparency with this approach | 16:28.00 |
| | but the plus side is that it is less complex | 16:28.12 |
| Robin_Watts | I am entirely prepared to believe that there are optimisations to be had. | 16:28.22 |
| mvrhel_laptop | I am not looking to redesign transparency in mupdf | 16:28.47 |
| | just want to understand how it is working | 16:29.00 |
| Robin_Watts | (Oh, btw, when the cluster ran the lcms commit, it went from 2:28 to 3:15) | 16:29.24 |
| mvrhel_laptop | I am so gs biased in my vision of transparency that I could not see how paths were getting blended | 16:29.28 |
| | really? It was faster before | 16:29.41 |
| | must be all the changes you and tor8 made ;) | 16:29.52 |
| Robin_Watts | It seems to regularly give results in the 3:25 region now. | 16:31.06 |
| | Yeah, we added some delay loops that we can remove later to look clever. | 16:31.19 |
| mvrhel_laptop | hehe | 16:31.30 |
| | I may not have been looking at the right numbers in the cluster report | 16:31.44 |
| | that has been known to happen | 16:31.49 |
| Robin_Watts | or the cluster was feeling speedy that morning. | 16:32.04 |
| | (or the previous test was abnormally slow etc) | 16:32.16 |
| | OK, so I moved the crash into the bit of fz_ensure_pixmap_is_additive that only runs when we have a subtractive input, and it now never crashes. | 16:33.20 |
| mvrhel_laptop | ok. So I think I have enough knowledge to get myself in trouble now | 16:33.28 |
| Robin_Watts | so we don't have any files in the cluster that use alphas with subtractive spaces. | 16:33.49 |
| | I guess that means we can not worry about this until we do :) | 16:34.00 |
| mvrhel_laptop | that is interesting | 16:34.02 |
| | I know for a fact that some of the xps files have CMYK + alpha tiffs | 16:34.20 |
| | we must convert them | 16:34.23 |
| | ? | 16:34.31 |
| Robin_Watts | mvrhel_laptop: Can you point me at such a file please? | 16:34.42 |
| mvrhel_laptop | I was afraid you would ask that ;) | 16:34.57 |
| | hold on let me look | 16:35.04 |
| Robin_Watts | I can hunt if required. | 16:35.10 |
| mvrhel_laptop | let me see if I have it | 16:35.29 |
| | I am pretty sure its the fts file that has the pink flower image | 16:39.37 |
| | hold on | 16:39.40 |
| Robin_Watts | 43xx? | 16:40.01 |
| mvrhel_laptop | that sounds right | 16:40.08 |
| Robin_Watts | page 4. | 16:40.24 |
| mvrhel_laptop | can | 16:41.28 |
| | can't seem to get it from the file fetcher | 16:41.40 |
| Robin_Watts | tests_private/xps/xpsfts-a4/fts_43xx.xps | 16:42.18 |
| mvrhel_laptop | ah that worked | 16:42.41 |
| | had it misspelled | 16:42.45 |
| | yes page 4 | 16:43.28 |
| | that flower | 16:43.33 |
| | I think might be CMYK + alpha | 16:43.39 |
| Robin_Watts | aha. | 16:46.39 |
| | ctx->colorspace->cmyk->is_subtractive = 0 | 16:46.57 |
| | cos it's an icc space. | 16:47.10 |
| | Is that expected? | 16:47.13 |
| | mvrhel_laptop: ^ | 16:50.43 |
| mvrhel_laptop | Robin_Watts: So I was going to fix that as I ran across that in the transparency work I am doing | 16:51.22 |
| | I can do it as a separate commit | 16:51.32 |
| | now if you want | 16:51.38 |
| Robin_Watts | because is_subtractive == 0, we never trigger fz_ensure_pixmap_is_additive :) | 16:51.52 |
| mvrhel_laptop | ok that is why | 16:52.01 |
| Robin_Watts | so, I'm confused as to why we don't get diffs. | 16:52.17 |
| mvrhel_laptop | of course we dont' really want to do that ensure | 16:52.32 |
| | eventually | 16:52.37 |
| | so lets just wait | 16:52.41 |
| | as I push on with transparency and color spaces | 16:52.59 |
| Robin_Watts | mvrhel_laptop: Well, presumably that ensure *is* needed at the moment. | 16:53.02 |
| | That's what I'm trying to establish. | 16:53.15 |
| mvrhel_laptop | oops that was a typo | 16:53.28 |
| | it should have read "of course we dont' really want to do that eventually" | 16:53.43 |
| Robin_Watts | Indeed, eventually we don't want it. | 16:53.57 |
| | and the first step towards being able to remove it is to understand why we need it now. | 16:54.15 |
| mvrhel_laptop | Robin_Watts: and if you have no rendering issue now with it then.... | 16:54.15 |
| Robin_Watts | mvrhel_laptop: yeah, but I'm reluctant to rip it out without needing it. | 16:54.38 |
| mvrhel_laptop | Robin_Watts: do you want me to give you a commit for the is_subtractice with icc? | 16:54.59 |
| Robin_Watts | mvrhel_laptop: Please. | 16:55.06 |
| mvrhel_laptop | ok hold on | 16:55.09 |
| Robin_Watts | Then I can check for diffs, and check whether fz_ensure_blah is doing something important at the moment. | 16:55.27 |
| mvrhel_laptop | Robin_Watts: ok on my repos | 17:03.59 |
| | master | 17:04.05 |
| | sorry it took so long | 17:04.12 |
| | something wacky is going on with my VS | 17:04.20 |
| | it keeps changing the line endings | 17:04.31 |
| | not sure why | 17:04.44 |
| Robin_Watts | thanks. | 17:06.25 |
| mvrhel_laptop | I guess I must have copied something in with the wrong line ending and then that changed its "mode" | 17:07.01 |
| Robin_Watts | mvrhel_laptop: New msvc "knows" about git, so it may be trying to be helpful. | 17:07.58 |
| mvrhel_laptop | "helpful" | 17:09.04 |
| | ok. going to make a simple file that has significant color blend issues. the ghent file is to complicated as it includes output intent etc which I am not prepared to fool with quite yet | 17:10.02 |
| | Forward 1 day (to 2017/06/23)>>> | |
Log of #mupdf at irc.freenode.net.