View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012294 | Scribus | Graphics / Image Frames | public | 2014-05-04 14:11 | 2014-06-14 06:39 |
| Reporter | BAlpha | Assigned To | jghali | ||
| Priority | normal | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Platform | x86/64 | OS | Fedora | OS Version | 20 |
| Product Version | 1.4.4.svn | ||||
| Fixed in Version | 1.4.5.svn | ||||
| Summary | 0012294: Image resampling sometimes does not fill the right-most column of pixels in the target image | ||||
| Description | scimage.cpp contains image resampling code (in scaleImageGeneric and scaleImage32bpp) and that was mostly copied from Qt a long time ago. This code had a bug in which the last column of pixels wasn't written to at all under certain circumstances. This can cause images in exported PDFs to contain a column of black (or noise) pixels on the right edge. Because these circumstances depend on various factors (image size, image frame size, resampling resolution, output colorspace, and possibly even the platform's floating point behavior) this is a bit hard to reproduce; I found at least 0007101 which reported this, and also http://forums.scribus.net/index.php/topic,1341.0.html which is a recent forum post with a similar issue. I can also reproduce this issue myself once in a while. This bug was fixed in Qt in 2009: https://qt.gitorious.org/qt/qt/commit/cbfef77bb7bd370f7373edb78c2646328461d259 (shortly before this code was actually fully removed from Qt at https://qt.gitorious.org/qt/qt/commit/76bcd00f74b0977b5f6ce12295aae987ea9ad4c1). The fix is a bit unsatisfactory because it just copies the pixel values from the previous column, but certainly better than black or noise. There is a second issue in the same code; in the "if (fraccoltofill > 0)" section, the alpha channel is multiplied by fraccolleft, while the RGB channels are multiplied by fraccoltofill. I haven't wrapped my head around whether this has to do with the alpha premultiplication (which was the reason for "forking" this code in Scribus in the first place), or whether this was another bug in Qt, but it certainly is a bug in Scribus (it can cause the last column to be too light, because the alpha channel represents the black channel in CMYK images); the factor should be fraccoltofill as well. Making both these changes fixes the issue for me. As far as I can see, the same code is still present in 1.5, so the fix should apply to that version as well. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
The proposed fixes cause apparently regression for gray and rgb images (last column too dark). |
|
|
Retested again. Don't known what happened, but now the fix seems to work correctly. Applied, thanks! In case of problems, I have anyway another one which works also correctly. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-05-04 14:11 | BAlpha | New Issue | |
| 2014-05-04 21:10 | jghali | Note Added: 0031838 | |
| 2014-06-07 12:26 | jghali | Note Added: 0032044 | |
| 2014-06-07 12:26 | jghali | Status | new => resolved |
| 2014-06-07 12:26 | jghali | Fixed in Version | => 1.4.5.svn |
| 2014-06-07 12:26 | jghali | Resolution | open => fixed |
| 2014-06-07 12:26 | jghali | Assigned To | => jghali |
| 2014-06-14 06:39 | cbradney | Status | resolved => closed |
| 2015-09-17 20:10 | Kunda | Category | Graphics / Image Frames => Graphics/Img Frames |
| 2015-09-17 20:11 | Kunda | Category | Graphics/Img Frames => Graphics / Image Frames |
