[digikam] [Bug 345649] Assigning "Rejected" label using Alt+1 shortcut leaves focus on menu

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345649

--- Comment #9 from DrSlony  ---
Not reproducible under KDE Plasma 5.7.2 or Awesome 3.5.9 using digiKam 5.0.0
(Help > About > Version shows 5.1.0), commit
0ee5030d1a3746249638c0e85e56c4b53fde6a25.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 338730] Image menu sometimes becomes disabled while downloading

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=338730

DrSlony  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |---

--- Comment #9 from DrSlony  ---
I was wrong.

Just imported a new batch of photos, about 250 on an SD card. 
Clicked Import > Card readers > SD
Scrolled down straight away.
The Item menu became disabled until the off-screen thumbnails loaded. Luckily
it didn't take very long, loading of thumbs is faster, but I still see no
reason for it to be disabled, it is still wasted time.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 281742] ICONVIEW : wrong selection start when browsing images

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=281742

--- Comment #9 from DrSlony  ---
Still valid in 5.0.0 (92997d9c6c589e044ab77c3ca1e726627ae2e0a3).

KDE Frameworks 5.23.0
Qt 5.6.1 (built against 5.6.1)

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 338730] Image menu sometimes becomes disabled while downloading

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=338730

DrSlony  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from DrSlony  ---
Cannot reproduce in 5.0.0 (92997d9c6c589e044ab77c3ca1e726627ae2e0a3).

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 275364] Allow to batch process more than one set of bracketed images

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=275364

DrSlony  changed:

   What|Removed |Added

Summary|Allow to batch processing   |Allow to batch process more
   |more than of sets of|than one set of bracketed
   |bracketed images|images

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 341407] Allow hosting application to tap Find functionality

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=341407

--- Comment #4 from DrSlony  ---
Eike I may have misunderstood your reply.

"no way to invoke it on the KPart from outside of it"
Should I open a feature request for this with the KPart (or other?) people?

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 204311] choice of resizing algorithms in resize dialog along with preview of each

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=204311

--- Comment #1 from DrSlony  ---
Confirmed that the downscaling algorithm in digiKam-5.0.0 does a great job.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 221985] update histogram before preview

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=221985

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

--- Comment #4 from DrSlony  ---
Using digiKam-5.0.0 on a laptop, histogram update is fast enough. Agreed to
keep it closed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 162132] crash while saving tiff (possibly caused by present alpha channel)

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=162132

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

--- Comment #4 from DrSlony  ---
I received an email about this issue today, so I tried to reproduce just in
case.

Cannot reproduce in digikam-5.0.0
http://commits.kde.org/digikam/09b876a13385981c39053cb8562167817204b58c

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 364790] Preview image shown too large

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364790

--- Comment #5 from DrSlony  ---
Thank you for taking this. As I build from git I can test as soon as its
committed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 364790] Preview image shown too large

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364790

--- Comment #3 from DrSlony  ---
"Yes, the 100% always refer to the original size of the image."
This is a bad design choice, and I will explain why.

When stretching the embedded JPEG preview to the reported raw size, digiKam's
preview is always blurry, soft and blocky when viewing raw files if one has a
camera which does not embed a full-sized JPEG preview in the raw file. In fact,
as most cameras which embed a "full-sized" JPEG preview don't actually make
that JPEG the same size as the reported original raw size, we are left with a
situation where digiKam's preview is never 1:1, never sharp, always stretched a
little or a lot...

Examples:
Nikon D700, reported original size 4288x2844, largest embedded JPEG size
4256x2832
Nikon D70s, reported original size 3040x2014, largest embedded JPEG size
3008x2000
Nikon D80, reported original size 3904x2616, largest embedded JPEG size
3872x2592
Pentax K10D, reported original size 3936x2624, largest embedded JPEG size
3872x2592
Pentax K-3, reported original size 6080x4032, largest embedded JPEG size
6016x4000
Canon 7D, reported original size 5360x3516, largest embedded JPEG size
5184x3456
etc.

