| | <<<Back 1 day (to 2012/11/13) | 2012/11/14 |
| chrisl_r61 | But it's late here, and I'm knackered, so g'nite! | 00:00.53 |
| Robin_Watts | mvrhel: I fixed the planes so they are offset from one another. | 00:16.58 |
| | And I added a -n flag so you can set the scale for the random noise. 0 is the lowest possible, 1 twice as noisy, etc. | 00:17.29 |
| | previously the code was defaulting to 5. | 00:17.45 |
| | but I haven't actually changed anything there. | 00:18.05 |
| | If you get around to looking at compute_randshift, we can talk about what I reckon it does. | 00:18.55 |
| mvrhel | Robin_Watts: ok | 00:23.25 |
| tkamppeter | oy, hi | 13:19.44 |
| oy | tkamppeter, hello | 13:40.44 |
| Robin_Watts | has a profile of MuPDF on android. | 14:37.14 |
| | time seconds seconds calls s/call s/call name | 14:38.47 |
| | 57.81 55.91 55.91 35733886 0.00 0.00 cmyk_to_rgb | 14:38.49 |
| | tor8: ping | 14:49.09 |
| tor8 | Robin_Watts: hey | 14:49.31 |
| Robin_Watts | hey. So any thoughts on cmyk_to_rgb? | 14:49.44 |
| | That's so far and above any other contribution for this file. | 14:50.02 |
| tor8 | #undef SLOWCMYK | 14:50.35 |
| Robin_Watts | won't that look horrid? | 14:50.51 |
| tor8 | yes :) | 14:50.55 |
| kens | cheap fast or good :-) | 14:51.07 |
| tor8 | we could build a 3d lookup table of the SLOWCMYK math and do interpolated sampling | 14:51.33 |
| Robin_Watts | kens: Right, we only want 2 of the 3 : ) | 14:51.39 |
| tor8 | 15*15*15 or something like that | 14:51.41 |
| Robin_Watts | tor8: 15*15*15*15? | 14:51.57 |
| tor8 | s/15/16/g | 14:51.57 |
| kens | Robin_Watts : MuPDF is already cheap so you cnaonly have fast or good | 14:52.07 |
| tor8 | oh right, 4-dimensional. ick. | 14:52.19 |
| | or we could do the K as a pre-lookup step | 14:52.31 |
| Robin_Watts | I think there is scope for optimising the maths. | 14:52.32 |
| | and we could convert to fixed point rather than FP (which would, I suspect, help a lot on ARM) | 14:53.16 |
| tor8 | vectorize the math :) | 14:53.22 |
| Robin_Watts | tor8: It's a per pixel call; can't do multiple pixels at once. | 14:54.00 |
| chrisl | Cache the result(s), and avoid the math for repeated sample values? | 14:54.06 |
| tor8 | we should check if cmyk_to_rgb is inlined in the fast_cmyk_to_rgb/bgr cases for pixmaps | 14:54.11 |
| | Robin_Watts: yeah, we do the per-pixel call because it's a long function for converting pixmaps | 14:54.31 |
| Robin_Watts | Let me run this file through very sleepy to see the call sequence. | 14:54.48 |
| tor8 | that also goes through the unsigned char -> float and back conversions | 14:54.57 |
| Robin_Watts | It's called from fast_cmyk_to_rgb | 14:58.51 |
| | and that's called from fz_convert_pixmap | 14:59.07 |
| | at that from fz_draw_fill_image | 14:59.20 |
| tor8 | right. so two easy targets: (1) do we cache the color converted pixmaps? (2) inline or write a batch version of the math, without floating point math, in fast_cmyk_to_rgb | 15:00.17 |
| | or (3) use a lookup table for fast_cmyk_to_rgb | 15:00.42 |
| Robin_Watts | 1) We don't. I was just pondering if we should change fz_image_to_pixmap to take a target colorspace. | 15:01.12 |
| | And it could do the color conversion for us (and hence cache the color converted ones). | 15:01.34 |
| | It might also allow things like only decoding JPEGs to grayscale rather than to RGB if we wanted to get smart. | 15:01.57 |
| tor8 | the color conversion will still be slow though. fz_std_conv_pixmap does memoization but that won't help for contone images | 15:02.49 |
| Robin_Watts | but I'm gonna have a stab at 2. | 15:02.55 |
| | Cos 2 will help even if we later do 1. | 15:03.06 |
| tor8 | (2) is probably easiest and will give the most significant boost if it pans out | 15:03.23 |
| | a 4d lookup table is probably going to be just as slow as a matrix mult | 15:03.35 |
| Robin_Watts | tor8: howso? | 15:04.43 |
| | This is a fixed conversion of course... I reckon a 4d lookup table might be the way to go. | 15:05.17 |
| | Let me try that. | 15:05.21 |
| tor8 | interpolating in 4 dimensions is going to be a lot of mults too | 15:05.30 |
| | and the size of the table might bump things out of the cache | 15:05.47 |
| | cpu cache* | 15:05.51 |
| | but it's worth trying both approaches | 15:06.07 |
| | if we do the lookup table, we can stick a better CMYK profile in there | 15:06.26 |
| | which is of course an added bonus :) | 15:06.41 |
| Robin_Watts | If we're going 8bit -> 8 bit, then we only need to use chars for the lookup table. | 15:07.12 |
| | 8x8x8x8 = 4096 = 4K. | 15:07.21 |
| | oh, x3 = 12k :( | 15:08.02 |
| tkamppeter | oy, can you report a bug about the auto-selection of the default (first) output intent? | 15:51.09 |
| kens | tkamppeter : oy is gone I think | 16:05.27 |
| tkamppeter | kens, I will tell it to him by e-mail, so that he gets it for the start of tomorrow's workday. | 16:26.43 |
| Robin_Watts | tor8: I've got a reformulated version of cmyk_to_rgb here; avoids many muls. | 16:36.19 |
| | Gives visually identical results on windows, and is a tiny bit faster (but the timings for that function were small on windows anyway). | 16:36.51 |
| | Rebuilding for android now. | 16:36.58 |
| ray_laptop | finally getting the fuzz out of my head. No more cold meds, and using coffee as a solvent helps | 16:48.24 |
| | Robin_Watts: 4k entries is enough for a lookup on 3-bits per component (12kbytes) | 16:49.16 |
| Robin_Watts | ray_laptop: Right. 12K is too much. | 16:49.38 |
| ray_laptop | Robin_Watts: so for a cache, I've used the low bits off of each component as the cache key, which takes 32-bits for the CMYK value plus 24 bits for the RGB, thus 7 bytes per cache slot | 16:50.58 |
| | 7 * 4k entries is 28Kb | 16:51.37 |
| Robin_Watts | Search time in such a cache would be prohibitive. | 16:52.22 |
| ray_laptop | Robin_Watts: are CMYK images even that common, though ? Or is this just one example that is really slow ? | 16:52.38 |
| Robin_Watts | This is the slowest file I can find in as much of the PDF ATS before I lost the will to live. | 16:53.12 |
| | cor, evidently I couldn't be bothered to type half that sentence. Sorry. | 16:53.38 |
| ray_laptop | Robin_Watts: search time is collecting the low 3 bits of each component (shifts) to form the slot offset | 16:53.41 |
| chrisl | I'd try a simple, one value, look-aside cache - even contone images often have runs of repeated sample values | 16:54.25 |
| Robin_Watts | chrisl: yes, that's all lcms does. | 16:54.42 |
| chrisl | It's often a lot of bang for very little effort | 16:55.07 |
| ray_laptop | chrisl: that's what I was talking about. If the CMYK value doesn't match the slot, if it doesn't match compute it and replace the slot contents | 16:55.49 |
| Robin_Watts | I'll see how fast I can get the standard code, then add caching. | 16:56.04 |
| chrisl | Robin_Watts: I take it this is for image samples? Maybe doing a fixed-point conversion for 0-255 sample values would be useful | 16:56.58 |
| Robin_Watts | chrisl: That's exactly what I'm doing now. | 16:57.13 |
| ray_laptop | chrisl: what good are 255 samples ? | 16:57.33 |
| Robin_Watts | I've optimised the 'general' floating point version to reduce muls etc. | 16:57.35 |
| chrisl | ray_laptop: 8 bit values | 16:57.59 |
| Robin_Watts | ray_laptop: I mean, I'm writing code that takes components as 0...255 rather than floats in the 0 to 1 range. | 16:58.11 |
| ray_laptop | in my experience, real world images need a cache of about 32-64k slots to get a hit rate of around 65% | 16:59.00 |
| | of course it depends a lot on the level of detail in the image. | 16:59.27 |
| | I've also done a cache where each slot ignores the low bits of the input, then interpolate. The interpolation using shifts and adds is fast on CPU's w/o FP h/w | 17:01.32 |
| | but the interpolation overhead was enough that the simple cache won. | 17:02.04 |
| mvrhel_laptop | I wonder if anyone will ever want mupdf to do real color | 17:02.31 |
| Robin_Watts | mvrhel_laptop: Hooking mupdf up to a CMM is something we've talked about for ages, but it's never bubbled up the priority list. | 17:03.08 |
| mvrhel_laptop | right | 17:03.18 |
| ray_laptop | Robin_Watts: for sure, working from 8-bit input (instead of floats) make sense. Also, is the color conversion done BEFORE the image smoothing (interpolation) ? | 17:03.28 |
| mvrhel_laptop | I don't think there has been any demand | 17:03.31 |
| Robin_Watts | ray_laptop: Yes. | 17:03.44 |
| ray_laptop | mvrhel_laptop: we've had one query for mupdf to use output ICC profiles, but we just steered them to gs. | 17:04.24 |
| Robin_Watts | The question is, what costs more? converting more from 4->3 or scaling 4 instead of 3 ? | 17:04.48 |
| kens | Depends on the caling I expect | 17:05.12 |
| ray_laptop | Robin_Watts: I don't follow the question | 17:05.15 |
| Robin_Watts | We start with a CMYK image, and we want to get a scaled rgb image. | 17:05.44 |
| | Either we can convert 4 ->3 then scale 3, or we can scale 4 then convert 4->3. | 17:06.04 |
| ray_laptop | Robin_Watts: as kens said, it depends on the scaling. | 17:06.16 |
| Robin_Watts | yes. At the moment we always convert then scale. | 17:06.41 |
| | actually, mupdf subsamples/converts/scales. | 17:06.56 |
| ray_laptop | for downsampling, we don't really want to convert all of the iinput, for upsampling then we want to convert, then scale (I would think) | 17:07.02 |
| mvrhel_laptop | right | 17:07.22 |
| Robin_Watts | So the 'gross resizing' happens in the subsample phase (to the nearest power of 2), I believe. | 17:08.06 |
| ray_laptop | Robin_Watts: what is the subsample step (downsampling)? | 17:08.10 |
| Robin_Watts | We decode images at a subsampled size. | 17:08.38 |
| ray_laptop | Robin_Watts: surely not when the image is to be scaled up ? | 17:09.01 |
| Robin_Watts | that size being the smallest power of 2 subsampling factor such that the image is just bigger than we actually need. | 17:09.15 |
| | Indeed, not when we are scaling up. | 17:09.20 |
| ray_laptop | I realize that mupdf "thinks" in terms of cramming a page on a cell phone screen, so downsampling is the norm | 17:09.32 |
| Robin_Watts | So for upscaling, we're converting then scaling - exactly what we want. | 17:09.49 |
| | For downscaling, we decode to a subsampled size, then convert, then scale. | 17:10.13 |
| ray_laptop | Robin_Watts: OK, so it sounds like the number of covnersions is reasonably optimized | 17:10.24 |
| mvrhel_laptop | that does sound reasonable | 17:10.33 |
| Robin_Watts | We cache the result of the subsample. | 17:10.35 |
| | We should really cache the result of the conversion instead, I think | 17:10.46 |
| mvrhel_laptop | right | 17:10.55 |
| ray_laptop | Robin_Watts: for re-draws, yes, I would think so | 17:10.59 |
| Robin_Watts | but that requires some slight reworking. | 17:11.15 |
| mvrhel_laptop | ok. I am going to beat a bit on some of these output intent issues from cups for a bit | 17:11.23 |
| ray_laptop | so the sub-sampled image is floats ? or 8-bit ? | 17:11.43 |
| | Robin_Watts: on the -n you added to ETS... Does that control rand_scale ? | 17:13.45 |
| Robin_Watts | sub sampled image is 8 bit. | 17:14.07 |
| | ray_laptop: Yes, rand_scale. | 17:14.14 |
| | -n only has an effect if -r is used. | 17:14.40 |
| ray_laptop | Robin_Watts: right, that makes sense | 17:15.18 |
| | Robin_Watts: so adding a simple cache that uses some low bits of each component to get a cache slot index should be simple to insert in the flow. 3-bits per component would only need 28Kb | 17:17.14 |
| Robin_Watts | ray_laptop: Yes, I could certainly do that. | 17:18.19 |
| ray_laptop | adjusting the number of bits per component (more for M and less for Y, for instance) can improve the hit ratio for a given size | 17:18.25 |
| Robin_Watts | but for now, I'd like to get the performance as good as possible without caching. Then we can add caching later. | 17:18.48 |
| ray_laptop | mvrhel_laptop: not sure what can improve the K channel handling, however, but doing 'simple' BG/UCR and then just converting the remaining 3 components may be faster (depending on the complexity of the CMY->RGB step) | 17:20.41 |
| | i.e., if interpolation in a multi-dimensional LUT is being used | 17:21.31 |
| mvrhel_laptop | ray_laptop: right doing the cmy to rgb and doing an adjustment based upon k to the rgb value would make the most sense | 17:22.55 |
| henrys` | ray_laptop:at the meeting yesterday I was going to ask about the chunk memory manager and mt, I think it should get some priority, what do you think? | 17:23.22 |
| mvrhel_laptop | for something sleazy | 17:23.25 |
| ray_laptop | dropping the K channel lets us use more of the remaining color bits in the cache key | 17:23.25 |
| mvrhel_laptop | right | 17:23.43 |
| ray_laptop | mvrhel_laptop: well, it is just for mupdf ;-) | 17:24.05 |
| | so sleazy is fine ;-) | 17:24.11 |
| mvrhel_laptop | :) | 17:24.14 |
| ray_laptop | remember that we are talking about primarily a viewer on a tablet or phone, not making plates for a press or printer | 17:25.33 |
| | henrys`: is this the issue with the locking in memory managers ? | 17:26.19 |
| mvrhel_laptop | yes. tell that to the lady who ordered the sweater based upon the color shown in her viewer app | 17:26.24 |
| ray_laptop | mvrhel_laptop: just blame her monitor calibration | 17:26.54 |
| mvrhel_laptop | its all sRGB.... | 17:27.02 |
| ray_laptop | like 99.999% of the people even know there is such a thing as monitor calibration. | 17:27.28 |
| mvrhel_laptop | true | 17:27.44 |
| | people just expect it to work | 17:27.52 |
| henrys` | yes all pcl, xps, etc files potentially crash mt. - see marcos mt regression test email | 17:28.14 |
| ray_laptop | henrys`: is this the issue with the underlying PCL chunk manager not being thread safe ? | 17:28.34 |
| | henrys`: right (I typed too slowly) | 17:28.48 |
| | henrys`: I should dust off that branch and finish it. I added 'on / off' locking to allocators so that multi-threaded apps can turn it on, but (for instance) a single instanced PCL parser step won't incur the performance hit. | 17:30.30 |
| kens | goodnight everyone | 17:32.01 |
| ray_laptop | so that ONLY when MT rendering is used, we turn on locking for the underlying chunk manager so that allocations outside the MT rendering (i.e. in the main thread) are protected | 17:32.06 |
| | bye, kens | 17:32.13 |
| | looking at the Miranda blurb in ken's default /quit message, it occurs to me we should put more of an 'ad' tag line instead of (or before) GPL Ghostscript GIT PRERELEASE 9.07 (2012-07-31) | 17:35.01 |
| henrys` | ray_laptop:I don't understand the details - why is extra stuff needed for pcl and not gs, I understand the chunk manager isn't used by the writer with gs and the chunk manager is. But what breaks because of that? | 17:35.43 |
| ray_laptop | henrys`: the gs parser always uses the GC for the parser step, and the non_gc_memory always has mutex protection. | 17:36.43 |
| henrys` | okay that's right | 17:38.05 |
| | I forgot that | 17:38.23 |
| ray_laptop | henrys`: PCL would incur a performance hit if every access to the chunk manager for all of the little allocations/frees | 17:40.26 |
| mvrhel_laptop | tkamppeter are you here? | 17:40.38 |
| ray_laptop | phone call to Scott... bbiab | 17:40.42 |
| chrisl | henrys`: I just pushed a fix for that PCL glyph spacing problem. I get *much* closer results between the FAPI and non-FAPI code, now, across *loads* of tests. | 17:51.37 |
| Robin_Watts | chrisl: nice one. | 17:52.48 |
| chrisl | Robin_Watts: I'm just waiting on all the other problems, now ;-) | 17:53.27 |
| henrys | okay chrisl I'll continue testing - thanks | 18:06.34 |
| tkamppeter | mvrhel_laptop, yes. | 18:09.30 |
| mvrhel_laptop | tkamppeter in bug 691952 did you include -dUsePDFX3Profile in your command lines in item 6? | 18:10.49 |
| | realize that due to CMM differences between lcms and adobe, every rendering intent and every profile combination is not going to give exactly the same color value | 18:11.36 |
| tkamppeter | I have tried the test files with -dUsePDFX3Profile now. 070_OutputIntent_ISOCoated1-v1_x3.pdf gives red crosses on all samples, 130_Source\ Profile.pdf gives no crosses (at least one correctly treated file) and 131_Rendering\ intent.pdf gives crosses on the first three fields and no cross on the last (white) field (partial success). | 18:12.01 |
| mvrhel_laptop | but, we should not be seeing extreme difference (e.g. like a green X in a blue square) | 18:12.02 |
| | let me look at 070_OutputIntent_ISOCoated1-v1_x3.pdf | 18:15.08 |
| | 070_OutputIntent_ISOCoated1-v1_x3.pdf renders fine for me | 18:16.51 |
| | let me try without -dUsePDFX3Profile | 18:17.05 |
| | and lots of x's without -dUsePDFX3Profile | 18:18.04 |
| | that was out to a cmyk device | 18:18.16 |
| | let me try an RGB device | 18:18.21 |
| | which will be a proofing case | 18:18.27 |
| | x's may be partially visible in this case | 18:18.37 |
| | as it uses the output intent as a proofing profile | 18:19.30 |
| | ick | 18:19.51 |
| | that did not work correctly | 18:19.58 |
| | lets see what adobe does with this | 18:20.03 |
| tkamppeter | mvrhel_laptop, with the cups output device and color space 6 (CMYK) 070... works for me, color space 1 (RGB) shows red crosses on rosé squares. | 18:21.39 |
| mvrhel_laptop | tkamppeter: ok that is what I am seeing. the RGB case really should be better than that | 18:22.02 |
| | let me dig into that right now | 18:22.07 |
| | in that case, it is supposed to be using the output intent as a proofing profile | 18:22.21 |
| tkamppeter | mvrhel_laptop, in color space 6 all three files work. | 18:24.41 |
| mvrhel_laptop | tkamppeter: ok that is good news | 18:25.01 |
| | so it is just the proofing flow | 18:25.07 |
| | nice acrobat reader crashed on me | 18:25.18 |
| | I am a little worried about the output intent profiles in these files | 18:27.11 |
| | They may not be round tripping at all | 18:27.25 |
| | which would break the proofing process | 18:27.36 |
| | this is the danger of using the output intent as your primary method of color managment | 18:27.58 |
| | but we will see | 18:29.02 |
| tkamppeter | mvrhel_laptop, bug report updated. | 18:31.31 |
| mvrhel_laptop | ok thanks | 18:31.38 |
| henrys | chrisl:looks good now there are pretty close - it seems like fuzzy should work but it doesn't with the parameters I have. I'll fool with it a bit | 18:34.50 |
| | s/there are/they are/ | 18:35.14 |
| mvrhel_laptop | ok. found one issue. we are going through the proofing profile when the source color is already in the proper color space. this explains the rose background that should have been purple | 18:36.38 |
| chrisl | henrys: I was using "-w 7" with fuzzy - that's the same error window we used with the Ghostscript FAPI work | 18:38.19 |
| mvrhel_laptop | ok. now for the red x's | 18:45.50 |
| henrys | chrisl:oh okay I think I'll go through at least the fts visually, that's a bit larger than I'd want to set it for. | 18:47.22 |
| chrisl | henrys: My problem is, I'm a bit snow-blind from staring at the differences, now. BTW, I'm working at 300 dpi (mostly), I guess that influences the effect of the window setting? | 18:50.56 |
| Robin_Watts | window setting is in device pixels. | 18:51.19 |
| | so passing with a window of 7 at 300dpi is much better than passing with a window of 7 at 72dpi | 18:51.43 |
| chrisl | Yeh, I assumed as much, since the files we're using don't have a dpi setting in them | 18:52.07 |
| Robin_Watts | Hmm. My rewriting got it down from 69% to 60%. | 18:52.17 |
| henrys | yes I was using 300 - but I look at the output and it doesn't look like it should need 7 ... | 18:52.26 |
| | but it does | 18:52.29 |
| Robin_Watts | Adding a 1 place cache got it from 60% to 31%. | 18:52.30 |
| mvrhel_laptop | I guess I am going to have to extract this output intent profile to see what is going on | 18:54.47 |
| henrys | errands bbiab | 18:55.58 |
| mvrhel_laptop | ok these profiles are *ucked in terms of working as proofing profiles | 19:05.01 |
| | hmm actually this should work | 19:14.29 |
| | since applying the sequence of profiles manually in photoshop give something reasonable | 19:14.59 |
| | perhaps a rendering intent issue | 19:15.30 |
| | bbiab | 19:16.23 |
| wart___ | hi folks. i'm becoming increasingly frustrated at how big my pdf files are getting; I work with a lot of (medieval) manuscripts and old books, and some of my pdfs just take about 10 seconds in (say) mupdf to load. There's got to be a clever trick (ghostscript? pdftk?) to strip these down so they load reasonably. | 19:46.55 |
| | but i can't find the right magic in google to get an answer. | 19:47.04 |
| | (an answer that works) | 19:47.14 |
| | some of my pdf files load very fast, so there's gotta be a difference that makes a difference | 19:47.30 |
| | and i'd love to figure out what | 19:47.36 |
| | i tried this: ~/Downloads/WADDING/test $ gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf test.pdf | 19:51.37 |
| | but it appears all the pages are blank and it spit out this error over and over: **** ERROR: Unable to process JPXDecode data. Page will be missing data. | 19:52.14 |
| Robin_Watts | wart___: Sounds to me like the files are just scanned images on each page. | 20:00.27 |
| | And the images are in jpeg2000 format. | 20:00.37 |
| | and for some reason you're getting an error about processing that data. | 20:01.09 |
| wart___ | Robin_Watts: yeah, that would make sense; so can I pop them out, convert them to something more reasonable, and pop them back in (so to say)? It seems like this is a commonality with the files I work with. | 20:01.10 |
| Robin_Watts | wart___: Well, gs decodes jpeg2ks just fine. | 20:01.41 |
| | but recoding from jpeg2k to something else is likely to make the files *larger*. | 20:01.59 |
| wart___ | Robin_Watts: here's a link to a sample file: http://archive.org/download/operaomni01duns/operaomni01duns_bw.pdf | 20:02.26 |
| | ah i need to compile ghostscript with jpeg2k | 20:03.08 |
| | let me see if that does the trick | 20:03.14 |
| tor8 | Robin_Watts: (just read the logs from a few hours back) | 20:14.03 |
| | Robin_Watts: I see you are making a cache lookup table? | 20:14.19 |
| Robin_Watts | tor8: No. | 20:14.22 |
| | I've done various things. | 20:14.33 |
| | 1) Optimise the standard FP version to use fewer MULs, and to avoid using MULs in favour of adds/subs. | 20:15.03 |
| | 2) Then I took that and stuck it into the middle of the fast_cmyk_to_rgb function, and munged it so it worked in fixed point with 8 bit values as input/output. | 20:15.51 |
| | 3) Then I put a simple 1 place cache in there too. | 20:16.13 |
| | 1 saved 20% on windows, but not much on android. | 20:16.32 |
| | 2 saved 9% or so on android. | 20:16.45 |
| | 3 saved 30% on android. | 20:16.54 |
| | I'm just tidying it all up for commit now. | 20:17.08 |
| tor8 | I was hoping for more on (2) | 20:17.10 |
| Robin_Watts | Me too. | 20:17.16 |
| tor8 | but any improvement is welcome | 20:17.18 |
| mvrhel_laptop | ok. looks like the issue with the output intent is due to the use of different rendering intents | 20:18.11 |
| tor8 | sampling a 4-d lookup with linear interpolation is 16 fetches and 10 lerps | 20:19.02 |
| | probably not an improvement over the matrix mult, but may be worth trying | 20:19.21 |
| Robin_Watts | There may well be something to be had by spotting cases in the matrix mult where each plane is 0. | 20:19.59 |
| | Changes pushed to my repo. | 20:23.06 |
| tor8 | Robin_Watts: feel free to commit those to master | 20:27.04 |
| Robin_Watts | tor8: Thanks. If you can see any improvements, please say. | 20:27.21 |
| tor8 | Robin_Watts: also, you're missing the .c files in your xps device work-in-progress | 20:27.22 |
| Robin_Watts | tor8: oops, yes, thanks. | 20:27.34 |
| | there really isn't much there yet. | 20:27.44 |
| tor8 | Robin_Watts: speaking of the xps (and pdf write) device, you reckon we should add begin_page(w, h) and end_page() calls to fz_device? | 20:29.04 |
| Robin_Watts | tor8: I was going to address that a different way to start with. | 20:29.56 |
| | My plan was that you'd open an xps output file, then for each page, ( open a device on that file, run the page, close the device ) then finally close the file. | 20:30.58 |
| tor8 | Robin_Watts: okay. there was something else I found scribbled on a note yesterday -- something about removing fz_bbox from the public api and using fz_rect everywhere outside of the draw device | 20:31.12 |
| Robin_Watts | fz_rect being the floaty one ? | 20:31.32 |
| tor8 | Robin_Watts: yup. | 20:31.37 |
| Robin_Watts | The only purpose of fz_bbox is for device level representations. | 20:31.59 |
| | but I do think it's useful for people to work in device level representations with a bbox rather than a rect. | 20:32.21 |
| tor8 | Robin_Watts: yeah. only for the draw device to represent areas of pixmaps. | 20:32.23 |
| Robin_Watts | Well, I'm pretty sure viewer apps need it too. | 20:32.48 |
| tor8 | a fz_rect can represent all values any sane person wants out of a fz_bbox | 20:32.50 |
| Robin_Watts | Right, but I'd worry about floatyness. | 20:33.16 |
| tor8 | Robin_Watts: I'm less certain they *need* the intness | 20:33.19 |
| Robin_Watts | I suspect we could get away with floats, but I like the ints. It makes it clearer when you're dealing with what. | 20:33.57 |
| tor8 | the one place they need to turn it into ints is when creating the pixmap as a destination | 20:34.11 |
| Robin_Watts | yeah. | 20:34.17 |
| tor8 | everywhere else is better (or at least as well) served with floats | 20:34.37 |
| | like the text hit testing, and search highlighting, etc | 20:34.58 |
| Robin_Watts | I disagree, I think. | 20:35.18 |
| | Anywhere where we deal with screen coords, I think we should talk in bboxes. | 20:35.41 |
| tor8 | you get nasty quantization, and being able to reuse the values of a text extraction when the zoom changes is not well served by ints | 20:35.52 |
| Robin_Watts | Don't want to have to force the user to make the bboxes from the rects themselves to ensure proper coverage. | 20:36.16 |
| | A text extraction via the text extraction device should return in rects, cos it's document space (or something like it, right?) | 20:36.56 |
| tor8 | that's the place that prompted me in the first place; the resolution dependency of the text extraction device that uses bboxes | 20:37.09 |
| | Robin_Watts: yeah. I think a lot of the places where we use bboxes now can be changed to rects | 20:37.29 |
| Robin_Watts | A list of rectangles for search results is intrinsically bound to the transform that was fed in; i.e. the current zoom etc. | 20:37.31 |
| mvrhel_laptop | ok. so lcms does not let me pick and choose different rendering intents to use when constructing a multi profile transform | 20:37.40 |
| Robin_Watts | hence that should stay as bboxes. | 20:37.45 |
| tor8 | Robin_Watts: which is why in my viewers I send in fz_identity and post-transform the list of rects | 20:37.48 |
| Robin_Watts | mvrhel_laptop: Is that because of the use of cmsChangeBufferFormat ? | 20:38.02 |
| mvrhel_laptop | no | 20:38.05 |
| tor8 | that way I don't have to re-extract the text if I zoom | 20:38.05 |
| mvrhel_laptop | Robin_Watts: I have a source profile, a proof profile and a destination profile | 20:38.20 |
| Robin_Watts | tor8: right. | 20:38.23 |
| mvrhel_laptop | need to use the one intent type for the mapping from source to proof and a different intent from proof to destination | 20:38.42 |
| tor8 | Robin_Watts: which is why I'd prefer floaty rects there | 20:38.44 |
| Robin_Watts | mvrhel_laptop: So that's an lcms bug? | 20:38.47 |
| mvrhel_laptop | well not a bug | 20:38.52 |
| | but lack of a feature | 20:38.55 |
| Robin_Watts | tor8: It feels odd to me, but then I've not had to code a viewer using it. | 20:39.12 |
| mvrhel_laptop | I believe I have a trick to get around it though | 20:39.23 |
| | need to head off now for a bit | 20:39.27 |
| | bbiaw | 20:39.29 |
| Robin_Watts | I guess we should poll paulgardiner on it to see what he does in the android stuff. | 20:39.32 |
| tor8 | Robin_Watts: how about I rejig the parts that can safely use rects instead of bboxes first and we can look at that and see how many places fz_bbox remains in | 20:39.35 |
| Robin_Watts | sure. | 20:39.42 |
| tor8 | Robin_Watts: I suspect only the bits that touch fz_pixmaps in some form will want them | 20:40.10 |
| Robin_Watts | I have changes here to make the android build work with the profiler. | 20:40.14 |
| | one of the changes is that the app needs permission to write files. | 20:40.33 |
| tor8 | Robin_Watts: oh, and I've got a handful of patches on tor/master that could do with a review | 20:40.36 |
| | right. not familiar with android profiling or app permissions, better let paul have a look at that :) | 20:41.27 |
| Robin_Watts | tor8: OK. I'm quitting for the night now, I think. Eyes are tired. I'll review 'em all first thing tomorrow, ok? | 20:41.27 |
| tor8 | Robin_Watts: sure. they've been sitting a week already. | 20:41.43 |
| Robin_Watts | It's basically gprof. | 20:41.46 |
| tor8 | so no rush there | 20:41.49 |
| Robin_Watts | ok. have a good one. | 20:41.55 |
| tor8 | I just keep forgetting to tell you :) | 20:42.07 |
| | Forward 1 day (to 2012/11/15)>>> | |
IRC Logs