| | <<<Back 1 day (to 2017/08/31) | 20170901 |
| mvrhel_laptop | Robin_Watts: question for you | 15:07.37 |
| Robin_Watts | shoot | 15:07.46 |
| mvrhel_laptop | So, right now when we do our compositing of the spots etc and then transform to RGB eventually, we end up using either the output intent profile as our destination color space or DeviceCMYK | 15:08.42 |
| | and then go to RGB | 15:08.50 |
| | I would like to add the ability to have a different CMYK target, and I was thinking of adding the capability by adding a new color space to fz_separations_s | 15:09.50 |
| | That would enable us to do our print proofing | 15:10.25 |
| Robin_Watts | ok, I'm trying to parse that. bear with me. | 15:10.45 |
| mvrhel_laptop | ok | 15:10.50 |
| Robin_Watts | So we render the whole page as CMYK+spots, and we convert it to rgb to output it. | 15:11.45 |
| mvrhel_laptop | yes | 15:11.52 |
| | and we have a target CMYK color space in that process | 15:12.01 |
| Robin_Watts | As part of that conversion we rely on the Output intent profile. | 15:12.02 |
| mvrhel_laptop | but not all files have an output intent profile | 15:12.15 |
| Robin_Watts | right, and in the absence of one, we use DeviceCMYK. | 15:12.32 |
| | You're saying that you'd like to add a feature to allow a different profile to be substituted there. | 15:13.03 |
| mvrhel_laptop | Yes. | 15:13.08 |
| Robin_Watts | so we can do print proofing etc. | 15:13.10 |
| mvrhel_laptop | Yes | 15:13.13 |
| | Now one problem is this | 15:13.22 |
| Robin_Watts | Right, sorry, I find this stuff alien, so restating it in my own words help ensure I'm not misunderstanding. | 15:13.38 |
| mvrhel_laptop | If there is an OutputIntent we really should map to the output intent then to the printer CMYK profile then to RGB in special case | 15:14.05 |
| Robin_Watts | mvrhel_laptop: You mean we don't "ignore" the output intent, we "compose" it with our proofing profile. | 15:14.50 |
| | That seems plausible to me. | 15:15.05 |
| mvrhel_laptop | Robin_Watts: right. I will work those details out. I am just trying to figure out how best to communicate the CMYK profile I want to use and where it should live | 15:15.37 |
| | I was thinking in the seps object | 15:15.44 |
| Robin_Watts | So, the seps object is generally read from the page. | 15:16.06 |
| | Can we not have something to parallel fz_set_default_output_intent ? | 15:17.25 |
| mvrhel_laptop | true. this maybe should be document level | 15:17.26 |
| | Robin_Watts: yes that may make sense | 15:17.41 |
| | It would be used in the same manner as that | 15:17.52 |
| Robin_Watts | oh, but fz_set_default_output_intent is called by the interpreter not the end user, normally. | 15:18.15 |
| mvrhel_laptop | right | 15:18.20 |
| Robin_Watts | Having an fz_document or an fz_page call to say "set the proofiling profile to X" seems attractive, but neither the document or the page level feels right. | 15:20.23 |
| | cos we might be rendering 2 pages at once in different threads (which screws the document level) | 15:20.46 |
| | and we might want to render the same display list in different proofing profiles, which means the page level is wrong. | 15:21.25 |
| | It's like it should be something fed into fz_run_page... | 15:22.02 |
| | does this only make sense with the draw device? | 15:22.12 |
| | should it be an option to the draw device maybe? | 15:22.22 |
| | Maybe when we create a draw device and pass in a pixmap, we should pass in a proofing profile (or NULL) at the same time? | 15:23.03 |
| mvrhel_laptop | That is what I am thinking | 15:23.26 |
| | As there is where it is needed | 15:23.38 |
| | s/there/that/ | 15:23.48 |
| | we pass in a seps object now | 15:24.10 |
| | and we only are going to be doing this when we have the seps object | 15:24.23 |
| Robin_Watts | So, we could rename fz_new_draw_device to be fz_new_proofing_draw_device and add the extra param there, and then add a stub fz_new_draw_device that calls that with NULL. | 15:24.28 |
| | Urm... | 15:24.32 |
| mvrhel_laptop | which is why I thought we would stick it in there | 15:24.33 |
| Robin_Watts | The seps object is inside the pixmap that we pass in. | 15:24.40 |
| | fz_new_draw_device(fz_context *ctx, const fz_matrix *transform, fz_pixmap *dest) | 15:25.02 |
| | dest->seps is what we want. | 15:25.13 |
| | We *could* maybe add dest->proof ? | 15:25.35 |
| | or we could do: | 15:25.38 |
| mvrhel_laptop | dest->proof would be intuitive | 15:26.09 |
| Robin_Watts | fz_new_proofing_draw_device(fz_context *ctx, const fz_matrix *transform, fz_pixmap *dest, fz_icc_profile *proof) | 15:26.13 |
| mvrhel_laptop | or that would be fine too | 15:26.29 |
| Robin_Watts | does it make sense to have a profile attached to a pixmap? | 15:26.32 |
| mvrhel_laptop | Robin_Watts: well there already is one. colorspace | 15:26.55 |
| Robin_Watts | mvrhel_laptop: But we can't just hijack that, can we? | 15:27.09 |
| mvrhel_laptop | no | 15:27.14 |
| | this is another colorspace | 15:27.19 |
| Robin_Watts | Right, so that doesn't feel so intuitive to me. | 15:27.27 |
| | (but my instincts are not as good as yours here) | 15:27.42 |
| mvrhel_laptop | well you would have fz_colorspace *colorspace; and fz_colorspace *proof | 15:27.48 |
| | well you would have fz_colorspace *colorspace; and fz_colorspace *proof_cs | 15:27.58 |
| Robin_Watts | Once the actual rendering has finished though, and we've got our rendered pixmap, does the proof_cs still make sense? | 15:28.22 |
| | i.e. is it something we might ever refer to again? (If so, then it makes sense to pair it with the pixmap). If not, and it's just a place to put something to pass it into the draw device, I think I'd prefer an explicit extra arg to the draw device creation call. | 15:29.18 |
| mvrhel_laptop | No. Once we rendered to cs, we no longer need the proof cs | 15:29.19 |
| | ok. I am fine with the extra arg in the draw creation call | 15:29.42 |
| | so fz_new_proofing_draw_device(fz_context *ctx, const fz_matrix *transform, fz_pixmap *dest, fz_icc_profile *proof) | 15:30.08 |
| Robin_Watts | yeah. tor8 will want to change the function name else on principle :) | 15:30.38 |
| | (and it'll be a better name, damn him) | 15:30.47 |
| mvrhel_laptop | :) | 15:31.24 |
| | Robin_Watts: ok thanks | 15:32.13 |
| | Robin_Watts: to go along with the other items in the code maybe fz_new_draw_device_with_proof? | 16:44.57 |
| Robin_Watts | yeah, could do. | 16:45.10 |
| geikko | are any of you around? | 18:29.11 |
| | I had a question | 18:29.24 |
| Robin_Watts | ask, don't ask to ask :) | 18:36.58 |
| geikko | Robin_Watts, hi | 18:40.58 |
| | it's a bit off topic, but I have 2 ".sis" dictionaries and I was wondering if you knew how to convert them to Stardict or similar | 18:41.45 |
| Robin_Watts | nafc, sorry. | 18:42.14 |
| geikko | ok | 18:42.20 |
| | thanks anyway | 18:42.22 |
| | I'm the user who submitted the bug a few weeks ago (electrolex,icem) | 18:42.39 |
| | different nick now :| | 18:42.49 |
| | Robin_Watts, any chance you'll make the next version for "Windows" portable? | 21:33.09 |
| | also, you told me the next version would be in September (do you know what date?) | 21:35.01 |
| | Forward 1 day (to 2017/09/02)>>> | |
Log of #mupdf at irc.freenode.net.