If someone's camera makes the largest preview similar in size to the reported
original size, digiKam's preview is only a little stretched, only a little
blurry and blocky.
If someone's camera makes the largest preview half the size of the reported
original size, digiKam's preview is blurry and blocky beyond use.

If one's raw files contain a preview which is half the size of the reported
original raw size, if one sets digiKam as follows: "Preview Options > Embedded
view shows full image > Embedded preview", one expects 100% to show a sharp
embedded JPEG preview at 1:1 size, not this blurry mess
https://i.imgur.com/xfg9W09.png
At 100% I expect to see this https://i.imgur.com/1P8hEPN.jpg not this
https://i.imgur.com/cSHPxEL.jpg
>From the first I can tell the photo is perfectly in focus. From the second I
can tell nothing.

This stretching functionality is not helpful. How is one supposed to choose the
sharpest of three shots in digiKam? How is one suppose to choose the shot most
exposed to the right without clipping when digiKam insists on not allowing me
to see the neutral raw data in the preview? How am I supposed to compare
exposure-bracketed shots in digiKam if digiKam insists on applying auto-levels?

The preview digiKam shows is essentially broken with an inability to zoom to
1:1 pixel level, and it is impossible to set digiKam to show a full-sized
demosaiced no-auto-levels preview as I reported years ago. "Embedded view shows
full image" is not true, it is misleading. I wrote how to fix that here
https://bugs.kde.org/show_bug.cgi?id=319241#c9

I don't understand why someone would want a stretched, blurry, non-1:1 preview,
but if there is such a need, fine. Then I propose this solution:

Preview Options
The preview image for raw files shows:
● The largest embedded JPEG image.
○ Full-sized demosaiced raw data.
○ Half-sized demosaiced raw data.
Apply auto-levels to demosaiced raw data: (see bug #347010)
● No
○ Yes
Stretch the embedded JPEG preview to raw image size?
● No
○ Yes

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 364790] Preview image shown too large

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364790

--- Comment #1 from DrSlony  ---
Unusable 100% preview in digiKam looks like this:
https://i.imgur.com/zO0owHz.jpg

Today's master,
http://commits.kde.org/digikam/543a36a75162ce8bc23c3c06d7cbd91ecf35f244

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 364790] Preview image shown too large

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364790

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 364790] New: Preview image shown too large

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364790

Bug ID: 364790
   Summary: Preview image shown too large
   Product: digikam
   Version: 5.0.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Preview
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

It is important that the "Zoom to 100%" view shows the image at 100%, i.e. at
1:1 pixel ratio. When I look at raw files, I can't view them correctly because
the 100% view blows the embedded preview up too much, and if digiKam is set to
show the "raw data in half size" then it still blows the preview up too much.

When digiKam is set to "show embedded JPEG", 100% zoom should show the JPEG at
100%.
When digiKam is set to "raw data in half size", 100% zoom should show the raw
data at half size, not at full size.

Related:
bug 319241
bug 347010

Here is a sample raw file and the output of "exiv2 -ep1,2 DSC00420.ARW"
https://filebin.net/yco5le4ygqjp3llh (Link expires on August 28th 2016)

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 317210] THUMBDB : delete image removes file, but does not remove thumbnails

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=317210

--- Comment #29 from DrSlony  ---
Yes, looks like just a refresh problem.

I tried to reproduce the problem from a console now by just copying an existing
album under a new name, starting digiKam and deleting photos from the new
album, but the thumbs were correctly removed from digiKam, so I couldn't
reproduce. I will run it from a console the next time I import and delete and
report back to you.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 317210] THUMBDB : delete image removes file, but does not remove thumbnails

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=317210

--- Comment #26 from DrSlony  ---
Using the SQLite database.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 317210] THUMBDB : delete image removes file, but does not remove thumbnails

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=317210

--- Comment #25 from DrSlony  ---
Using 7fb769c27cf48408cf45cad65ba4330940663c05

I imported over 100 photos. Back in the main digiKam window, once importing
finished, I went to the new album, clicked on the last thumb, jumped 50 photos
back using the "left arrow" key, then I held shift and clicked on the first
photo in the album, to select the first >50, then I shift+deleted them. The
confirmation popped up, I agreed, and digiKam deleted the photos... only the
thumbnails have not disappeared.
https://i.imgur.com/8bHLn3j.png

