Version: 1.5.0 (using KDE 3.5.2, Kubuntu Package 4:3.5.2-0ubuntu18.1 dapper) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.15.7-ubuntu1 I'll try to explain what I did to produce this bug. I was able to reproduce the bug on my system using the same image to take screenshots. And I was able to reproduce the bug on my system using a different NEF image. 1) Started digiKam, selected a NEF image (Nikon RAW format) and chose "Open with > Krita" 2) The Krita RAW import screen shows up, accepted default values 3) The image loaded 4) I tried to rotate the image 180° using Image > Rotate > Rotate Image 180° >> The left area of the image becomes transparent or white (or a combination of both). I checked whether the image was rotated around the wrong point and part of the layer was simply not shown. When I move the layer the transparent part moves along and is part of the layer. 5) Not wanting this result, I clicked undo >> The *entire* image becomes transparent. My layer data is gone. I then started Krita from the command line and opened the same image. The bug remains and no additional output is produced on the command line. I'll be posting my screenshot's *) normal.png Image opened in Krita *) rotated.png Rotated image *) other-image.png Rotated of another image *) closeup-of-another-image.png Closup of the rotated version of the other version when I started Krita from the command line. *) undo-operation.png After the undo operation, Layer becomes empty. For additional info email me.
Created an attachment (id=18023) [details] Image opened in Krita Image opened in Krita
Created an attachment (id=18024) [details] Rotated version of the original version Rotated version of the original image. On the right a white area appears. The first time, it wasn't white, it was transparent.
Created an attachment (id=18025) [details] another image rotated Another image after being rotated. This time the bar on the right is part white part transparant
1.5.0 indeed had a problem rotating large images. That is fixed, but the undo problem is not yet fixed in 1.6rc1 :-(.
Created an attachment (id=18026) [details] Closeup of another image Close up of the other image rotated a second time. Anther pattern in the right bar.
Created an attachment (id=18027) [details] undo operation Image after undo operation. Layer data is gone
Well the undo works... but alpha is set to 0, using a script I was able to "restaure" the layer. This is weird.
Hm, and this is true even for small images -- the empty-area problem was only valid for large images. However can we set the alpha value of the undo tiles to zero? The mind, she boggles.
SVN commit 592798 by berger: fix undo of rotate 180 BUG:135165 M +4 -5 kis_transform_worker.cc --- branches/koffice/1.6/koffice/krita/core/kis_transform_worker.cc #592797:592798 @@ -146,7 +146,7 @@ } for (Q_INT32 y = r.top(); y <= r.bottom(); ++y) { - KisHLineIteratorPixel srcIt = src->createHLineIterator(r.x(), y, r.width(), false); + KisHLineIteratorPixel srcIt = src->createHLineIterator(r.x(), y, r.width(), true); KisHLineIterator dstIt = dst->createHLineIterator(-r.x() - r.width(), -y, r.width(), true); KisHLineIterator dstSelIt = dstSelection->createHLineIterator(-r.x() - r.width(), -y, r.width(), true); @@ -264,7 +264,7 @@ dstLen = scale; // Calculate extra length (in each side) needed due to shear - Q_INT32 extraLen = (support+256)>>8; + Q_INT32 extraLen = (support+256)>>8 + 1; Q_UINT8 *tmpLine = new Q_UINT8[(srcLen +2*extraLen)* pixelSize]; Q_CHECK_PTR(tmpLine); @@ -344,14 +344,13 @@ { Q_UINT8 *data; - if(srcIt.isSelected()) - { data = srcIt.rawData(); memcpy(&tmpLine[i*pixelSize], data, pixelSize); // XXX: Should set alpha = alpha*(1-selectedness) cs->setAlpha(data, 0, 1); - + if(srcIt.isSelected()) + { tmpSel[i] = 255; } else
Oh, and thanks for the report! This was really in the nick of time, since 1.6 will be out very, very soon.
You need to log in before you can comment on or make changes to this bug.
KDE Bug Tracking System
KDE Bug Tracking System 