Version: 2.0.0 (using KDE 4.6.4)
With the latest PGF changes the image editor just shows an empty pane when the zooming is set to 100%.
Reproducible: Didn't try
Steps to Reproduce:
Open the image editor with some picture and set the zooming to 100%.
Close the ditor and open a PGF in the editor via pressing F4. No picture is shown.
Click on "fit to screen" to see the image.
There is no reason to see this problem with only PGF images... zoom level don't care about image format.
Please checkout my last changes performed tody about libpgf and try again.
Same issue. Even the small preview that appears if you click on the icon inbetween the horizontal and the vertical scroll-bar at the bottom-right just shows an empty frame if the zoom is set to 100%. Works with non-pgf pictures.
Can you attach PGF file to this entry ?
which option you use about preview. Do you load full image size in this mode ?
It's the image editor, not the preview in the album view.
If the image fits completely into the image pane in the editor at 100% it is shown. If it is larger and would not be shown completely the issue occurs.
Currently I cannot attach a sample picture because even with lossy compression set to 9 (lowest quality) a 2 MPx picture is bigger than the 1 MB max attachment size.
send it to me by private mail
If you make the image editor's window small enough you can reproduce it with the test images from digikam-software-compilation/core/tests/databases/testimages/a2/pgf>
Attached is what I see at zoom 120% and 100%
Created attachment 61396 [details]
Created attachment 61397 [details]
converting digikam-software-compilation/core/tests/databases/testimages/a2/pgf/foto001q5.pgf to png, and problem disappear...
i can reproduce the problem. Change zoom level, and look artifacts with canvas tile mechanism. I already see this problem in old past...
It due to a precision issue with tile size computation, probably about image size. code is there :
Created attachment 61405 [details]
canvas tile artifacts
Zoom to 768% and look the result.
I think image data are not corrupted. Export this image as well to PNG, and load it. All is fine.
Git commit 3f5e6a3c587aa27573f6b421928f4f9af2da10fc by Marcel Wiesweg.
Committed on 30/06/2011 at 22:09.
Pushed by mwiesweg into branch 'master'.
If the image has no alpha channel, we can avoid QPixmap scanning the whole image for
transparent pixels if we specify the correct QImage format.
As a side effect, this fixes bug 276096, but as explained there, there's a libpgf regression as well.
M +2 -2 libs/dimg/dimg.cpp
This one was difficult to debug.
At the root, there is a libpgf regression: When the image has no alpha
channel, the alpha byte is set to 0, instead of 255.
(we initialize the memory with 0xFF, which seems unnecessary, given that
libpgf seems to fully write the memory including the alpha byte).
Afterwards, the story goes so that we see the problem only in a very specific
Whenever we scale, the alpha byte is ignored because hasAlpha is false, so all
is well. At 100%, no scaling is done, and we pass the data as is to QImage and
then to QPixmap. QPixmap sees transparent pixels and produces a transparent
I will commit an optimization which as a side-effect fixes the problem here -
if alpha is false, the image is RGB32 and not ARGB32, which frees QPixmap from
scanning the image for transparent pixels.
but I think the underlying regression must be fixed in libpgf, it should
preferably write 255 to the alpha channel, or not touch the alpha channel (and
say so in the API docs)
Please take a look in Marcel comment #13. There is a regression in libpgf since i updated the library in digiKam core to 6.1.24.
> This one was difficult to debug.
sorry for that one. I suspect we introduced this behaviour when attempting to fix the non-determinism (i.e. we now initialize all buffers).
Can anyone confirm that this problem also exists in 1.9.0?
In 1.9.0, libpgf is not updated with last version. In fact 1.9.0 is not maintained.
But i can do it using an external version of libpgf and recompiling 1.9.0 as well. I will do it today.
Just tested with 1.9.0 (from package repository, using libPGF 6.09.44) on another Ubuntu VM. The problem already exists. I'll see what I can do about that.
Ok thanks Raphael...
Is it possible that the image out buffer (QImage) is somehow initialized to 0x04 (contrary to 0xFF)? In CPGFimage::GetBitmap I see that 'buff' consists of 0x04 values. Explicitly writing 255 to the (otherwise untouched by libPGF) alpha channel has the desired effect of showing the image.
memset(data, sizeof(data), 0xFF);
pgf.Read(level, CallbackForLibPGF, this);
pgf.GetBitmap(m_sixteenBit ? width*8 : width*4,
m_sixteenBit ? 64 : 32,
Hmmm...could it be that sizeof(data) is 4?
I thought the problem is with https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/abd03787b7b1e3a392803edc5b40dfb25a69423c/entry/libs/threadimageio/pgfutils.cpp#L80 with the uninitialized QImage buffer (I'm sure I saw a corresponding stacktrace today).
But for pgfloader, should it not be memset(data, 0xFF, width*height*(m_sixteenBit ? 8 : 4)) ?
Created attachment 61825 [details]
memset patch for missing alpha channel values
> > memset(data, sizeof(data), 0xFF);
> But for pgfloader, should it not be memset(data, 0xFF,
> width*height*(m_sixteenBit ? 8 : 4)) ?
Here we have the 0x4:
We set the first 0xFF bytes to the value of sizeof(data), which is 4 ;-)
What's new in this file ? It can be closed for 2.0.0 ?
No related changes in https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/dimg/loaders/pgfloader.cpp (maybe in another branch/revision?)
Problem identified, patch (https://bugs.kde.org/attachment.cgi?id=61825) submitted. When applied everything should be fine.
Git commit a33630e56184ad1370f668d744c443a1f3d3ea80 by Marcel Wiesweg.
Committed on 23/07/2011 at 15:39.
Pushed by mwiesweg into branch 'master'.
Fix memset call (thanks to Raphael Schweizer)
M +2 -1 NEWS
M +1 -1 libs/dimg/loaders/pgfloader.cpp