| | <<<Back 1 day (to 2018/02/03) | 20180204 |
| sebras | I'm confused. in fz_copy_pixmap_area_converting_seps() in the non-deviceN case we first take a standard color converter to convert the process colors (consider CMYKA+2spots -> RGBA+2spots). | 00:58.19 |
| | this appears in template_span_3_with_alpha_general() to handle alpha as well. | 00:59.15 |
| | next in fz_copy_pixmap_area_converting_seps() we take care of each spot color at a time and try to simulate how this spot color would affect the normal process colors. | 00:59.46 |
| | now, if both dst and src has alpha we compute dd[k] = fz_clampi(dd[k] - v * convert[k], 0, a); where v is the value of the separation sample, a is the source alpha dd is the destination sample and k is the process color component. | 01:01.21 |
| | now, consider if a == 0 (source alpha), then the spot should be transparent, but we take dd[k] and clamp it to the range [0, a], i.e. [0, 0] which means that we fade out the destination sample completely. | 01:02.30 |
| | that just seems wrong to me. | 01:02.34 |
| | that is regardless of the value of v. | 01:03.04 |
| | if a == 255 we would let v affect the destination pixel. | 01:03.25 |
| | now... none of this alpha computation resembles that in template_span_3_with_alpha_general(). | 01:03.45 |
| | also what I worry about (but I haven't entirely figured it out) is that first we convert the process colors where destination alpha and source alpha both may affect the blended outcome, but then in a latter pass we _again_ try to fiddle around with the process colors without taking both destination alpha and source alpha into account. | 01:05.23 |
| | I need to sit down tomorrow and reacquiant myself with masa and the blending arithmetic. :-/ | 01:09.11 |
| | I'm having the inclination that it might not be possible to handle the extra components that affect the normal process colors afterwards because of how the alphas would interact. but I'm not entirely sure. | 01:24.04 |
| | also there are a number of commits on sebras/master that addresses out of bounds accesses for this part of the code. :-/ | 01:24.33 |
| fredross-perry | tor8, sebras - I get a build error on Android with certain versions of NDK (notably the one that ATS uses), that I can solve by including <limits.h> in memory.c | 06:13.14 |
| | question - is that safe to do for all compilers, or should I make it android-only? | 06:13.44 |
| sebras | fredross-perry: what NDK-version does ATS use? if we're going to ensure that that version always builds we shoukd be testing that version too. | 11:38.59 |
| fredross-perry | sebras - it's r14b. | 16:42.50 |
| | I believe there is (probably) a way to tell ATS to use a different version. But I'm actually thinking mupdf shoud be made to work with a range of NDK versions. | 20:36.00 |
| sebras | fredross-perry: yes, I have been looking for what version we have previously stated that we require. | 23:41.28 |
| | Forward 1 day (to 2018/02/05)>>> | |
Log of #mupdf at irc.freenode.net.