| | <<<Back 1 day (to 2017/08/03) | 20170804 |
| mvrhel_laptop | aha! | 00:07.03 |
| kr1shna | does mupdf support reading of .pdb files ? | 11:36.03 |
| tor8 | kr1shna: no. | 11:37.15 |
| Robin_Watts | The only .pdb files I've ever seen are debugging files from MSVC | 11:37.16 |
| tor8 | Robin_Watts: pbd is also the 'palm database' binary format used by the old palm pilots | 11:37.46 |
| | which is what amazon use in their kindle software | 11:38.05 |
| | kr1shna: you'll need to convert the pdb/mobi file to epub using something like calibre or amazon's mobi-to-epub converter tool | 11:38.38 |
| kr1shna | tor8 i am asking about aportisdoc or palmdoc, i assumed it may work, epub files open fine, thank you for clarification | 11:39.39 |
| tor8 | kr1shna: afraid not, we only read EPUB2 files. | 11:42.04 |
| kr1shna | tor8 i am using small footprint mupdf mini for epub2 files, works like a charm, good to know about epub2 files | 11:49.14 |
| tor8 | Robin_Watts: in mudraw, I think the file level header/trailer logic is wrong. the first_page, output_append, output_file_per_page stuff is not doing things correctly and the code is too confusing for me to follow. | 12:37.41 |
| | it's outputting file level headers and trailers for each page | 12:37.52 |
| Robin_Watts | That sounds bad. | 13:24.14 |
| | Morning mvrhel_laptop | 14:52.49 |
| mvrhel_laptop | Morning | 14:52.55 |
| Robin_Watts | So, I picked up your bugfix. Looks good to me. | 14:53.19 |
| mvrhel_laptop | ok. I am fighting with another softmask related bug on that same file | 14:53.45 |
| Robin_Watts | I'm looking at page 7 now, where some alpha is going missing. | 14:53.57 |
| mvrhel_laptop | I am wondering about this | 14:53.59 |
| Robin_Watts | go on. | 14:54.06 |
| mvrhel_laptop | So this file has a soft mask, and the soft mask has an image that has a soft mask | 14:54.44 |
| | which is also an image | 14:54.59 |
| Robin_Watts | Urgh... | 14:55.02 |
| mvrhel_laptop | the later image being DeviceGray | 14:55.06 |
| | The former image being DeviceN | 14:55.13 |
| | The DeviceN image has colorants Cyan and Magenta only | 14:55.31 |
| Robin_Watts | I'm lost except to understand that "it's a nest of snakes". | 14:57.02 |
| mvrhel_laptop | The DeviceN color space has a FunctionType 0 that maps the DeviceN to DeviceCMYK for the tint transform, as well as the Separation defintions | 14:57.03 |
| | The spec is clear in that all Separation and DeviceN color spaces that exist in a softmask should use the alternate tint transform | 14:57.32 |
| | I am wondering if that is where things might be going wrong | 14:57.40 |
| | Getting ready to try to catch it there | 14:57.50 |
| | basically what I am seeing is the alpha in the final output is off | 14:58.02 |
| | it is nest of snakes | 14:58.38 |
| Robin_Watts | When we encounter a new softmask in the draw device, we create a new pixmap for it to render to. | 14:58.45 |
| mvrhel_laptop | right | 14:58.51 |
| Robin_Watts | I believe that pixmap is created with no spots. | 14:58.54 |
| | hence any rendering *will* be done using the alternates. | 14:59.12 |
| mvrhel_laptop | ok | 14:59.37 |
| | I did notice an odd thing | 14:59.42 |
| | Maybe not odd. Just surprising to me. The CMYK softmask image has an alpha channel (when the debug dump is done) which I assume is the softmask from the DeviceGray Image | 15:00.42 |
| Robin_Watts | I would imagine that that is how the alpha is introduced, yes. | 15:01.52 |
| mvrhel_laptop | ok | 15:01.58 |
| | well I will keep looking it over and try to further simplify the file | 15:02.29 |
| Robin_Watts | Did you get anywhere with the DeviceGray -> CMYK thing? | 15:03.31 |
| | (shoe3.pdf, or whatever it was). | 15:03.41 |
| | The bug I'm looking at now looks to be a case where constant alpha is not being applied to a group. | 15:06.14 |
| | I mention it in case it sounds like it might be related to what you're looking at. | 15:06.46 |
| mvrhel_laptop | Robin_Watts: oh yes. I need to look at that | 15:18.24 |
| | sorry | 15:18.26 |
| | This other thing was a rabbit hole | 15:18.33 |
| Robin_Watts | no worries. we have many issues still to go. | 15:19.37 |
| | I hadn't spotted there was a page 17 :( | 15:19.43 |
| mvrhel_laptop | yes. That is the page I used for working on spots in different trans color spaces | 15:25.33 |
| | That one I think we are sufficiently fine | 15:25.44 |
| | but it will take time | 15:25.56 |
| Robin_Watts | fz_blend_nonseparable_nonisolated is knackered with constant alpha, as far as I can tell. But I can't see why immediately. Still looking... | 16:16.12 |
| | mvrhel_laptop: Hi. Do you have a few minutes to talk? | 18:09.12 |
| mvrhel_laptop | Yes. definitely | 18:09.22 |
| Robin_Watts | I have found problems in fz_blend_nonseparable_nonisolated | 18:09.41 |
| mvrhel_laptop | ah | 18:09.51 |
| | imagine that | 18:09.56 |
| Robin_Watts | Firstly, the if (ba == 0) case should be if (ba == 0 && alpha == 255) | 18:10.19 |
| mvrhel_laptop | let me get there | 18:10.21 |
| Robin_Watts | cos if the alpha is not 255 we can't just simply copy stuff across. | 18:10.52 |
| mvrhel_laptop | ah good point | 18:11.08 |
| Robin_Watts | I'm sure that is an old long standing problem. | 18:11.26 |
| mvrhel_laptop | there should be an optimization for that case though of ba and alpha only | 18:11.30 |
| | ba == 0 and alpha != 255 | 18:11.40 |
| Robin_Watts | yeah, maybe. I'll worry about that after stuff works :) | 18:11.56 |
| mvrhel_laptop | yes | 18:12.01 |
| Robin_Watts | Next problem, in the complement bit... | 18:12.16 |
| | if alpha, then we need to combine sk and bk. | 18:13.03 |
| mvrhel_laptop | oh there is an n==4 in there still | 18:13.06 |
| | I thought I fixed that | 18:13.11 |
| | line 824 | 18:13.17 |
| Robin_Watts | ok, have fixed that. | 18:13.37 |
| mvrhel_laptop | thanks | 18:13.41 |
| | ok so now line 878? | 18:14.00 |
| Robin_Watts | yeah. | 18:14.22 |
| | In there, if alpha != 255, we can't just use the background or source values for black. | 18:14.52 |
| | we need to blend them. | 18:14.56 |
| | I have code for that here. | 18:15.07 |
| | That gets us a lot closer. | 18:15.12 |
| mvrhel_laptop | good point the blend value is supposed to be either sk or bk | 18:15.14 |
| | I screwed that up | 18:15.19 |
| | leaving out the actualy blending | 18:15.26 |
| Robin_Watts | easy mistake, especially because the way alpha is hidden in haa. | 18:15.44 |
| | so I have code that looks a lot more plausible, but my test file shows I'm not getting the c/m/y blend right. | 18:16.37 |
| mvrhel_laptop | I wonder if any this helps me. one of my blends in this mess is luminosity | 18:16.39 |
| Robin_Watts | let me put the commit so far up for you to poke at. | 18:16.54 |
| mvrhel_laptop | ok | 18:16.57 |
| | thanks | 18:16.59 |
| | let me know when it is there | 18:17.44 |
| Robin_Watts | It's there now. | 18:17.51 |
| mvrhel_laptop | ok | 18:18.10 |
| Robin_Watts | There is a test file, b3.pdf in my casper home dir too. | 18:18.18 |
| mvrhel_laptop | ok | 18:18.25 |
| Robin_Watts | dead simple file; a black rectangle filling half the page, with a green rectangle luminosity blended half on top of it with alpha .1 | 18:19.14 |
| | The cmyk values for the green are 60% 0% 100% 0% | 18:19.45 |
| | So at the end, in the bit that doesn't overlap the black rectangle, I expect to see values of 6% 0% 10% 0% | 18:20.29 |
| | (and acrobat agrees) | 18:20.44 |
| | but I'm only seeing 1% 0% 1% 0% | 18:20.55 |
| mvrhel_laptop | ok. let me fool with this then | 18:21.08 |
| | got everything | 18:21.21 |
| Robin_Watts | I suspect I'm doing something stupid in the maths, but I'm going algebra blind :) | 18:21.33 |
| mvrhel_laptop | np. its friday evening there.... | 18:22.03 |
| | ok. yes I am seeing the same thing | 18:25.36 |
| | This may very well be the source of one of my problems | 18:26.15 |
| | As something is coming out much lighter than it should be | 18:26.33 |
| | And I have Luminosity blending | 18:27.16 |
| Robin_Watts | Ah. The component values are having alpha applied to them BEFORE we premultiply. | 18:34.48 |
| | back in 10 mins. | 18:36.12 |
| mvrhel_laptop | oh you already found it.... | 18:36.17 |
| | you mean around line 856 | 18:44.45 |
| | there are too many alphas running around there | 18:44.57 |
| | here | 18:44.59 |
| | So right now, I understand there can be sa, ba, alpha, and hp all contributing to alpha | 18:46.02 |
| | sa and ba, I assume correlate to alpha_s and alpha_b in the spec. alpha, likely the group alpha, and hp a possible softmask alpha or the shape that has aa in it? | 18:47.12 |
| | not sure what h stands for... | 18:47.32 |
| | so ra is the result_alpha and should be computed using alpha_b+alpha_s-(alpha_s*alpha_b) | 18:49.35 |
| | line 793 sort of looks like this | 18:51.12 |
| Robin_Watts | h = sHape. | 18:53.46 |
| mvrhel_laptop | ah ok | 18:54.11 |
| Robin_Watts | ha = shape value at a pixel (coverage, so between 0 and 255) | 18:54.17 |
| | haa = ha * a = ha * alpha | 18:54.27 |
| | I suspect the central blends should be using ha not haa. | 18:54.38 |
| | but I don't have time to experiment now. | 18:54.49 |
| | Helen is calling for me. | 18:54.55 |
| mvrhel_laptop | Robin_Watts: no probelm | 18:55.02 |
| Robin_Watts | I will try to look over the weekend unless you find anything! | 18:55.10 |
| mvrhel_laptop | I am about to get myself in trouble here | 18:55.13 |
| | :) | 18:55.15 |
| | sort of like tearing something apart and having parts left over | 18:55.31 |
| Robin_Watts | Yeah, but that's the way we roll in MuPDF :) | 18:55.46 |
| | I'd better go, or I'll get yelled at. sorry! | 18:56.03 |
| mvrhel_laptop | np | 18:56.06 |
| | have a good night | 18:56.08 |
| | tell helen hello | 18:56.12 |
| | and blame it on me | 18:56.18 |
| Robin_Watts | hey | 23:17.42 |
| 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. | 23:17.42 |
| Robin_Watts | mvrhel_laptop: hi | 23:17.53 |
| mvrhel_laptop | Helo | 23:17.59 |
| Robin_Watts | Did you get anywhere? | 23:18.06 |
| mvrhel_laptop | not yet. just getting started again. had a pile of distractions | 23:18.24 |
| Robin_Watts | ah, ok. I suspect that replacing ha for haa in the middle bit of the routine might solve it. | 23:19.07 |
| | (i.e. the calculation of ra is correct, but all the color stuff should use ha, not haa (and baha rather than bahaa etc)). | 23:19.45 |
| | I'll give that a whirl tomorrow if you have other stuff to be getting on with. | 23:20.05 |
| | but I have to get up in less than 8 hours, so I'm off to bed now :) | 23:20.19 |
| mvrhel_laptop | Robin_Watts: that sounds like it might be right. ok. good night. I will let you know if I do anything with this | 23:20.35 |
| Robin_Watts | Ta. I'll check logs in the morning. | 23:20.54 |
| | Forward 1 day (to 2017/08/05)>>> | |
Log of #mupdf at irc.freenode.net.