| | <<<Back 1 day (to 2011/08/28) | 2011/08/29 |
| henrys | thanks robin_watts did you purchase it at some point? | 00:26.23 |
| | indeed our font does seem to be wrong. | 00:49.57 |
| Robin_Watts | Gah. Mupdfs 'compression bomb' code strikes again. | 11:28.11 |
| kens | does not understand | 11:35.45 |
| Robin_Watts | mupdf has code that spots "a compression bomb", and refuses to handle the file. | 11:42.18 |
| kens | oh. | 11:42.25 |
| tor8 | kens, Robin_Watts: yeah, that compression bomb stuff has caused more trouble than it's worth IMO. | 12:23.58 |
| Robin_Watts | Looks like -t either isn't getting through to the bmpcmp on the cluster, or bmpcmp isn't handling it right :( | 12:24.47 |
| | marcosw_: Are you still on european time ? | 12:30.55 |
| marcosw_ | I am. I'll be here all week. | 12:31.05 |
| Robin_Watts | Is there any way to see the logs from a bmpcmp job ? | 12:31.22 |
| | Specifically, I want to look at the bmpcmp invocations - don't even know if that's logged. Probably not I fear. | 12:31.53 |
| marcosw_ | The logs from the last run job are in /home/regression/cluster/{machine_name}.log | 12:32.28 |
| | the invocations of the jobs are in /home/regression/cluster/jobs | 12:32.40 |
| | note that these go away when the next job starts, so that can be a problem :-) | 12:32.52 |
| Robin_Watts | Damn. No bmpcmp invocations listed :( | 12:33.23 |
| | The pngs2html.pl stage runs on casper, right ? | 12:34.33 |
| | This stuff falls out of cache every time I look at it. I need a bigger memory. | 12:37.09 |
| kens | If you find a good supplier I need one too | 12:37.24 |
| | And some other upgrades. | 12:37.31 |
| | :-) | 12:37.50 |
| Robin_Watts | So the bmpcmp happens on the remote machines. They produce pngs and metadata. That gets uploaded to casper, and that produces the html. | 12:37.52 |
| | :) | 12:37.53 |
| | marcosw_: Where in the code does the actual bmpcmp invocation happen? | 12:40.01 |
| marcosw_ | the file jobs has bmpcmp invocations in it: bash -c "nice ./bmpcmp <(gunzip -c ./temp/tests_private__comparefiles__Bug691941.pdf.pbmraw.300.1.gz) <(gunzip -c ./baselineraster/tests_private__comparefiles__Bug691941.pdf.pbmraw.300.1.gz) ./temp/bmpcmp/tests_private__comparefiles__Bug691941.pdf.pbmraw.300.1 0 100" | 12:42.46 |
| Robin_Watts | marcosw_: Right. So my last clusterpush should have been "bmpcmp -t16" and yet I see no -t16 in the jobs list. | 12:47.31 |
| marcosw_ | I'm guessing there is an issue passing the -t option to the clustermaster. To be honest I need a bigger cache too, since I don't recall ever implementing anything that allows for bmpcmp options. | 12:48.26 |
| Robin_Watts | I thought you'd previously said that anything other than bmpcmp was passed as a bmpcmp option. | 12:48.51 |
| | Maybe I'm misremembering, which would explain it. | 12:49.29 |
| | Specifically, I need to be able to pass -t and -w options (for threshold and window) | 12:52.43 |
| marcosw_ | okay, I'll add that (or fix it if it's already there and broken). | 12:53.54 |
| Robin_Watts | marcosw_: Thanks. | 12:54.12 |
| marcosw_ | Robin_Watts: http://www.spa-francorchamps.be/en/track-activities.php | 12:54.44 |
| Robin_Watts | Turned out to be another good race. | 12:55.19 |
| marcosw_ | No rain though, so my extra $ for the covered seat was wasted :-) | 12:55.42 |
| Robin_Watts | :) | 12:56.55 |
| | But if you hadn't paid the $, it would have tipped it down. | 12:57.09 |
| | lunchtime. | 12:57.12 |
| marcosw_ | Robin_Watts: I've traced the code and there is full support for passing arbitrary options to bmpcmp. Now to figure out why it's not working. | 13:22.10 |
| Robin_Watts | Ah. | 13:38.11 |
| marcosw_ | Robin_Watts: sorted (assuming my test works). | 13:41.10 |
| Robin_Watts | Tell me when it's safe and I'll kick off a new test, thanks. | 13:41.38 |
| marcosw_ | I think it's safe now. The jobs file shows the options I specified. I'll abort my test job. | 13:46.44 |
| Robin_Watts | Thanks. | 13:47.14 |
| | Does that mean I can do: "clusterpush.pl bmpcmp gs ls xps pcl -t16 -w1" and it'll all work as I want ? | 13:50.17 |
| | I had a couple of ideas for clusterpush the other day. | 13:50.58 |
| | Firstly, sometimes it'd be nice to be able to only run a subset of jobs. | 13:51.32 |
| | so we could do: clusterpush.pl gs -filter=ppmraw -filter=300 | 13:52.07 |
| | That'd just be a question of filtering the jobs that got put into the jobs file, right ? | 13:52.58 |
| | Also, only the first 1000 differences found in bmpcmp go into the jobs file. So it'd be nice to be able to say -offset=1000 and get the second 1000 jobs. | 13:55.29 |
| marcosw_ | Robin_Watts: I like the idea of being able to filter the jobs based on dpi and type, but I'm not sure the offset feature would get that much use. Do people have the patience to look at 1000 jobs via the web site and then run another 1000 jobs and look at those? | 14:08.20 |
| Robin_Watts | marcosw_: Suppose I run a job, and get 10000 changed files. | 14:09.11 |
| | I then run a bmpcmp -t16 and I find that all my diffs are small colour changes; i.e. no actual diffs reported. | 14:09.41 |
| | That only tells me that the first 1000 jobs were OK. | 14:09.56 |
| | There is no way currently to be able to test the rest in the cluster. | 14:10.27 |
| | (I'm hoping that this is exactly the situation that I'm in now, with a change to the colour rounding for some devices). | 14:10.55 |
| marcosw_ | right, I didn't think of the fact that bmpcmp can be used to determine that changes aren't significant. | 14:11.15 |
| Robin_Watts | I have 4000ish diffs, and i'm hoping that -t16 -w1 will get rid of most of them. | 14:11.24 |
| | marcosw_: I was thinking that the "filtering based on dpi and type" could be done by just looking for the specified text within the "pathname.res.device.band" string. | 14:12.28 |
| | That way we could also do: -filter=PDFIA etc. | 14:12.38 |
| kens | marcosw_ Bugzilla doesn't have a '9.04' entry for the version number. | 14:12.46 |
| marcosw_ | yeah, that parts easy (actually both parts are relatively easy). | 14:12.59 |
| | kens: oops, my bad. | 14:13.03 |
| kens | Logically we shuld have a 9.03 as well | 14:13.12 |
| marcosw_ | do we need a 9.04 in bugzilla? I thought we didn't have any bugs in that release? | 14:13.26 |
| kens | New ones ? | 14:13.37 |
| | There's precedent for missing number out, we didn't include 8.55. | 14:14.03 |
| | So we could skip 9.03 | 14:14.13 |
| Robin_Watts | marcosw_: Yes, but people need to be able to report the things they think are bugs, so we can say "That's not a bug, it's a feature". | 14:14.20 |
| kens | Or in my case "That's not our bug" and "That's already been fixed" | 14:14.42 |
| marcosw_ | do we need a 9.03 for GhostPCL as well? As far as I recall the customer who requested 9.03 only uses Ghostscript? | 14:16.11 |
| kens | I think we could skip 9.03 altogether. | 14:16.30 |
| marcosw_ | works for me | 14:16.38 |
| kens | Like I said, we didn't have a 8.55 either though we had 8.54 and 8.56 | 14:17.26 |
| | Since its only one customer, they will probably just send email if they have a problem with it | 14:17.44 |
| alexcher | kens: I'm looking in the bug 692471. This is a JPX file and Jasper is known to use lseek() and small read() calls. | 14:48.57 |
| kens | OK Alex, maybe that's it then, I didn't look carefully | 14:49.16 |
| | It just looked like Octal, which suggested text. | 14:49.59 |
| alexcher | kens: On my 64-bit Linux, strace shows small number of mmap calls instead of lseek and read. The run is CPU-bounded. | 14:51.12 |
| kens | Fair neough | 14:51.55 |
| Robin_Watts | Gah. | 15:25.24 |
| | If I run a side by side comparison of plank and pamcmyk4 on my local machine using a perl script I see lots of differences. | 15:26.22 |
| | If I then rerun those files manually using the same invocations... I don't. | 15:26.39 |
| | Ooh, found it. I am SOOOO stupid. | 15:35.53 |
| henrys | Robin_Watts:kens suggested you look at 692323 he's been working on alexcher's bugs - he also suggested just booting it back to them and saying turn off interpolation which seems reasonable also, do you want to look at it before we kick it back? | 15:52.03 |
| Robin_Watts | let me check | 15:52.24 |
| henrys | kens:the simplified file was different for me. I pulled out the black pattern which the raster would have used as a color. | 15:53.12 |
| kens | henrys as far as I can tell, the problem is that the 'lines' are being drawn as filled rectangles. If I run the simplified file through pdfwritre, tehn all the lines are the same, no big black boxes. | 15:54.25 |
| henrys | 692457 ^^^ | 15:54.25 |
| kens | I've tried cutting the file down myself, and if I remove everything except the fills, teh problem goes away :-( | 15:54.47 |
| | I'm persevering with it, but its going to take time for me to reduce the file and still see the problem | 15:55.21 |
| | The fills don't seem to use a pteern, they are '0' which is just black for a rectangular fill in PCL. | 15:55.53 |
| Robin_Watts | henrys: 30% of the time is in cmsTetahedralInterp16 | 15:56.40 |
| | I have previously tried to optimise that code. | 15:56.53 |
| | but I was finding slightly differences in my optimised version to the original that I couldn't explain. | 15:57.14 |
| kens | I'm of the opinion that the customer can have the nice interpolation, in which case its slow, or he can have it fast, but then no interpolation, so lower qulaity. | 15:57.24 |
| Robin_Watts | It's something I'd like to look at again. | 15:57.25 |
| kens | IIRC the file is mostly an image stretched across a 40x40 inch page, with transparency applied to all of it, and then rendered at 2540 dpi. | 15:58.07 |
| | So I don't think its ever going to be quick.... | 15:58.17 |
| Robin_Watts | 479 million calls to cmsTetahedralInterp16. Ouch. | 15:58.25 |
| kens | Big imaghe, even bigger page, high resolution. | 15:58.46 |
| Robin_Watts | I wonder if we'd maybe be better off doing colour management BEFORE interpolation. | 15:58.48 |
| henrys | right but there are lines perpendicular to the lines in my simplified file that don't appear in the non pdfwrite - | 15:58.56 |
| Robin_Watts | (when scaling up at least) | 15:59.04 |
| kens | I see henrys ran away after that last comment :-( | 15:59.20 |
| | Robin_Watts : I think that would be 'OK'. While its possible that the interpolation woudl result in colour shifts, I think its unlikely to be perceptible. | 16:00.24 |
| Robin_Watts | kens: Yes. | 16:00.58 |
| | For highly non-linear profiles it might give differences, but how often do we ever see those? | 16:01.30 |
| | (That's a real question, and one we should ask Michael about) | 16:01.42 |
| kens | Yes, that's what I think. And even if they are highly non-linear, the interpolation shifts smoothly, so it shouldn't cause a problem. But yes, pass it by the expert ;-) | 16:02.17 |
| henrys | sorry wireless glitch | 16:02.34 |
| Robin_Watts | So, which one of us scared you off? :) | 16:02.39 |
| kens | henrys I didn't see that difference. I' re-running the files to check | 16:03.02 |
| Robin_Watts | Ok, at last I can reproduce the plank/pamcmyk4 differences. | 16:03.21 |
| kens | Drat, I just corrupted my copy of the original file. | 16:03.52 |
| Robin_Watts | I have a pdf file here, that goes something like: q 0 0 0 rg 0 0 100 100 re f Q q 100 0 100 100 re f Q | 16:06.04 |
| kens | henrys the output from your simplified file doesn't show the big black rectangles, which is the real problem. I believe the vertical lines are correct. | 16:06.13 |
| Robin_Watts | i.e. first it sets an rgb color of 000 and draws a rectangle. Then it restores, then it draws another rectangle in the default colour (still black, but DeviceGray). | 16:06.52 |
| | Does it seem unreasonable to anyone else for those to give different colours ? | 16:07.07 |
| kens | Yes. | 16:07.20 |
| | But it depends if you have transparency involved | 16:07.32 |
| Robin_Watts | No transparency. | 16:07.41 |
| kens | transfer functions ? | 16:07.46 |
| Robin_Watts | No transfer functions. | 16:07.52 |
| kens | Are you using the 'default' ICC profiles ? | 16:08.02 |
| Robin_Watts | AFAIK, yes. | 16:08.09 |
| kens | If not then you may well get different colours | 16:08.09 |
| | In that case, have to ask Michael | 16:08.21 |
| Robin_Watts | Yeah, that's what I was planning. | 16:08.51 |
| henrys | kens:I assumed that was the problem - the line corresponds to the side of the black rectangle which isn't being filed properly from reducing the file. I can look at it again if you want. | 16:09.21 |
| kens | henrys, the problem is (or seems to be) that some of teh lines are drawn as 'filled rectangles'. Some of those are drawn too large (vertically) which results in the black boxes. | 16:10.00 |
| | The rendering of the PCL files differs at 300 and 600 dpi. Not all the lines are visible at 300 dpi. | 16:10.29 |
| | But the text should all be in boxes. | 16:10.39 |
| | If the lines don't form complete rectangles, they should. | 16:10.57 |
| | I don't understand why some of the lines are drawn as imagemasks, and some are drawn as filled rectangles, but that seems to be how they are done. The filled rectangles cause the problem. But if I remove the rest of the content, the problem goes away..... | 16:11.40 |
| henrys | it is just raster in the file right? let me loook again. | 16:11.43 |
| kens | henrys, no there are definitely filled rectangle commands. | 16:11.56 |
| henrys | oh okay pcl will use a rectangle for large single colored raster. | 16:12.29 |
| kens | EG: (don't kow if this will paste) | 16:12.43 |
| | *p297X*p320Y*c1A*c64B*c0P | 16:12.43 |
| henrys | that's in my file? | 16:12.57 |
| kens | No, its in the original | 16:13.03 |
| | Your file works OK, the original doesn't | 16:13.13 |
| henrys | my feeling is if I add back in a missing pattern my file will be a black rectangle like what is obviously wrong in the original file, as it is now it is a white rectangle with just a side rendered. | 16:17.50 |
| | but I'll look again probably faster for me to simplify it. | 16:18.18 |
| kens | Well, the PDF looks identical to the rendered PCL at 600 dpi. | 16:18.43 |
| | If there's an incorrect rectangle, I can't see it, presumably because its in white. If that's the case, ycould you leave it in black ? Its much easier to identify the problem. | 16:19.25 |
| henrys | oh okay let me look again I thought it was wrong at 600 dpi | 16:19.42 |
| kens | I could be mistaken, but it looked the same to me. | 16:19.55 |
| henrys | I'll get back on it and update the bug sometime today. No great hurry, not a customer. | 16:20.50 |
| | I can't believe that chancery font is 20% too small, the em-size must have been accidentally changed by the open source folks doing cyrillic. | 16:22.36 |
| | kens:are there customers marcosw_ should contact for alexcher's bugs I can review them if you like but if you know offhand by all means send him an email. | 16:26.22 |
| | I do wonder if customer bugs should be commented as fixed and assigned to marcosw_ who would then finally change the status and hopefully contact the customer. | 16:27.05 |
| kens | henrys they were all customer bug reports. | 16:27.33 |
| | To behonest I'm not sure I remember which ones deserve a reply. Actually one of tehm was a GPF that Marcos foudn I think, not a customer report | 16:28.08 |
| | There was one, which was a change to a static #define for lots of spot colours. I'll ask Marcos to contact them. | 16:28.36 |
| henrys | I can't seem to get my wireless back ... trying a modem reset which will likely drop me. | 16:31.25 |
| kens | OK mail sent to Marcos | 16:34.24 |
| henrys | thanks kens | 16:34.33 |
| kens | No problem. | 16:34.52 |
| | Time for me to go, haev a good night everyone. | 16:35.07 |
| Robin_Watts | night kens | 16:35.13 |
| henrys | too slow | 16:35.36 |
| Robin_Watts | I'm confused. I didn't think Michaels new thresholding code had been enabled yet... | 16:36.56 |
| | I thought the purpose of the current plank vs pamcmyk4 tests was to ensure that the old way of working worked OK. | 16:37.40 |
| henrys | yes mvrhel2's code should be disabled for that. | 16:39.41 |
| Robin_Watts | So how am I getting a SEGV in SSE2 stuff then... | 16:40.01 |
| henrys | but I think mvrhel2 committed before the plan was firmed up and wanted to see differences in a possibly broken plank device. | 16:40.29 |
| | at least it might identify some obvious issues. | 16:40.54 |
| Robin_Watts | I thought that mvrhel2's new code was committed, but was currently disabled. | 16:45.46 |
| | And he was only going to enable it by default when we had plank == pancmyk4 (or as near as dammit) | 16:46.31 |
| henrys | I agree that is the right thing to do. | 16:48.51 |
| Robin_Watts | The first pamcmyk4 vs plank diff is a problem with an image being displayed incorrectly. | 16:50.05 |
| | And a tiny change to my cutdown file can provoke a crash in SSE2 code, which suggests that the new code is being run already. | 16:50.29 |
| | Oh, mvrhel2 is here. Didn't see him arrive. | 16:51.07 |
| | mvrhel2: You awake? | 16:51.13 |
| | Oh... It's not the colour thresholding code that's being hit. It's the mono thresholding code. I wonder why... | 17:11.19 |
| mvrhel2 | I am here | 17:13.39 |
| Robin_Watts | mvrhel2: Some dumb questions, if I may. | 17:14.08 |
| | gximono.c line 94. | 17:14.19 |
| | dev_color_ok = ... | 17:14.26 |
| | That allows the use of the thresholding stuff for cmyk planar devices ? | 17:14.54 |
| mvrhel2 | hold on | 17:15.22 |
| | yes it should | 17:16.18 |
| Robin_Watts | really? enabled already ? | 17:16.56 |
| mvrhel2 | apparently | 17:17.20 |
| | we have not had any regression testing for planar device to catch this | 17:17.33 |
| Robin_Watts | Cos that's a) giving bad results in the tests, and b) crashes if I modify the file. | 17:17.38 |
| | Right. | 17:17.46 |
| | So the problems that marcosw is finding *may* be to do with this. | 17:17.56 |
| mvrhel2 | thats what happens when we dont regression test devices | 17:17.59 |
| | very much so | 17:18.06 |
| | so go ahead and turn this off | 17:18.30 |
| | and then we can debug after we get the plank vs pamcmyk4 comparison done | 17:18.59 |
| Robin_Watts | ok. | 17:19.47 |
| | Another question, if I may. | 17:20.02 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692475 | 17:20.17 |
| | If I plot 2 rectangles, one in 'default' black and one in 'rgb black', it'd be bad if they gave different halftoned colours, right ? | 17:20.50 |
| mvrhel2 | yes. I am looking at that now. It has to do with how gray is mapped for a CMYK device. It is always mapped directly to K. | 17:20.54 |
| Robin_Watts | Ah, ok. | 17:21.08 |
| mvrhel2 | This is not true for an RGB source. That will go through the default profiles | 17:21.10 |
| Robin_Watts | That's a shame. | 17:21.24 |
| mvrhel2 | well it is easy enough to fix | 17:21.31 |
| | by changing your profiles | 17:21.41 |
| Robin_Watts | Or rather, it's a shame that the black points of all our default profiles don't match up. | 17:21.43 |
| mvrhel2 | what does AR doe with the file? | 17:21.47 |
| | the black points match up just fine | 17:21.56 |
| Robin_Watts | Haven't tried it. Let me try it now. | 17:22.00 |
| | Identical. | 17:22.13 |
| mvrhel2 | it is that device gray sources map to K for a CMYK device | 17:22.20 |
| | that is the oddity | 17:22.22 |
| | it is basically not color managed | 17:22.31 |
| Robin_Watts | In fact, I'd go further and say "It's a shame that our default rgb profile doesn't give us black for black". | 17:22.40 |
| mvrhel2 | define black for me | 17:22.48 |
| | we use the same default as AR | 17:23.02 |
| Robin_Watts | in this instance, when we halftone the colour you get from '0 0 0 setrgbcolor' we get a speckled pattern. | 17:23.28 |
| | I'd expect a solid black pattern. | 17:23.37 |
| | Is that an unreasonable expectation ? | 17:24.46 |
| mvrhel2 | so AR gives the same result | 17:25.22 |
| Robin_Watts | No, sorry. | 17:25.33 |
| | AR renders both rectangles as proper black. | 17:25.43 |
| mvrhel2 | the RGB maps to CMYK of 75 68 67 90 percent | 17:25.47 |
| | and the Device Gray maps to CMYK of 0 0 0 100 percent | 17:26.00 |
| | dont' halftone and you will get the same thing | 17:26.11 |
| | if you were to print this on a paper it will be black | 17:26.23 |
| Robin_Watts | mvrhel2: Right. And that CMYK result halftones to some horrible speckled thing. | 17:26.28 |
| mvrhel2 | viewing on the screen, you see the speckles | 17:26.37 |
| | if you were actually printing on a real printer you would specify the ICC CMYK profile for your device | 17:26.57 |
| | and get black printed for an RGB input of 0 0 0 | 17:27.06 |
| Robin_Watts | Right, I understand that. | 17:27.19 |
| mvrhel2 | you are getting your soft view of halftones mixed up with what would be printed on a real page | 17:27.25 |
| Robin_Watts | It still feels wrong that I get a disparity. | 17:27.55 |
| mvrhel2 | well you need a better soft view emulator for halftones | 17:28.11 |
| | :) | 17:28.15 |
| | or print it on a real printer | 17:28.21 |
| | or look at it in contone | 17:28.30 |
| | on the display | 17:28.36 |
| Robin_Watts | If I printed that file onto a CMYK printer, for which the profiles were right, I'd still get the left rectangle printed using a different combination of inks to the right hand rectangle, right? | 17:29.18 |
| mvrhel2 | yes | 17:29.25 |
| Robin_Watts | That has to be wrong, surely. | 17:29.31 |
| mvrhel2 | no | 17:29.33 |
| | you need to turn off graytoK | 17:29.56 |
| | if you dont want device gray to go to pure K only | 17:30.06 |
| | and then you will get a match | 17:30.14 |
| Robin_Watts | Hmm | 17:30.26 |
| | Why is that on by default ? | 17:30.30 |
| henrys | chrisl:you around? I'd like to fix the chancery thing soon, seems an egregious problem to me. | 17:30.37 |
| mvrhel2 | that is the adobe specification | 17:30.37 |
| | and it is what AR does | 17:30.42 |
| Robin_Watts | Fair enough, if that's the spec then so be it. | 17:31.15 |
| mvrhel2 | there were many complaints about the way I had it before, which would give, by default for a CMYK device the matching that you (and I) so desired | 17:31.35 |
| | which is matching independent of source color | 17:32.02 |
| | for black | 17:32.03 |
| | in device color | 17:32.10 |
| Robin_Watts | mvrhel2: And now you've changed it, we can expect many more complaints. Sounds like an FAQ entry candidate. | 17:32.17 |
| mvrhel2 | unfortunately the spec states ottherwise | 17:32.20 |
| | hehe. Now I can point to AR | 17:32.34 |
| | and it is easy to make it work the old way | 17:32.47 |
| chrisl | henrys: yes, as I said in the bug, I'll update the fonts in the next couple of weeks. I just didn't feel comfortable sticking them in shortly before a release. | 17:32.59 |
| Robin_Watts | mvrhel2: Yes, the fact that it can be 'fixed' with a command line switch and we follow AR means we're probably doing the best possible thing. | 17:33.37 |
| mvrhel2 | Robin_Watts: incidentally on my screen, the RGB color is black and the Gray color is a dark gray in contone | 17:33.48 |
| | when rendered to TIFF by AR | 17:34.01 |
| Robin_Watts | But an FAQ entry sounds like a good idea. | 17:34.07 |
| | mvrhel2: Really? | 17:34.10 |
| | The profiles aren't set right on my desktop. 2 mismatched monitors. | 17:34.23 |
| mvrhel2 | yes. the CMYK color of 75 68 67 90 is blacker than 0 0 0 100 | 17:34.42 |
| | for a swop CMYK profile | 17:34.57 |
| Robin_Watts | ok, well, feel free to close the bug with a "you are a fool who knows nothing about color!" comment :) | 17:35.53 |
| henrys | chrisl:oh i misread that sorry, I thought it was sometime before 9.05 and I'd vote for sooner, next few weeks is great. | 17:36.42 |
| chrisl | henrys: Yes, I want it done soon, for a good amount of testing, in the hope/expectation we'll ship the (new)plain URW fonts in 9.05. | 17:38.08 |
| mvrhel2 | Robin_Watts: you brought up some good points. so where are we putting these FAQs? | 17:38.14 |
| Robin_Watts | The plan was to write entries and mail them to... marcos or chrisl. marcos I think. | 17:38.39 |
| mvrhel2 | ok. | 17:39.35 |
| | so Robin_Watts: are you going to go ahead and turn off the planar case for mono images? | 17:40.28 |
| Robin_Watts | I am doing that now. | 17:40.35 |
| mvrhel2 | ok great | 17:40.37 |
| | sorry about that | 17:40.40 |
| Robin_Watts | no worries. | 17:40.44 |
| henrys | interesting I just noticed language in the pdf manual 1.7 1.2.6 that specifically discusses unicode filenames and such - I didn't notice that before our unicode changes to the windows build. I guess we are okay for unicode not so sure if we are right for "using the standard encoding" | 17:40.56 |
| Robin_Watts | marcosw_: You about? | 17:49.32 |
| | marcosw_: Could you rerun the plank vs pamcmyk4 comparison please? | 17:51.08 |
| | I'm running just the files that differed in your last run locally here with the latest change, but it's very slow. | 17:52.04 |
| marcosw_ | Robin_Watts: will do. | 17:58.22 |
| Robin_Watts | Thanks. | 17:58.29 |
| tkamppeter | I found the time to answer bug 692419. | 18:02.15 |
| Robin_Watts | mvrhel2, henrys, marcosw_: There are still (non trivial) differences between plank and pamcmyk4. I'll look into those now. | 18:17.51 |
| mvrhel2 | ok | 18:20.41 |
| Robin_Watts | look like pattern tiling isn't working right. | 18:20.53 |
| | mvrhel2: Ping? | 18:35.34 |
| | In gxp1fill.c in gx_dc_pattern_fill_rectangle at line 341, should that have " && device is not planar" ? | 18:36.16 |
| mvrhel2 | I am back | 18:42.50 |
| | shoot I am in a different branch hold on | 18:44.01 |
| Robin_Watts | git.ghostscript.com/?p=ghostpdl.git;a=blame;f=gs/base/gxp1fill.c;h=0d6671bd9ed9cef76e4749242807d906fa570595;hb=HEAD | 18:45.31 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=blame;f=gs/base/gxp1fill.c;h=0d6671bd9ed9cef76e4749242807d906fa570595;hb=HEAD | 18:45.38 |
| | Stupid chrome. | 18:45.42 |
| mvrhel2 | ok. I am back to master now | 18:45.52 |
| Robin_Watts | Ah, sorry, wasn't fast enough - the above link would have saved you swapping your tree. | 18:46.14 |
| mvrhel2 | no problem | 18:46.25 |
| | I see, we need to do some work to handle the simple case with planar | 18:47.15 |
| | for now, we could do a not planar and go to the tiling case | 18:47.47 |
| Robin_Watts | simple, non-transparent case, with planar, yeah. | 18:47.57 |
| mvrhel2 | Robin_Watts: why dont you go ahead and for now force it to always do tiling but open a bug to fix this | 18:48.54 |
| | (that is for the planar case) | 18:49.08 |
| Robin_Watts | That seems tp solve the pattern problems I've seen (at least the first few). | 18:49.12 |
| mvrhel2 | thats good | 18:49.24 |
| Robin_Watts | I'll let it run and will commit after dinner if it seems good. Thanks. | 18:49.28 |
| mvrhel2 | can you attach a file to the bug also for the simple case | 18:49.42 |
| Robin_Watts | Sure. | 18:51.19 |
| mvrhel2 | thanks! | 18:51.25 |
| Robin_Watts | np. | 18:51.28 |
| mvrhel2 | back to SSE2 for color conversion in lcms | 18:51.35 |
| | that piece of code seems to be our biggest bottleneck | 18:51.54 |
| | I am pretty close to having this working. | 18:52.03 |
| | not sure if it will be faster though | 18:52.08 |
| | but since trilinear interpolation in the table requires a few sets of 8 16 bit multiplies it is well suited to the SSE2 approach | 18:53.18 |
| | lunchtime bbiab | 19:03.48 |
| Robin_Watts | mvrhel2: Did you see my suggestion earlier about maybe doing colour conversion *before* image scaling if we're scaling up? | 19:20.51 |
| | It relies on the idea that linear interpolation of looked up values is still reasonable, but would cut down on the number of lcms calls. | 19:21.44 |
| mvrhel2 | hi Robin_Watts: I did not see that | 20:09.22 |
| | I agree that would makes sense | 20:09.39 |
| | I thought we were already doing interpolation in the source color space | 20:10.14 |
| | but maybe I am mistaken | 20:10.19 |
| | I am mistaken | 20:33.03 |
| | cool. my weights for the color table interpolation are getting computed correctly with sse2. now just need to apply them to the table data in one SSE2 operation | 20:36.38 |
| tkamppeter | About bug 692419 (and also about the speed advantage), should we make perhaps make -dNOINTERPOLATE default in Ghostscript? Is there an easy way to build Ghostscript with this setting being default? | 22:18.15 |
| alexcher | tkamppeter: The change on PS level is easy but it would be better to fix interpolation instead. I'd like to hear from our architects first. | 22:36.13 |
| tkamppeter | alexcher, but for the speed advantage, doing no interpolation by default would make sense. | 22:40.25 |
| Robin_Watts | mvrhel2: Sounds very cool. I look forward to seeing it. | 22:58.02 |
| | Forward 1 day (to 2011/08/30)>>> | |
IRC Logs