Clicking F5 reloaded the album and then the deleted photos disappeared.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 363937] Add option to disable thumbnails in Import window

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363937

--- Comment #4 from DrSlony  ---
No to both gphoto and to UMS. I used a class 10 SD card.
By the way, when digiKam hang earlier today with those 223 photos I made sure
there was "no active process".

I imported another batch of photos and now it took perhaps a second or two to
populate all the thumbs that fit into the whole maximized window - fast! I
didn't change anything in settings.

Since showing thumbs really is fast, we can close this issue. But please advise
me what to check the next time digiKam becomes unresponsive for a long time
when I open the Import window.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 363937] Add option to disable thumbnails in Import window

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363937

--- Comment #2 from DrSlony  ---
No.

https://i.imgur.com/d0Q3cfe.png
https://i.imgur.com/KXnpLdb.png

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 363937] Add option to disable thumbnails in Import window

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363937

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 363937] New: Add option to disable thumbnails in Import window

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363937

Bug ID: 363937
   Summary: Add option to disable thumbnails in Import window
   Product: digikam
   Version: 5.0.0
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Import
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

Using today's git head, 7fb769c27cf48408cf45cad65ba4330940663c05.

Generating thumbnails takes a long time and makes the Import window
unresponsive. Many users don't need to see thumbs in the Import window. For
many users the more important thing is being able to quickly import our photos
from a memory card or via USB into digiKam.
Please add an option to disable thumbnails in the Import window.

As an example, I have just 223 raw images on my SD card, but the import window
was unresponsive for so long I closed it (with great difficulty), re-opened it,
still unresponsive, restarted digiKam, opened the Import window again, still
unresponsive. I let it sit there for a minute before it became responsive. I
guess thumbnail generation is to blame. This was a waste of time, I just want
to "download all".

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359959] Labels Filter panel requires too much horizontal space

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359959

--- Comment #4 from DrSlony  ---
Your font, compared to mine, is huge. That could be why keeping the right panel
that wide makes sense on your end.
http://i.imgur.com/njQsdV0.png

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359959] Labels Filter panel requires too much horizontal space

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359959

--- Comment #2 from DrSlony  ---
Small icons set to 16 http://i.imgur.com/HlK3Oc5.png
Everything else looks fine, looks right, except that the right panel needs to
be made too wide to facilitate this row of icons. If you split that row into
two rows, it solves the problem.
These icons have huge padding, maybe that's the problem?
http://i.imgur.com/VeLYlqD.png

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 360077] New: Color management - specify monitor profile and rendering intent

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360077

Bug ID: 360077
   Summary: Color management - specify monitor profile and
rendering intent
   Product: systemsettings
   Version: 5.5.5
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-b...@kde.org
  Reporter: b...@londonlight.org

Feature request to be able to specify a color profile and rendering intent
which will be used by image-displaying applications in Plasma 5.

If there is a way of doing this in Plasma5 already, please do tell how.

colord-kde looks dead and doesn't work in Plasma5 (I checked some 3 months
ago).
https://projects.kde.org/projects/playground/graphics/colord-kde/repository

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 360077] Color management - specify monitor profile and rendering intent

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360077

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 360076] New: Gwenview 15.12.1 doesn't apply monitor profile to webp images

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360076

Bug ID: 360076
   Summary: Gwenview 15.12.1 doesn't apply monitor profile to webp
images
   Product: gwenview
   Version: Other (add details in bug description)
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: gwenview-bugs-n...@kde.org
  Reporter: b...@londonlight.org
CC: myr...@kde.org

Hello

Gwenview 15.12.1
_X11_PROFILE atom set and used correctly by gwenview for my JPEG images.

Download this image, it's in webp format:
https://plus.google.com/+JarrodCastaing/posts/ZmGMTjciN9W
Open in Gwenview. The image has wrong colors because the monitor color profile
which is specified by _X11_PROFILE is not applied. Loading a JPEG image makes
use of the monitor color profile.

