[gwenview] [Bug 333733] Allow adjusting the chroma sampling parameters

2019-08-26 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=333733

--- Comment #7 from DrSlony  ---
For more info, see https://bugs.kde.org/show_bug.cgi?id=277996#c14

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

[gwenview] [Bug 277996] Make it possible to adjust JPEG quality/compression settings when saving

2019-08-26 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=277996

--- Comment #12 from DrSlony  ---
What about chroma subsampling?

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

[gwenview] [Bug 277996] Make it possible to adjust JPEG quality/compression settings when saving

2019-08-26 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=277996

--- Comment #15 from DrSlony  ---
Created attachment 122370
  --> https://bugs.kde.org/attachment.cgi?id=122370=edit
PNG test image

The same pattern repeated several times over varying background and angles.

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

[gwenview] [Bug 277996] Make it possible to adjust JPEG quality/compression settings when saving

2019-08-26 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=277996

--- Comment #16 from DrSlony  ---
Created attachment 122371
  --> https://bugs.kde.org/attachment.cgi?id=122371=edit
Chroma subsampling 4:2:0

Quality 90, chroma subsampling 4:2:0 - chroma information was quartered (halved
horizontally and vertically).

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

[systemsettings] [Bug 388872] User Manager does not let me configure myself

2020-01-21 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=388872

--- Comment #2 from DrSlony  ---
I have reinstalled since then, and can no longer reproduce.

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

[Breeze] [Bug 396561] Inkscape does not use native theme when opening SVG but does when opening Inkscape directly

2020-09-29 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=396561

DrSlony  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED
 Status|NEEDSINFO   |RESOLVED

--- Comment #10 from DrSlony  ---
Tested Inkscape 1.0 in KDE using Breeze Dark, using Plasma 5.19.4, Frameworks
5.72.0 and Qt 5.15.0.

No longer an issue - Inkscape launched both ways shows the same correct colors
with clearly visible tooltips.

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

[digikam] [Bug 155384] Easily copy properties from one image to another one

2021-01-07 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=155384

DrSlony  changed:

   What|Removed |Added

 CC|b...@londonlight.org|

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

[kate] [Bug 396623] Script categorization could use improvement

2020-11-05 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=396623

--- Comment #3 from DrSlony  ---
Hey

Since Emmet is an external plugin, it could be argued for Emmet scripts to
remain separate.

The "category:" entries link is dead.

I see two entries in Navigation, one entry in Quick Coding and seven in
Editing. I'm a developer and don't know the difference between Editing and
Quick Coding. No point having a subcategory for two, let alone one, items. I
would get rid of those rather empty and ambiguous categories and just have the
entries right under Scripts.

Furthermore, the Tools menu has entries such as Uppercase, Lowercase,
Capitalize... These are effectively no different than the entries in Scripts >
Editing, such as Sort Selected Text, Move Lines Up, etc. From a user's
perspective, they all belong together. I shouldn't need to hunt through menus
and submenus looking for something which has been (to me arbitrarily)
categorized based on whether it comes from a script or not, or maybe whether it
comes from a bash script or a python script or C++.

What I'm essentially saying is that, unless it's common practice for KWrite
users to modify what appears under the Scripts menu, it would be good to get
rid of this sub-categorization based on where a bit of code comes from, and
just list actions in one place, making them easier for users to find.

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

[kdenlive] [Bug 434754] Crash on "Clear current cache"

2021-05-31 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434754

DrSlony  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |REPORTED
 Ever confirmed|1   |0

--- Comment #10 from DrSlony  ---
Tested kdenlive-21.07.70-9b89f4e-x86_64.appimage with no project open.

Crash fixed.

There are still 2 popups with the same message.

If I select all folders and click "Clear current cache", OR if I delete all
folders one by one and then delete the last one, the last one appears twice.

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

[kdenlive] [Bug 434754] Crash on "Clear current cache"

2021-05-31 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434754

--- Comment #11 from DrSlony  ---
Created attachment 138894
  --> https://bugs.kde.org/attachment.cgi?id=138894=edit
same folder listed twice

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

