| <<<Back 1 day (to 2021/01/12) | Fwd 1 day (to 2021/01/14)>>> | 20210113 |
artifexirc-bot | <Robin_Watts> @sebras OK, looking at your commits now. Just checking tor hasn't beaten me to them? | 14:56.53 |
| <Robin_Watts> The manual for mutool sign... "optsion" | 14:58.48 |
| <Robin_Watts> The manual for mutool sign... "optsion" => "options" | 14:59.02 |
| <Robin_Watts> And I *really* hope we can avoid putting the "don't return in the middle of fz_try()" commit in, cos that will conflict horribly with the commits I've been waiting weeks for 😦 | 15:02.34 |
| <Robin_Watts> Can I fix that in those, and we get those in? | 15:02.40 |
| <Robin_Watts> That's all the comments I have on your non WIP ones. | 15:03.41 |
| <ator> @sebras could you take the stuff I wrote in "Add mutool sign documentation." and put somewhere in your new mutool-sign.html commit as well? | 15:23.12 |
| <Robin_Watts> @sebras Right... So the scaling done in the read_sample call is designed to ensure that all the values are passed back in the min...max range. | 15:29.34 |
| <Robin_Watts> So in this particular case, I get them back as 0..1000. | 15:29.54 |
| <Robin_Watts> However, if "use_function" we want to convert the values to be in a 0..1 range. We we're undoing the scaling that was done before in this case. | 15:33.57 |
| <sebras> sure, no problem. | 15:34.21 |
| <sebras> Yes, I'll merge them. | 15:35.10 |
| <Robin_Watts> Ah, because when we sample the shade function, we roll the scales in there. | 15:37.00 |
| <Robin_Watts> Possibly, the condition should be for shades 4/5/6/7, not just 5. | 15:37.43 |
sebras | @Robin_Watts yeah, maybe. it looked strange to only do this for type 5. | 15:38.31 |
artifexirc-bot | <Robin_Watts> I'll test that change now. | 15:39.00 |
sebras | 4 and 5 use the same datatype och the description of /Function appears to be similar at least. | 15:39.20 |
| @Robin_Watts let me see if I get this now. you're saying that eval_sample_func() in pdf-function.c scales the output value of the /Function according to the /Decode array and we need to undo that scaling in prepare_mesh_vertex() because we want the color values to be in a 0..1 range (well, 0..255 since we multiply by 255 in the next step)? | 16:10.55 |
artifexirc-bot | <Robin_Watts> @sebras Urm... | 16:18.44 |
sebras | am I wrong or did it already fall out of the cache again? :) | 16:19.23 |
artifexirc-bot | <Robin_Watts> The thoeretical flow is: values are read, and scaled into the given min/max range. These go into the function, which gives the output (always in 0..1, I think). | 16:21.09 |
| <Robin_Watts> We sample the function, so we want it's inputs to be in 0...1 (actually 0..255). | 16:22.05 |
sebras | as far as I understand /Decode is used to map the functions output value to a suitable range (probably 0..1?). | 16:23.10 |
artifexirc-bot | <Robin_Watts> If that is true, then the input to functions should always be in the 0..1 range. | 16:27.31 |
| <Robin_Watts> Let me look at pdf_ref for a mo. | 16:27.36 |
sebras | the descrption for /Function (page 315 in pdfref17) states "If the value returned by the functin for a given color component is out of range, it is adjusted to the nearest valid valid." this suggests some kind of clamping, but I haven't found that in prepare_mesh_vertex() or in fz_process_shade_type5() which indirectly calls it. | 16:30.13 |
artifexirc-bot | <Robin_Watts> Functions map values from their "domain" to their "range" | 16:30.15 |
sebras | maybe it is there, I just haven't found it. | 16:30.18 |
| @Robin_Watt yes. | 16:30.30 |
artifexirc-bot | <Robin_Watts> According to type 4 spec: Function | 16:30.48 |
| <Robin_Watts> function | 16:30.48 |
| <Robin_Watts> (Optional) A 1-in, n-out function or an array of n 1-in, 1-out functions (where n is the number of color components in the shading dictionary’s color space). If this entry is present, the color data for each vertex must be specified by a single parametric variable rather than by n separate color components. The designated function(s) are called with each interpolated value of the parametric variable to determine the actual color at | 16:30.49 |
| <Robin_Watts> Nasty use of "range" there. | 16:31.17 |
| <Robin_Watts> That reads to me like "Decode" defines the scaling to be used on the inputs to the function. | 16:31.47 |
| <Robin_Watts> "Each input value is forced into the... interval specified for the corresponding color component in the shading dictionary’s Decode array." | 16:32.15 |
| <sebras> well, they say that domain must be a superset of the range interval specified in the decode array..? | 16:32.28 |
| <Robin_Watts> That fits too. | 16:32.41 |
| <Robin_Watts> cos you could define a function on -1...2 and only ever feed it 0..1 quite happily. | 16:33.04 |
| <sebras> yes. | 16:33.12 |
| <Robin_Watts> So, I think I stand by my description. | 16:33.27 |
| <sebras> and in that case maybe the decode array specified 0..1 | 16:33.28 |
| <Robin_Watts> In the example I have here, the decode array is [0, 1000] | 16:33.52 |
| <Robin_Watts> so values are conceptually read from the mesh and scaled to 0 to 1000 | 16:34.24 |
| <Robin_Watts> then fed into the function to give values in the 0...1 range. | 16:34.35 |
| <sebras> how do you know it gives values in the 0..1 range though? | 16:35.15 |
| <Robin_Watts> ??? | 16:35.24 |
| <sebras> I agree that that's what the current code looks like, but is that right? | 16:35.27 |
| <Robin_Watts> That's the range that all such functions are defined to return in. | 16:35.44 |
| <Robin_Watts> (or rather they are defined to return 'color component values', so maybe for Lab or something wierd they may be different) | 16:36.42 |
| <Robin_Watts> but that's nothing to do with the problem we have here. | 16:36.51 |
| <Robin_Watts> The key thing is that we need to sample f(x) at 256 points. | 16:37.21 |
| <Robin_Watts> So rather than sampling f(x) at 256 points between min and max, we sample F(x) at 256 points between 0 and 1. | 16:37.58 |
| <Robin_Watts> where F(x) = f(x*(max-min)+min) | 16:38.25 |
| <sebras> I can't find that mentioned in the spec. that's why I'm being difficult (well, that and me being dense). | 16:38.34 |
| <Robin_Watts> From the bit I quoted above: "The designated function(s) are called with each interpolated value of the parametric variable to determine the actual color at each point." | 16:39.18 |
| <Robin_Watts> At any rate, nothing we're doing here affects the scaling of the *output* of the function. | 16:39.46 |
| <Robin_Watts> We have bent the range for the *input* of the function when we sample it. | 16:40.08 |
| <Robin_Watts> So the change in the code is to bend the input data accordingly. | 16:40.49 |
| <sebras> @Robin_Watts when you say Decode is [0,1000] is that /Decode in the shading dictionary or in the function dictionary? | 16:48.38 |
| <Robin_Watts> Shading. | 16:49.34 |
| <Robin_Watts> /Decode [ -16384 16384 -16384 16384 0 1000 ] | 16:49.41 |
| <Robin_Watts> Function dicts don't have a /Decode, do they? | 16:50.25 |
| <sebras> they do! | 16:50.38 |
| <sebras> see e.g. page 170 in pdfref17.pdf | 16:50.54 |
| <Robin_Watts> They have a /Domain[] | 16:50.57 |
| <sebras> at least type 0 functions might have a /Decode | 16:51.16 |
| <Robin_Watts> That's a Type0 specific thing. | 16:51.37 |
| <Robin_Watts> That's to do with the particular implementation of functions. | 16:51.48 |
| <sebras> yeah, I hadn't looked it up for all yet. | 16:51.50 |
| <sebras> so the function(s) ought to have an (output) range of 0..1000 and the (input) domain is at least 0..1000, possibly bigger then. | 16:52.08 |
| <Robin_Watts> @sebras Urm... no? | 16:52.35 |
| <Robin_Watts> Why do you think the function ought to have an output range of 0..1000 ? | 16:53.03 |
| <sebras> as I understand the /Decode array it specifies the min/max values that the output of the function is scaled to. | 16:53.52 |
| <Robin_Watts> No. | 16:53.59 |
| <Robin_Watts> The /Decode array specifies the min/max values for the mesh data. | 16:54.39 |
| <Robin_Watts> So each point in the mesh data has (x,y,c), where x and y are within -16384...16384 and each c is within 0 to 1000. | 16:55.24 |
| <Robin_Watts> The c from the mesh data gets mapped by the function to give the colour values. | 16:55.56 |
| <Robin_Watts> so the function takes input values in the 0 to 1000 range (and returns in 0..1) | 16:56.24 |
| <Robin_Watts> Our implementation bends the function to expect input values in the 0...1 range when we sample it. Hence we need to do the same when feeding the mesh data into the sampled function. | 16:57.58 |
| <sebras> aha! ok, we're hoping that the function returns values in the range 0..1 and that last sentence (If the value returned by the function for a given color component is out of range, it is adjusted to the neartes value) then means we ought to multiply by 255 and fz_clamp(0,255). | 16:58.27 |
| <Robin_Watts> That seems reasonable, yes. | 16:58.46 |
| <Robin_Watts> WTF is the cluster doing? Or WTF am I doing with it. I'm getting loads of diffs that look like being due to freetype, but I'm up to date. | 16:59.30 |
| <Robin_Watts> Why did @cgdae's jpeg fix give 6000 diffs in the cluster? | 17:01.17 |
| <Robin_Watts> Same question for the one before that? | 17:01.51 |
| <sebras> and this input interval bending then happens in pdf_sample_shade_function(), right? but this function is called also for linear and radial shadings, not just types 4-7, so every shading's function would have a bent input interval. if that's the case wouldn't we need to apply the same scaling in prepare_mesh_vertex() for all functions that have use_function set? | 17:03.14 |
| <sebras> @Robin_Watts I saw a large number of diffs on my first cluster run after freetype was added. I assumed it was the progressions from the freetype update..? | 17:04.04 |
| <Robin_Watts> Yes, I'd expect diffs then, but no clue about why we're getting them for later commits. | 17:04.33 |
| <cgdae> i thought these same diffs occurred for mudrawpy before my push today, so figured they were not caused by my push. | 17:05.23 |
| <Robin_Watts> @cgdae I don't believe they are caused by your patch. I am concerned that testing appears to show that they are. | 17:06.22 |
| <Robin_Watts> Either something is broken in the cluster, or updating freetype has lead to indeterminisms. | 17:06.53 |
| <sebras> did I miss something when I updated freetype? I ran it with a threshold to avoid having to look through too many subpixeldiffs. | 17:06.57 |
| <sebras> and everything I *did* see with the threshold applied looked like a progression. | 17:07.51 |
| <sebras> otherwise I wouldn't have proposed it for merging of course. | 17:08.25 |
| <Robin_Watts> @sebras Not seeking to blame here, I'd have fallen into the same hole (if indeed this is a hole, and not just me getting confused). | 17:08.55 |
| <sebras> of course, I just want to tell you what I saw when testing. | 17:09.32 |
| <sebras> maybe it gives an indication of what has gone wrong. | 17:09.41 |
| <Robin_Watts> *Something* is definitely wrong, cos there is no way adding 'x' to fopen can have caused 6000 diffs. | 17:09.48 |
| <Robin_Watts> @sebras My worry is that we now have freetype giving different results on different nodes. | 17:10.09 |
| <cgdae> what about my other commit to `extract_exif_resolution()`? changing the detection of out-of-range float before converting to int? could that cause problems? | 17:10.43 |
| <sebras> surprisingly the number of diffs after the freetype commit are fewer than after @cgdae's 'x' commit. | 17:10.46 |
| <Robin_Watts> @sebras Would you object to me rewriting git history to pull the freetype commit out? | 17:11.24 |
| <sebras> @Robin_Watts that would explain why the number of diffs changes between runs (depending on where tests are scheduled) | 17:11.33 |
| <Robin_Watts> @cgdae No, I don't think that's it either. | 17:11.52 |
| <sebras> @Robin_Watts no. | 17:11.53 |
| <Robin_Watts> Then we can run that one back to back multiple times to see if it gives stable results. | 17:12.11 |
| <sebras> @Robin_Watts I never expected issues so I only ran it the one time. | 17:12.28 |
| <Robin_Watts> As I would have done. | 17:12.37 |
| <sebras> back it out and see if the cluster returns to normal. | 17:12.51 |
| <Robin_Watts> Ok, backed out, cluster running. | 17:20.04 |
| <Robin_Watts> ok, so the cluster is "stable" without that in. | 18:34.32 |
| <Robin_Watts> I've run it once, and it gave me the expected shedload of diffs. | 18:34.47 |
| <Robin_Watts> I'm running it again, and I hope the "changes from previous run" section of the report should be empty. | 18:35.05 |
| <sebras> make sense. | 18:35.17 |
| <Robin_Watts> Differences from previous clusterpush: none. | 18:48.59 |
| <Robin_Watts> So I'm putting the commit back in... | 19:13.48 |
| <Robin_Watts> And while I get 13000 diffs with my user test, with the cluster testing it I only get 4000. WTF? | 19:27.10 |
| <Robin_Watts> OK, rods is giving me different results to peeved | 19:37.06 |
| <Robin_Watts> OK, rods is giving me different results to peeved and nuc9 | 19:37.17 |
| <Robin_Watts> If I do a clean rebuild I get sane results... | 19:42.36 |
| <Robin_Watts> ok, so on the cluster we have directories mupdf and mupdf.1 | 20:24.59 |
| <Robin_Watts> the former is used for user jobs. The latter for git commit jobs. | 20:25.22 |
| <Robin_Watts> both claim to be the same git version. clean builds from each on rods give different results. | 20:25.40 |
| <Robin_Watts> I'll have to keep looking tomorrow. This is frying my brain. | 20:36.19 |
unixbsd | hello | 20:45.20 |
mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 20:45.20 |
unixbsd | when I mark an area with right mouse click (black rectangle), is it possible that the mupdf printf the x,y : x1, y1, x2, y2 (onto terminal)?[3~ | 20:46.27 |
artifexirc-bot | <Fred> Even though git says they're at the same version, are they really the same? | 21:15.56 |
unixbsd | Ok, I have done it and forked the project:: https://gitlab.com/openbsd98324/mupdf | 21:30.23 |
malc_ | - git pull1 | 23:47.42 |
| fatal: Not possible to fast-forward, aborting. | 23:47.43 |
| i guess something was force pushed, what would be the canonical way to bring things back to order on my end? | 23:47.43 |
| <<<Back 1 day (to 2021/01/12) | Forward 1 day (to 2021/01/14)>>> | |