| | <<<Back 1 day (to 2017/07/16) | 20170717 |
| Robin_Watts | tor8, mvrhel_laptop: Morning. | 11:39.00 |
| | I've fixed the 'complement blend' commit on robin/mvrhel_master, and folded all the fixes back into it. | 11:39.40 |
| | The bmpcmp now looks much better. | 11:39.47 |
| | I have just run a paranoid check to see that we don't get any premultiplied values out of range, and there are 4 files that trigger that. | 11:40.18 |
| | so I'm looking into that now. | 11:40.24 |
| tor8 | Robin_Watts: yep, I saw. the robin/mvrhel_master commits look good to me | 11:41.24 |
| Robin_Watts | tor8: Ta. | 11:41.34 |
| tor8 | I missed the n==4 case in the nonseparable blending so I thought it only did RGB | 11:44.45 |
| Robin_Watts | tor8: yeah, easy to do, simple fix. | 11:45.13 |
| | I had to move the complement calls out slightly to include the uncomposite/recomposite stuff too. | 11:45.47 |
| | tor8: In pdf_show_image there is a line: /* apply blend group even though we skip the soft mask */ | 13:30.54 |
| | That sounds wrong to me. | 13:32.38 |
| tor8 | Robin_Watts: I don't know | 13:33.37 |
| Robin_Watts | it looks to appear back in 4dfa69f388b5eaccc5afe87d368f9b30a8f10475 | 13:45.21 |
| | The code in question is: | 13:45.25 |
| | +if (image->mask) | 13:45.38 |
| | +{ | 13:45.40 |
| | +/* apply blend group even though we skip the softmask */ | 13:45.41 |
| | +if (gstate->blendmode) | 13:45.43 |
| | +fz_begin_group(csi->dev, bbox, 0, 0, gstate->blendmode, 1); | 13:45.44 |
| | +fz_clip_image_mask(csi->dev, image->mask, gstate->ctm); | 13:45.46 |
| | +} | 13:45.47 |
| | Surely the call to fz_clip_image_mask is not "skipping" the softmask? | 13:46.10 |
| tor8 | it's older than that | 13:47.37 |
| Robin_Watts | it is. tracking it now... | 13:47.52 |
| tor8 | 5ee34c75db2752a656f56c7bbeeb67f67f158519 | 13:49.01 |
| Robin_Watts | yeah, I just made it to the same place. | 13:50.00 |
| | in what way are we skipping the softmask there? | 13:50.26 |
| tor8 | Robin_Watts: we're calling fz_begin_group directly in the if(image->mask) case | 13:51.27 |
| | but pdf_begin_group with the &softmask in the else | 13:51.35 |
| Robin_Watts | oh, we take the blend mode from the gstate, but we skip any gstate->softmask. | 13:51.50 |
| | So should we REALLY be doing both gstate->softmask AND image->mask ? | 13:52.12 |
| tor8 | Robin_Watts: page 341 in pdfref17 | 14:02.43 |
| | an image SMask entry overrides the softmask in the gstate | 14:03.57 |
| Robin_Watts | tor8: right. | 14:04.50 |
| mvrhel_laptop | Robin_Watts: That is good news | 15:48.17 |
| kens | mvrhel_lapto: p I can't remember if it was you ro Chris who did hte WinRT build and wrote hte instructions in the documentation ? | 15:49.22 |
| | mvrhel_laptop : ^^# | 15:49.42 |
| mvrhel_laptop | kens: I had nothing to do with winRT for ghostscript | 15:50.04 |
| | only mupdf | 15:50.06 |
| kens | I guess it was chrisl then | 15:50.17 |
| mvrhel_laptop | It was either chrisl or Robin_Watts | 15:50.29 |
| Robin_Watts | I did the initial "METRO" stuff, but never anything more than getting a library that claimed to work. | 15:51.19 |
| | I believe chrisl took it further. | 15:51.32 |
| kens | I'm cl;ueless about the terminology, is 'METRO' the same as 'WinRT' ? | 15:51.42 |
| Robin_Watts | Me too. | 15:52.12 |
| | When I say "METRO" I mean the #ifdef METRO stuff. | 15:52.23 |
| | The "colorful block UI" that MS introduced in Windows 8 was to be called METRO at one point. | 15:53.11 |
| | To code for that you had to use a 'different' API (i.e. not win32). | 15:53.30 |
| | so that was what I did (mostly by chopping stuff out). | 15:53.45 |
| kens | I think I'll leave it to chrisl.... | 15:54.03 |
| Robin_Watts | They then dropped the METRO name, cos some German company called Metro AG (IIRC) complained. | 15:54.13 |
| | AIUI, WinRT shared some, but not all of that 'different' API. | 15:54.42 |
| | It was a horrible mess. | 15:54.45 |
| kens | I htink tha'ts probably where I lost the thread | 15:54.51 |
| mvrhel_laptop | Metro was the early term for WinRT | 15:56.31 |
| | I think it was called that before the official release of windows 8 | 15:56.44 |
| Robin_Watts | I know that "Metro apps" were suddenly supposed to be called "Windows Store apps" or something. It all stank of a horrible last minute panic. | 15:57.36 |
| | The register referred to them as TIFKAM apps. (The Interface Formerly Known As Metro) | 15:58.04 |
| mvrhel_laptop | ok. got my dna testing results... | 16:20.54 |
| | turns out I am a European mutt for the most part. With 31 % British, 28 % western Europe and 24 % Eastern Europe | 16:22.17 |
| | Stephanie was surprisingly mostly British | 16:22.32 |
| | Robin_Watts: So what should I focus on today? Where there any obvious issues in the bmcmp? | 16:27.15 |
| | s/Where/were | 16:27.27 |
| Robin_Watts | mvrhel_laptop: It's the tea affecting her DNA. | 16:27.59 |
| | mvrhel_laptop: So, I'm bashing my head against a problem with premultiplication. | 16:28.34 |
| mvrhel_laptop | Perhaps. She always thought she was German but turns out she was 65 percent British and 9 percent scandanavian | 16:28.38 |
| | Robin_Watts: if you want me to take it over I can and you can work on devicen and overprint | 16:29.09 |
| Robin_Watts | Gawd knows what I'd be. Some obscure percentage Mauritian. | 16:29.13 |
| mvrhel_laptop | Well I did have one crazy thing in my results | 16:29.27 |
| Robin_Watts | mvrhel_laptop: Give me 5 mins to get what I've got into some sort of sane order, then I'll show you the problem. | 16:29.50 |
| mvrhel_laptop | less than 1 percent African. Now I know we are all from Africa but apparently there was some DNA there that was a bit more recent. | 16:30.55 |
| | Robin_Watts: ok. I will grab some breakfast | 16:33.57 |
| Robin_Watts | ok, new robin/mvrhel_master, and a file in my homedir on casper called 'blend3.pdf'. | 16:34.34 |
| | yell when you're back. | 16:35.46 |
| mvrhel_laptop | Robin_Watts: ok. I am back. I have the file and your repo | 16:50.47 |
| Robin_Watts | So, I wrote some code to check that the premultiplied values were always <= alpha. | 16:51.20 |
| | If they weren't, I SEGV. | 16:51.29 |
| | and I cluster tested, and I got this list back: https://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=robin | 16:51.47 |
| | so I made a cut down version of tests_private/pdf/sumatra/.... as blend3.pdf to show the problem | 16:52.14 |
| mvrhel_laptop | ok | 16:52.33 |
| Robin_Watts | If you run mutool draw -D -r72 -o out.pgm blend3.pdf you'll see the problem. | 16:53.10 |
| | There is a rectangle with a star blended on top of it. | 16:54.28 |
| | You can see the errors along the bottom of the rectangle. | 16:54.40 |
| | If you enable PARANOID_PREMULTIPLY at the top of draw-blend.c, it'll trip in the code. | 16:55.12 |
| mvrhel_laptop | ok here is what I see | 16:55.14 |
| | If I run with with -A 0 it looks fine. If I include AA then I see a black square appear. | 16:55.39 |
| | at the left lower intersection of star and rectangle | 16:56.02 |
| Robin_Watts | mvrhel_laptop: Yeah, it's to do with the way we're clipping through softmasks. | 16:56.05 |
| | If you enable DUMP_GROUP_BLENDS in the top of draw-device.c, and rerun, we'll get some PNGs dumped out that we can examine. | 16:56.50 |
| | It's to do with our handling of the shape plane. | 16:58.08 |
| | We're getting a shape plane with an unexpected value in, and when we uncomposite, that's causing the grey value to be larger than the alpha. | 16:58.42 |
| mvrhel_laptop | Is the shape plane able to cope properly with AA? | 16:59.11 |
| Robin_Watts | mvrhel_laptop: It's certainly supposed to. | 16:59.26 |
| mvrhel_laptop | It looks to me like it is not | 16:59.31 |
| Robin_Watts | But I think something is broken w.r.t. shape planes and softmasks. | 16:59.53 |
| | If you look at fz_draw_clip_image_mask... | 17:00.20 |
| | I think we're drawing to the wrong shape plane, but even if I fix that, it still goes wrong. | 17:00.38 |
| mvrhel_laptop | Robin_Watts: I have to get Ethan out the door and to the bus (he is still sleeping). I am going to have to come back to this shortly | 17:03.39 |
| Robin_Watts | mvrhel_laptop: No worries. | 17:03.50 |
| | tor8: I am tempted to suggest we should push everything up to the point I showed you this morning. Certainly we have no massive regressions in there now. I think this premultiplied thing I'm working on now has been there for ages. | 17:28.37 |
| | Any objections? | 17:28.40 |
| | It also means that bmpcmps from this point on become useful :) | 17:29.10 |
| mvrhel_laptop | I vote for a push | 18:12.25 |
| Robin_Watts | mvrhel_laptop: Have a quick look at my bmpcmp. I reckon these are progressions. | 18:25.39 |
| mvrhel_laptop | Robin_Watts: | 18:25.47 |
| | ok | 18:25.48 |
| | Robin_Watts: yes. They look good. | 18:29.20 |
| Robin_Watts | That's this change: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=ef43aa8826d3f1bcbb5ad79018c3648a9c41bd2a | 18:29.32 |
| | basically we were rendering to the previous shape plane, rather than to the new shape plane. | 18:29.53 |
| mvrhel_laptop | ah | 18:30.01 |
| | as you mentioned above about the wrong shape | 18:30.15 |
| Robin_Watts | That doesn't solve the problem, unfortunately, but I think it's part of it. | 18:30.20 |
| | I think based on tor's comments from this morning, that we can assume he's happy. | 18:30.51 |
| mvrhel_laptop | So the altona test with the overlapping groups has an issue. I may look at that. It took me a while to get that one working in gs | 18:30.52 |
| | Robin_Watts: Yes. We need to commit and push on I feel | 18:31.10 |
| Robin_Watts | mvrhel_laptop: Yeah, the 2 altona files are crapping out in my SEGV test. | 18:31.19 |
| mvrhel_laptop | if we have any hope of getting this done before you go | 18:31.19 |
| Robin_Watts | Ok. so if you're happy with that change, I'll push the lot. | 18:31.33 |
| mvrhel_laptop | Robin_Watts: yes please | 18:31.39 |
| Robin_Watts | mvrhel_laptop: Could you review the top 3 commits here too please? | 18:34.10 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=shortlog;h=refs/heads/mvrhel_master | 18:34.11 |
| | oops, not the very top one. | 18:34.29 |
| | but the 2 previous ones. | 18:34.42 |
| mvrhel_laptop | Robin_Watts: They look reasonable to me | 18:35.53 |
| Robin_Watts | Ta. | 18:36.04 |
| | That'll keep the cluster busy for a bit. | 18:39.49 |
| mvrhel_laptop | Robin_Watts: ok I may work on taking apart the overlapping groups image from altona and isolate that issue | 18:44.13 |
| Robin_Watts | mvrhel_laptop: Go for it. | 18:44.25 |
| mvrhel_laptop | page 14 | 18:44.28 |
| Robin_Watts | I still have shape issues to solve here, so I shouldn't interfere with you. | 18:44.48 |
| mvrhel_laptop | ok sounds good | 18:44.57 |
| Robin_Watts | mvrhel_laptop: Oh, that fix *did* solve the issue. | 18:48.41 |
| mvrhel_laptop | awesome! | 18:48.47 |
| Robin_Watts | So I'm happy. | 18:48.48 |
| | no, it didn't solve it :( | 18:50.04 |
| mvrhel_laptop | :( | 18:50.09 |
| | Robin_Watts: let me ask you this | 18:50.22 |
| Robin_Watts | When we push a group, if we don't have a shape plane, and we're either using alpha, or a non-zero blendmode, or it's an isolated group, we make ourselves a new shape plane. | 18:50.51 |
| | Hmm. Let me rephrase that. | 18:51.29 |
| | When we push a group, we always make ourselves a new shape plane, unless we are using normal blendmode, with solid alpha, and isolated plotting, in which case we don't bother. | 18:52.15 |
| mvrhel_laptop | The fact that I am seeing issues on the edges when using AA makes me a little suspicious that the shape plane is not accounting for any growth. I don't know enough about how mupdf is doing AA but it just looks suspicious. Realize this is me talking without knowing anything.... | 18:52.23 |
| Robin_Watts | 'growth' ? | 18:52.31 |
| mvrhel_laptop | well yes. Let me rephrase that | 18:52.40 |
| | do a run with AA and without AA | 18:52.50 |
| | compare the bitmaps on blend3.pdf | 18:52.54 |
| | you will see the bottom line where the mask is | 18:53.06 |
| Robin_Watts | the shape plane should have the same alpha values around the edges of a shape that the shape does. | 18:53.13 |
| | If you turn on DUMP_GROUP_BLENDS in draw-device and do the run, it'll save out pngs so you can examine exactly what we are blending with what. | 18:54.17 |
| mvrhel_laptop | Robin_Watts: ok. Just a sec. Had to remigrate projects to vs 2017 which takes a bit of time | 18:54.59 |
| | Robin_Watts: so how does AA work with the alpha plane and the shape plane in mupdf? I know what happens in gs but mupdf AA is much different | 18:56.05 |
| Robin_Watts | The same code that writes values into the alpha plane writes 'em into the shape plane. | 18:56.29 |
| | pixmaps hold rgba, right? I *did* ponder about making pixmaps hold rgbah (where h = shape) | 18:57.44 |
| avih | Robin_Watts: tor8: did you get a chance to play with mpv with js support? | 18:58.03 |
| mvrhel_laptop | you are supposed to have a separate shape for proper handling of knockout groups | 18:58.08 |
| Robin_Watts | but then 'inventing' a whole new pixmap seemed harder, so we keep a completely separate pixmap which just holds the shape plane. | 18:58.45 |
| | mvrhel_laptop: Right, and we have that. | 18:58.51 |
| mvrhel_laptop | cool | 18:58.54 |
| | ok. projects converted. Robin_Watts would you prefer I help on this problem or work on the altona page? | 18:59.15 |
| | I don't want to get in the way | 18:59.22 |
| Robin_Watts | mvrhel_laptop: Let me run you through this, cos you might spot something immediately dumb that I'm doing. | 18:59.35 |
| mvrhel_laptop | ok | 18:59.40 |
| Robin_Watts | so in draw-device.c enable DUMP_GROUP_BLENDS | 18:59.54 |
| | (this might be worth doing anyway, cos it's potentially useful to you as a debug tool) | 19:00.19 |
| mvrhel_laptop | ok building... | 19:00.37 |
| | built | 19:00.40 |
| Robin_Watts | Then rebuild, and run: mutool -D -r72 -o out.pgm blend3.pdf | 19:00.58 |
| | As well as producing out.pgm that'll put a load of dumpXX.png's in your current dir. | 19:01.35 |
| | And the output on stdout tells you what each of those is. | 19:01.48 |
| mvrhel_laptop | ok so that last row | 19:01.58 |
| | of the mask | 19:02.02 |
| | just humor me for one sec | 19:02.10 |
| Robin_Watts | sure. | 19:02.14 |
| mvrhel_laptop | that row has no mask effect when AA is off | 19:02.27 |
| | doesn't that seem a little suspicious as a possible issue | 19:02.54 |
| Robin_Watts | "no mask effect". | 19:03.00 |
| mvrhel_laptop | so save that pgm and do a run with -A 0 | 19:03.16 |
| Robin_Watts | the rectangle that is drawn doesn't cross the midpoint of the pixel. | 19:03.17 |
| | so with -A 0 it doesn't get rendered. | 19:03.40 |
| | That's the sole difference. | 19:03.44 |
| | That's just the way the 'old' mupdf renderer works. | 19:04.02 |
| mvrhel_laptop | ok. maybe I am stuck in thinking like gs. When I see something like this in gs, it has always been an issue with copy_alpha into the pdf14 device | 19:04.27 |
| Robin_Watts | mvrhel_laptop: look at dump07.png | 19:04.42 |
| mvrhel_laptop | but I guess mupdf is so different that there is no such thing | 19:04.49 |
| | ok | 19:04.51 |
| | hold on | 19:04.52 |
| Robin_Watts | That's the image of that rectangle rendered. | 19:04.58 |
| mvrhel_laptop | ok that looks reasonable | 19:05.46 |
| Robin_Watts | ok, so let's walk through the output... | 19:05.57 |
| mvrhel_laptop | ok | 19:06.10 |
| Robin_Watts | The first time we have to do any group blending etc is when we create the imagemask. | 19:06.24 |
| | (this is rendering the softmask) | 19:06.29 |
| | If you do 'start dump00.png' it opens in Windows bitmap viewer for me, and I can then use left and right to easily step through the different output. | 19:07.16 |
| | so, dump00.png is the image that we have to plot. | 19:08.37 |
| | dump01.png is the empty destination that it's being plotted onto | 19:09.01 |
| | and dump02.png is the empty shape plane. | 19:09.12 |
| | (When the output says 00/01 that's always 'destination/shape') | 19:09.39 |
| | (Oh, it says 00(%x)/01(%x) now, doesn't it.) | 19:10.01 |
| | The %x is the address of the pixmap - useful for when looking in the debugger. | 19:10.21 |
| | Does this make sense? | 19:10.52 |
| | This is all akin to the DUMP_RAW stuff you have in pdf14 in gs. | 19:11.21 |
| mvrhel_laptop | mine says plotting 00 onto 01/02 | 19:11.42 |
| Robin_Watts | hmm. I worry that you don't have the latest version then, but that might not matter. | 19:12.22 |
| mvrhel_laptop | no I updated with a hard reset | 19:12.34 |
| | to golden after your push | 19:12.44 |
| Robin_Watts | what SHA? | 19:12.45 |
| mvrhel_laptop | SHA-1: 244f297e9a0d0a7a3ff712cbbb21b7795ae64fab | 19:13.10 |
| Robin_Watts | Same as me. | 19:13.19 |
| mvrhel_laptop | Group begin | 19:13.42 |
| | Clip (image mask) begin | 19:13.44 |
| | Creating imagemask: plotting 00(03DD6110) onto 01(03DD5CB0)/02(03DF35C8) to get 03(03DD5CB0)/04(03DF35C8) | 19:13.45 |
| | Clipping 05(03DD6178)/06(03DF35C8) onto 07(03DECEF8)/08(03DE9ED0) with 09(03DD5CB0) to get 10(03DECEF8)/11(03DE9ED0) | 19:13.47 |
| | Group end: blending 12(03DECEF8)/13(03DE9ED0) onto 14(03DDD7F0) (blend 15) to get 15(03DDD7F0) | 19:13.48 |
| | Group end: blending 16(03DDD7F0) onto 17(03DD8C78) (isolated) to get 18(03DD8C78) | 19:13.50 |
| Robin_Watts | Ah, perfect. | 19:13.54 |
| | plotting 00(address) onto 01(address)/02(address) to get 03(address)/04(address) | 19:14.27 |
| mvrhel_laptop | yes. you had said (Oh, it says 00(%x)/01(%x) now, doesn't it.) | 19:14.49 |
| | I don't see that | 19:14.58 |
| Robin_Watts | yeah, sorry, irc probably swallowed the percentage thing. | 19:15.09 |
| mvrhel_laptop | oh ok | 19:15.23 |
| Robin_Watts | Ah, no, I meant that previously it used to say things like: 09/10 | 19:15.28 |
| | and now it says 09(address)/10(address) | 19:15.37 |
| | sorry, being unclear. | 19:15.54 |
| mvrhel_laptop | hold on I am lining up the images so that I can follow | 19:16.16 |
| Robin_Watts | so dump03 and dump04 are the resulting destination/shape planes from creating the imagemask. | 19:16.39 |
| mvrhel_laptop | makes sense | 19:16.48 |
| Robin_Watts | Next line is where we've drawn the star, and are clipping it back. | 19:17.12 |
| | so 05/06 is the result of the image plot. | 19:17.43 |
| | and 07/08 are the background onto which it needs to be clipped. | 19:17.59 |
| | 07 shows the rectangle, and 08 is entirely empty for me. | 19:18.17 |
| | 09 is the mask we are using (which you can see from the address is the same as 03). | 19:18.53 |
| | and 10/11 is the result. | 19:18.59 |
| | The next line is the "end of group" blend, and this is where you can see the error. | 19:20.20 |
| mvrhel_laptop | so lets walk through the 12/13 onto 14 | 19:22.22 |
| Robin_Watts | If you add some asserts to check what's going on in the blend, you never see 15 produced. | 19:22.42 |
| | because the uncomposition that is done in this step gives grey values > alpha. | 19:23.08 |
| | which makes me suspect that the shape value has gone wrong somewhere. | 19:23.25 |
| | sure, let's walk through. | 19:23.41 |
| mvrhel_laptop | Robin_Watts: before we do that | 19:23.58 |
| Robin_Watts | 12/13 should be the product of rendering the group contents. | 19:24.02 |
| | go on. | 19:24.04 |
| mvrhel_laptop | So on dump15, the black pixels on the right side of the star are the issue here? | 19:24.21 |
| Robin_Watts | mvrhel_laptop: The black pixels on the right side of the star are wrong. | 19:24.38 |
| mvrhel_laptop | yes ok | 19:24.43 |
| Robin_Watts | They are caused by the blending step going wrong. | 19:24.52 |
| | the maths goes haywire because the input pixmap has larger grey values than alpha values once the uncomposition has been done. | 19:25.29 |
| | so, I don't believe the problem is in the blending maths. I believe it's in the inputs we are feeding to the blending maths. | 19:26.46 |
| mvrhel_laptop | Robin_Watts: so a couple silly questions | 19:27.05 |
| | I see the blending is Luminosity | 19:27.13 |
| | So the whole math for uncomposition is a little unclear to me. I have not really ever needed to dig into it. Does it assume any sort of blending mode or is uncomposition unrelated to blending. I guess my question is best answered by looking at the spec to understand where and why uncomposition is needed. IIRC it was needed to avoid having the backdrop worked in twice | 19:29.49 |
| Robin_Watts | mvrhel_laptop: AIUI, it's exactly that. | 19:30.11 |
| | As best I could work out... | 19:30.21 |
| mvrhel_laptop | Robin_Watts: so a silly question | 19:30.25 |
| | If the backdrop was blended at one point with blending type A should the decomposition not account for that? | 19:30.51 |
| | I don't know the answer to this, just throwing it out there. | 19:31.05 |
| | I am going to need to read to understand this better | 19:31.16 |
| Robin_Watts | we come to the end of the group, and we say "we've blended a whole load of stuff onto a background B. Let's UNDO that blending, and to do that we assume that it's been simple B' = B*(1-a) + Ca blending. | 19:31.22 |
| | gs does not account for it like that. | 19:31.41 |
| | gs assumes simple blending throughout. | 19:31.51 |
| mvrhel_laptop | ok | 19:31.58 |
| Robin_Watts | (at least, such is my understanding from staring at the code in pdf14.c - I would welcome a double check). | 19:32.24 |
| | The whole 'decomposition' thing really offends me. I would *so* much prefer to hold stuff so it doesn't need to be decomposed, but I couldn't make that work. | 19:33.34 |
| mvrhel_laptop | Robin_Watts: that seems ok | 19:37.28 |
| | Robin_Watts: ok another silly question | 19:39.12 |
| | so 13 is a shape image, correct? | 19:39.27 |
| Robin_Watts | yes. | 19:39.53 |
| | Anything immediately after a / is a shape image. | 19:40.08 |
| mvrhel_laptop | I am a little confused on why shape images have anything other than 0 and 1 | 19:40.35 |
| Robin_Watts | mvrhel_laptop: cos of antialiasing. | 19:40.46 |
| | shape values = amount of pixel covered. | 19:41.13 |
| mvrhel_laptop | ah! so the shape is holding the aa information here. sorry for being so dense | 19:41.57 |
| Robin_Watts | mvrhel_laptop: No apology necessary. | 19:42.09 |
| | both shape and alpha planes hold aa information. | 19:42.28 |
| mvrhel_laptop | hmm | 19:43.02 |
| | right. I am seeing that both 12 and 13 have AA going on | 19:43.30 |
| | for the star | 19:43.33 |
| Robin_Watts | yes. | 19:43.55 |
| mvrhel_laptop | That seems odd to me in a way. | 19:44.13 |
| Robin_Watts | care needs to be taken so that alphas aren't applied twice, but I believe this is basically correct. | 19:44.39 |
| | (my belief may be wrong, of course) | 19:44.49 |
| mvrhel_laptop | To me, it would seem that shape should be used just for shape and be purely an 0 or a 1 and the alpha should take care of AA | 19:45.24 |
| Robin_Watts | mvrhel_laptop: how does that work for pixels which are the edge of a shape? | 19:46.11 |
| | It's not always possible to assign an integer value for shape for all pixels when you are doing AA rendering. | 19:47.05 |
| mvrhel_laptop | I don't follow your questions. I would have the relationship that shape*opacity = alpha | 19:47.08 |
| Robin_Watts | Ah, but I'm not holding shape and opacity. | 19:47.27 |
| | I'm holding shape and alpha. | 19:47.32 |
| mvrhel_laptop | no you have shape and alpha | 19:47.37 |
| | ha | 19:47.46 |
| | yes I agree | 19:47.51 |
| | but you don't really have shape | 19:47.58 |
| | you have alpha and something else | 19:48.07 |
| | shape * alpha | 19:48.15 |
| | maybe | 19:48.19 |
| | ok. So given that you have shape * alpha and alpha, lets look at the equations | 19:49.33 |
| | where is step 15 occurring in the code | 19:49.49 |
| Robin_Watts | fz_draw_end_group | 19:50.14 |
| | which calls fz_blend_pixmap | 19:50.34 |
| | which ends up in fz_blend_nonseparable_gray | 19:51.28 |
| | no, sorry... fz_blend_nonseparable_nonisolated_gray | 19:52.12 |
| mvrhel_laptop | hmm does this happen in rgb too? | 19:52.29 |
| Robin_Watts | mvrhel_laptop: No. | 19:53.02 |
| | or at least, I don't think so. | 19:53.12 |
| mvrhel_laptop | oh well that smells suspicous | 19:53.16 |
| Robin_Watts | but we might just be being lucky with the numbers. | 19:53.27 |
| mvrhel_laptop | right | 19:53.36 |
| Robin_Watts | I'm being called for dinner. | 19:54.10 |
| | Don't sweat too much over this. | 19:54.19 |
| | If you can see a solution, then brilliant, but if not, I'll keep bashing on it tomorrow. | 19:54.35 |
| | will check back in a bit. | 19:54.44 |
| mvrhel_laptop | Robin_Watts: ok. no problem. | 19:54.49 |
| Robin_Watts | thanks. | 19:54.52 |
| mvrhel_laptop | I am going to step through this | 19:54.57 |
| | I am very curious | 19:55.04 |
| | Robin_Watts: so I can step through the issue by putting a breakpoint at line 629 with a count of 305 | 20:30.50 |
| | in draw-blend.c | 20:30.58 |
| | The uncomposite equation gives a blown up sg value | 20:31.25 |
| | you may already know this | 20:31.32 |
| | page 538 of the pdf spec describes the uncomposite operation | 20:32.03 |
| | so sg and bg coming into the equation seem reasonable | 20:33.56 |
| | So ha, is the "alpha" value coming from the "shape" pixmap which is really a shape * alpha pixmap | 20:35.33 |
| | that has a value of 29 | 20:35.50 |
| | 39 | 20:35.52 |
| | sorry | 20:35.55 |
| | ba is 16 | 20:36.03 |
| | and sa is 53 | 20:36.06 |
| | I am really having trouble wrapping my head around the alpha that is in the shape, vs the alpha in the backdrop, vs the alpha in the source pixmaps | 20:37.13 |
| | fyi, the rgb output also shows the issue | 20:41.51 |
| | There is something odd going on with the alpha in the shape | 20:44.48 |
| | I have to run to the bus stop | 20:44.53 |
| | bbiab | 20:44.58 |
| tor8 | Robin_Watts: no objections from me. | 20:51.37 |
| Robin_Watts | mvrhel_laptop: ping | 23:27.34 |
| mvrhel_laptop | Hi Robin_Watts | 23:27.40 |
| Robin_Watts | So you reckon our shape plane is wrong? | 23:27.53 |
| mvrhel_laptop | Well. I am not sure. I am working on my expense report right now but I want to go back and really try to understand the uncomposite math in the pdf spec and how that relates to what we have and what the meaning of the shape*alpha data is | 23:29.23 |
| | I am a little confused about the use of the shape with alpha vs the source with alpha vs the background with alpha | 23:30.07 |
| Robin_Watts | It struck me while I was downstairs, that this is a long standing issue that has fairly minor effects. | 23:30.10 |
| | I suspect we should ignore it and move on, and come back when the time pressure has passed. | 23:30.24 |
| mvrhel_laptop | Robin_Watts: I would be fine with that | 23:30.31 |
| | This could take a little time to unravel | 23:30.37 |
| | I can push on with the altona file | 23:30.50 |
| | and you with the devN and overprint | 23:30.57 |
| Robin_Watts | mvrhel_laptop: I think that would be best. | 23:31.07 |
| mvrhel_laptop | sounds good. Maybe we should open a bug, attach your file | 23:31.24 |
| | Because I wont remember :) | 23:31.45 |
| Robin_Watts | Yeah, I'll do that tomorrow morning. | 23:31.54 |
| mvrhel_laptop | awesome. Have a great night | 23:32.00 |
| Robin_Watts | you too. night. | 23:32.39 |
| | Forward 1 day (to 2017/07/18)>>> | |
Log of #mupdf at irc.freenode.net.