| | <<<Back 1 day (to 2017/06/22) | 20170623 |
| tor8 | Robin_Watts: fz_ensure_pixmap_is_additive should only affect CMYK with an alpha channel (that has values other than 0 or 1) | 09:25.31 |
| | I fully expect our test file coverage for such cases to approach zero | 09:25.51 |
| | and reading further down the logs, I am now curious to see what you found with the is_subtractive colorspace thing with CMYK ICC colorspaces | 09:31.31 |
| Robin_Watts | tor8: so, mvrhel had cmyk set to have is_subtractive=0 | 10:40.24 |
| | If I set it to 1, I do indeed see fz_ensure_pixmap_blah called. | 10:40.48 |
| | but I'm not convinced it gives progressions. | 10:41.18 |
| tor8 | I can't remember how we do AA-compositing with CMYK pixmaps and colors | 11:08.08 |
| | all I remember is we use premultiplied alpha for gray and rgb | 11:08.28 |
| Ed___ | Hi ! Guys can I annotate a pdf using mupdf library on my own android app ? | 11:34.31 |
| kens | Ed___ : I believe the answer is yes but you'll need one of the MuPDF developers to say for sure | 11:39.44 |
| | Robin_Watts : is probably best placed to answer but he may be at lunch right now | 11:40.04 |
| Ed___ | I'll wait thanks | 11:41.34 |
| malc_ | Ed___: yes you can, include/mupdf/pdf/annot.h contains prototypes of functions that deal with annotations | 11:53.55 |
| Ed___ | malc_: Thanks, I'll give a try on android | 11:54.35 |
| tor8 | Ed___: the new JNI/Java library for mupdf supports creating annotations and can be used to write your own viewer | 12:23.24 |
| | Ed___: http://git.ghostscript.com/?p=mupdf-android-viewer-mini.git;a=summary for a minimalist viewer example | 12:24.20 |
| Ed___ | tor8: Thanks I'll read it. I'm looking for some examples and this one will help | 12:27.19 |
| kens | Ed___ : Normally Robin asks this question, but since he seems to be afk.... You are aware of the fact that MuPDF is licensed under teh AGPL, and you are happy with the restrictions in that license ? | 12:28.33 |
| Ed___ | No, I'm not | 12:39.47 |
| tor8 | You have two options. One: use the AGPL and follow its restrictions (you must give away the source to ALL of your app) | 12:40.38 |
| | Two: acquire a commercial license from Artifex (which lets you keep your source code secret, but costs money) | 12:40.58 |
| | We suggest you ask for a commercial license before you start any serious amount of work. You may not like the license or pricing, and we'd hate for you to have wasted your time. | 12:41.54 |
| | Ed___: http://artifex.com/licensing/ for more details. | 12:42.19 |
| Ed___ | Thanks for the information, tor8 I didn't know about it and I can't provide access to the source code of this app so I'll look for other option | 12:42.44 |
| tor8 | Ed___: it sounds like you'll want the commercial license then. | 12:45.54 |
| Ed___ | Well I show this for my boss and he ask me to look for another option but if we dont find I suggest to him to pay | 12:46.35 |
| avih | tor8: having noticed several of those already, don't you find it at least somewhat surprising that most devs seem to assume it's for free, without checking the license/options first? | 13:00.19 |
| | like, if i'm about to use someone's else code, the first thing i'd do is check what kinds of strings it has attached | 13:01.10 |
| | (which isn't necessarily failsafe, as i proved with the initial integration of mujs with mpv 2 years ago when it was agpl, but that was my fault for not understanding exactly what its compatibility with the GPL means) | 13:03.09 |
| kens | It amazes me that people don't check before they go and use code | 13:03.13 |
| avih | imagine how many used it without needing technical help here | 13:05.21 |
| | s/used/use/ | 13:06.02 |
| kens | We already have some idea on that one | 13:06.41 |
| | A number of organisations have been approached already | 13:07.04 |
| avih | some, i bet, but still.. amazing it happens. that's not some minor utility. it's a big library with obviously considerable effort behind it. how could one just assume they can just use it? | 13:07.57 |
| kens | "I found it on the 'Net, so it must be free, right ?" | 13:08.31 |
| | Combined with downright dishonestyt in a few cases | 13:09.17 |
| | And parasitism in a few others (are you listening Oracle ?) | 13:09.39 |
| avih | well.. i don't agree with, but i can understand dishonesty. the part that amazes me is the obliviousness | 13:10.21 |
| | right. gl fighting oracle :/ | 13:11.30 |
| kens | We aren't fighting them... FOr years they added 'PDF reporting' capability by telling their users to download Ghostscritp. | 13:12.21 |
| avih | OTOH, you do distribute it as AGPL, and it's available on different distros. people could easily assume it can be used freely in open source | 13:12.31 |
| kens | THen when their users have problems they tell them to contact us. | 13:12.38 |
| avih | you could consider them sending you clients. hey, you should pay them for the redirections! | 13:14.08 |
| Ed___ | Guys thanks for all I'll leave now and don't worry the give up to build/edit pdf on mobile and we'll do it on the webserver | 13:21.31 |
| RobinWattsLenovo | tor8: 2 commits in robin/master then. | 13:21.44 |
| | Ed___: What will you use instead? | 13:21.50 |
| Ed___ | I think it'll jasper | 13:22.12 |
| RobinWattsLenovo | The GNU AGPL covers SaaS, so you can't use gs or mupdf on the webserver. | 13:22.18 |
| | ok. | 13:22.20 |
| Ed___ | The server side isn't with me | 13:22.53 |
| | but I know the use jasper | 13:23.04 |
| RobinWattsLenovo | tor8: 2 commits on robin/master. You've looked at both before, but I've tweaked the harfbuzz one according to your comments. | 13:27.14 |
| | tor8: The answer is that the current code makes a mess of plotting to cmyk :( | 13:36.56 |
| | tor8: ping | 14:35.33 |
| | mvrhel_laptop: Morning | 14:52.52 |
| mvrhel_laptop | RobinWattsLenovo: good morning | 14:53.03 |
| | So I have been looking at the transparency stuff some | 14:53.13 |
| RobinWattsLenovo | ok... | 14:53.34 |
| | I've been looking into this subtractive space with alpha stuff. | 14:53.59 |
| mvrhel_laptop | So the way gs works, is that cmyk blending is done by inverting the colors and then blending | 14:54.04 |
| RobinWattsLenovo | mvrhel_laptop: Right. | 14:54.15 |
| | tor8 mentioned the idea of holding subtractive colors inverted yesterday. | 14:54.51 |
| mvrhel_laptop | Yes. I am thinking that may be beneficial performance wise due to the way these groups are pushed for each path drawing | 14:55.27 |
| RobinWattsLenovo | so spots are subtractive, right? | 14:55.55 |
| mvrhel_laptop | otherwise we are inverting two source groups, blending and then inverting the results | 14:55.57 |
| | spots would get inverted too | 14:56.11 |
| RobinWattsLenovo | right. | 14:56.17 |
| | How nightmarish does that make the lcms stuff ? | 14:56.31 |
| mvrhel_laptop | but having inverted data may be problematic for lcms | 14:56.35 |
| | :) | 14:56.36 |
| | I need to look at that today | 14:56.45 |
| RobinWattsLenovo | It's "just" another formatter. | 14:56.51 |
| mvrhel_laptop | hehe | 14:56.55 |
| | it may already be there | 14:57.12 |
| | look at bgr.... | 14:57.17 |
| | that was pretty simple | 14:57.25 |
| | ok. I will continue investigating this approach | 14:57.44 |
| RobinWattsLenovo | I've found a problem in the old code (pre-lcms). | 14:58.08 |
| | If we get a CMYK+alpha image, and plot it to a CMYK screen, stuff goes wrong. | 14:58.22 |
| | We decode the CMYK+alpha image, we run 'ensure_additive' and convert it to rgb+alpha, then premultiply. | 14:58.49 |
| | Then we call fz_convert_pixmap to get it back to cmyk for plotting, and that fails to take account of the premultiplication. | 14:59.10 |
| mvrhel_laptop | ah | 14:59.16 |
| | I think we need to do away with the ensure additive business | 14:59.34 |
| RobinWattsLenovo | I think we'd get the same problem with an rgba pixmap plotted to a cmyk device. | 14:59.41 |
| | mvrhel_laptop: | 14:59.47 |
| | mvrhel_laptop: Yes, but if we get the same problem with rgba -> cmyk device, then we'll hit it even without losing that. | 15:00.09 |
| | so I'm trying to fix one bit at a time :) | 15:00.16 |
| | must feed puppy. brb. | 15:00.38 |
| mvrhel_laptop | RobinWattsLenovo: right now I have added the color space information to the group pushes and during the pops, the current pixmap is getting color transformed to the next level down (if needed) | 15:01.02 |
| | I hope we are not going to step on one another's feet | 15:01.24 |
| | maybe I should go work on devicen | 15:01.32 |
| RobinWattsLenovo | mvrhel_laptop: That sounds like you're working in the draw device. | 15:03.50 |
| mvrhel_laptop | yes | 15:04.02 |
| | most of the changes are there | 15:04.08 |
| RobinWattsLenovo | I'll be working in draw-paint.c and pixmap.c etc. | 15:04.24 |
| mvrhel_laptop | ah ok | 15:04.27 |
| RobinWattsLenovo | so I think we'll be nicely orthogonal. | 15:04.32 |
| mvrhel_laptop | ok good deal | 15:04.36 |
| RobinWattsLenovo | I'm pondering whether to add a flag to pixmaps to say they are premultiplied. | 15:05.14 |
| | But maybe I can just 'know' that by where I'm calling in the code. | 15:06.24 |
| mvrhel_laptop | I would add flag... | 15:07.01 |
| RobinWattsLenovo | Currently alpha = 0 means no alpha, 1 means 1 channel of alpha. | 15:08.29 |
| | I could have 2 to mean premultiplied alpha. | 15:08.39 |
| | That would mean knock on changes everywhere that does n-alpha to be n-!!alpha | 15:08.55 |
| | Do we ever forsee ourselves wanting to cope with multiple alpha channels ? | 15:09.24 |
| | (jpeg2000 has that concept apparently) | 15:09.43 |
| mvrhel_laptop | really? | 15:10.04 |
| RobinWattsLenovo | yeah, AIUI, each channel can be tagged alpha or not. | 15:10.20 |
| | so you can have multiple alpha channels in the decoded image. Not got a clue what that actual physical use that is. | 15:10.44 |
| | I wish tor8 were here, he would have an opinion on all this. | 15:11.38 |
| | lcms has a FLAVOR_SH bit. | 15:14.56 |
| mvrhel_laptop | oh nice | 15:15.06 |
| RobinWattsLenovo | 0 = MinIsBlack, 1 = MinisWhite | 15:15.15 |
| | so that's not so bad. | 15:15.34 |
| mvrhel_laptop | right | 15:15.58 |
| RobinWattsLenovo | Urm... in the code that allows for premultipled alpha with lcms... I can see where we unpremultiply when we pass the data in. | 15:19.29 |
| | I can't see where we repremultiply it when we get it out. | 15:19.46 |
| | Does gs not use premultiplied data? | 15:20.01 |
| mvrhel_laptop | no | 15:21.38 |
| RobinWattsLenovo | Cor, there is wibbling in the top of draw-paint.c about why we use premultiplied data. | 15:22.14 |
| mvrhel_laptop | brb | 15:23.06 |
| | ok back | 15:27.49 |
| | reading the comment.... | 15:29.23 |
| RobinWattsLenovo | I'm sure that made sense to me when I wrote it :( | 15:29.35 |
| mvrhel_laptop | To me, non-premultiplied seems to make a lot of sense when dealing with the various pdf transparency stuff. but I could be wrong. I should sit down like you did here and do an analysis | 15:30.52 |
| | Let me spend a few moments wrapping my head around this | 15:31.34 |
| | spend a little time looking at pdf spec yet again and transparency | 15:39.33 |
| RobinWattsLenovo | mvrhel_laptop: I always assumed that non-premultiplied was easier, but then I heard that RenderMan (is that the name? The thing used by companies like ILM and LucasFilm) works exclusively in premultiplied data because it makes everything easier. | 15:51.35 |
| mvrhel_laptop | RobinWattsLenova: It may. I am working on it right now | 15:52.08 |
| RobinWattsLenovo | And it avoids having to do divisions during blending, which seems like a win, especially on ARMs. | 15:52.11 |
| | sure. | 15:52.12 |
| mvrhel_laptop | yes | 15:52.13 |
| | I think that is the upside | 15:52.24 |
| RobinWattsLenovo | Taking non-premultiplied in is easy, it's the getting non premultiplied out that hurts. I'll shut up and let you look. | 15:52.55 |
| mvrhel_laptop | working off of pdf spec compositing stuff now to see... | 15:52.56 |
| | oh | 15:55.17 |
| | actually pdf spec shows the formulation | 15:55.25 |
| | page 526. Which is much nicer | 15:55.36 |
| | so that is the pre-multiplied case. | 15:56.26 |
| | RobinWattsLenovo: so lets stick with premultiplied | 15:56.55 |
| RobinWattsLenovo | ok. | 15:57.05 |
| | so reversing the sense of CMYK should make all this much easier. | 15:57.29 |
| mvrhel_laptop | yes | 15:57.35 |
| | so let me ask you this | 15:57.39 |
| | when we are doing a drawing of a cmyk source color into a pixmap for a cmyk device, where would the cmyk value get inverted? | 15:59.33 |
| | i.e. when its not being color managed | 15:59.39 |
| RobinWattsLenovo | if we reverse the sense of cmyk, I can lose ensure_additive, which will be much nicer. I'll need to change all the output routines that take CMYK to reverse them, including the halftoning code. And I'll still need to make the pixmap converter cope with premultiplied input some of the time. | 15:59.45 |
| | let me think... | 15:59.51 |
| mvrhel_laptop | incoming RGB to CMYK will be converted by lcms (we hope) | 16:00.14 |
| RobinWattsLenovo | So if the PDF document handler gets told "0 0.1 0.2 0.3 k", say. | 16:00.41 |
| mvrhel_laptop | hmm and we have to think for a bit about cmyk source images.... | 16:02.10 |
| | going to RGB pixmaps | 16:02.24 |
| | as we will want to treat those not inverted | 16:02.46 |
| RobinWattsLenovo | the interpreter could spot the colorspace->is_subtractive and then invert the values before calling fz_clamp_color | 16:02.50 |
| | cmyk source images which are converted to rgb in the loading code won't have any changes (but we shouldn't be doing that). | 16:03.31 |
| | cmyk source images that get decoded to pixmaps will need the decoder to invert the color values as they decode. | 16:03.51 |
| mvrhel_laptop | oh ok | 16:04.08 |
| | that was the case I was worried about | 16:04.22 |
| | it will be up to the decoder then | 16:04.29 |
| | that will work out then. lcms will *always* treat cmyk inverted | 16:04.56 |
| RobinWattsLenovo | Essentially any pixmaps or colors we see over the device interface must have the values already inverted by the caller if we are using subtractive spaces. | 16:05.15 |
| | similarly for spots. | 16:05.22 |
| | (as all spots are assumed to be subtractive) | 16:05.35 |
| | Is that going to fit with DevN etc? | 16:05.57 |
| mvrhel_laptop | great. I think this will work nicely | 16:05.58 |
| | oh | 16:06.12 |
| | one issue | 16:06.13 |
| | we have to be careful about | 16:06.25 |
| | it may not be an issue, but if we are using the alternate tint transform for sep or devicen we want to make sure the values going into the transform are not inverted | 16:07.04 |
| | I forget if that happens on the device side or the interp side | 16:07.27 |
| | that will be something to watch for as we move forward | 16:07.47 |
| RobinWattsLenovo | yeah. | 16:07.52 |
| | I think we convert from byte -> float form and back there anyway. | 16:08.23 |
| mvrhel_laptop | yes | 16:08.29 |
| | so how should be approach this | 16:08.37 |
| | s/be/we/ | 16:08.42 |
| RobinWattsLenovo | so it's just a tweak to that conversion - but well remembered. | 16:08.43 |
| | Well, I can have a crack at it, or you can. Up to you. | 16:09.27 |
| | I think this is something which will probably bounce between us a few times. | 16:09.41 |
| | I'll give it a go now if you want. | 16:10.06 |
| mvrhel_laptop | ok that would be fine | 16:10.13 |
| RobinWattsLenovo | ok. wish me luck :) | 16:10.25 |
| mvrhel_laptop | good luck.... I guess I will work on a couple things that Ted wanted me to do | 16:10.57 |
| | RobinWattsLenovo: Let me know if you need me | 16:12.07 |
| RobinWattsLenovo | mvrhel_laptop: ok, so if I have an rgb + spots pixmap... | 16:22.17 |
| | I'll have a=0, s=2 (say), n=5, colorspace= fz_devicergb ? | 16:22.46 |
| | or would I need colorspace=fz_devicergb_plus_2_spots ? | 16:23.14 |
| | Color management is based on the colorspace - are spots unmanaged, or does the colorspace need to have an appropriate profile to cope with them too ? | 16:24.22 |
| mvrhel_laptop | RobinWattsLenovo: So spots will be unmanaged. I actually think the information about the number of spots should be in the colorspace | 16:32.55 |
| | As the cmm will need to know how many to skip | 16:33.12 |
| | in its processing | 16:33.16 |
| RobinWattsLenovo | mvrhel_laptop: So that would mean we'd need some mechanism for asking for "fz_device_rgb but with 3 spots" | 16:33.41 |
| | Playing devils advocate for a moment... | 16:34.06 |
| mvrhel_laptop | RobinWattsLenovo: The only place we will run into this is in pushes of groups in transparency | 16:34.20 |
| RobinWattsLenovo | When we go to transform a pixmap, the pixmap will know the number of spots. | 16:34.36 |
| | so that can be fed to lcms then. | 16:34.59 |
| mvrhel_laptop | yes | 16:35.05 |
| RobinWattsLenovo | without the colorspace needing to know. | 16:35.14 |
| mvrhel_laptop | So I think we will be fine with it just in the pixmap | 16:35.15 |
| | The color space would just be fz_devicergb | 16:35.32 |
| | or and icc RGB color space etc | 16:35.46 |
| RobinWattsLenovo | Does the link depend on the format ? | 16:35.47 |
| mvrhel_laptop | So yes. This is something I could work ono | 16:36.00 |
| | let me explain one thing | 16:36.18 |
| | Right now lcms set the formater when you create the link. We can't really change it as that would break thread safety if the link is shared. The heavy part of creating a link is the creation of the table. This is the same regardless of the formater. It would be nice to be able to take an existing link copy the non-format parts and create a new link with the desired formater. | 16:38.14 |
| | So for example if we had a RGB to CMYK already created | 16:38.28 |
| | from ealier | 16:38.31 |
| | earlier | 16:38.33 |
| RobinWattsLenovo | I understand. | 16:38.37 |
| mvrhel_laptop | ok I will stop. | 16:38.44 |
| RobinWattsLenovo | So we'll no longer have a colorspace -> single link mapping any more. | 16:39.06 |
| | perhaps we'll end up with a colorspace->link[FZ_MAX_SPOTS] list of links ? | 16:39.31 |
| mvrhel_laptop | Here is my thought | 16:39.49 |
| RobinWattsLenovo | and if we can find some way to have those links share the big tables, that'd be great. | 16:40.05 |
| | go on. | 16:40.11 |
| mvrhel_laptop | oh | 16:40.23 |
| | good idea about sharing the tables | 16:40.40 |
| | I was thinking about copying them | 16:40.46 |
| | right now we are creating them each time | 16:40.53 |
| | which is very bad | 16:41.00 |
| RobinWattsLenovo | A 'master' link and various 'slaves' that differ just in formatting? | 16:41.19 |
| | No idea how much of a git that will be to do with lcms. | 16:41.37 |
| mvrhel_laptop | Gosh this will require a little thought | 16:44.59 |
| RobinWattsLenovo | I would imagine that spots don't come and go during rendering. | 16:45.41 |
| | So it's not like as we're doing a single render, and the draw device is pushing and popping groups that the number of spots present in the system is going to change, right? | 16:46.34 |
| mvrhel_laptop | No they should stay constant | 16:46.50 |
| RobinWattsLenovo | So we don't actually gain anything by sharing tables. | 16:47.04 |
| | cos we'll only ever have 1 link for a given colorspace. | 16:47.27 |
| | (actually, we might be doing multiple renders at the same time, on different pages that share the same colorspaces, with different numbers of spots) | 16:48.16 |
| mvrhel_laptop | oh | 16:48.26 |
| | we also currently have to worry about with and without alpha. So if we do a link without alpha and then a link with alpha it creates two transforms | 16:49.06 |
| | That is when I became aware of the problem | 16:49.20 |
| | oh also this | 16:49.23 |
| | color fills use 16 bit formating | 16:49.34 |
| | images use 8 bit formatting | 16:49.42 |
| | so they no longer share a table that they should share | 16:49.50 |
| RobinWattsLenovo | (but that's an edge case. I think we need to cope with the idea that we *might* get the same colorspace used with differing numbers of spots, but it'd be on a different page, and so if we end up making a second copy that uses more memory in that odd case, tough). | 16:50.09 |
| | Ah. | 16:50.10 |
| | So does a colorspace have a pointer to a link? or is it found through the store ? | 16:50.24 |
| mvrhel_laptop | In gs we just change the formator | 16:50.26 |
| RobinWattsLenovo | mvrhel_laptop: yeah, but that has limitations, AIUI. | 16:50.39 |
| mvrhel_laptop | found in the store. But it has to match the bit depth, and has_alpha | 16:50.41 |
| RobinWattsLenovo | yeah. | 16:50.47 |
| mvrhel_laptop | if we could eliminate the bit depth and alpha and "add another formater" | 16:51.07 |
| RobinWattsLenovo | mvrhel_laptop: OK, so I reckon we just add the number of spots to the store key, and we're sorted. | 16:51.09 |
| mvrhel_laptop | if we dont have it that would be good | 16:51.19 |
| | RobinWattsLenovo: yes | 16:51.23 |
| | add number of spots to store key would solve the short term issue | 16:51.41 |
| RobinWattsLenovo | no need to perform surgery on lcms. Phew. | 16:51.41 |
| mvrhel_laptop | we may want to later though | 16:51.49 |
| RobinWattsLenovo | I don't believe it'd be inefficient in any case we really care about. | 16:52.19 |
| mvrhel_laptop | ok | 16:52.25 |
| RobinWattsLenovo | ok. I will bash on. Thanks. | 16:52.32 |
| mvrhel_laptop | np | 16:52.37 |
| | Forward 1 day (to 2017/06/24)>>> | |
Log of #mupdf at irc.freenode.net.