Bug 125735 - Can't disable individual Monitor/Workspace/Input/Proof profiles
Summary: Can't disable individual Monitor/Workspace/Input/Proof profiles
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: ColorManagement-Profiles (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-17 14:50 UTC by Duncan Hill
Modified: 2022-02-01 11:19 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 7.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan Hill 2006-04-17 14:50:30 UTC
Version:           0.9 SVN (using KDE KDE 3.5.2)
Compiler:          gcc 4.0.2 prerelease 
OS:                Linux

In .9 SVN, digiKam assumes that if there is a file that matches the category, then the file should be loaded.  The only way to disable any of the profiles is to move it out of the directory, and reset the configuration options.  It would be nice if the dropdowns offered 'None' as an option for each profile category, allowing the user to selectively disable categories if they want to.
Comment 1 caulier.gilles 2006-04-17 15:12:46 UTC
I'm fully agree with you Ducan, about this point. 

Paco, can you give us your viewpoint ? Thanks in advance.

Gilles Caulier
Comment 2 F.J. Cruz 2006-04-18 10:12:35 UTC
---- Duncan Hill <kdebugs@nacnud.force9.co.uk> escribió: 
[bugs.kde.org quoted mail]
I think a "None" option makes no sense, let's me explain this:

For a basic color management system you need at least two profiles: an input and an output/workspace one, if you select "none" for one of them, then you are breaking the color workflow, this is, you are disabling the CMS.

On the other hand, the monitor profile works only if "Managed view" option is enabled and the proof profile is usefull if you use the CM plugin avaliable in Image Editor and showfoto.

Paco Cruz
Comment 3 Duncan Hill 2006-04-18 10:54:17 UTC
Ahh.  Fair enough - blame this on not knowing enough about how colour managed workflows are meant to work :)  Perhaps the configuration interface needs a slight re-work so that you have something like:

[] Enable colour management
[_____________________________] [Dir browse button]

Basic colour management
-----------------------
Input profile    :  [ Dynax 5D ^ ]  [Info]
Workspace profile:  [ sRGB     ^ ]  [Info]
() Automatically apply colour management when editing and viewing
() Ask whether to apply colour management when editing and viewing

Advanced colour management
--------------------------
[] Enable colour managed view
[] Use black point compensation
Rendering intent :  [ Percept  ^ ]  [Help]
Monitor profile  :  [ sRGB     ^ ]  [Info]
Proofing profile :  [ sRGB     ^ ]  [Info]

This splits up the profile loading, but categorises each type of profile by basic or advanced.

Validation:
When save is clicked, if only one half of the basic setup is provided (input or workspace), indicate that this won't work, and offer to disable colour management?
Comment 4 F.J. Cruz 2006-04-18 11:01:03 UTC
---- Duncan Hill <kdebugs@nacnud.force9.co.uk> escribió: 
[bugs.kde.org quoted mail]

Of course, we can review the setup page for Color Management.

What do you thing about this Gilles?

Paco Cruz.
Comment 5 caulier.gilles 2006-04-18 13:50:25 UTC
Yes, this way look good for me. PAcon we have always a developpers view about GUI. Sometimes user viewpoint sound like more easy to understand... and ICC workflow is a little bit complex.

I'm agree to change GUI using Duncan proposal. 

Paco, who make the changes ? you or me (:=)))) ?

Gilles 
Comment 6 F.J. Cruz 2007-02-15 23:12:27 UTC
Bug is going to be closed.

Paco Cruz.