[kdenlive] [Bug 434752] missing build version from AppImage

2021-03-23 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434752

--- Comment #3 from DrSlony  ---
A tag is a description of a specific commit, so if the build I was using is
made off of a tag, then yes, there is no need for a commit hash. When I opened
the issue, I thought I was using a nightly build, but this was incorrect. You
are right that nightly builds do include the hash. So all good.

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

[kdenlive] [Bug 434753] Website - backtrace info box text is difficult to read

2021-03-23 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434753

--- Comment #3 from DrSlony  ---
Great, fixed!

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

[klipper] [Bug 353087] klipper pops up 3 context menus when triggered

2021-04-01 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=353087

--- Comment #3 from DrSlony  ---
I haven't seen this bug for quite some time. Let's close.

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

[kdenlive] [Bug 385981] Creation and deletion of project profiles not displayed correctly

2021-04-05 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=385981

DrSlony  changed:

   What|Removed |Added

 Status|NEEDSINFO   |REPORTED
 Resolution|WAITINGFORINFO  |---
 Ever confirmed|1   |0

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

[kdenlive] [Bug 434754] Crash on "Clear current cache"

2021-03-22 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434754

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

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

[kdenlive] [Bug 434754] New: Crash on "Clear current cache"

2021-03-22 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434754

Bug ID: 434754
   Summary: Crash on "Clear current cache"
   Product: kdenlive
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: User Interface
  Assignee: j...@kdenlive.org
  Reporter: b...@londonlight.org
  Target Milestone: ---