If the image does not contain a color profile, it is OK to assume that it's in
sRGB, but either way the monitor profile should still be used.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 360076] Gwenview 15.12.1 doesn't apply monitor profile to webp images

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360076

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 360075] New: No way to control color management

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360075

Bug ID: 360075
   Summary: No way to control color management
   Product: gwenview
   Version: Other (add details in bug description)
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: gwenview-bugs-n...@kde.org
  Reporter: b...@londonlight.org
CC: myr...@kde.org

Hello

Gwenview 15.12.1 uses the _X11_PROFILE atom if its set, which is nice because
that way the image shown is color-corrected for the loaded monitor profile, but
there is no way in Gwenview to control the color management.

Please add:
1- A possibility to toggle color management on/off. Just because one has the
_X11_PROFILE set doesn't mean one needs to use it. 
2- A possibility to select a different monitor profile. A very common
misconception is that there is such a thing as "one correct profile", but that
is not true. A monitor profile serves a purpose - you could have one for
working on typical photos, one for working on photos with extreme colors where
they must not be clipped, one for matching prints, etc.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 360075] No way to control color management

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360075

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359960] digiKam product category lacks recent versions

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359960

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

--- Comment #4 from DrSlony  ---
"5.0.0 beta versions need feedback from users who test. This is why 5.0.0
exists in bugzilla..."
Maybe you did not understand the problem. There are two of them, allow me to
explain:
1- There is no 5.0.0 version yet. If bugs which exist only in pre-5.0.0
versions, such as 5.0.0-beta3 for example, are filed as "5.0.0", then you will
have a mess when 5.0.0 is released on 29 May 2016.
2- Some users, such as myself, get the latest code from git. If I find a bug I
want it to be clear that this bug is in today's git version, not in some tag
which is either many commits behind git, or as is the case with 5.0.0 not even
released yet.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359966] Clicking and holding a spinbox arrow doesn't keep increasing the value

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359966

--- Comment #2 from DrSlony  ---
Those work. I think this can be closed, though I don't know how users are to
learn of this behavior.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359969] BQM claims it finished processing instantly

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359969

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359969] New: BQM claims it finished processing instantly

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359969

Bug ID: 359969
   Summary: BQM claims it finished processing instantly
   Product: digikam
   Version: 5.0.0
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Batch Queue Manager
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

I often add one large panorama to the BQM and have it downscaled, sharpened,
watermark applied, and saved as JPEG. This takes around 10 seconds, but when I
start BQM it instantly says that it finished processing. The output image
appears after some 10 seconds as expected.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359967] Edit slider values as text

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359967

--- Comment #2 from DrSlony  ---
Confirmed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359967] Edit slider values as text

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359967

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359967] New: Edit slider values as text

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359967

Bug ID: 359967
   Summary: Edit slider values as text
   Product: digikam
   Version: 5.0.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

Editing slider values as text should be possible. e.g. instead of dragging the
"Noise filter" slider to 0.030, which is impossible, just type "0.030".

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359966] Clicking and holding a spinbox arrow doesn't keep increasing the value

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359966

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359966] New: Clicking and holding a spinbox arrow doesn't keep increasing the value

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359966

Bug ID: 359966
   Summary: Clicking and holding a spinbox arrow doesn't keep
increasing the value
   Product: digikam
   Version: 5.0.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

http://i.imgur.com/pGGZIUF.png
When I click and hold the up or down chevron, the little ^ arrow, the value
should keep increasing or decreasing as long as I hold it. It doesn't, it only
goes +1 or -1 regardless of how long I hold it. This would not be a problem if
I could manually type a number, but I can't. I'm pretty sure in digikam4 one
could click on the value to edit it as text, but in digikam5 I can't.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359963] In the Albums treeview, clicking an album which has a sub-album does not show its thumbnails

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359963

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359963] New: In the Albums treeview, clicking an album which has a sub-album does not show its thumbnails

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359963

Bug ID: 359963
   Summary: In the Albums treeview, clicking an album which has a
