Working with CIELab TIFFs?

Hi everyone,

just tried to open a TIFF which is in CIELab in DigiKam, but I got an
error message

"digikam(30199)/digikam (core) Digikam::TIFFLoader::load: Can not handle
image without RGB color-space:  8"

I wonder in how far digikam is Lab-capable at all? I mean, I can choose
a generic Lab identity profile as working color space, but after opening
an image and converting it to Lab, I haven't seen any UI elements which
would look like Lab controls rather than RGB. So it seems that with Lab
being defined as working color space, digikam still converts images to
some RGB-based color space prior to letting the user apply any
operation, right?

Confused --

        Torsten

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2014-05-15 21:59 GMT+02:00  <[hidden email]>:

> Hi everyone,
>
> just tried to open a TIFF which is in CIELab in DigiKam, but I got an error
> message
>
> "digikam(30199)/digikam (core) Digikam::TIFFLoader::load: Can not handle
> image without RGB color-space:  8"
>
> I wonder in how far digikam is Lab-capable at all? I mean, I can choose a
> generic Lab identity profile as working color space, but after opening an
> image and converting it to Lab, I haven't seen any UI elements which would
> look like Lab controls rather than RGB. So it seems that with Lab being
> defined as working color space, digikam still converts images to some
> RGB-based color space prior to letting the user apply any operation, right?

yes it is. digiKam store image color data ad ARGB. It don't know LAB
color space.

Gilles Caulier
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles,

> yes it is. digiKam store image color data ad ARGB. It don't know LAB
> color space.

thanks for that explanation.

Any plans to implement Lab support in the (near or not-so-near) future?
Might prove useful -- I've read several tutorial which suggest that many
color and brightness correction tasks would benefit from working in Lab
colorspace since it completely separates brightness from chromaticity
information.

Regards --

Torsten

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

There is already a report in bugzilla about this topic.

The only way to support non RBG color space with tiff is to process
LAB=>RGB conversion in your case. It's already done for some others
color spaces, but not yet with LAB...

Look here for details :

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

Gilles Caulier


2014-05-16 8:38 GMT+02:00  <[hidden email]>:

> Gilles,
>
>
>> yes it is. digiKam store image color data ad ARGB. It don't know LAB
>> color space.
>
>
> thanks for that explanation.
>
> Any plans to implement Lab support in the (near or not-so-near) future?
> Might prove useful -- I've read several tutorial which suggest that many
> color and brightness correction tasks would benefit from working in Lab
> colorspace since it completely separates brightness from chromaticity
> information.
>
> Regards --
>
>
> Torsten
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Hi,

> There is already a report in bugzilla about this topic.
 > Look here for details :
 > https://bugs.kde.org/show_bug.cgi?id=186054

I see... but this only addresses half the issue. As you say...

> The only way to support non RBG color space with tiff is to process
> LAB=>RGB conversion in your case. It's already done for some others
> color spaces, but not yet with LAB...

...this is about DidiKam internally converting Lab input images to RGB
prior to any processing (like thumbnail generation or edit actions). I
wonder if it was possible to allow for DigiKam to handle Lab
*internally* so that one would be able to e.g. adjust color without
altering percieved brightness.

Regards --

        Torsten


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2014-05-16 13:45 GMT+02:00  <[hidden email]>:

> Hi,
>
>
>> There is already a report in bugzilla about this topic.
>
>> Look here for details :
>> https://bugs.kde.org/show_bug.cgi?id=186054
>
> I see... but this only addresses half the issue. As you say...
>
>
>> The only way to support non RBG color space with tiff is to process
>> LAB=>RGB conversion in your case. It's already done for some others
>> color spaces, but not yet with LAB...
>
>
> ...this is about DidiKam internally converting Lab input images to RGB prior
> to any processing (like thumbnail generation or edit actions). I wonder if
> it was possible to allow for DigiKam to handle Lab *internally* so that one
> would be able to e.g. adjust color without altering percieved brightness.

No. For the moment image container is based on ARGB unsigned short
data conatiner by color component to optimize memory allocation.

RGB color space will deserve 90% of user cases.

Changing color component storage in memory will require to change a
lots of code everywhere.

Nota : For image quality reason i know 3 code that use LAB color space
to work in digiKam : Noise reduction, Local Contrast, and Restoration
tools.

Gilles Caulier

>
>
> Regards --
>
>         Torsten
>
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Gilles,

> No. For the moment image container is based on ARGB unsigned short
> data conatiner by color component to optimize memory allocation.

I see.

> Changing color component storage in memory will require to change a
> lots of code everywhere.

I can imagine that...

> Nota : For image quality reason i know 3 code that use LAB color space
> to work in digiKam : Noise reduction, Local Contrast, and Restoration
> tools.

Sounds reasonable!

Thanks again for your kind replies to my little inquiries.

Regards --

        Torsten


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users