kdenlive-20.12.3a-x86_64.appimage (can't find the exact build hash in the
AppImage - issue #434752)

1. Run kdenlive > Settings > Manage Cached Data.
2. Select a folder with an auto-generated numeric name, e.g. 1616409092687.
3. Click "Delete current cache"
4. In the popup warning dialog, click Continue.
5. In the second warning popup dialog (too many warning popup dialogs!), click
Continue. Crash.

qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2467, resource
id: 16114544, major code: 40 (TranslateCoords), minor code: 0
/tmp/.mount_kdenliT4I9py/AppRun: line 42: 32335 Segmentation fault  (core
dumped) kdenlive --config kdenlive-appimagerc $@

When I ran "gdb ./kdenlive-20.12.3a-x86_64.appimage", there was no stack.

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

[kdenlive] [Bug 434752] New: missing build version from AppImage

2021-03-22 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434752

Bug ID: 434752
   Summary: missing build version from AppImage
   Product: kdenlive
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Installation
  Assignee: vpi...@kde.org
  Reporter: b...@londonlight.org
  Target Milestone: ---

The AppImage should include the build version (commit hash) so that bug reports
can offer some useful info regarding the version. Currently, the latest
AppImage filename is "kdenlive-20.12.3a-x86_64.appimage" which really tells us
little, and when you run it and go to Help > About Kdenlive you see "Version
20.12.3" which is very vague.

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

[kdenlive] [Bug 434752] missing build version from AppImage

2021-03-22 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434752

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

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

[kdenlive] [Bug 434753] New: Website - backtrace info box text is difficult to read

2021-03-22 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434753

Bug ID: 434753
   Summary: Website - backtrace info box text is difficult to read
   Product: kdenlive
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Documentation
  Assignee: ttg...@gmail.com
  Reporter: b...@londonlight.org
  Target Milestone: ---

https://kdenlive.org/en/bug-reports/

The "How to get useful crash information (backtrace)" box shows yellow text
(#ada771) on a yellow background (#f9f9da). I have a calibrated/profiled
monitor and that text is difficult to read.

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

[kdenlive] [Bug 434753] Website - backtrace info box text is difficult to read

2021-03-22 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434753

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

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

[kdenlive] [Bug 385981] Creation and deletion of project profiles not displayed correctly

2021-03-22 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=385981

--- Comment #6 from DrSlony  ---
kdenlive-20.12.3a-x86_64.appimage (can't find the exact build hash in the
AppImage - issue #434752)

Settings > Configure Kdenlive > Project Defaults > Manage project profiles
(icon button)

Original point 1 is still valid - the combobox shows "HD 1080p 25 fps" and
after hitting "Create new profile" it still shows the same text. It looks like
I'm editing that profile, not creating a new one.

Point 2 is no longer valid. After saving, the combobox is updated to show the
new profile.

Point 3 is no longer valid. After hitting "Close", the list of profiles is
reloaded.

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

[kdenlive] [Bug 434754] Crash on "Clear current cache"

2021-04-21 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434754

--- Comment #4 from DrSlony  ---
> It seems you have opened "Manage Cached Data" after you opened a project or 
> changed anything on the "untitled" project

Negative, the steps to reproduce are from once I start kdenlive.

I'm using Sabayon.

I will attach a screencast to help.

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

[kdenlive] [Bug 434754] Crash on "Clear current cache"

2021-04-21 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434754

--- Comment #5 from DrSlony  ---
Created attachment 137758
  --> https://bugs.kde.org/attachment.cgi?id=137758=edit
Screencast of crash

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

[kdenlive] [Bug 434754] Crash on "Clear current cache"

2021-04-21 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=434754

--- Comment #2 from DrSlony  ---
Hey

Yes I am familiar with gdb, but the stack is empty, so no backtrace.

I tested kdenlive-21.04.0-rc-x86_64.appimage and received the same 2
confirmation popups and reproduced the same crash.

(gdb) bt full
No stack.

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

[kdenlive] [Bug 443468] New: NVENC H264 render profiles obsolete

2021-10-08 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=443468

Bug ID: 443468
   Summary: NVENC H264 render profiles obsolete
   Product: kdenlive
   Version: 21.08.1
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Video Display & Export
  Assignee: j...@kdenlive.org
  Reporter: b...@londonlight.org
  Target Milestone: ---

Kdenlive 21.08.1.

Create a project, click "Render" and select either of these formats:
NVENC H264 ABR
NVENC H264 VBR

Click "Render to file". The job error log says:
> This encoder is deprecated, use 'h264_nvenc' instead

Currently, the format options show the codec name is "nvenc_h264", so just swap
it around.

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

[kdenlive] [Bug 443468] NVENC H264 render profiles obsolete

2021-10-08 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=443468

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

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

[kdenlive] [Bug 444595] No way to define default project folder

2021-11-15 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=444595

--- Comment #2 from DrSlony  ---
Which GUI widget corresponds to KdenliveSettings::defaultprojectfolder ? Is it
Configure > Project Defaults > Custom project folder?

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

[kdenlive] [Bug 444593] New: "Select Folder" windows are unresponsive and cannot be closed

2021-10-29 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=444593

Bug ID: 444593
   Summary: "Select Folder" windows are unresponsive and cannot be
closed
   Product: kdenlive
   Version: 21.08.1
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: User Interface
  Assignee: j...@kdenlive.org
  Reporter: b...@londonlight.org
  Target Milestone: ---

SUMMARY
Some of the "Select Folder" windows are unresponsive and refuse to close,
forcing me to kill Kdenlive.

STEPS TO REPRODUCE
1. Start KDENlive
2. Go to Project > Project Settings
3. Enable "Custom project folder" and click "Open file dialog" button.

ALTERNATIVE STEPS TO REPRODUCE
1. Start KDENlive
2. Go to Configure > Environment > Default folders
3. Disable "Use default folder" for "library folder" and click the button to
select a folder.

OBSERVED RESULT
"Select Folder" window pops up, but is non-responsive. Clicking anything in the
tree, or Places, or any of the buttons, does nothing.

When I resize the "Select Folder" window, the contents resize accordingly, so
it's not completely frozen, just completely unresponsive.

No form of closing the window works ("Cancel" button in lower-right, "x" button
in window titlebar, Alt+F4, clicking on the window titlebar and selecting
"Close", etc). I have to kill Kdenlive.

I'm using the Flatpak in MX Linux.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: MX Linux
KDE Plasma Version: 5.14.5
KDE Frameworks Version: MX is using 5.54.0, Kdenlive flatpak shows 5.86.0
Qt Version: MX is using 5.11.3, Kdenlive flatpak shows 5.15.3.

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

[kdenlive] [Bug 444593] "Select Folder" windows are unresponsive and cannot be closed

2021-10-29 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=444593

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org
Version|21.08.1 |21.08.2

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

[kdenlive] [Bug 444595] New: No way to define default project folder

2021-10-29 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=444595

Bug ID: 444595
   Summary: No way to define default project folder
   Product: kdenlive
   Version: 21.08.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: User Interface
  Assignee: j...@kdenlive.org
  Reporter: b...@londonlight.org
  Target Milestone: ---

I want to set all new projects to use /foo as the project folder by default.
There seems to be no way of doing so.

I can go to Project > Project Settings and set "Custom project folder", but
that only applies to that project.

I can go to Configure > Project Defaults and change "Custom project folder",
but that only applies to the edited project. It does not change the default.

I can go to Configure > Environment > Default Folders, but there is no option
called "Project folder".

So either there is no way of doing that, in which case this is a feature
request, or there is a way of doing it but it is mis-labeled or mis-placed.

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

[kdenlive] [Bug 444595] No way to define default project folder

2021-10-29 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=444595

DrSlony  changed:

   What|Removed |Added

 CC||b...@londonlight.org

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

[kdenlive] [Bug 444596] New: Unnecessary clip jobs when adding clips

2021-10-29 Thread DrSlony
https://bugs.kde.org/show_bug.cgi?id=444596

Bug ID: 444596
   Summary: Unnecessary clip jobs when adding clips
   Product: kdenlive
   Version: 21.08.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Video Display & Export
  Assignee: j...@kdenlive.org
  Reporter: b...@londonlight.org
  Target Milestone: ---

SUMMARY
When I add clips to a project, Kdenlive automatically starts performing some
clip jobs... What are these jobs, what is it doing? These are large clips which
I must convert to proxy clips before I can work with them. So after half an
hour of waiting for these clip jobs to finish, I select all the clips,
right-click them and select "Proxy clip", then I wait another hour.

STEPS TO REPRODUCE
1. Add large clips to project.

OBSERVED RESULT
Unnecessary clip jobs.

EXPECTED RESULT
No unnecessary clip jobs.

What are these clip jobs Kdenlive performs when I add a clip?

-- 
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

2015-12-20 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=351248

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

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

--- Comment #7 from DrSlony <b...@londonlight.org> ---
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.


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

2015-12-27 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357224

DrSlony <b...@londonlight.org> 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

2015-12-27 Thread 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.


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

2016-06-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=317210

--- Comment #26 from DrSlony <b...@londonlight.org> ---
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

2016-06-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=317210

--- Comment #29 from DrSlony <b...@londonlight.org> ---
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

2016-06-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=317210

--- Comment #25 from DrSlony <b...@londonlight.org> ---
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

2016-06-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=363937

--- Comment #2 from DrSlony <b...@londonlight.org> ---
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

2016-06-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=363937

--- Comment #4 from DrSlony <b...@londonlight.org> ---
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] New: Add option to disable thumbnails in Import window

2016-06-04 Thread 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 363937] Add option to disable thumbnails in Import window

2016-06-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=363937

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

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


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

2016-06-26 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=364790

--- Comment #1 from DrSlony <b...@londonlight.org> ---
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

2016-06-26 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=364790

DrSlony <b...@londonlight.org> 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

2016-06-26 Thread 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 358848] Chroma subsampling incorrectly described