sub-album does not show its thumbnails
   Product: digikam
   Version: 5.0.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Albums View
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

Clicking on a folder which has a subfolder in the "Albums" treeview, like this
http://i.imgur.com/L9B8ikl.png expands that folder in the tree, but does not
show the photos it contains. I have to click it a second time to see the photo
thumbnails.

digikam 5 git
http://commits.kde.org/digikam/78d0a3cdda2b9cb8514d95c9fcfe984f64107376
rev 78d0a3cdda2b9cb8514d95c9fcfe984f64107376
revision 78d0a3cdda2b9cb8514d95c9fcfe984f64107376
(testing whether this bugzilla automatically links to revisions)

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[bugs.kde.org] [Bug 359960] New: digiKam product category lacks recent versions

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359960

Bug ID: 359960
   Summary: digiKam product category lacks recent versions
   Product: bugs.kde.org
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: templates
  Assignee: sysad...@kde.org
  Reporter: b...@londonlight.org
CC: she...@kde.org

The digiKam product's versions jump from 4.14.0 to 5.0.0. There is no 5.0.0
version yet, there are only betas, see
https://www.digikam.org/about/releaseplan
There should also be a "digiKam 5 git" version entry, or something to that
effect, which people can choose when reporting bugs.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359959] Labels Filter panel requires too much horizontal space

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359959

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359899] Tags Filter panel too wide

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359899

--- Comment #2 from DrSlony  ---
Correct.

If you can't reproduce, maybe the tag name you set wasn't long enough if your
font is small.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Breeze] [Bug 354370] GIMP icon is bad

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=354370

--- Comment #8 from DrSlony  ---
I've made icons before, maybe I can help. Could you link me to the guideline?

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 359909] Monitor profile should use relative colorimetric rendering intent by default

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359909

--- Comment #1 from DrSlony  ---
Oh, version 15.12.1.

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 359909] Monitor profile should use relative colorimetric rendering intent by default

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359909

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 359909] New: Monitor profile should use relative colorimetric rendering intent by default

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359909

Bug ID: 359909
   Summary: Monitor profile should use relative colorimetric
rendering intent by default
   Product: gwenview
   Version: Other (add details in bug description)
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: gwenview-bugs-n...@kde.org
  Reporter: b...@londonlight.org
CC: myr...@kde.org

I am happy to see that Gwenview uses my monitor's color profile, but
unfortunately it appears to be using the perceptual rendering intent and I see
no way of changing that. Please add an option to change the rendering intent,
or at the very least hard-code it to use relative colorimetric, not perceptual!

To help you test the change, you can download my monitor color profile here, it
includes gamut mappings for perceptual and saturation intents.
http://filebin.net/211bsvrbjo

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 319241] Improvement about embedded preview loads full-sized image option

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=319241

DrSlony  changed:

   What|Removed |Added

Version|4.10.0  |5.0.0

--- Comment #9 from DrSlony  ---
A bump for making the preview mode selection more clear and more useful.

Currently digiKam5 git shows this option:
Preview Options
● Embedded preview shows a small, quick preview
○ Embedded view shows the full image.
Raw Images: 
● Automatic
○ Embedded preview
○ Raw data in half size

This is not clear because raw images can contain several embedded JPEG images
of various sizes plus the raw data itself. TIFF images can contain a tiny
thumbnail but perhaps also a larger preview as well (I am unsure of this, I am
sure of the rest). So what does "a small, quick preview" mean? It's not clear.

I don't know whether "a small, quick preview" applies to JPEG, PNG and TIFF
images. Does it? If it does, please explain how.

I propose this because it is far more clear:

