| | <<<Back 1 day (to 2017/08/06) | 20170807 |
| sebras | tor8: hi! a few patches on sebras/master | 13:57.17 |
| | tor8: the first includes an upgrade of the newly extracted jbig2dec. | 13:57.35 |
| tor8 | sebras: I take it you figured out that the jbig2dec.git is auto-updated from ghostpdl.git with a cron job every night? | 13:59.29 |
| sebras | yup. | 14:00.06 |
| | tor8: so I had kens LGTM the jbig2dec patches for gs during the weekend. | 14:00.23 |
| | tor8: and now I can merge it into mupdf! :) | 14:00.32 |
| tor8 | sebras: "Disable freetype stream support, avoiding FILE interface." why not edit scripts/freetype/slimftoptions.h? | 14:01.18 |
| sebras | tor8: I didn't know it was used! | 14:01.41 |
| tor8 | sebras: it was the line above the one you changed! | 14:01.52 |
| | you even added a '\' to it :P | 14:02.04 |
| sebras | tor8: doesn't mean I knew what it was! but yeah, I'll adapt the patch. | 14:02.33 |
| tor8 | bah, don't type ^W when you mean ^V | 14:03.43 |
| | sebras: other than that detail, the commits look good to me | 14:03.55 |
| sebras | tor8: updated. | 14:07.15 |
| tor8 | sebras: all on sebras/master LGTM | 14:09.25 |
| sebras | tor8: I'll just recluster it. | 14:15.12 |
| kens | sebras did you inform the customer on bug #697947 ? | 14:17.09 |
| | Apparently not, I will do that now | 14:19.31 |
| sebras | kens: no I can't find any evidence that I did. | 14:25.16 |
| | tor8: pushed. | 14:26.56 |
| | kens: at the time I didn't know about the process. | 14:27.25 |
| | kens: thanks for helping out. | 14:27.33 |
| kens | NP | 14:27.55 |
| | It came up in the bug report and this tiem I noticed it | 14:28.22 |
| Robin_Watts | mvrhel_laptop: Are you here? | 17:01.57 |
| mvrhel_laptop | I am | 17:11.00 |
| | good morning | 17:11.08 |
| Robin_Watts | kinda | 17:11.20 |
| mvrhel_laptop | uhoh | 17:11.27 |
| Robin_Watts | I spent a long time on saturday, and an even longer time today pushing equations around. | 17:11.41 |
| | and the more I did, the more I became convinced that the blending was right in this damn routine. | 17:11.59 |
| | and having gone round and round in circles for hours, I've just stepped through and decided that the numbers would be right (in this case at least) if I wasn't multiplying by the result alpha at the end. | 17:12.57 |
| | and indeed it does look good. | 17:13.02 |
| | but I'm damned if I can see a mathematical justification for it. | 17:13.13 |
| mvrhel_laptop | Robin_Watts: I have to say. I looked at it only a little bit. My thought was to go through it today in detail if we (or you rather) had not gotten anywhere | 17:13.21 |
| | Why dont you stop there | 17:13.34 |
| | and let me be a second set of eys | 17:13.41 |
| | eyes | 17:13.43 |
| Robin_Watts | mvrhel_laptop: Yeah. Let me tidy up what I've got. | 17:13.57 |
| mvrhel_laptop | ok. sounds good | 17:14.02 |
| | Robin_Watts: just a couple quick questions though | 17:14.36 |
| Robin_Watts | Oh! | 17:16.02 |
| | Oh gawd, | 17:16.08 |
| | I might just have twigged. | 17:16.17 |
| mvrhel_laptop | oh good | 17:16.52 |
| | Robin_Watts: I need to run ethan to bus stop. will be back in a bit | 17:23.32 |
| Robin_Watts | ok. | 17:23.38 |
| mvrhel_laptop | ok back | 18:20.20 |
| Robin_Watts | getting there. | 18:21.23 |
| mvrhel_laptop | Robin_Watts: So you figured something out? | 18:21.24 |
| | ok I will wait. | 18:21.29 |
| | I do have a pile of P1 bugs to look at for gs | 18:21.38 |
| Robin_Watts | go for it. | 18:22.16 |
| mvrhel_laptop | Robin_Watts: go for the P1 bugs? | 18:27.21 |
| Robin_Watts | Ok, I'm at a point we can talk about stuff sanely. | 18:27.54 |
| | Ok, so first off, some obvious fixes: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=046e499c4183e6a5de63b82dce9aa53e4cf16432 | 18:28.25 |
| mvrhel_laptop | So before we do that. | 18:29.07 |
| | Let me take a few things apart to help me follow some of this | 18:29.22 |
| | So bp is the background pointer, bal tells us if bp has an alpha channel. Effectively that is always true when we are fooling with transparency. sp is the source point sal tells us the same info as bal, hp is the shape pointer associated with the source. hp contents include shape + opacity stuff from AA, and alpha is the "global" alpha for the source | 18:33.05 |
| | is that all correct? | 18:33.08 |
| Robin_Watts | bp is the background pointer. | 18:33.24 |
| mvrhel_laptop | Robin_Watts: and if we had had a softmask in this mess, it would already be the alpha channel of the source | 18:33.40 |
| Robin_Watts | bal tells if if we have an alpha channel where we are writing. | 18:34.00 |
| | This is NOT always true. | 18:34.06 |
| | sp = source pointer | 18:34.17 |
| | sal = whether we have a source alpha channel. | 18:34.28 |
| | hp is the shape pointer. | 18:34.35 |
| | hp contents are coverage, not shape + opacity. | 18:34.48 |
| | hp is pure shape. | 18:34.55 |
| | alpha is the constant alpha. | 18:35.04 |
| mvrhel_laptop | hmm I would not call hp pure shape but that is fine | 18:35.22 |
| Robin_Watts | (at least, that is my understanding). | 18:35.28 |
| sebras | tor8 (for the logs): while fixing largefile=yes builds I stumbled into a fz_throw that did %#x, and so I fixed it. | 18:35.38 |
| Robin_Watts | I found some interesting lines in the spec about this... | 18:35.39 |
| mvrhel_laptop | I do see the discussion in section 7.2 | 18:36.35 |
| | about AA | 18:36.37 |
| Robin_Watts | Shape values of 0.0 and 1.0 identify points that lie outside and inside a conventional sharp-edged object; intermediate values are useful in defining soft-edged objects. | 18:36.39 |
| mvrhel_laptop | yes | 18:36.43 |
| sebras | tor8 (for the logs): now largefile=yes still has a problem in that it allocates HUUUGE amounts of memory if the xref object number offset is large (but small enough for the object numbers to fit into 32 or 64 bits). I'm not sure if we want to do something about that. | 18:36.44 |
| mvrhel_laptop | Hence my comment of hp contents include shape + opacity stuff from AA | 18:36.56 |
| Robin_Watts | hence intermediate values are expected on the edge of things. | 18:37.10 |
| mvrhel_laptop | i suppose fractional coverage is more correct | 18:37.15 |
| Robin_Watts | No, that's not opacity. | 18:37.17 |
| | I prefer coverage, yes. | 18:37.27 |
| mvrhel_laptop | that is fine | 18:37.31 |
| | in any event it is the information from AA+shape | 18:37.39 |
| | contained in hp | 18:37.43 |
| sebras | tor8 (for the logs): this is fallout from bug 698279 btw. | 18:37.46 |
| Robin_Watts | Yes. | 18:37.47 |
| sebras | sleeps. | 18:37.51 |
| mvrhel_laptop | Robin_Watts: and if we had had a softmask in this mess, it would already be the alpha channel of the source | 18:38.10 |
| | ? | 18:38.13 |
| Robin_Watts | Yes. | 18:38.16 |
| mvrhel_laptop | ok | 18:38.19 |
| Robin_Watts | All our blending operations are of the form dest += (source,alpha) | 18:38.37 |
| | For some operation '+' :) | 18:38.49 |
| | We never do output = input1 (+) input2 as it were. | 18:39.21 |
| mvrhel_laptop | I suppose on the final blend perhaps to a pam output you dont? | 18:40.35 |
| | have a bal? | 18:40.45 |
| Robin_Watts | Indeeed. | 18:40.51 |
| mvrhel_laptop | ok and since the data is premultiplied that is all good | 18:41.18 |
| Robin_Watts | I'm test to png here (rgb, not rgba) and hence the final blend has no alpha. | 18:41.20 |
| mvrhel_laptop | nothing special/different to do | 18:41.29 |
| | So lets step through fz_blend_nonseparable_nonisolated as you have it | 18:41.59 |
| | we first compute haa which is the coverage alpha for the source times the source alpha | 18:42.33 |
| Robin_Watts | mvrhel_laptop: Urm... | 18:42.45 |
| | If we're going to step through the code, it's probably worth stepping through the final version. | 18:43.04 |
| mvrhel_laptop | I thought i was there | 18:43.17 |
| | is there another final version | 18:43.22 |
| Robin_Watts | The weblink I gave above was to a diff that fixes some obvious stuff. | 18:43.32 |
| mvrhel_laptop | ah ok | 18:43.39 |
| Robin_Watts | If you're looking at the git repo, then there is 1 later commit that fixes more maths. | 18:43.59 |
| | Including much ascii algebra. | 18:44.14 |
| mvrhel_laptop | well I would prefer to step through the final version | 18:44.34 |
| | just point me there | 18:44.37 |
| Robin_Watts | You may already be looking at that - I just didn't want us to get off on the wrong foot. | 18:44.43 |
| | Probably easiest just to fetch and look at it? | 18:44.52 |
| mvrhel_laptop | yes let me do that | 18:44.57 |
| | hold on | 18:45.01 |
| | ok fz_blend_separable_nonisolated | 18:48.38 |
| | ? | 18:48.40 |
| | wait nonsep | 18:48.53 |
| Robin_Watts | fz_blend_nonseparable_nonisolated, yeah. | 18:49.22 |
| mvrhel_laptop | ok I am there | 18:49.51 |
| Robin_Watts | Ok. So first thing, look at the TOP of the file. | 18:50.02 |
| mvrhel_laptop | ok I am there | 18:50.15 |
| | yes. I did that math on Friday :) | 18:50.36 |
| | I have it here on my paper | 18:50.41 |
| Robin_Watts | The notes here are tidied up info about the stuff I have scattered around me on bits of paper too. | 18:50.53 |
| | I put in in here so that 1) when I come back to this in 6 months I might not have to spend quite so long convincing myself it's right. | 18:51.27 |
| mvrhel_laptop | let me read what you wrote for Alpha blending on top of compositing: | 18:51.27 |
| Robin_Watts | and 2) so I can refer to it from the code. | 18:51.42 |
| | The idea of the "Alpha blending on top of compositing" is that we basically want to do the group composite, then alpha blend the results of that all in one hit. | 18:52.13 |
| mvrhel_laptop | Robin_Watts: | 18:59.15 |
| | So I am a little confused by | 18:59.22 |
| | Cr= (1-alpha) * Cb + alpha * Ir= Cb - alpha * Cb + alpha * Cb - alpha * Cb * As / Ar + alpha * As / Ar * [ (1 - Ab) * Cs + Ab * B(Cb, Cs) ] | 18:59.26 |
| Robin_Watts | Well, do you agree with the central idea that: | 18:59.55 |
| | Cr= (1-alpha) * Cb + alpha * Ir ? | 19:00.06 |
| mvrhel_laptop | if alpha = As/Ar and Ir = [ (1-Ab) * Cs + Ab * B(Cb,Cs) ]the yes | 19:00.44 |
| Robin_Watts | No.... | 19:00.59 |
| mvrhel_laptop | I am just starting at the top and working down | 19:01.07 |
| Robin_Watts | In the absence of alpha, Ir would be exactly what we want, right? | 19:01.17 |
| mvrhel_laptop | Perhaps you are missing some math | 19:01.21 |
| Robin_Watts | To blend source onto dest with 100% alpha, the standard equation is all we need. | 19:02.12 |
| mvrhel_laptop | I want Cr = (1 - As/Ar) * Cb + As/Ar * [ (1-Ab) * Cs + Ab * B(Cb,Cs) ] | 19:02.16 |
| | yes if As = 1 then we want IR | 19:02.43 |
| Robin_Watts | OK. | 19:02.49 |
| mvrhel_laptop | I am missing something in the step | 19:03.18 |
| | Cr= (1-alpha) * Cb + alpha * Ir | 19:03.22 |
| | = Cb - alpha * Cb + alpha * Cb - alpha * Cb * As / Ar + alpha * As / Ar * [ (1 - Ab) * Cs + Ab * B(Cb, Cs) ] | 19:03.23 |
| Robin_Watts | So imagine now that we have a group blend with alpha. | 19:03.36 |
| | My contention is that that would be the same as doing the 100% blend to a temporary bitmap (if you want to think of it that way), and THEN doing a simple alpha blend to the destination. | 19:04.12 |
| | Ir is the result of the 100% blend. | 19:04.43 |
| | And thus Cr = (1-alpha) * Cb + alpha * Ir is the final result. | 19:05.24 |
| | You follow my logic? | 19:05.32 |
| | (never mind the algebra, does the overall approach make sense?) | 19:06.12 |
| mvrhel_laptop | I agree with that | 19:07.06 |
| Robin_Watts | ok. | 19:07.10 |
| | So: Cr = (1-alpha) * Cb + alpha * Ir is the obvious blend equation. | 19:07.44 |
| | happy? | 19:07.52 |
| mvrhel_laptop | I am happy with that | 19:08.17 |
| Robin_Watts | So let's substitute Ir in. | 19:08.26 |
| mvrhel_laptop | wait | 19:08.53 |
| | I think I am confused by what you are calling IR | 19:09.54 |
| Robin_Watts | Would you rather I used Cr instead, and called the final alpha blended result Fr ? | 19:11.09 |
| mvrhel_laptop | It is interesting | 19:11.24 |
| | So in gs, we do our group drawings etc and then we have a special compositing operation for when the group blends work | 19:11.57 |
| Robin_Watts | yeah, possibly in gs you do alpha and blending separately? | 19:12.25 |
| mvrhel_laptop | So I am a little worried about us applying alpha twice here. But lets say that we have done all our drawings in the group and we are doing a group pop (that is coming from the end of the xform). Is it only in this group pop that the group alpha is going to be applied or was it also applied during all the path fills? | 19:15.02 |
| Robin_Watts | mvrhel_laptop: It is only in this group alpha that it will be applied. | 19:16.44 |
| | (otherwise stuff like overlapping paths would look wrong) | 19:17.05 |
| mvrhel_laptop | ok. yes | 19:17.08 |
| | ok so now we have a group alpha and a blend for that group | 19:17.21 |
| Robin_Watts | yes. | 19:17.27 |
| | and my contention is that we *conceptually* do the blend first, and then alpha blend the result of that. | 19:17.58 |
| | (really annoying overloading of the word blend there, sorry) | 19:18.13 |
| mvrhel_laptop | yes | 19:18.16 |
| | I think of blend as | 19:18.20 |
| | [ (1 - Ab) * Cs + Ab * B(Cb, Cs) ] | 19:18.34 |
| | this part | 19:18.42 |
| Robin_Watts | Ah, to me, blending is the act of: (1-a).x + a.y | 19:19.29 |
| mvrhel_laptop | ok so lets back up for one sec | 19:19.44 |
| | lets call (1-a).x + a.y alpha blend | 19:19.59 |
| Robin_Watts | and what you describe there is a particular type of blend that I have no good name for :) "posh blend" maybe :) | 19:19.59 |
| | or "group" blend | 19:20.17 |
| mvrhel_laptop | and B(Cb, Cs) the blend mode | 19:20.18 |
| Robin_Watts | yes. | 19:20.25 |
| mvrhel_laptop | so I am a little confused by where you are headed | 19:22.10 |
| | lets say that we just had normal blend mode | 19:22.20 |
| Robin_Watts | My thinking is that the equations as given in the spec don't account for doing alpha blends and group blends at the same time. | 19:23.01 |
| | hence I am simply deriving an equation that lets me do that. | 19:23.16 |
| | and I do that by just composing the two equations, and everything falls out nicely. | 19:23.38 |
| mvrhel_laptop | ok. I *do* agree with your final equation | 19:24.33 |
| | = Cb * (1 - alpha * As / Ar) + alpha * As / Ar * [ (1 - Ab) * Cs + Ab * B(Cb, Cs) ] | 19:24.35 |
| Robin_Watts | And, do you agree with the premultiplied form? | 19:24.57 |
| mvrhel_laptop | where alpha is the group alpha and As is what ever alpha the the source had | 19:25.22 |
| Robin_Watts | yes. | 19:25.37 |
| mvrhel_laptop | yes result alpha should be Union(Ab, alpha * As) | 19:25.48 |
| Robin_Watts | (limitations of ascii for doing algebra) | 19:25.51 |
| | OK, so now we can look at the code :) | 19:26.03 |
| mvrhel_laptop | essentially all should be the same as if we were drawing with an alpha of alpha*As | 19:26.07 |
| | I agree absolutely with that | 19:26.19 |
| Robin_Watts | mvrhel_laptop: yeah. | 19:26.45 |
| mvrhel_laptop | the source alpha is basically multiplied accordingly | 19:26.46 |
| Robin_Watts | yes. | 19:26.51 |
| | I had done that in the code before, but wanted to be 100% explicit and sure that it was justified in the maths. | 19:27.32 |
| mvrhel_laptop | ok | 19:28.41 |
| Robin_Watts | so hopefully the code should be straightforward now. | 19:29.34 |
| | There were a couple of things we were doing wrong before. | 19:29.46 |
| | We were falling into the "just memcpy" loop too often (not allowing for alpha != 0). | 19:30.18 |
| | I had failed to account for the /ra bits of the equations (which is why I moved to the premultiplied result form) | 19:30.52 |
| | The "if (complement)" code was not allowing for alpha at all. | 19:31.25 |
| | and when we're in the premultiplied form, the "re-inversion" of the result needs to be different. | 19:32.20 |
| | I'll let you walk through the code, and you can shout if you spot something you don't like. | 19:32.59 |
| mvrhel_laptop | sorry I am back | 19:43.53 |
| | Robin_Watts: ok lets walk through it | 19:44.26 |
| Robin_Watts | No worries. I'm going to have to go for food in a few minutes. | 19:44.32 |
| mvrhel_laptop | ok | 19:44.37 |
| Robin_Watts | but let's do what we can. | 19:44.43 |
| mvrhel_laptop | ok so as before haa is the alpha and the coverage product for the source | 19:45.53 |
| | is that correct? | 19:46.03 |
| Robin_Watts | yes. ha.a | 19:46.04 |
| | ha = ha * a | 19:46.08 |
| mvrhel_laptop | ok so now this is new | 19:46.42 |
| | the ra0 and the ra | 19:46.46 |
| | ra is the union | 19:46.52 |
| Robin_Watts | if haa == 0 then there can be no impact on the output | 19:47.06 |
| mvrhel_laptop | of the back drop alpha and the source alpha (which is haa) | 19:47.12 |
| Robin_Watts | right, ra is unchanged. | 19:47.19 |
| | ra0 is just a temporary product that will be useful later. | 19:47.29 |
| | ignore it for now. | 19:47.35 |
| mvrhel_laptop | ha | 19:47.37 |
| | ok I will ignore even though it is hard | 19:47.53 |
| Robin_Watts | Damn. I have to go for dinner. I'll try to pop back in a bit to answer any questions. Hopefully this should be simple enough. | 19:48.31 |
| mvrhel_laptop | so yes. sorry I agree on the ba==0 && alpha ==255 | 19:48.33 |
| | np. I will step through | 19:48.41 |
| | is it giving the right results? | 19:48.45 |
| Robin_Watts | In my limited testing, yes. | 20:23.23 |
| mvrhel_laptop | hmm | 20:23.24 |
| | I am up the the /*CMYK */ Section | 20:23.37 |
| Robin_Watts | and it solves some of the edge effects I'd seen on some pages. | 20:23.39 |
| mvrhel_laptop | so far all good | 20:23.41 |
| Robin_Watts | cool. Tomorrow, I will run through the rest of the code applying the same logic there. | 20:24.40 |
| mvrhel_laptop | So I am am confused though as I would think we would be doing complement stuff before and after the blend | 20:24.49 |
| | I don't understand why all the logic is needed there | 20:25.04 |
| | oh that is the k case | 20:25.23 |
| Robin_Watts | This is the same logic as you had before, but amended to allow for the alpha. | 20:26.05 |
| mvrhel_laptop | right | 20:26.11 |
| | ok | 20:26.13 |
| Robin_Watts | Clearly we don't need to alpha blend when we are mixing bk with bk :) | 20:26.20 |
| mvrhel_laptop | yes | 20:26.35 |
| Robin_Watts | so it's only the LUMINOSITY case that has that. | 20:26.35 |
| mvrhel_laptop | looks good | 20:30.19 |
| | so you will update the other methods? | 20:30.34 |
| Robin_Watts | The spot case is missing alpha. | 20:30.36 |
| mvrhel_laptop | Yes I was going to ask about the spot | 20:30.46 |
| Robin_Watts | yeah, I'll tidy up all the rest tomorrow. | 20:30.58 |
| mvrhel_laptop | cool | 20:31.01 |
| Robin_Watts | Or I can still a WIP up and you can run with it. | 20:31.13 |
| mvrhel_laptop | If you want me to do any of it today I can | 20:31.16 |
| Robin_Watts | All depends what you'd rather do. | 20:31.17 |
| mvrhel_laptop | I want to get that crazy page working, but I suspect the issue is realated to this | 20:31.46 |
| | bbiab | 20:34.59 |
| Robin_Watts | OK, I've pushed what I've got so far to robin/spots. | 20:35.52 |
| | Feel free to run with it, or not. Just let me know ! :) | 20:36.04 |
| | mvrhel_laptop: hey | 23:24.23 |
| | mvrhel_laptop: So page 1-3 look perfect now (the edge effects on 3 are gone). | 23:38.01 |
| mvrhel_laptop | nice | 23:38.13 |
| Robin_Watts | Page 4 is vastly improved, but there are still a few stray pixels. | 23:38.16 |
| | 5 and 6 are fine. | 23:38.39 |
| | 7 has an alpha being dropped. Will look into that tomorrow. | 23:38.54 |
| | 8 has one gradient still not right :( | 23:39.23 |
| | 11 has one block wrong. | 23:39.42 |
| | 13 looks pretty good. | 23:40.18 |
| | 14 is still not right. | 23:40.33 |
| | 15 is hopeless. | 23:40.42 |
| mvrhel_laptop | my nemesis | 23:40.45 |
| | 15 is the optional content | 23:40.57 |
| Robin_Watts | Ah, well, at least we know what's wrong. | 23:41.08 |
| | no idea about 17. | 23:41.17 |
| mvrhel_laptop | what do you want me to do | 23:41.26 |
| Robin_Watts | whatever you'd like. | 23:41.35 |
| mvrhel_laptop | I am feeling a bit useless.... | 23:41.37 |
| | Are all the fixes in the blending functions? | 23:41.54 |
| Robin_Watts | I'll look at 7 and/or 8 tomorrow unless you want to take them sooner. | 23:41.58 |
| | I haven't done more since I pushed the WIP earlier. | 23:42.09 |
| mvrhel_laptop | ok. I will work on 14 | 23:42.20 |
| | 11 also might be straight foreward | 23:42.34 |
| Robin_Watts | I put a load of FIXMEs in where I think we need to double check the code and I'll look at that tomorrow unless you beat me to it. | 23:42.45 |
| mvrhel_laptop | let me look at that fist | 23:42.45 |
| | ok | 23:43.06 |
| | have a good night | 23:43.11 |
| Robin_Watts | mvrhel_laptop: Ah, so the problem with the OCG stuff is that we ignore OCG stuff in BDC commands. | 23:57.20 |
| mvrhel_laptop | is that an easy fix? | 23:57.30 |
| Robin_Watts | It's a simple matter of programming. | 23:57.41 |
| mvrhel_laptop | :) | 23:57.45 |
| Robin_Watts | I'd have to read the spec again. | 23:58.06 |
| | I dunno if we have the concept of a "disabled" state in the pdf interpreter offhand. When we hit an OCG, we need to check if the state is enabled or not (that's easy enough), but if it's not we need to disable the interpreter from calling more device calls | 23:59.24 |
| mvrhel_laptop | Robin_Watts: so your fixes did fix one issue on that crazy page | 23:59.57 |
| | Forward 1 day (to 2017/08/08)>>> | |
Log of #mupdf at irc.freenode.net.