| | <<<Back 1 day (to 2011/11/07) | 2011/11/08 |
| Robin_Watts | tor8: Ah, well, at least that makes sense. | 00:22.31 |
| | tor8: I'll look into it tomorrow. | 00:23.12 |
| tor8 | my guess would be an off-by-one but I think I've seen distortions of more than 1 source pixel | 00:23.13 |
| | you should be able to reproduce with the iphone simulator | 00:23.29 |
| | just ping me tomorrow and I'll send you some test files | 00:23.42 |
| | and walk you through the Xcode nightmare | 00:23.54 |
| Robin_Watts | I was hoping to avoid the iphone bit at all. | 00:23.55 |
| | I'll see if I can see it in android. | 00:24.07 |
| | Some test files would be good though. | 00:24.33 |
| tor8 | yeah, you could probably see it with pdfdraw. it's just very easy to spot with the iphone app because I have the low-res version of the page as a backdrop so you can see the shifting happen when the new render arrives | 00:24.45 |
| | I can get you the test files and some screen shots | 00:24.55 |
| | Robin_Watts: http://ghostscript.com/~tor/stuff/scaling/ | 00:30.12 |
| Robin_Watts | Thanks. | 00:30.21 |
| tor8 | screen shots there | 00:30.26 |
| | I'll put the files on casper for scp | 00:30.43 |
| | in /home/tor | 00:31.24 |
| Robin_Watts | Thanks. | 00:40.27 |
| | I'm off to bed now, but that'll be my focus for tomorrow. | 00:40.51 |
| tor8 | night | 00:41.05 |
| | Robin_Watts: if you're still there (or for the logs) -- I get asm errors on draw_simple_scale.c | 01:14.02 |
| | invalid literal constant: pool needs to be closer | 01:14.19 |
| | unsupported relocation on symbol L0 | 01:14.27 |
| | and on the one that compiles, at runtime I get: warning: check_safe_call: could not restore current frame | 01:17.06 |
| Robin_Watts | I'm damned if I can see the image shifting problem that tor8 reports :( | 12:48.31 |
| | Even in his screenshots. | 12:48.39 |
| kens | Need someone else to look as well ? | 12:48.54 |
| Robin_Watts | http://ghostscript.com/~tor/stuff/scaling/ | 12:49.12 |
| | As he zooms in and out he displays a scaled image behind the display. | 12:49.58 |
| kens | Just grabbing files | 12:50.12 |
| Robin_Watts | And when it resolves, he sees a noticable jump when the real image is displayed. | 12:50.32 |
| | He says if he disables smooth scaling the problem goes away. | 12:50.46 |
| | His screenshots are designed to show it, but I'm damned if I can see it :( | 12:51.04 |
| kens | Given that the content is different for each screen, what am I supposed to look at ? | 12:52.52 |
| Robin_Watts | Aha. | 12:53.09 |
| kens | :-) | 12:53.13 |
| Robin_Watts | kens: Don't worry... but thanks. | 12:53.17 |
| | tor8: Hi. | 12:53.20 |
| kens | NP | 12:53.31 |
| tor8 | Robin_Watts: morning | 12:53.38 |
| Robin_Watts | I'm having trouble reproducing the problems (or even seeing them in your screenshots) | 12:53.51 |
| tor8 | Robin_Watts: screenshot 01.27.47, left half of the circle that surrounds the "27" is the blurry low-res | 12:55.06 |
| | the high-res right half is shifted up about one texel | 12:55.17 |
| | Robin_Watts: it's a lot easier to see in motion than on a static screenshot | 12:55.59 |
| Robin_Watts | tor8: Before we continue... the scaled backdrop you display... | 12:56.07 |
| | Is that a stored lowres image of the page ? | 12:56.20 |
| | or the previous image zoomed up? | 12:56.36 |
| tor8 | the previous image zoomed up | 12:56.44 |
| | i.e. it's the 100% zoom rendering, scaled up by iOS | 12:57.07 |
| Robin_Watts | http://www.prior-ip.com/patent/9260871/ | 12:57.41 |
| | I believe the scott patent covers that :( | 12:58.09 |
| tor8 | ah, but it's not a thumbnail and it's not for file management navigation! | 12:58.29 |
| Robin_Watts | The alternative (holding a dedicated page thumbnail and scaling that) is covered by a patent taken by Picsel, and now sold to Samsung. | 12:58.36 |
| tor8 | nor is it using a discrete wavelet transform. | 12:58.46 |
| Robin_Watts | scaled by iOS ? | 12:58.52 |
| tor8 | the screenshot you're seeing is composed of two UIImageViews | 12:59.16 |
| | one being the first image we ever draw, that has been zoomed in | 12:59.35 |
| Robin_Watts | Is it possible that the problem is iOS scaling being wrong ? | 12:59.37 |
| tor8 | Robin_Watts: if it was, the text would shift around as well. it isn't. | 12:59.53 |
| Robin_Watts | OK. Just don't want to be tilting at windmills. | 13:00.12 |
| tor8 | the second, the high detail rendering at the current zoom/resolution. | 13:00.14 |
| | and if I turn off scaling, it looks dreadful but everything stays put (modulo the shimmering of dropped scanlines/columns) | 13:00.45 |
| Robin_Watts | Given that we only ever use the scaler to scale down, the source image must be bigger than the destination one. | 13:01.02 |
| | Therefore a source texel would be smaller than an output pixel. | 13:01.36 |
| tor8 | yeah, so the blurry (low res) image would seem to be scaled wrong in the image | 13:02.40 |
| | but please do confirm anything I say! | 13:02.59 |
| Robin_Watts | Sorry, not sure I'm following. | 13:08.48 |
| tor8 | render at low res (so scaling triggers), render at high res (so no scaling) | 13:09.29 |
| | scale the result and compare | 13:09.34 |
| | http://ghostscript.com/~tor/stuff/scaling/ compare a.png and b.png | 13:12.48 |
| Robin_Watts | tor8: Does the problem still happen if you disable grid fitting ? | 13:12.51 |
| tor8 | a.png is rendered at 50dpi | 13:12.53 |
| | b.png is rendered at 200dpi and then scaled by 25% in gimp | 13:13.11 |
| Robin_Watts | When scaling images we grid fit them to the output. | 13:14.06 |
| | This can move their edges by up to 1 output pixel. | 13:14.24 |
| tor8 | Robin_Watts: yes, as far as I have tested | 13:14.26 |
| | c.png is at 50dpi without grid fitting | 13:14.35 |
| | anyway, need to run down to the bank before they close | 13:14.57 |
| Robin_Watts | That would mean that the initial "100%" zoom image would have that done to it. | 13:14.58 |
| tor8 | back in an hour | 13:15.09 |
| | Robin_Watts: yes. that was my first thought too. but the errors are bigger than a device pixel. | 13:15.27 |
| Robin_Watts | Then when we zoom back up, those pixels would be moved by the "1 source texel" you were talking about. | 13:15.30 |
| | tor8: OK. talk to you later. I'll keep staring. | 13:15.49 |
| tor8 | Robin_Watts: stare at the page number alignment in the circle that's part of the page backdrop image | 13:16.10 |
| chrisl | kens: did you get a mail (through support) from Grant Boyle this morning? gmail spam binned it for me and I only noticed it by accident....... | 14:38.28 |
| kens | No, I don't thin kI saw it. | 14:50.10 |
| | Its held. | 14:50.22 |
| Robin_Watts | alexcher: What are your movements in Miami? Are you around for the everglades trip? | 14:50.29 |
| chrisl | kens: okay, thanks, I'll try to remember to point marcosw at it | 14:50.49 |
| Robin_Watts | chrisl: Are you flying on the same flight as us? Tuesday 11am from Heathrow? | 14:51.15 |
| chrisl | Yes, I'm on that flight, too | 14:51.34 |
| Robin_Watts | Ok. So the plan is for us to hire a car at the airport to get to the hotel. | 14:51.55 |
| kens | chrisl, thanks. | 14:51.58 |
| kens | will get the airport shuttle | 14:52.11 |
| chrisl | Robin_Watts: okay, cool. Just let me know what I should chip in | 14:52.33 |
| Robin_Watts | chrisl: We'll worry about that when we get everything with the trips sorted. | 14:52.57 |
| chrisl | Fine | 14:53.09 |
| Robin_Watts | Bring your drivers license etc if you want to be one of the drivers. | 14:53.21 |
| chrisl | Eek, not sure I'd be safe driving on the right........ | 14:54.54 |
| alexcher | Robin_Watts: I'm attending only the business part. | 14:55.00 |
| Robin_Watts | alexcher: Fair enough. | 14:55.12 |
| | So, it's 'just' 13 people for the trip (plus marcos & co, but I think he'll have his own car if he's going to Key West first) | 14:56.09 |
| | tor8: ping ? | 14:58.17 |
| | tor8: I reproduced your test here; render DragonAge.pdf page 27 at 100 dpi, and scale it to 50dpi. Then render DragonAge.pdf at 50dpi. There is indeed a mismatch. | 15:00.29 |
| | But DragonAge.pdf at 100dpi is scaling up; hence we are comparing scaled with unscaled. | 15:01.14 |
| | If I render DragonAge at 80dpi, and scale that down to 40, and then render again at 40dpi, I get visually identical results. | 15:01.48 |
| | actually, I see a difference between 60 scaled down and 30. Let me look into that. | 15:03.22 |
| | actually, no, that's to be expected too because @60 it's an odd number of pixels in size. | 15:05.26 |
| | 94 and 47 exactly match. 62 and 31 exactly match. | 15:10.49 |
| | Scaling seems to be exactly consistent with itself. | 15:10.58 |
| | The problem must be scaling being compared to unscaled. | 15:11.09 |
| tor8 | Robin_Watts: pong. | 15:13.29 |
| Robin_Watts | still struggling here. | 15:13.51 |
| tor8 | Robin_Watts: right. | 15:14.05 |
| Robin_Watts | The problem seems to be a mismatch between scaled and unscaled; but whenever I compare scaled to scaled, I get exactly the results I expect. | 15:14.38 |
| tor8 | yeah. so at least it's deterministic :) | 15:15.00 |
| Robin_Watts | The unscaled stuff; that's using nearest neighbour in the plotter, right ? | 15:15.27 |
| tor8 | does it look pixelated? | 15:15.52 |
| | I have tried both with and without, didn't notice much difference | 15:16.37 |
| | especially on the dragon age pdf, the images don't have /Interpolate set | 15:16.56 |
| Robin_Watts | Let's try rendering at a HUGE dpi and then scaling down. | 15:22.03 |
| | Right. The difference between 800 scaled down to 40 and 40 is tiny. | 15:24.33 |
| | OK. So I've proved to my satisfaction that the scaled things are consistent (80 scales down to match 40, 94 to 47, 62 to 31 etc) | 15:33.40 |
| | So I thought I'd try the same thing with unscaled... | 15:33.53 |
| | 1000 scaled down to 100 does NOT match 100. | 15:34.02 |
| | wheras 1000 scaled down to 50 DOES match 50. | 15:34.43 |
| tor8 | did you disable bilinear sampling for those? | 15:34.46 |
| Robin_Watts | which suggests to me that the unscaled stuff tends towards correctness as the resolution gets large. | 15:35.16 |
| | I haven't changed the source from the default. | 15:35.26 |
| | (except to disable gridfitting) | 15:35.39 |
| | but I reckon there is an error in the unscaled image painting stuff when it's close to 1:1. | 15:36.15 |
| | which would make sense with the nearest neighbour selection. | 15:36.28 |
| | Let me see if it's interpolating or not. | 15:36.34 |
| | ok, so that is interpolating. Let's redo without interpolation. | 15:39.12 |
| | There is a second set of gridfitting in here that i hadn't spotted before. | 15:39.38 |
| | Without interpolation, I still get a noticeable difference between 1000 scaled down to 100 and 100 rendered directly. | 15:45.15 |
| | wheras 1000 scaled down to 100 agrees pretty well with the scaled version. | 15:45.38 |
| | I'm not sure I follow the gridfitting code in fz_paint_image_imp | 15:53.55 |
| tor8 | Robin_Watts: if it's rectilinear, the a,b,c,d coefficients are the image size in device pixels | 15:58.55 |
| | two of the coefficients should be zero, depending on rotation | 15:59.37 |
| Robin_Watts | Right. Except in the dragonage case, we have: 825.499999 0 0 -1137.5 -1.5 1137.5 | 15:59.45 |
| | so the gridfitting code takes that to be 826 0 0 -1138 -2 -1137 | 16:00.27 |
| | so the gridfitting code takes that to be 826 0 0 -1138 -2 1137 | 16:00.32 |
| | note the difference in -1138 and 1137 giving rise to a 1 pixel change in height. | 16:00.52 |
| tor8 | yes. grid fitting at work. or am I missing something? | 16:01.12 |
| Robin_Watts | dst->w = 825, dst->h = 1138 | 16:01.13 |
| | I'd have expected the 1137 to be 1138. | 16:02.03 |
| | but I'm still working it through, so bear with me. | 16:02.26 |
| tor8 | the 1137 in the tx, ty part of the matrix? | 16:02.40 |
| Robin_Watts | yeah. | 16:02.43 |
| tor8 | right. not sure it would make much difference. the roundup is there mostly so we don't lose very small images (less than 1 device pixel wide or tall) | 16:03.42 |
| | I think, but that doesn't make much sense. it's been a while since I wrote that code :) | 16:04.11 |
| | http://git.ghostscript.com/?p=user/tor/mupdf.git;a=blobdiff;f=draw/imagedraw.c;h=e50233dec5e760a9ae45f06e7a4374358354aa79;hp=030c0e943cc6cd5a71bed7a4fc8626f30b0ca300;hb=a7e4226b65fc3b8bc4742b1c159f048d72dfcfeb;hpb=89b649be84883c4552193fb05a6e3e14dd6c344f | 16:05.46 |
| Robin_Watts | The ctm maps a unit square to the destination output space. | 16:05.57 |
| tor8 | maybe I'm confusing it with the previous version | 16:06.00 |
| Robin_Watts | So grid fitting would mean that we want to make the minimum changes to the ctm to ensure that we map the corner points neatly onto whole pixel boundaries. | 16:07.07 |
| tor8 | so we should just round() the coefficients rather than floor/ceil | 16:07.57 |
| Robin_Watts | actually, the grid fitting I do in the scaling code ensures that I always round 'outwards'. | 16:08.18 |
| | hence images never get lost. | 16:08.25 |
| tor8 | that's what the roundup() function tries to do as well | 16:08.34 |
| Robin_Watts | Let me have a crack at some replacement code. | 16:08.50 |
| tor8 | same as what I do when rounding fz_rect to integer fz_bbox | 16:08.52 |
| | does everything look right with grid fitting turned off in all places? | 16:09.16 |
| Robin_Watts | it might not make a difference, but if we get back to the same place it's a reasonable bet it's right. | 16:09.28 |
| tor8 | the grid fitting should match between the plotter and the scaler | 16:09.33 |
| Robin_Watts | haven't tried that. Would spoil the suspense :) | 16:09.40 |
| tor8 | :D | 16:09.44 |
| | there is that TODO in the plotter -- if the ctm is [1 0 0 1 x y] it should copy the scanlines directly without doing the texture mapping | 16:10.40 |
| Robin_Watts | yeah, but ThatNeverHappens(TM) | 16:11.47 |
| tor8 | it should with scaling :) but probably NotOftenEnoughToMatter(R) | 16:12.53 |
| Robin_Watts | Ah, true. | 16:18.15 |
| | New gridfitting code makes 1000 to 100 and 100 match up much better. | 16:37.18 |
| ray_laptop | morning, all | 16:41.53 |
| Robin_Watts | morning ray. | 16:42.01 |
| ray_laptop | goes to check the logs ... | 16:42.02 |
| kens | Hi ray | 16:42.04 |
| ray_laptop | Robin_Watts: If we manage to get the colors crammed into a 64-bit value (such as with compressed color encoding), what do you think of a 'planar' mem device that actually paints ALL of the separations into planar buffers ? | 16:50.56 |
| | much the way the pdf14 device does it | 16:51.44 |
| Robin_Watts | urm... I can't immediately think of a limit on the number of planes the planar device supports. | 16:51.46 |
| ray_laptop | I was pondering bug 692618 (file 1 -- the non-encodable color issue) and thinking about a 'put_image' to get the data out of the pdf14 device, but realized that it doesn't help if we still have to encode the 'image' into a 64-bit value. | 16:53.10 |
| | but the device 'put_image' proc actually gets all of the planes from the pdf14 device, so a planar memory device _could_ just copy the data in | 16:53.50 |
| Robin_Watts | I might have something halfway intelligent to offer if I knew what put_image did. | 16:54.02 |
| ray_laptop | it passes a a device scaled set of planes from the pdf14 device into the call -- passes the aplha plane and tag plane as well as num_components | 16:55.29 |
| | if the call returns "can't do that" from the initial call with alpha, it appliles the alpha and tries again | 16:56.24 |
| Robin_Watts | So it's a way of the pdf14 device passing it's direct buffers to an underlying device. | 16:56.44 |
| | To allow things like pngalpha etc ? | 16:56.52 |
| ray_laptop | and if that fails, it puts the image as an 'image' call | 16:56.56 |
| | Robin_Watts: exactly | 16:57.09 |
| Robin_Watts | ok... so this would solve for the problem only in the case where we are overflowing the number of encodable colors on account of pdf14 blending. | 16:57.47 |
| | (which is exactly the current problem, but might not be the next one down the road) | 16:58.18 |
| ray_laptop | since we have device scaled planes, we avoid the whole nonsense of packing the data into a chunky color index and then using the generalized image code to paint something which is 1:1 scaled anyway | 16:58.29 |
| | Robin_Watts: right, not the next one down the road. | 16:59.01 |
| henrys | meeting time should we wait a bit for michael and marcos? | 17:00.47 |
| ray_laptop | the next issue that mvrhel and I have started discussing is now to paint with the actual colors (hl colors). The fill_rectangle_hl_color is a start in the right direction | 17:00.51 |
| kens | michael is here isn'rt he ? | 17:01.50 |
| ray_laptop | kens: not that I see | 17:02.01 |
| Robin_Watts | nope. | 17:02.02 |
| kens | Oh no, I thought I saw him, must be hallucinating | 17:02.33 |
| henrys | he was here - timeout 20 minutes ago | 17:03.10 |
| ray_laptop | probably taking the kids to school | 17:03.23 |
| kens | That explains the hallucination | 17:03.23 |
| | While we wait.... | 17:03.36 |
| | Anyone have any hints on finding a memory allocation that isn't a leak exaclty ? | 17:03.53 |
| | -ZA the only help ? | 17:04.05 |
| ray_laptop | kens: pretty much | 17:04.21 |
| kens | OK well I'll get bck to sifting it tomorrow | 17:04.33 |
| Robin_Watts | kens: Memento can probably help. | 17:04.42 |
| ray_laptop | kens: I usually just capture the output and then start searching it. | 17:04.52 |
| kens | COuld be. | 17:04.54 |
| Robin_Watts | build with memento, run until you have the block. | 17:04.58 |
| kens | Yes, I have the output, but I don;t really know what its telling me :-( | 17:05.08 |
| Robin_Watts | Then Memento_find((void *)address_in_block) | 17:05.13 |
| henrys | okay, there is mvrhel_laptop | 17:05.16 |
| mvrhel_laptop | good morning. sorry I am a bit late | 17:05.17 |
| kens | Robin_Watts : I don't know what the block is. | 17:05.20 |
| henrys | np | 17:05.21 |
| ray_laptop | if using the chunk allocator, allocations also get a sequence number (in debug mode) | 17:05.27 |
| kens | I have an increasing allocation and don;t know why | 17:05.33 |
| | Its something to do with images | 17:05.44 |
| | More images = more allocations | 17:05.50 |
| Robin_Watts | So, in what way is that not a leak ? :) | 17:05.52 |
| kens | They seem to get cleaned up at EOJ | 17:06.01 |
| ray_laptop | kens: PS, PDF or PCL ? | 17:06.05 |
| henrys | I wanted to ask folks about coverity commits - I would like them to be batched on a branch and checked in all together, thoughts? | 17:06.05 |
| kens | But persist when I wouldn't expect them to | 17:06.11 |
| | ray_laptop : PS but its inside pdfwrite, so probably all | 17:06.25 |
| ray_laptop | kens: eoj does a 'restore' | 17:06.28 |
| kens | ray_laptop : Yes :-( | 17:06.35 |
| | But the garbage collecotr doesn't remove them mid-job | 17:06.50 |
| chrisl | kens: is the eoj restore, or is it final memory cleanup before we shut down? | 17:07.08 |
| | s/is/is it | 17:07.17 |
| alexcher | henrys: there's always a chance that a patch will break something. Small patches help to isolate the problem. | 17:07.18 |
| Robin_Watts | kens: Run for a while, pause, tell memento to list all blocks. Hopefully lots of them will have the obvious same size. | 17:07.20 |
| kens | chrisl don't know | 17:07.20 |
| ray_laptop | pdfwrite keeps stuff around for images to allow for 'same image' recognition, but I thought it only kept hashes | 17:07.21 |
| henrys | kens:if you can reproduce the problem in PCL you can run a "malloc" only build. | 17:07.29 |
| kens | Robin_Watts : that might help. | 17:07.39 |
| | henrys I only see it on the customer's (ridiculous) job | 17:07.54 |
| | In PostScript | 17:08.00 |
| henrys | sigh.. | 17:08.03 |
| Robin_Watts | If you can spot a block that looks like a culprit then run again with Memento_breakAt(block number) to see where the allocation is being done. | 17:08.06 |
| kens | But I have a cold today so I'm not thinking well. | 17:08.14 |
| | Robin_Watts : I may ask for some help with that tomorrow. | 17:08.29 |
| Robin_Watts | kens: ping me tomorrow if you need help. | 17:08.32 |
| henrys | alexcher - all the patches will be in the branch | 17:08.36 |
| alexcher | henrys: OK | 17:09.08 |
| henrys | do others have opinions? | 17:09.34 |
| kens | Not really. Both ways seem OK to me. | 17:09.50 |
| mvrhel_laptop | From a management point of view having them all in a branch seems clean | 17:10.18 |
| ray_laptop | kens: if they aren't getting collected by the GC, then they are either still referenced, or were in non-GC memory. but if the EOJ 'restore' is freeing them, they _are_ in GC memory, just still 'active' | 17:10.35 |
| kens | ray_laptop : yes, I'm not sure whic. | 17:11.05 |
| henrys | mvrhel_laptop:I agree. | 17:11.17 |
| Robin_Watts | I see no real advantage to having them in the branch. | 17:11.18 |
| kens | pdfwrite *does* allocate stuff both in and out of GC. If it allocates it in GC it 'may' still be referencing it. | 17:11.26 |
| Robin_Watts | I would rather see them all individually tested on the cluster, personally. | 17:11.34 |
| mvrhel_laptop | they still can be | 17:11.42 |
| kens | presumed they would be | 17:11.53 |
| Robin_Watts | mvrhel_laptop: Only if done manually. | 17:12.06 |
| | And that requires manual rebasing of the branch to keep bringing it up to date with the trunk in order for the cluster test to be sane. | 17:12.43 |
| mvrhel_laptop | yes | 17:12.55 |
| Robin_Watts | (and you can't even do that if you publish the branch) | 17:13.03 |
| henrys | alexcher:okay I'm fine with alexcher continuing as is. When my office heats up for a one line change the contrib drivers that I know don't have a prayer of working with or without a change it annoys me. But carry on. | 17:14.15 |
| ray_laptop | seems like a lot of work for patches that aren't supposed to cause any issues. | 17:14.33 |
| Robin_Watts | ray_laptop: Do you ever write code intending it to cause issues? :) | 17:14.50 |
| ray_laptop | I (personally) don't have a problem with the patches as a single commit | 17:14.57 |
| chrisl | The cluster doesn't test contrib drivers, does it? | 17:15.32 |
| ray_laptop | and many of the coverity issues are in devices we don't test anyway, aren't they | 17:15.37 |
| | what chrisl said | 17:15.47 |
| chrisl | :-) | 17:15.52 |
| | So the contrib changes could be done as a single commit, or committed with "CLUSTER_UNTESTED" | 17:16.24 |
| henrys | yes CLUSTER_UNTESTED would be nice. | 17:16.50 |
| Robin_Watts | While we're on the subject of the cluster; I sent an email out yesterday about a change to offer 'filter=blah' on the clusterpush stuff. If the email is unclear, please ask me (or tell me if you find problems!) | 17:17.02 |
| ray_laptop | chrisl: I'd like for there to be a test of the batch, just in case (and for compiler errors/warnings) | 17:17.07 |
| henrys | alexcher you also brought up indeterminism - I do notice the delta log is brightly colored. | 17:17.11 |
| | do we have bugs for all the problems? | 17:17.54 |
| ray_laptop | if the changes haven't even been tested (by alexcher or someone) as a regression run, then I wouldn't want them tagged CLUSTER_UNTESTED | 17:18.34 |
| henrys | Robin_Watts:can we filter by filename ".*fts.*" and are you globbing or regexping? | 17:18.39 |
| Robin_Watts | I do if ($t =~ m/$term/) ... in perl | 17:19.08 |
| | where $term ends up with what you specify. | 17:19.22 |
| alexcher | henrys: not yet, I'll open the bugs about indeterminisms. | 17:19.36 |
| henrys | so regex | 17:19.41 |
| Robin_Watts | So to limit to files with fts in the name, just do filter=fts | 17:19.46 |
| henrys | Robin_Watts:thank you nice enhancement | 17:20.15 |
| Robin_Watts | I meant to ask marcosw how much hassle it would be to change the suffix for pdf written and ps written files to be pdfw and psw respectively. | 17:20.51 |
| | speak of the devil. | 17:21.08 |
| marcosw_ | oh oh | 17:21.14 |
| Robin_Watts | I meant to ask marcosw how much hassle it would be to change the suffix for pdf written and ps written files to be pdfw and psw respectively. | 17:21.14 |
| henrys | ray_laptop:did we ever get to the bottom of why there weren't compiler warning with the declaration mismatches in the clist code? I am concerned that might be a more widespread problem? | 17:21.24 |
| Robin_Watts | Cos that way we can do filter=pdfw etc | 17:21.26 |
| henrys | and I just had one more thing from marcosw_ if he's really here and that join was not a trick. | 17:22.23 |
| marcosw_ | Robin_Watts: I can look at it, but it affects lots of pieces of the code. | 17:22.27 |
| Robin_Watts | marcosw_: Ok, no biggy. I was hoping it might be a simple change. | 17:22.45 |
| marcosw_ | btw, sorry I was late, traffic worse the usual. | 17:22.58 |
| ray_laptop | henrys: no, I don't know why we weren't getting (at least) possible data loss warnings | 17:23.17 |
| chrisl | marcosw_: I found a support mail in the gmail spam bin, from Grant Boyle (no subject) - if you haven't seen it, you might check your spam folder (or I can forward it to you) | 17:23.21 |
| henrys | marcosw_:well 2 things: can you do a history check of william bader's problem, I think we want to understand that and (2) do you need help with the customer fixed not closed bugs - it looks like a long list. | 17:23.51 |
| marcosw_ | chrisl: It's in my in basket. | 17:23.58 |
| ray_laptop | henrys: but it _should_ be resolved now -- a lot more places touched than I initially expected | 17:23.59 |
| chrisl | marcosw_: cool, just wanted to be sure | 17:24.26 |
| henrys | ray_laptop:okay just worried because we use that calling convention a lot in the code. If none are being checked obviously not good. | 17:25.07 |
| marcosw_ | henrys: I'm behind in the fixed but not closed bugs, they usually go pretty quick, so I'll try to catch up today Can you be more specific about WIlliam Bader's problem. | 17:25.21 |
| henrys | I assigned it to you a couple days ago | 17:25.48 |
| marcosw_ | http://bugs.ghostscript.com/show_bug.cgi?id=692611 | 17:25.53 |
| ray_laptop | I'm not sure of the compiler warning issues. If a function expects int64_t and is called with an 'int', doesn't it silently promote it ? | 17:25.58 |
| henrys | marcosw_:right | 17:27.05 |
| | ray_laptop:yes but with a declaration you should get a warning right? | 17:27.22 |
| ray_laptop | OTOH, something like: int code = clist_io_procs->ftell(...) _should_ generate a "possible data loss" warning | 17:27.42 |
| henrys | doesn't match prototype or something | 17:27.43 |
| ray_laptop | henrys: I really don't know. Anybody else a C99 expert w.r.t warnings | 17:28.46 |
| | ? | 17:28.49 |
| henrys | yes I was wondering if the compiler is only checking direct function calls and not checking when the function has to be had from a pointer. | 17:29.08 |
| ray_laptop | henrys: that would be pretty lame. How else would it know what to pass ? | 17:30.13 |
| henrys | anyway anything else for the meeting? | 17:30.15 |
| kens | Nope | 17:30.28 |
| marcosw_ | I'm a bit confused by the bug report, Comment #0 says that 9.04 takes 7+ hours and Comment #2 says 60 minutes. Or are we mostly concerned with the 8.54 to 8.56 performance decrease (3 minutes to 32 minutes)? | 17:30.32 |
| mvrhel_laptop | nothing from me | 17:30.38 |
| | hoping to get Robin's patch finished up | 17:30.51 |
| ray_laptop | mvrhel_laptop: at some point I'd like to do more brainstorming on better support for separations (using planar mem devices and HL color calls) | 17:31.09 |
| mvrhel_laptop | and trying to work with a friend at GM for Scott. | 17:31.18 |
| ray_laptop | marcosw_: what bug ? | 17:31.30 |
| mvrhel_laptop | ray_laptop: ok | 17:31.30 |
| henrys | chrisl:how's freetype type 1 | 17:31.32 |
| | ? | 17:31.34 |
| marcosw_ | http://bugs.ghostscript.com/show_bug.cgi?id=692611 | 17:31.43 |
| henrys | marcosw_:both really. | 17:31.54 |
| ray_laptop | marcosw_: thx | 17:31.57 |
| alexcher | ray_laptop: MSVC generates about 1500 warnings at -W3 level. The question is how much heat fixing them will create on the cluster and the IRC? | 17:31.58 |
| mvrhel_laptop | gawd. those should be combined | 17:32.25 |
| | as best as possible | 17:32.30 |
| chrisl | henrys: I've passed a first attempt at the freetype end over to Werner - I'm waiting to hear back (he's quite busy just now). I don't want to start the GS end of things until the FT side is agreed. | 17:32.35 |
| henrys | chrisl:we can't just get an okay on the api and go forward? | 17:33.50 |
| | anyway past 10:30 don't want to hold folks up. | 17:34.35 |
| chrisl | henrys: that's what I'm waiting for. As I said, Werner is busy with his own work, so I'm going to leave a day or so before I bug him about it | 17:34.41 |
| marcosw_ | since I came 15 late I'll stay till 45 past the hour. | 17:35.00 |
| chrisl | henrys: I mean "another day or so" before I bug him | 17:35.18 |
| henrys | chrisl:okay so this is not a matter of wait for months - that was my first take. | 17:35.38 |
| chrisl | henrys: no, I only sent him the patch on Friday. | 17:36.19 |
| marcosw_ | I should mention that I'll be in Germany next week, but will have good internet access so it won't be an issue (other than that I'll be online at CET times rather than PST). | 17:36.36 |
| henrys | marcosw_:okay then you don't want support coverage? | 17:37.12 |
| marcosw_ | no, shouldn't be necessary. | 17:37.46 |
| ray_laptop | I'm (trying to) take a short break from bugs to work on cleaning up 'gen_stochastic' (formerly genpat) and add in the multi-level threshold support | 17:38.56 |
| | so I can get it committed (finally) to toolbin. | 17:39.15 |
| Robin_Watts | marcosw_: I haven't committed my cluster changes to git -wanted to give you a chance to look at them first. | 17:39.33 |
| ray_laptop | mvrhel_laptop: any problem with me adding it to the toolbin/color/halftone as a sub-directory ? | 17:39.50 |
| marcosw_ | Robin_Watts: I'll do that. | 17:39.55 |
| henrys | ray_laptop:okay it will be nice to have that, when is mvrhel_laptop going to pull out wts? | 17:40.04 |
| mvrhel_laptop | ray_laptop: that sounds good about adding it | 17:40.39 |
| kens | Off for the night. Goodnight all. | 17:40.47 |
| mvrhel_laptop | henrys: I will try to rip out wts this week | 17:40.55 |
| ray_laptop | mvrhel_laptop: is the location OK, or do you want me to put it somewhere else ? | 17:41.00 |
| mvrhel_laptop | ray_laptop: that makes the most sense to me. I was thinking that I should pull hafltone out of color though and have it be toolbin/halftone | 17:41.37 |
| ray_laptop | mvrhel_laptop: and I was going to rename 'linearize_threshold' to 'thresh_remap' (unless you have a better name) | 17:41.42 |
| | mvrhel_laptop: moving it out of color makes sense to me | 17:42.05 |
| mvrhel_laptop | ok | 17:42.15 |
| | ray_laptop: can you go ahead and do that since you are adding your stuff? | 17:42.39 |
| ray_laptop | mvrhel_laptop: sure, I'll go ahead and move it | 17:42.52 |
| mvrhel_laptop | ok thanks | 17:43.03 |
| | ray_laptop: then move my project into a subfolder of ordered dithered | 17:43.34 |
| | or something | 17:43.38 |
| | like that | 17:43.40 |
| | please | 17:43.42 |
| ray_laptop | mvrhel_laptop: OK. how about 'gen_ordered' ?? | 17:43.59 |
| mvrhel_laptop | sounds good | 17:44.05 |
| marcosw_ | Robin_Watts: your filter changes to the cluster look fine, a bit hard to follow with all the uncommitted changes to the various source files I had made over the last few weeks/months (oops, I must stop doing that). | 17:44.31 |
| Robin_Watts | marcosw_: This may be a stupid question, but is there a perl equivalent of "indent" we could run on the code ? | 17:45.25 |
| ray_laptop | mvrhel_laptop: so we'll have halftone/gen_ordered halftone/gen_stochastic and halftone/thresh_remap under toolbin, right ? | 17:45.32 |
| mvrhel_laptop | yes. that sounds perfect | 17:45.54 |
| Robin_Watts | tor8: Right. If I disable the linear interpolation stuff, then with the new gridfitting code, it seems to match well. | 17:46.05 |
| marcosw_ | yes, hold on a sec (though you'll incur henrys' wrath regarding whitespace changes) :-) | 17:46.11 |
| Robin_Watts | tor8: Want a patch to test? | 17:46.15 |
| | marcosw_: henrys is sensible enough not to look at the cluster code, I think :) | 17:46.31 |
| | marcosw_: We should do that as a separate commit though. | 17:46.47 |
| tor8 | Robin_Watts: sure. | 17:46.49 |
| ray_laptop | is sensible enough not to expect ANY perl code to be 'pretty' | 17:46.54 |
| marcosw_ | Robin_Watts: ~regression/bin/perltidy (the options that match my perl style can be found in ~regression/bin/mytidy). | 17:47.32 |
| henrys | you can't add noise to perl. | 17:47.39 |
| ray_laptop | running indent on perl code probably just prints out a warning "Ha, Ha, you're kidding, right?" | 17:47.56 |
| Robin_Watts | tor8: http://ghostscript.com/~robin/0001.patch | 17:48.04 |
| | tor8: remember to build 3 times, right? :) | 17:48.20 |
| tor8 | I've fixed the dependency brokenness of Xcode, but in essence, yes :) | 17:48.49 |
| ray_laptop | mvrhel_laptop: do you prefer gen_ordered or gen_clustered | 17:50.01 |
| mvrhel_laptop | ray_laptop: I think I prefer ordered. It would be possible to do a dispersed order. Not sure who would want to do such a thing | 17:50.46 |
| ray_laptop | mvrhel_laptop: I think there is a typo in the README: size_of_supercell should not be set to something reasonably large to achieve a specified target_quantization_levels. | 17:51.39 |
| | mvrhel_laptop: I think the 'not' is wrong | 17:51.51 |
| mvrhel_laptop | yes. that is wrong | 17:52.05 |
| ray_laptop | OK. | 17:52.11 |
| mvrhel_laptop | thanks | 17:52.13 |
| ray_laptop | mvrhel_laptop: can the target_quantization_levels be > 256 ?? | 17:52.29 |
| Robin_Watts | ray_laptop: While you're changing it... what constitutes "reasonably large"? | 17:52.33 |
| mvrhel_laptop | mumble something to myself about checking my work. something I had to tell my 10 year old this week | 17:52.47 |
| Robin_Watts | maybe add (e.g. 15) ? | 17:52.59 |
| ray_laptop | Robin_Watts: I think it will eventually be fixed (the next comment is: Work is underway to have this value optimally set based upon the desired number of gray levels) | 17:53.19 |
| | Robin_Watts: there is a 'For example 64' comment | 17:53.50 |
| Robin_Watts | fair enough. | 17:53.50 |
| mvrhel_laptop | oh two editors | 17:53.52 |
| Robin_Watts | oh, spot on then :) | 17:53.58 |
| ray_laptop | two editors never agree :-( | 17:54.32 |
| Robin_Watts | removes nose from other peoples business :) | 17:54.52 |
| tor8 | Robin_Watts: I still see shifting :( | 17:55.07 |
| Robin_Watts | as bad ? | 17:55.18 |
| mvrhel_laptop | ray_laptop: I can output 16 bit level screens | 17:55.18 |
| | so I think in theory I could have more than 256 levels | 17:55.37 |
| tor8 | less bad on the inlaid pictures, just as bad on the big backdrop | 17:55.39 |
| marcosw_ | Robin_Watts: the biggest problem with the cluster code is that I also run it as the nightly regression code, the weekly regression code, the performance regression code, and use it to run tests such as comparing lcms1 to lcms2. Unfortunately I'm really, really lazy when it comes to keeping the different bits in sync (about once every three months I spend half a day using vimdiff and swearing a lot). \ | 17:56.16 |
| mvrhel_laptop | ray_laptop: I suppose I should beat on the code a bit more to see if anything explodes in these extreme cases | 17:56.55 |
| ray_laptop | mvrhel_laptop: didn't you add an option to output the 'raw' threshold order as 'thresh_remap' will expect ? | 17:57.40 |
| mvrhel_laptop | yes I did | 17:57.47 |
| | did I not add it to the README | 17:57.56 |
| Robin_Watts | tor8: Odd. I'm testing with a cutdown pdf file with just that big backdrop in :( | 17:58.01 |
| mvrhel_laptop | I may have only added it to the command options | 17:58.09 |
| | information | 17:58.15 |
| ray_laptop | is just looking at the README. I'll check the code for the option and update it | 17:58.16 |
| mvrhel_laptop | I think I need to update the README. there we a bunch of stuff that I added in the options | 17:58.43 |
| | s/we/was/ | 17:58.50 |
| Robin_Watts | tor8: Could you try to find a pdfdraw invocation that will reproduce the problem please? | 17:58.54 |
| tor8 | Robin_watts: and with the a.png and b.png test, the backdrop is in the right spot, but the inlaid pictures shift | 17:59.00 |
| | ./build/debug/pdfdraw -o b.png -r200 ~/Dropbox/Dragon\ Age\ Origins\ -\ Prima\ Official\ Game\ Guide.pdf 217 | 17:59.33 |
| | -r50 for a.png | 17:59.36 |
| | open them up, scale b.png by 25% and flip between the two | 17:59.50 |
| Robin_Watts | Right. That I can do. | 18:00.01 |
| tor8 | the lower right decoration frame seems to shift about two pixels | 18:00.27 |
| | let me try to see what happens with scaling and grid fitting and bilinear sampling all off | 18:02.29 |
| Robin_Watts | Just uploading my results from that... | 18:02.53 |
| | http://ghostscript.com/~robin/out200to50.png | 18:03.21 |
| | http://ghostscript.com/~robin/out50.png | 18:03.43 |
| | As far as I can tell, the background bitmaps don't move at all between the two. | 18:05.14 |
| | The inlaid images move slightly (not the bboxes, but the contents thereof) | 18:05.40 |
| tor8 | Robin_Watts: this is with everything off? | 18:06.12 |
| Robin_Watts | That's exactly as I sent you the patch. | 18:06.25 |
| tor8 | okay! | 18:06.30 |
| Robin_Watts | (i.e. all grid fitting on, but interp off) | 18:06.37 |
| tor8 | that's what I'm seeing on my iPad too | 18:06.38 |
| | it's the image contents shifting that made me notice this in the first place | 18:07.04 |
| henrys | uh oh Robin_Watts cruising around FL on the right side of the road. | 18:07.40 |
| Robin_Watts | henrys: the "wrong" side of the road :) | 18:07.58 |
| henrys | I had relatives in the Virgin Islands they have american cars steering on right but drive on the left that was fun! | 18:09.18 |
| tor8 | http://ghostscript.com/~tor/stuff/scaling/a-off.png | 18:09.23 |
| | http://ghostscript.com/~tor/stuff/scaling/b-off.png | 18:09.26 |
| | that's with no interpolation, no scaling, no grid fitting | 18:09.34 |
| henrys | or steering on the left... | 18:09.36 |
| Robin_Watts | henrys: wierd. | 18:09.57 |
| | tor8: I'm having real trouble seeing anything that offensive in your last two links. | 18:16.48 |
| tor8 | Robin_Watts: with those images, I see the contents remain more stable, but it seems to still shift a bit | 18:16.59 |
| Robin_Watts | The worst movement I can see is with the 'Fade Shapeshifting' box on the right. | 18:17.13 |
| marcosw_ | you'd think there would be an inherent advantage of having the driver sitting on the left or the right based on right-handedness being dominant (I'd argue that shifting with the right hand is easier than shifting with the left, but shifting with the left hand felt pretty normal after a week of driving in the UK the last time I was there). Thank dog the the brake/gas/clutch pedals aren't rearranged. | 18:17.14 |
| ray_laptop | mvrhel_laptop: can I change the gen_ordered to use -f [b | ps | ppm | tos] or something ? (and of course README changes to match) ? | 18:17.23 |
| mvrhel_laptop | ray_laptop: that is fine | 18:17.42 |
| tor8 | http://ghostscript.com/~tor/stuff/scaling/a-scale.png is 50dpi, scaling, no grid fit (no grid-fit in transform_pixmap either) | 18:17.46 |
| Robin_Watts | marcosw_: I'd rather have the dominant hand on the wheel, I think :) | 18:17.51 |
| ray_laptop | mvrhel_laptop: OK thanks. It makes the README easier | 18:17.56 |
| | Robin_Watts: not to mention holding you lance or sword in your right hand for those vehicle josts ;-) | 18:18.59 |
| marcosw_ | from what little I know about jousting I believe the lance is held in the right hand but diagonally across the horse. | 18:19.44 |
| Robin_Watts | ray_laptop: That's true. We have the dominant hand to give people the finger with. | 18:19.46 |
| marcosw_ | http://en.wikipedia.org/wiki/File:Broken_lances.jpg | 18:20.21 |
| | or http://en.wikipedia.org/wiki/File:Modern-Knight.jpg | 18:20.46 |
| | the second image is from california, so it's possible that jousting in the UK is performed the other way round. | 18:21.22 |
| tor8 | Robin_Watts: okay, on the iPad, with scaling, interpolation but no grid fitting anywhere, it behaves perfectly | 18:24.23 |
| mvrhel_laptop | bbiaw | 18:24.41 |
| Robin_Watts | tor8: Right. | 18:24.48 |
| tor8 | I do however see gaps, but the scaling and positioning seems right | 18:25.14 |
| Robin_Watts | Well, rendering at different sizes with grid fitting is going to make image contents 'swim'. | 18:25.26 |
| tor8 | white lines between the inlaid picture and the frame around it | 18:25.27 |
| Robin_Watts | I can't see a way around that. | 18:25.55 |
| tor8 | it looks like it's fading out to transparent a row/column early | 18:26.13 |
| | yeah, grid fitting was the first thing I tried tweaking, but I forgot about the grid fitting in the scaling code | 18:26.49 |
| Robin_Watts | Ah. I forgot it the other way around :) | 18:27.06 |
| | With everything on (except interp), a direct comparison of 50dpi and 50dpi without scaling enabled comes back 'unswimmy'. | 18:27.48 |
| | tor8: Do you have an options page? :) | 18:30.42 |
| tor8 | nope! | 18:32.19 |
| | okay, between lerp and nearest neighbor the images still shift a device pixel though | 18:33.02 |
| | s/device/texel/ | 18:33.06 |
| | so the point sampling of NN is probably off center | 18:33.17 |
| Robin_Watts | OK. I'll look at that. | 18:33.52 |
| tor8 | forced interpolation, scaling, never grid fitting works great | 18:33.58 |
| | I believe we do grid fitting for two main reasons: | 18:34.10 |
| Robin_Watts | except for the white lines. | 18:34.16 |
| tor8 | 1) latex documents that draw table borders with 1x1 images | 18:34.27 |
| | 2) the white cracks when image are drawn piecemeal | 18:34.49 |
| Robin_Watts | tor8: More generally, there are a (large) sub class of pdf files out there that use nx1 images to build up full bitmaps. | 18:35.28 |
| tor8 | we might get away with 2 by not antialiasing; I wonder what apple does to solve this | 18:35.40 |
| Robin_Watts | I think grid fitting is unavoidable, personally. | 18:35.58 |
| tor8 | Robin_Watts: the gaps I mentioned earlier between the inlay and the frame were due to nearest neighbor being off | 18:36.24 |
| Robin_Watts | really? | 18:36.45 |
| | NN vs lerp should never affect what destination pixel gets written - just the value that gets written to it. | 18:37.12 |
| tor8 | well, it was picking transparent pixels | 18:38.09 |
| | like it was off by 1/2 texture column, and that at a size where each texel covers 8 pixels is a 4 pixel gap | 18:38.42 |
| Robin_Watts | ok. | 18:39.27 |
| | tor8: if (!dolerp) { u += 32768; v += 32768; } | 18:40.53 |
| | tor8: What page of that file were you seeing the gaps in? | 18:41.38 |
| tor8 | 217 | 18:42.01 |
| | top left image, along the left edge | 18:42.08 |
| | the topmost screenshot in the left column | 18:42.31 |
| Robin_Watts | At what res? (or maybe you don't know in the viewer?) | 18:45.27 |
| tor8 | fairly high | 18:45.58 |
| | can't tell exactly | 18:46.02 |
| | about 300dpi or so, but visible at lower resolutions too | 18:46.20 |
| | argh. now I'm not getting the crack! | 18:47.46 |
| | Robin_Watts: okay, I know what I saw. without forcing dolerp, so mixing interpolated screenshot with non-interpolated backdrop is what gave me the big crack. | 18:51.25 |
| | the u += 0.5 reduces it by a lot, but introduces other shifting | 18:53.26 |
| Robin_Watts | I see no other shifting here; can you give me a pointer ? | 18:55.56 |
| | (I still have gridfitting on) | 18:56.48 |
| tor8 | you really need to look at the zoomed in view | 18:58.42 |
| | the image shifts in relation to the text | 18:58.59 |
| | with forced interpolation, things are the most stable | 18:59.14 |
| Robin_Watts | the bbox of the image changes ? | 18:59.22 |
| tor8 | it almost looks that way | 18:59.36 |
| | and I've turned off grid fitting | 18:59.41 |
| | or the whole bbox is shifted | 18:59.51 |
| | you should get an iPad as well ;) | 19:00.52 |
| | or reimplement my app in android... | 19:01.04 |
| | or wait until miami | 19:02.42 |
| Robin_Watts | I think the if (!dolerp) { u += 32768; v += 32768; } is correct. | 19:06.06 |
| | I'd hope it's better now than it was this morning? | 19:06.46 |
| | I vote we wait for miami. | 19:06.50 |
| tor8 | I think the half-step addition we do should only be done for the dolerp case | 19:11.31 |
| | anyway, I too vote for miami | 19:11.36 |
| | this needs four eyes on the same screen and lots of fingerprints on the screen | 19:11.59 |
| Robin_Watts | tor8: Urm... | 19:12.12 |
| tor8 | no wait, the half step is to adjust for the device pixels | 19:12.49 |
| | center | 19:12.51 |
| Robin_Watts | The half step addition we already do is because we want to sample the centre of the device pixels. Yes :) | 19:13.02 |
| tor8 | I should get back to messing with iOS frameworks, that needs less brainpower :) | 19:13.12 |
| Robin_Watts | hence that's the same for both. | 19:13.14 |
| | but *really* we should adjust every single non lerp painting routine to offset by 0.5 - but that's too hard, hence the if (!dolerp) { u += 32768; v += 32768; } | 19:14.13 |
| tor8 | so, if I grid fit in the matrix but not the scaler, I get the expected shifting from that | 19:17.01 |
| | but if I also grid fit in transform_pixmap, I get twice the shifting | 19:17.14 |
| | this is with your patched grid fitting | 19:17.23 |
| Robin_Watts | That's strange. | 19:18.00 |
| tor8 | looking at the page number circle | 19:18.16 |
| Robin_Watts | If we grid fit in the scaler, then the ctm should come out all integers. | 19:18.17 |
| | so the grid fitting in transform_pixmap shouldn't do anything. | 19:18.31 |
| tor8 | other places they match up | 19:18.34 |
| Robin_Watts | Can you get debug out? | 19:19.18 |
| | print the before/after gridfitting values? | 19:19.32 |
| tor8 | sure. | 19:20.14 |
| Robin_Watts | If we ever see adjustments in both places, that's a mistake. | 19:21.15 |
| tor8 | grid fit 0: 7280 0 0 -5020 -3640 5020 | 19:22.02 |
| | grid fit 1: 7281 0 0 -5021 -3641 5021 | 19:22.02 |
| | that's before and after fitting in fz_paint_image_imp | 19:22.42 |
| Robin_Watts | Are you forcing those numbers to be ints ? | 19:24.11 |
| tor8 | printf %g | 19:24.22 |
| Robin_Watts | Well, that makes no sense. | 19:25.32 |
| | We'd go into the first case of the if. | 19:25.40 |
| | f = 7280 | 19:25.49 |
| | Sorry, f = -3640 | 19:26.06 |
| | f is not > -3640 | 19:26.18 |
| | so ctm.e = -3640 - i.e. no change. | 19:26.32 |
| | You could try replacing the (float)(int)x things with floorf(x) ? | 19:27.40 |
| | but that really smells like a floating point wierdness there. | 19:28.04 |
| tor8 | grid fit 0: 7280 0 0 -5020 -3640 5020 | 19:29.08 |
| | grid fit 1: 7281 0 0 -5021 -3641 5021 | 19:29.08 |
| | no change with floorf | 19:29.22 |
| Robin_Watts | Can you step through that code? | 19:29.50 |
| | or maybe print f ? | 19:29.58 |
| tor8 | grid fit 0: 7280 0 0 -5020 -3640 5020 | 19:31.20 |
| | f = -3641 | 19:31.20 |
| | grid fit 1: 7281 0 0 -5021 -3641 5021 | 19:31.20 |
| Robin_Watts | How do you know this case has been through the scalers gridfitting already? | 19:32.14 |
| tor8 | ah! | 19:32.24 |
| | gotcha | 19:32.26 |
| | it hasn't | 19:32.40 |
| Robin_Watts | ah, phew. | 19:32.45 |
| | %.3g maybe ? | 19:32.55 |
| tor8 | http://ghostscript.com/~tor/stuff/scaling/Screen%20shot%202011-11-08%20at%208.34.20%20PM.png | 19:35.13 |
| | can you see the shift there? | 19:35.19 |
| Robin_Watts | Vertically, yes. | 19:36.07 |
| tor8 | yup. that's what I've been seeing variations of for two days staring at this >.< | 19:36.28 |
| | the only solution I have now is to turn off grid fitting and force interpolation. that gives the expected rendering all the time. | 19:36.57 |
| | both grid fitting and nearest neighbor sampling seem to have issues. | 19:37.13 |
| Robin_Watts | hold on. | 19:37.15 |
| | You said earlier: | 19:37.20 |
| | so, if I grid fit in the matrix but not the scaler, I get the expected shifting from that | 19:37.42 |
| | but if I also grid fit in transform_pixmap, I get twice the shifting | 19:37.44 |
| tor8 | one sec, making another screen shot with only the paint_imp fitting | 19:38.10 |
| Robin_Watts | Just so I'm clear on this... if you grid fit *only* in the fz_paint_image_imp, you get what you expect, but enabling the grid fitting in fz_scale_pixmap_gridfit doubles the effect ? | 19:39.14 |
| tor8 | http://ghostscript.com/~tor/stuff/scaling/Screen%20shot%202011-11-08%20at%208.39.07%20PM.png -- with grid fitting only in fz_paint_image_imp | 19:40.35 |
| | http://ghostscript.com/~tor/stuff/scaling/Screen%20shot%202011-11-08%20at%208.39.38%20PM.png -- with no grid fitting at all | 19:40.56 |
| Robin_Watts | Right. With no grid fitting at all, I'd expect us to get pretty much perfect results. | 19:42.43 |
| | and it looks like we are. | 19:42.49 |
| | BUT we have the problem with cracks and disappearing images. | 19:43.03 |
| tor8 | yup. until we start doing nearest neighbor, but that may just be on account of being nearest neighbor. | 19:43.09 |
| Robin_Watts | right. | 19:43.18 |
| | So enabling grid fitting in fz_paint_image_imp should make the shifting "a bit worse". | 19:43.41 |
| tor8 | as in the last screenshot, no grid fitting, forced linear interpolation, we get good stable results always | 19:43.44 |
| Robin_Watts | The thing that concerns me, is that when we enable grid fitting in both places, we get "much worse". | 19:44.12 |
| tor8 | yeah. it doesn't make sense either. the matrix doesn't look like it's changed. | 19:44.36 |
| Robin_Watts | What happens if you only grid fit in the scaler? | 19:44.44 |
| | (maybe the scalers grid fitting is broken?) | 19:45.04 |
| tor8 | eh, right! you're on to something there. | 19:45.40 |
| | it looks identical to the twice-fit result | 19:45.47 |
| Robin_Watts | OK, so lets get some before/after figures for the scalers grid fitting. | 19:46.28 |
| tor8 | grid fit scale 0: 1456 0 0 -1004 -728 1004 | 19:48.54 |
| | grid fit scale 1a: 1456 0 0 1005 -728 0 | 19:48.54 |
| | grid fit paint 3: 1456 0 0 1005 -728 0 | 19:48.55 |
| | grid fit paint 4: 1456 0 0 1005 -728 0 | 19:48.55 |
| Robin_Watts | OK, I need decimal places :) | 19:49.06 |
| tor8 | that's with %g, let me get you %f | 19:49.16 |
| | grid fit scale 0: 1456.000000 0.000000 0.000000 -1004.000061 -728.000000 1004.000061 | 19:49.57 |
| | grid fit scale 1a: 1456 0 0 1005 -728 0 | 19:49.57 |
| | grid fit paint 3: 1456 0 0 1005 -728 0 | 19:49.57 |
| | grid fit paint 4: 1456 0 0 1005 -728 0 | 19:49.57 |
| Robin_Watts | Eh? From -1004 to 1005 ? | 19:50.01 |
| tor8 | you flipped vertically | 19:50.09 |
| | the translation is also changed | 19:50.17 |
| Robin_Watts | right. | 19:50.23 |
| tor8 | grid fit scale 0: 1456.000000 0.000000 0.000000 -1004.000061 -728.000000 1004.000061 | 19:50.48 |
| | grid fit scale 1a: 1456.000000 0.000000 0.000000 1005.000000 -728.000000 0.000000 | 19:50.49 |
| Robin_Watts | Can you print out the changed matrix in fz_scale_pixmap_gridfit before you call fz_scale_pixmap ? | 19:51.02 |
| | -1004.and a tiny bit. | 19:51.53 |
| tor8 | grid fit scale 0: 1456.000000 0.000000 0.000000 -1004.000061 -728.000000 1004.000061 | 19:52.42 |
| | scale 0 xywh = -728.000000 1004.000061 1456.000000 -1004.000061 | 19:52.42 |
| | scale 1 xywh = -728.000000 1005.000000 1456.000000 -1005.000000 | 19:52.42 |
| | grid fit scale 1a: 1456.000000 0.000000 0.000000 1005.000000 -728.000000 0.000000 | 19:52.42 |
| Robin_Watts | Oh! | 19:53.02 |
| | Oh! Me so fool. | 19:53.07 |
| | Oh, no, wait, I see what I did. | 19:54.04 |
| | I suspect the problem is that I'm detecting -1004.000061 as being non integer, when really I should accept that as 'close enough'. | 19:55.05 |
| ray_laptop | my youngest (age 6) has to do a "family tree" going back to great-grandparents -- I bet he's the only one that has a great-grandfather born in 1853 ! | 20:03.07 |
| Robin_Watts | mvrhel: Just booking car now. I'm getting a 5 seater. | 20:28.11 |
| | If it turns out that you don't get one, we can always sort out upgrading it nearer the time. | 20:28.24 |
| mvrhel | Robin_Watts: ok | 20:28.46 |
| | are you getting one for the whole time or just to get from the airport to the hotel? | 20:28.59 |
| Robin_Watts | We arrive on tuesday afternoon, so I'll get it from then til thursday night. | 20:29.22 |
| mvrhel | ah. ok. that makes sense | 20:29.31 |
| | so with your 5 seater you can carry you, helen, chris, and ken | 20:30.03 |
| Robin_Watts | Miles is getting a 7 seater. | 20:30.19 |
| mvrhel | oh wait we have tor + 1 and scott and ellen | 20:30.23 |
| Robin_Watts | And there are 13 of us. | 20:30.24 |
| mvrhel | oh is miles doing the tour too | 20:30.30 |
| Robin_Watts | indeed. | 20:30.34 |
| mvrhel | how many is he bringing? | 20:30.43 |
| Robin_Watts | just miles. | 20:30.47 |
| mvrhel | oh. we have seating for 12 and there are 13 of use | 20:31.10 |
| | us | 20:31.14 |
| | when is miles arriving? | 20:31.22 |
| Robin_Watts | Miles arrives wednesday night, collects 7 seater van and drives to hotel in it. | 20:31.47 |
| | So we'll have miles 7 + my 5 + yours if you have one. | 20:31.58 |
| | If you don't, then I'll get a larger car. | 20:32.19 |
| mvrhel | ok. I need to check on this. I will do some looking tonight | 20:32.24 |
| Robin_Watts | ok. | 20:32.41 |
| | I'm going to book now - I'm sure they'll be happy to upgrade me if needs be. | 20:33.04 |
| mvrhel | of course | 20:33.14 |
| | wow. car rental prices are high here | 20:34.12 |
| Robin_Watts | mvrhel: Are you lookin at hertz? | 20:34.29 |
| mvrhel | hertz is super high | 20:34.48 |
| Robin_Watts | hertz is close to the hotel :) | 20:35.09 |
| | 81quid for tuesday -> thursday - doesn't seem to bad to me. | 20:35.23 |
| mvrhel | that is not bad | 20:35.31 |
| | I am seeing that rate per day | 20:35.38 |
| Robin_Watts | really? I'm on hertz.com | 20:36.01 |
| mvrhel | well I was doing a search of all of them on expedia | 20:36.15 |
| | let me check hertz and also costco | 20:36.21 |
| | are you renting from the airport | 20:37.43 |
| | and dropping off locally | 20:37.48 |
| Robin_Watts | yes. | 20:37.58 |
| mvrhel | which is the return location? | 20:39.48 |
| Robin_Watts | Eden Roc Renaissance | 20:40.10 |
| | 4525 Collins Avenue | 20:40.12 |
| | Miami Beach, FL, US | 20:40.14 |
| | The hotel us 4833 Collins Ave. | 20:40.53 |
| | all booked. being called for food. bbiab. | 20:41.41 |
| mvrhel | hmm for some reason the cost of picking up at the airport is about 90+ a day | 20:41.56 |
| | from hertz | 20:42.00 |
| | I will look this over more later | 20:42.05 |
| | going to eat now | 20:42.09 |
| | Forward 1 day (to 2011/11/09)>>> | |
IRC Logs