Preview Options
The preview image for raw files shows:
● The largest embedded JPEG image.
○ Full-sized demosaiced raw data.
○ Half-sized demosaiced raw data.
Apply auto-levels to demosaiced raw data: (see bug #347010)
● No
○ Yes

As a photographer it is very important that the preview does not apply
auto-levels. Currently it does and its impossible to turn this off.

As for the demosaicing algorithm, anything will do, though I invite you to
borrow the latest AMaZE code from RawTherapee, as it is very speed-optimized
and produces high quality results in a very short time, though this is a
separate issue, I just thought I'd mention it here.
https://github.com/Beep6581/RawTherapee/blob/master/rtengine/amaze_demosaic_RT.cc

I suppose showing the largest embedded JPEG image is fastest. Showing a
full-sized AMaZE-demosaiced image is slowest, though that does not mean its
slow - because the current AMaZE code in RawTherapee is so well optimized, a 10
megapixel image takes just 150-300ms on a typical machine.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359897] Compilation failure - conflicting return type decodeRawImage()

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359897

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359899] Tags Filter panel too wide

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359899

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359899] New: Tags Filter panel too wide

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359899

Bug ID: 359899
   Summary: Tags Filter panel too wide
   Product: digikam
   Version: 5.0.0
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

If a tag in the Tags Filter panel is very wide, the panel becomes wide enough
to contain it. As a result, the whole right panel needs to be that wide,
otherwise you need to use the horizontal scrollbar. What should happen is that
the Tags Editor panel's size fills the width of the whole right panel, and if
the tags are too long to fit within that size then a horizontal scrollbar
appears in the Tags Editor panel only.
http://i.imgur.com/uISQLjs.png

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 359897] New: Compilation failure - conflicting return type decodeRawImage()

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359897

Bug ID: 359897
   Summary: Compilation failure - conflicting return type
decodeRawImage()
   Product: digikam
   Version: 5.0.0
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

Hello

I tried to compile git head of digikam 
=media-gfx/digikam-
and it failed with:

utilities/kdesupport/kipi/kipiinterface.cpp:584:10: error: conflicting return
type specified for ‘virtual uint
Digikam::KipiInterfaceRawProcessor::decodeRawImage(const QUrl&, QByteArray&,
int&, int&, int&)’
 uint decodeRawImage(const QUrl& url, QByteArray& imageData, int& width,
int& height, int& rgbmax)
  ^

Installing the git version of libkipi solved it
=kde-apps/libkipi-

This report is to let the person in charge of the Gentoo digikam- ebuild
know of the dependency version requirement.

I confirm that compilation fails when using libkipi 15.12.1 and works with
, I haven't tested 15.12.2 or 15.12.49..

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 193232] Add advanced input side-car files support (as .pto, .pp2, .pp3, .pano, thm, etc...)

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=193232

--- Comment #22 from DrSlony  ---
Bump, please add support for digiKam-5 to treat user-specified file types as
sidecar files so that when you move photos, these files get moved too.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358848] Chroma subsampling incorrectly described

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358848

--- Comment #3 from DrSlony  ---
+1 for Maik's commit, in my opinion it is now much clearer now to the users.
P.S. It would also be nice if we spoke in English and not only in diffs.

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358844] Add "fit" or "bounding box" resize option

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358844

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358843] New: Add link to source code web interface to main menu

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358843

Bug ID: 358843
   Summary: Add link to source code web interface to main menu
   Product: digikam
   Version: 4.14.0
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

I was unable to find a way to browse the digiKam source code online, I had to
ask for a link on IRC. It would be good if there was an easy to find link to
the web interface of your source code repository, preferably in the main menu.
This link: https://quickgit.kde.org/?p=digikam.git
If the link is already somewhere on your website, I was unable to find it.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358843] Add link to source code web interface to main menu

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358843

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358844] New: Add "fit" or "bounding box" resize option

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358844

Bug ID: 358844
   Summary: Add "fit" or "bounding box" resize option
   Product: digikam
   Version: 4.14.0
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: Batch Queue Manager
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

Resizing is a very frequently used feature, however digiKam's implementation
lacks any way to have portrait and landscape photos resized together so they
end up in a predictable size.
Please add an option to resize:
- Width
- Height
- Bounding box (sometimes called "fit")

The third option lets you specify dimensions within which the image must fit,
e.g. 1920x1080, regardless of the photo's orientation.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358843] Add link to source code web interface to main menu

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358843

--- Comment #2 from DrSlony  ---
Sorry, where?

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358848] New: Chroma subsampling incorrectly described

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358848