2016-02-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358848

--- Comment #3 from DrSlony <b...@londonlight.org> ---
+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

2016-01-31 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358844

DrSlony <b...@londonlight.org> 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

2016-01-31 Thread 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

2016-01-31 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358843

DrSlony <b...@londonlight.org> 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

2016-01-31 Thread 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

2016-01-31 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358843

--- Comment #2 from DrSlony <b...@londonlight.org> ---
Sorry, where?

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


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

2016-01-31 Thread 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

2016-01-31 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=358848

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
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...)

2016-02-03 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=193232

--- Comment #22 from DrSlony <b...@londonlight.org> ---
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 359899] Tags Filter panel too wide

2016-02-28 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359899

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

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


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

2016-02-28 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359897

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

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


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

2016-02-28 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=319241

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

Version|4.10.0  |5.0.0

--- Comment #9 from DrSlony <b...@londonlight.org> ---
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] New: Compilation failure - conflicting return type decodeRawImage()

2016-02-28 Thread 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 359899] New: Tags Filter panel too wide

2016-02-28 Thread 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.


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

2016-02-28 Thread 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.


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

2016-02-28 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359909

--- Comment #1 from DrSlony <b...@londonlight.org> ---
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

2016-02-28 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359909

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

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


[Breeze] [Bug 354370] GIMP icon is bad

