| | <<<Back 1 day (to 2013/04/18) | 2013/04/19 |
| ray_laptop | henrys: sorry I missed your follow up comment regarding duplexing. | 00:47.22 |
| | I agree that it is perplexing (unless we do the entire job in duplex mode multiple times) | 00:47.52 |
| | at the very least, if non-collated is OK, we need to do the front and the back, then the front and back again until we have enough copies. But that _still_ requires retaining at least one page (more likely two) | 00:49.58 |
| | then we move on to the next pair of pages. | 00:50.17 |
| | the "pcx2up" device sort of does this but save_page requires clist mode and so PXL is out of the question | 00:52.01 |
| | it puts two pages out on the same image, but a variant for raster mode PCL wouldn't be too hard | 00:52.32 |
| | BGPrint now works with -o x%d.ppm as well as with NumCopies > 1. One last test then clusterpush -- the prior with NumRenderingThreads=4 | 03:26.53 |
| | changes for BGPrint were rather more extensive than I thought they would be (refactoring without messing stuff up was the hard part), and making sure that the foreground doesn't mess up the background particularly w.r.t. the OutputFile | 06:01.25 |
| | the 'sketch' I sent around is still basically the same. As usual, "the devil is in the details" | 06:02.37 |
| | time for sleep... | 06:03.47 |
| kens | Hmm, you r last commit failed to build chrisl | 08:45.52 |
| chrisl | Oh, not again :-( | 08:46.02 |
| kens | I guess I'll wait a minute before pulling :-) | 08:46.08 |
| | compilefail on all nodes | 08:46.24 |
| | configure: error: UFST source directory not found | 08:47.18 |
| | ---pmake_start--- | 08:47.19 |
| | make: *** No targets specified and no makefile found. Stop. | 08:47.19 |
| | ---pmake_end--- | 08:47.19 |
| | make: *** No targets specified and no makefile found. Stop. | 08:47.19 |
| chrisl | kens: I've zapped that commit, you can pull if you want | 08:52.29 |
| kens | No rush, I've got a test running | 08:52.44 |
| chrisl | I really wish the UFST configure option had been implemented the same as all the others :-( | 08:54.20 |
| kens | I'm surprised it wasn't | 08:54.34 |
| chrisl | Well, it wasn't me that added it....... | 08:54.56 |
| kens | Me neither :-) | 08:55.02 |
| chrisl | My predecessor | 08:55.17 |
| chrisl_r61 | Aha! I committed the wrong change - the change I really meant to use was "stashed". It makes sense now..... | 09:08.42 |
| sebras | forgot to check the irclogs yesterday. :p | 09:28.30 |
| Robin_Watts | tor8: ping | 09:30.40 |
| tor8 | Robin_Watts: morning | 09:31.53 |
| Robin_Watts | Morning | 09:32.09 |
| | There are 5 commits on robin/master. | 09:32.14 |
| | 2 are ready to go. | 09:32.22 |
| | The third is ready to go, but it's purely to satisfy my sense of neatness, so we could drop it if you object. | 09:32.41 |
| | tor8: So, I'm at my wits end over this problem with missing pixels. | 09:43.57 |
| | I've tried lots of things, but none of them work quite right. | 09:44.14 |
| tor8 | fz_bound_mesh_typeX word order? | 09:44.18 |
| Robin_Watts | tor8: I can rejig that if you want. | 09:44.37 |
| | at the moment they match the fz_mesh_type1_process functions from earlier in the same file | 09:45.18 |
| tor8 | 3 patches up to and including bound-path-accurate look good, but do please do change the word order | 09:45.25 |
| Robin_Watts | will do. | 09:45.42 |
| tor8 | maybe those should be renamed too then! | 09:45.52 |
| Robin_Watts | will do, but as a separate commit. | 09:46.13 |
| | So, my latest plan with the white pixels was to tweak the triangle plotting. | 09:46.51 |
| | so that when it loads each line, it knows whether it is a left hand edge or a right hand edge. | 09:47.16 |
| tor8 | and the fourth one is okay too (the reshuffling of arguments), but I'd have done it as 1,2,3 :) | 09:47.51 |
| | or 3,1,2 | 09:48.13 |
| Robin_Watts | eh? | 09:48.56 |
| | that misses the point. | 09:49.03 |
| | Suppose i have a quad, where points are labelled in clockwise order 0,1,2,3 | 09:49.27 |
| | I can split that into 2 triangles. Let's say the first one is 0,1,3 | 09:50.02 |
| tor8 | actually, I'd do the quad as two tris with 0,1,2 then 0,2,3 | 09:50.14 |
| | but that'll probably make rasterization differences due to the gouraud shading direction being different in non-"planar" quads | 09:51.06 |
| Robin_Watts | The reason I want to pick the second one as 2,1,3 (or 1, 3, 2 or 3,2,1) is that when we have a series of patches that abut one another, we end up traversing all the edges in the same direction. | 09:51.10 |
| tor8 | hang on I need some pen and paper to plot that out! | 09:51.51 |
| Robin_Watts | IF we do 0 -> 1 -> 2. we end up traversing the shared edge as 2 -> 0 for instance. | 09:52.08 |
| | If we then do 0 -> 2 -> 3, we traverse the edge in the opposite order. | 09:52.26 |
| | 3 -> 2 -> 0 would be better. | 09:52.40 |
| kens | Windows wants a rebott.... | 09:54.37 |
| tor8 | Robin_Watts: there is no reason for making the edges the same direction, in practical terms | 09:55.12 |
| Robin_Watts | tor8: In general there is. | 09:55.35 |
| tor8 | what your patch does however is make the two triangles of the same quad have opposite winding... | 09:56.15 |
| Robin_Watts | When we walk from A to B we might not hit the same points as we do when we walk from B to A. | 09:56.32 |
| tor8 | the edges are sorted vertically when scan converted | 09:56.50 |
| | y0 = min(v0.y, v1.y) etc | 09:57.06 |
| Robin_Watts | That's true for bresenham, and even more true for the fixed point approximation we do. | 09:57.08 |
| | but yes, in this case, it makes no odds. | 09:57.17 |
| | but when I come back to read the code in another years time, I will once again say "Aha! We're traversing the edges in a different order! That'll be the problem." | 09:57.51 |
| tor8 | right, in bresenham the error term would differ when going from A to B vs B to A | 09:58.00 |
| | but for fixed point it should be the same | 09:58.05 |
| Robin_Watts | tor8: No, cos fixed point is not accurate. | 09:58.15 |
| | bresenham (implemented correctly) is more accurate than fixed point. | 09:58.29 |
| tor8 | oh. yes. of course. | 09:58.39 |
| | bresenham needs the correct initial error term to do that though! | 09:58.50 |
| Robin_Watts | As I say, this is an aesthetic one. | 09:59.04 |
| tor8 | and we currently also round to integer coordinates | 09:59.15 |
| Robin_Watts | Right. | 09:59.22 |
| tor8 | the flipped winding offends me (but that's just my baggage of having done backface culling on triangles in software 3d rasterizers...) | 09:59.50 |
| | so did you get a chance to try out not rounding to integers when plotting the triangles? | 10:00.09 |
| Robin_Watts | tor8: I tried bloody everything yesterday, all to no avail :( | 10:00.24 |
| tor8 | :( | 10:00.37 |
| Robin_Watts | I think it's time to let someone else have a stare in case I am doing something silly. | 10:00.49 |
| tor8 | I'd have assumed that more accurate rasterizing would solve the T-join issue | 10:00.58 |
| Robin_Watts | Let me mail you the full and cut down files, and I can tell you what my latest attempt was. | 10:01.11 |
| tor8 | if indeed that is the case with the mesh at hand | 10:01.12 |
| | sure. and you can have a go at 693845 if you want. | 10:01.52 |
| | I just don't understand what the hell is going on there. I've stared at the code and the specs and I just can't see anything we're doing wrong... | 10:02.14 |
| | must've missed some part of the spec or other | 10:02.21 |
| Robin_Watts | tor8: I will have a look at that, sure, but I should look at the rare multithreaded crashes that the customer is getting first :( | 10:03.40 |
| tor8 | Robin_Watts: sure. getting vertical text layout wrong is Bad⢠and should be fixed with priority even if it's not a customer. | 10:04.28 |
| | but do let customer bugs take priority | 10:04.37 |
| Robin_Watts | So, my latest plan was to 'explode' the triangles a bit when plotting them. | 10:07.58 |
| | I basically wanted to move the left hand edges left a bit, and the right hand edges right a bit to achieve the 'any part of a pixel' thing. | 10:08.49 |
| | When we 'load an edge' we set up the current position and the step. | 10:09.58 |
| | All our edges head 'downwards' due to the ordering we do. | 10:10.30 |
| | I was planning that if we were a left hand edge, and we were heading left, I'd do the first step of the bresenham immediately. | 10:10.54 |
| | Likewise if we were a right hand edge and we were heading right. | 10:11.08 |
| | That should have had the effect of 'thickening' the shape. | 10:11.26 |
| | But when I do that, the missing pixels get worse :( | 10:11.33 |
| | tor8: You may need to set SUBDIV to 1 to clearly see the white pixels problem. | 10:18.10 |
| tor8 | 14k vertices in that mesh. ick! | 10:28.42 |
| | 1998 unique ones, 7200 faces | 10:32.32 |
| Robin_Watts | yeah. | 10:36.36 |
| | I added code to output the meshes as postscript. | 10:36.54 |
| | and they look plausible, but I haven't dived down to the bit level. | 10:37.10 |
| tor8 | converting it into a 3d mesh and loading it up in blender shows it to be a very neat and regular grid, and I can see where the T-joins are | 10:39.07 |
| | exactly where the white pixels appear too, so that's good to know | 10:39.29 |
| | sadly, they are pretty damn near horizontal lines | 10:40.53 |
| | but if you rotate 15 degrees (with the 'a' key in mupdf) you can clearly see the white lines | 10:41.10 |
| | quite regularly too | 10:41.14 |
| Robin_Watts | tor8: Brilliant! So we've confirmed it's a file problem. | 10:41.28 |
| | That's nice. | 10:41.33 |
| tor8 | looks dreadful! | 10:41.34 |
| | the pixel snapping is terrible :( | 10:41.47 |
| Robin_Watts | The question is, is there anything we can do to help with the problem | 10:41.49 |
| | tor8: oh, you've outputted stuff *after* the pixel snapping ? | 10:42.14 |
| tor8 | no no, but the rendering pixel snaps so makes this one look dreadful if rotated | 10:42.41 |
| | terrible wobbly lines | 10:42.48 |
| Robin_Watts | Ah, I see. | 10:42.59 |
| | ok, I have renamed those functions. | 10:43.48 |
| | Did we reach a conclusion with the reordering of the vertexes? | 10:44.00 |
| | I'm now thinking that just putting a comment in there may be best. | 10:44.10 |
| tor8 | Robin_Watts: I don't really care, but do put a note about the winding and edge ordering | 10:44.55 |
| | I don't really care about the order, that is. | 10:45.12 |
| | your suggestion is fine, just make a note of what it is and that it's really not relevant at the time of writing | 10:45.27 |
| | since we'll always scan top-to-bottom | 10:45.59 |
| | Robin_Watts: http://ghostscript.com/~tor/stuff/mesh3.blend | 10:48.53 |
| | that shows the structure of the mesh pretty neatly if you just load it up | 10:49.09 |
| Robin_Watts | I don't have blender. | 10:49.24 |
| tor8 | lots of overlapping triangles too | 10:51.05 |
| | http://ghostscript.com/~tor/stuff/mesh3.png | 10:52.46 |
| Robin_Watts | Right. That's kinda what I saw in the postscript. | 10:53.22 |
| tor8 | yeah. blender lets you select and manipulate edges and faces so you can prod and poke at it :) | 10:53.57 |
| Robin_Watts | yes. very smart to use that. | 10:54.07 |
| | It didn't occur to me. | 10:54.11 |
| tor8 | you could probably do the same with inkscape, but seeing as it's a mesh blender came to mind :) | 10:54.37 |
| Robin_Watts | ok, updated versions of those commits. | 10:54.44 |
| | The customer is quite keen to try something with reducing the accuracy of mesh rendering if rendering is taking a long time. | 10:55.29 |
| | Hence the second to last commit on my repo. | 10:56.23 |
| | but it's imperfect as it will generate more 'T-joins' and hence more potential white pixels. | 10:56.49 |
| | Morning paulgardiner | 10:56.54 |
| paulgardiner | Hi Robin_Watts | 10:57.02 |
| Robin_Watts | tor8: I'm off for a run. I'll push those commits when I get back unless you tell me different. | 10:58.29 |
| tor8 | Robin_Watts: that batch of 4 are good to go | 10:58.32 |
| Robin_Watts | tor8: or I'll do it now :) | 10:58.40 |
| tor8 | I'm not sure I grok the logic of the extent/subdivision one. you can explain it after your run. | 10:58.56 |
| Robin_Watts | I find the bbox of each patch. | 10:59.19 |
| tor8 | but given the t-joins we should probably pick the subdiv on a per-mesh rather than per-patch level | 10:59.24 |
| Robin_Watts | if the bbox < 2 pixel, then there is no point in dividing more than once. | 10:59.43 |
| | if the bbox < 4 pixels then there is no point in dividing more than twice. | 10:59.56 |
| tor8 | you're assuming user space is pixels there? | 11:00.02 |
| Robin_Watts | tor8: At this point, we're in device space. | 11:00.15 |
| | unless I've missed something crucial :) | 11:00.42 |
| tor8 | oh right. forgot you changed the patch tesselation to happen at draw time. | 11:00.43 |
| | right, then I understand. | 11:00.48 |
| | hence the process_mesh painter thingy | 11:00.57 |
| Robin_Watts | picking on a per-mesh level is hard. | 11:01.17 |
| | cos we have no way of knowing the bbox for the mesh. or the number of patches in a mesh. | 11:01.35 |
| | or how big the biggest patch might be. | 11:01.47 |
| tor8 | yeah. we'd have to scan all the patches and do the subdiv_level_for_patch before starting to render | 11:02.33 |
| | and that means decoding the stream multiple times :( | 11:03.14 |
| Robin_Watts | decoding the stream ain't necessarily the biggy. | 11:05.14 |
| | the biggy is in the subdivisions etc. | 11:05.24 |
| | and we could cache the result in the shading maybe. | 11:05.37 |
| sebras | Robin_Watts: so this is just about limiting the extent to which we subdivide..? | 11:23.13 |
| tor8 | Robin_Watts: I think I'm just going to rip out the core triangle rasterizer and redo it with full fixpoint precision everywhere | 12:20.26 |
| Robin_Watts | tor8: bresenham would be nicer | 12:23.33 |
| | too slow :( | 12:23.36 |
| | sebras: There are 2 problems here. | 12:23.48 |
| sebras | ping. | 12:23.56 |
| | eh. pong. | 12:24.04 |
| Robin_Watts | The first one reported was that we subdivide more than we need to. That's what I did the patch bbox thing for. | 12:24.22 |
| sebras | yes, that one make sense. even to me. | 12:24.35 |
| | and the 2nd? | 12:24.37 |
| Robin_Watts | But in doing that I uncovered another problem, namely that for some meshes (regardless of sub div) we get white pixels. | 12:25.13 |
| | Now, it seems that this second is down to bad patch data. | 12:25.21 |
| | but it would still be nice if we coped a bit better. | 12:25.29 |
| sebras | right, so basically the nodes are not on the exact same coords. | 12:25.52 |
| Robin_Watts | We have 2 small patches next to one large patch. | 12:26.11 |
| | and the small patch midpoint does not necessarily exactly align with the 'middle' of the 2 small patches. | 12:26.50 |
| | That's what tor calls a t-join. | 12:26.57 |
| sebras | big patch midpoint, but ok. | 12:27.20 |
| Robin_Watts | oops, yes. | 12:27.41 |
| sebras | so that means that the midpoint of the large patch might have rounding errors or something like it that was not taken into account when placing the edge nodes of the 2 smaller patches. | 12:28.10 |
| Robin_Watts | sebras: right. | 12:28.20 |
| sebras | how are you going to fix this? | 12:28.20 |
| Robin_Watts | My plan, which I have so far utterly failed to implement was to change to the 'any part of a pixel' filling rule. | 12:28.51 |
| | if any part of a device destination pixel is touched, then fill the whole pixel. | 12:29.04 |
| | currently we only fill a pixel if the centre of that pixel is covered. | 12:29.22 |
| sebras | right. | 12:29.33 |
| Robin_Watts | That would effectively expand all patches by 1/2 pixel on average, and will hence close most of the gaps. | 12:29.46 |
| | It costs us overwrites at the edge of pixels, but for our purposes we don't care about that. | 12:30.12 |
| | s/pixels/patches/ | 12:30.34 |
| sebras | right, but the likelihood of two adjacent patches not having the same colors at two adajcent edges is probably quite small.. | 12:33.47 |
| Robin_Watts | sebras: Indeed. | 12:34.05 |
| | The case where it would matter is if we were plotting with alpha or something, cos then all the triangle boundaries would be blended twice. | 12:34.28 |
| | but as we always plot meshes opaquely and then blend them as a whole for transparency, that doesn't occur. | 12:34.58 |
| sebras | I seem to recall that we never render with alpha in this situation. I might be wrong though. | 12:35.12 |
| Robin_Watts | you're right. we never render with alpha in this situation. | 12:35.31 |
| sebras | so the fixpoint stuff is really unrelated, and purely an optimization. | 12:36.32 |
| Robin_Watts | the fixedpoint stuff is just how tor chose to implement it. | 12:37.28 |
| | Fixedpoint stuff has rounding issues potentially which could add up over large distances. | 12:37.57 |
| | That's why bresenham is better. | 12:38.04 |
| sebras | we use floats today, no..? | 12:42.43 |
| | or maybe those were removed to optimize for ARM... | 12:42.57 |
| sebras | has been out of touch with mupdf for too long evidently. | 12:43.10 |
| Robin_Watts | sebras: We subdivide the patches in floating point. | 12:50.06 |
| | Then we convert to fixedpoint for the actual plotting. | 12:50.17 |
| | There is an argument to say we should subdivide in fixed point too. | 12:51.00 |
| | but that would require more extensive changes to the mesh plotters other than 6 and 7. | 12:51.21 |
| | but it's still a possibility. | 12:51.30 |
| kens | Oh joy: | 13:10.33 |
| | http://www.reuters.com/article/2013/04/18/us-faa-flightdelays-idUSBRE93H1C620130418 | 13:10.34 |
| | delays strating SUnday.... | 13:10.44 |
| | Miami is mentioned as an airport likely to suffer delays late in the article | 13:11.35 |
| wart_ | hi folks. I'm trying to convert a high quality pdf file to a lower quality one that doesn't basically destroy my mupdf when it tries to read it. | 13:21.21 |
| | I've tried various tricks, but I'm not sure they are working. | 13:21.28 |
| | For instance, one trick I tried was this: | 13:21.33 |
| | ~/docs/peterjh/proj/Habitus $ gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf test.pdf | 13:21.51 |
| | that produced a bigger output.pdf file than the input file (test.pdf) in terms of filesize, but in terms of load times it seems to be about the same. | 13:22.10 |
| kens | Don't use -dPDSETTINGS as that changes a boat load of settings. You really need to assess why your files are so large, or why they take a long time to laod. | 13:31.42 |
| | One likely culprit is use of transparency, partciularly if you created the PDF file from Cairo nad doube particularly if it was an old version. | 13:32.23 |
| | Can you share an example file ? | 13:32.42 |
| wart_ | kens: i'll try | 13:36.59 |
| Robin_Watts | kens: great :( | 13:37.24 |
| kens | the flights thing Robin_Watts ? You're likely to get caught for Boston too :-( | 13:37.45 |
| Robin_Watts | yeah. | 13:37.51 |
| | I did idly wonder about just driving down from boston to miami. | 13:38.10 |
| | helen said I was being silly. | 13:38.15 |
| kens | Not so sure now.... | 13:38.29 |
| | Maybe even a boat | 13:38.35 |
| | Or a train, or Greyhound (if you're a masochist) | 13:39.11 |
| Robin_Watts | Harley :) | 13:39.26 |
| kens | Yeah! :-) | 13:39.34 |
| wart_ | http://antiopus.trilidun.org/test.pdf | 13:40.09 |
| | oh wait | 13:40.21 |
| | no space on device | 13:40.23 |
| kens | Gave me an error when I tried to dowload it ;-) | 13:40.36 |
| Robin_Watts | paulgardiner: upload progress? | 13:41.35 |
| paulgardiner | Only 4 3/4 hours to go. :-) | 13:42.16 |
| Robin_Watts | ok, so I won't be looking into it today :) | 13:42.42 |
| kens | SOunds liek a big upload | 13:42.50 |
| paulgardiner | 1.5 GB | 13:43.09 |
| | Limiting it to 60KB/s to avoid killing my internet | 13:43.45 |
| kens | ah, that explains the slowness | 13:45.12 |
| wart_ | kens: it is 5.7M and it is now there | 13:47.46 |
| | thanks in advance, btw | 13:47.56 |
| Robin_Watts | paulgardiner: How fast is your upload speed? | 13:48.07 |
| paulgardiner | 1000 Kb/s | 13:48.29 |
| Robin_Watts | crumbs. | 13:48.36 |
| paulgardiner | So maybe 100 - 120 KB/s | 13:49.16 |
| kens | wart_ : sorry was fetching coffee, I'll got get it now | 13:51.35 |
| | Well,its an 80 page document.... | 13:51.54 |
| wart_ | kens: i did pdftk from a 500 pg document :-) | 13:52.27 |
| kens | Seems like ite pretty much entirely composed of images | 13:52.39 |
| wart_ | yeah :p | 13:52.44 |
| kens | With invisible text on top | 13:52.54 |
| wart_ | so maybe i can pop out those images, make them 'less quality' and then remake the pdf? | 13:52.56 |
| kens | You shoudl be able to downgrade the resolution of the images yes | 13:53.14 |
| | ive me a few minutes htough | 13:53.25 |
| | Give* | 13:53.30 |
| paulgardiner | Should I be moaning at Zen? I thought 1 Mb/s was pretty much as fast as you can expect unless you have fibre. | 13:53.37 |
| kens | depends how far away your exchage is | 13:54.17 |
| | I get better than that, buyt I live in town, and near the exchange | 13:54.28 |
| | Oh, and on copper, not aluminium | 13:54.42 |
| paulgardiner | Pretty close. I get very nearly the full 20Mb/s downstream | 13:55.15 |
| kens | That seems like the best you're going to get then, unless you go symmetric or fibre (either expensive or not available, depending) | 13:55.56 |
| paulgardiner | kens: What do you get upstream? | 13:56.33 |
| kens | paulgardiner : varies a lot, I'd have to check to see what it is today | 13:56.50 |
| | wart_ : your file is 106Mb uncompressed | 13:57.00 |
| Robin_Watts | kens: You get better *upload* than that? | 13:57.15 |
| kens | SO I'd guess your images are fairly high resolution | 13:57.21 |
| | Robin_Watts : yes, can do | 13:57.28 |
| | but not all the time | 13:57.35 |
| | I get a lot of variance | 13:57.41 |
| wart_ | kens: yeah; i have a lot of files like this. I'd rather lose some of the high quality and get quicker performance out of mupdf | 13:58.24 |
| kens | the images are jpx encoded, that's a very expensive filter for decoding | 13:58.46 |
| wart_ | so a general conversion solution would be awesome! | 13:58.47 |
| kens | I suspect the reason its faster (but bigger) after going through pdfwrite is that we *mever* JPX encode images, because there are patent/licncing issues | 13:59.26 |
| | So the image is less well compressed, but the filter is quicker to decompress it. | 13:59.47 |
| wart_ | kens: well it isn't (noticably) faster (although it is bigger) after going through pdfwrite, fwiw. | 14:00.07 |
| kens | Well there is still a lot of aimge data. | 14:00.23 |
| | Each page seems to consist of 2 images | 14:00.46 |
| henrys | paulgardiner:are you good with travel and expense report stuff? | 14:01.40 |
| kens | wart_ : one of the images is the same on every page.... | 14:02.13 |
| | Oh actually no it isn't, the file reuses the same lable but with a different image every time, weird | 14:02.51 |
| | Ah, one of the images also has /Interpolate treu. | 14:03.45 |
| paulgardiner | henrys: Yesish. Took me a while to get around to claiming for the March flight, but I have now. Haven't put in the claim for the upcoming one yet, but I'll probably do so at the weekend. | 14:04.24 |
| kens | wart_ : the backgroudn of the page is drawn separately to the 'text' part of the page, which is why there are 2 images | 14:05.16 |
| henrys | paulgardiner:let one of us know if you have any problems. | 14:05.27 |
| paulgardiner | Thanks henrys. Will do. | 14:05.51 |
| wart_ | kens: yeah, i'm not sure who constructed these pdfs -- they were archived for archive.org via a university scanning project | 14:05.55 |
| | presumably they wanted the 'best' quality period | 14:06.01 |
| | and assumed that everyone had enormous mainframes to render them :-) | 14:06.22 |
| kens | Hmm, I'd have said that the grey background obscured the text, rather than improving it.I can understand the need to keep it if its a legal document (evidence purposes) but well, its not my PDF.... | 14:06.40 |
| wart_ | well i plan on 'keeping' the fancy pdf around for close reading, but i need something for fast reading | 14:07.56 |
| kens | There's no easy way to strip out the background image, or I would suggest that. | 14:08.28 |
| wart_ | it is a 18th text of John Duns SCotus, FWIW | 14:08.29 |
| | 18th-century | 14:08.38 |
| Robin_Watts | paulgardiner: You should mail miles and tell him your flight itinerary etc, if you haven't done so. | 14:08.51 |
| paulgardiner | oh ok. I'll do that now. | 14:09.16 |
| henrys | paulgardiner: now that I look you aren't on the everybody list so you've probably missed some relevant emails | 14:18.26 |
| kens | wart_ : I think a large part of your problem is that this file involves transparency. THe images making up the page are ocmposited together. Full page transparency is always going to lead to poor performance | 14:18.27 |
| tor8 | Robin_Watts: I'll start with floats, bresenham would be nicer but I'm not sure how it performs compared with fixed point on modern cpus | 14:19.16 |
| kens | dir out.pdf | 14:19.55 |
| | oops.. nobody saw that | 14:20.02 |
| | wart_ : try setting -dCompatibilityLevel=1.3 -r96 and see if that is faster | 14:21.01 |
| paulgardiner | henrys: anything particular that might be important? | 14:21.42 |
| kens | I imagine it will be, because Ghostscript and pdfwrite will 'flatten' the transparency into a single image. Which will be bigger but should process faster (the GS processing will be slow) | 14:21.54 |
| | You can meddle with teh resolution (-r parameter) to find an acceptable readability vs size | 14:22.24 |
| wart_ | kens: ok | 14:25.26 |
| | i'll give it a try | 14:25.28 |
| henrys | paulgardiner:I looked just some followup from last meeting you might have missed. I don't think it is particularly important, I'll add you to the list though. | 14:25.54 |
| kens | -r130 looks like a mnimum readability to me | 14:25.58 |
| paulgardiner | henrys: ta | 14:26.07 |
| tor8 | kens, wart_: sounds like the source may have been a djvu file (or constructed the same way, with two images consisting of background and text, and then invisible OCR text) | 14:26.55 |
| Robin_Watts | tor8: Sure. If you can get something working properly with floats, we can look at optimisations later. | 14:27.27 |
| kens | Yes, that's exactly how it is constrcuted, the wrinkle being that the background and image text are composited with an SMask. SInce its the whole page, that means a lot of transparency blending | 14:28.03 |
| tor8 | kens: unless it's using a funky blend mode, that should not really have a performance penalty in mupdf | 14:30.17 |
| | downscaling fullscreen high-res images is very slow though, and not much we can do there without sacrificing image rendering quality | 14:30.44 |
| | (we treat smasks and non-rectangular regular clips exactly the same in mupdf, so it's got to be fast!) | 14:31.40 |
| kens | Well, I'm not sure where the time is taken up tor, I have't tried MuPDF< but two large images, encoded wiht JPX ande tehn composited seems like a recipe for slowness | 14:39.34 |
| Robin_Watts | Damn. Lost vision. I need to go take a pill and lie down for a bit. | 14:40.27 |
| ray_laptop | kens: when flattening to an image with gs, it is important to use TextAlphaBits=4 GraphicsAlphaBits=4 -- these are ordinarily not used with pdfwrite, but should help when using the pdfwrite compositor | 16:21.28 |
| | pdf14 compoositor, sorry | 16:21.44 |
| kens | ray_laptop : was more interested initially in trying to see where the problem lies | 16:21.55 |
| ray_laptop | kens: right | 16:22.02 |
| kens | In this case textalphabits will have no effect, since there is no text | 16:22.48 |
| ray_laptop | kens: -dDOINTERPOLATE *might* improve the quality if going down to a much lower res. GraphicsAlphaBits doesn't help with images, either | 16:25.53 |
| kens | THe image is already interpolated | 16:26.22 |
| | OK Off now, goodnight all | 17:04.59 |
| mvrhel_laptop | ok this unpacking stuff of the image data in the high level clist images for color monitoring for our customer is a headache | 17:07.33 |
| Robin_Watts | paulgardiner: How goes the upload ? | 17:33.31 |
| paulgardiner | 50 minutes to go | 17:34.53 |
| ray_laptop | Got it. BGPrint now works with NumCopies > 1 and NumRenderingThreads > 1. | 17:50.38 |
| Robin_Watts | nice. | 17:50.48 |
| ray_laptop | Robin_Watts: I'm going to do a clusterpush with BGPrint=true as the default. Would you like to look over the changes ? | 17:51.22 |
| | or anyone else that wants to, of course. I thought of Robin_Watts since he has mucked about in multi-threaded stuff before | 17:52.04 |
| Robin_Watts | ray_laptop: I'm in multi-threading hell in mupdf at the moment (and just recovering from a migraine) | 17:52.37 |
| | so I won't get to look today, but I will try to look at some point. sorry. | 17:52.58 |
| ray_laptop | Robin_Watts: np. | 17:53.15 |
| | Robin_Watts: that's about the 6th circle or so, iirc | 17:53.54 |
| Robin_Watts | Just call me Dante. | 17:57.33 |
| henrys | Robin_Watts:hope you are feeling better. | 18:04.58 |
| Robin_Watts | henrys: going to walk the dog to the shop to try to clear the fuzz out of my head. think I'm over the worst of it. | 18:05.43 |
| henrys | Robin_Watts:let me know if you want to shoot a message to Raed that you'll get back to it Monday. | 18:06.13 |
| ray_laptop | spoke too soon. Even though background printing with multi-threaded rendering with NumCopies > 1 works, I seem to be leaving empty clist files laying around. :-( | 18:17.35 |
| | that and I get a strange warning out of VS 2008: on a line with "return_error(gs_error_VMerror);" I get: warning C4047: 'return' : 'gx_device *' differs in levels of indirection from 'int'c:\Artifex\agit\ghostpdl\gs\base\gxclthrd.c119 | 18:20.47 |
| Robin_Watts | henrys: I forgot to copy him my last support message. I forwarded that to him earlier with an apology. | 18:24.22 |
| | so the ball is in his court. | 18:24.36 |
| henrys | Robin_Watts: great | 18:27.24 |
| ray_laptop | grr... build problem on peeves. I did make debugclean ; make debug and I'm getting "No rule to make target `/libtiff/tif_config.h', needed by `debugobj/tif_config.h'". I had re-run autogen.sh prior to that | 18:45.57 |
| henrys | ray_laptop:yeah chrisl sent email about that. | 18:46.27 |
| | have you created new files? | 18:46.38 |
| ray_laptop | seems to be missing the directory prefix for libtiff. | 18:46.47 |
| | henrys: this is just a git co master, updated to origin/master | 18:47.17 |
| henrys | ray_laptop:yes see his mail I used git clean but if you've created new files that would be not what you want. | 18:47.27 |
| ray_laptop | peeves is just my linux testbed, so I can do a git clean I guess | 18:48.14 |
| | I do get "configure: exit 1" from my autoconf.sh run. | 18:52.38 |
| henrys | you did git clean -f -x -d ? | 18:52.56 |
| ray_laptop | no, I just had -f It did a lot more cleaning with -x -d (not surprisingly) | 18:54.23 |
| | at least configure exited normally this time | 18:55.16 |
| | Windows didn't need it :-/ | 18:56.54 |
| mvrhel_laptop | oh crap. I have to worry about decoding also in the high level image data | 21:17.12 |
| ray_laptop | mvrhel_laptop: decode is usually standard or inverse. Maybe you can check the decode for the image in clist_begin_typed_image and punt to non-HL images if you are doing 'gray detect' and the decode is funky. | 21:30.33 |
| | mvrhel_laptop: but thinking about it. as long as the components are known, all the checking cares about is equal values, not the polarity, right ? Decode applies to all components equally | 21:32.07 |
| | mvrhel_laptop: assuming that the Decode array has all pairs of values the same. Once again, punt on funky decode e.g. [ 0 1 0 2 0 3 ] | 21:34.19 |
| | I don't think I've ever seen a file with that (but since it probably works when rendering, I'm not sure I'd notice) | 21:35.33 |
| mvrhel_laptop | ray_laptop: well, each component can have its own decode | 21:50.52 |
| | some could be inverted others not | 21:51.00 |
| | values can also be biased | 21:51.47 |
| | ray_laptop: I am going to go ahead and punt on any crazy decode cases | 22:26.00 |
| | otherwise this gets to be too much | 22:26.06 |
| | I think it is better to worry about the more common case | 22:26.17 |
| | Forward 1 day (to 2013/04/20)>>> | |
IRC Logs