Bug ID: 358848
   Summary: Chroma subsampling incorrectly described
   Product: digikam
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Export
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

Continuation of https://plus.google.com/u/0/+digikam/posts/SExHL5iCt8f

https://quickgit.kde.org/?p=digikam.git=blob=f33c15ca92309ff6e8ec2e7a296bd88df0682c63=b5be6c56a43af98a639e2668ff99d8a47fd6504a=libs%2Fdimg%2Floaders%2Fjpegloader.cpp

Case 1: 2x1 1x1 1x1 = 4:2:2
Chroma halved horizontally.
You call it "low".

Case 2: 2x2 1x1 1x1 = 4:2:0
Chroma quartered in 2x2 blocks.
You call it "medium".

Case 3: 4x1 1x1 1x1 = 4:1:1
Chroma quartered in 4x1 blocks.
You call it "high".

Tooltip:
https://quickgit.kde.org/?p=digikam.git=blob=afa4beb83a6173345f516261ec442c199557738e=b5be6c56a43af98a639e2668ff99d8a47fd6504a=libs%2Fdimg%2Floaders%2Fjpegsettings.cpp

4:2:0 and 4:1:1 both quarter the chroma resolution, but in different ways.
4:1:1 is uncommon, but if you want to have it then I think it is misleading to
call 4:1:1 "high" and 4:2:0 "medium", as they both destroy 3/4 of the color but
in different ways.

Just saying "little to no visual difference" is not good, because the
difference can be the opposite of "little" depending on the image, and this
explanation does nothing to prepare the user for what sort of difference to
expect. I would not call this "little to no" http://i.imgur.com/zfvnrML.png

Saying that only 4:1:1 "tends to alter colors" leads the user to think the
other options don't when in fact they all butcher colors.

Lastly, 4:2:0 and 4:1:1 both quarter the resolution, so I wouldn't call one
"high" and the other "medium".

Here is my proposal:

d->subSamplingCB->setWhatsThis(i18n("Chroma subsampling reduces file
size by taking advantage of the eye's lesser sensitivity to color resolution.
How perceptible the difference is depends on the image - real-life full-sized
photos will generally show no difference, while sharp, down-scaled photos and
pixel-fine colorful watermarks and text may lose fine color detail."
"NoneJ:a:b 4:4:4, h/v 1/1No chroma subsampling, highest
quality but lowest compression."
"MediumJ:a:b 4:2:2, h/v 2/1Chroma halved horizontally,
average compression, average quality."
"High 2x1J:a:b 4:2:0, h/v 2/2Chroma quartered in 2x2 blocks,
high compression but low quality."
"High 4x1J:a:b 4:1:1, h/v 4/1Chroma quartered in 4x1 blocks,
high compression but low quality."));

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 358848] Chroma subsampling incorrectly described

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=358848

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 357224] Add ability to change icon theme

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357224

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[digikam] [Bug 357224] New: Add ability to change icon theme

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357224

Bug ID: 357224
   Summary: Add ability to change icon theme
   Product: digikam
   Version: 4.14.0
  Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: digikam-de...@kde.org
  Reporter: b...@londonlight.org

Hello

If one uses the Breeze color scheme and Breeze icon theme in Plasma and wants
to use a dark color scheme in digiKam, one finds that this is not possible,
because digiKam doesn't allow one to choose an icon theme, leading to this:
http://i.imgur.com/l6oNjFA.png
http://i.imgur.com/mGjH6R1.png

It is standard that photography software use a neutral dark theme. If digiKam
intends on letting users choose themes themselves, it should also let them
choose icon themes so that they can match the two. Otherwise just hard-code a
dark color scheme with a matching icon theme.

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.

[ark] [Bug 351248] ark-15.07.90 creates zip archive with parent folder structure when used from PCManFM

[DrSlony via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351248

DrSlony  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #7 from DrSlony  ---
Cannot reproduce using kde-apps-15.08.3 and kde-frameworks-5.17

-- 
You are receiving this mail because:
You are watching all bug changes.