2016-02-29 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=354370

--- Comment #8 from DrSlony <b...@londonlight.org> ---
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.


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

2016-03-01 Thread 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.


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

2016-03-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359963

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

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


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

2016-03-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359967

--- Comment #2 from DrSlony <b...@londonlight.org> ---
Confirmed.

-- 
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

2016-03-01 Thread 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 359966] Clicking and holding a spinbox arrow doesn't keep increasing the value

2016-03-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359966

DrSlony <b...@londonlight.org> 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

2016-03-01 Thread 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 359967] Edit slider values as text

2016-03-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359967

DrSlony <b...@londonlight.org> 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

2016-03-01 Thread 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 359969] BQM claims it finished processing instantly

2016-03-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359969

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
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

2016-03-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359966

--- Comment #2 from DrSlony <b...@londonlight.org> ---
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.


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

2016-03-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=360075

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

-- 
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

2016-03-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=360076

DrSlony <b...@londonlight.org> 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

2016-03-04 Thread 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 360075] New: No way to control color management

2016-03-04 Thread 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.


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

2016-03-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=360077

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

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


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

2016-03-04 Thread 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.


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

2016-03-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359959

--- Comment #4 from DrSlony <b...@londonlight.org> ---
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 359960] digiKam product category lacks recent versions

2016-03-03 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359960

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

--- Comment #4 from DrSlony <b...@londonlight.org> ---
"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 359959] Labels Filter panel requires too much horizontal space

2016-03-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359959

--- Comment #2 from DrSlony <b...@londonlight.org> ---
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.


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

2016-03-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359899

--- Comment #2 from DrSlony <b...@londonlight.org> ---
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.


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

2016-03-01 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=359959

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

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


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

2016-03-01 Thread 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 345649] Assigning "Rejected" label using Alt+1 shortcut leaves focus on menu

2016-07-31 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=345649

--- Comment #9 from DrSlony <b...@londonlight.org> ---
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 364790] Preview image shown too large

2016-06-27 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=364790

--- Comment #5 from DrSlony <b...@londonlight.org> ---
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

2016-06-27 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=364790

--- Comment #3 from DrSlony <b...@londonlight.org> ---
"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.

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

2016-07-04 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=341407

--- Comment #4 from DrSlony <b...@londonlight.org> ---
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 275364] Allow to batch process more than one set of bracketed images

2016-07-05 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=275364

DrSlony <b...@londonlight.org> 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.


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

2016-07-08 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=338730

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

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

--- Comment #8 from DrSlony <b...@londonlight.org> ---
Cannot reproduce in 5.0.0 (92997d9c6c589e044ab77c3ca1e726627ae2e0a3).

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


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

2016-07-08 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=281742

--- Comment #9 from DrSlony <b...@londonlight.org> ---
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

2016-07-09 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=338730

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

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

--- Comment #9 from DrSlony <b...@londonlight.org> ---
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 162132] crash while saving tiff (possibly caused by present alpha channel)

2016-07-03 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=162132

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

--- Comment #4 from DrSlony <b...@londonlight.org> ---
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 204311] choice of resizing algorithms in resize dialog along with preview of each

2016-07-03 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=204311

--- Comment #1 from DrSlony <b...@londonlight.org> ---
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

2016-07-03 Thread DrSlony via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=221985

DrSlony <b...@londonlight.org> changed:

   What|Removed |Added

 CC||b...@londonlight.org

--- Comment #4 from DrSlony <b...@londonlight.org> ---
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.



<    1   2