[Digikam-devel] extragear/graphics/digikam/utilities/imageeditor/tools

[F.J.Cruz]

SVN commit 507273 by fjcruz:

If the image to print has an icc profile embedded, this one is used to apply the printer profile.

CCMAIL:[hidden email]

 M  +10 -1     imageprint.cpp  


--- trunk/extragear/graphics/digikam/utilities/imageeditor/tools/imageprint.cpp #507272:507273
@@ -278,7 +278,16 @@
         IccTransform *transform = new IccTransform();
         readSettings();
 
-        transform->setProfiles( m_inProfilePath, m_outputProfilePath );
+        if (m_image.getICCProfil().isNull())
+        {
+            transform->setProfiles( m_inProfilePath, m_outputProfilePath );
+        }
+        else
+        {
+            transform->setProfiles(m_outputProfilePath);
+        }
+
+        
         transform->apply( m_image );
     }
     
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Am Mittwoch 08 Februar 2006 22:38 schrieb Francisco J. Cruz:
> SVN commit 507273 by fjcruz:

Hi Francisco,

a small question about ICC. I am a newbie when it comes to cms practice but I
know the wider basics. So I setup some icc profiles
20D.icc for my cam, 171s.icm for my monitor and sRGB as system profile

The RAW file format of the 20D has a dynamic of 4096 levels of intensity.
The IE uses 16bit dynamic or 65K levels per channel and the standard raw
convertion results in a dark picture.
I thought that when I apply a icc profile the 12bit will be extrapolated into
the 16bit  sRGB color space. This does not happen when I test this stuff with
0.9.0-svn.
Should this work?

A side note: My original Samsung icm profiles occurs unlabeled (no profile
description) in digiKams profile set-up.
Shall I mail you this profile so you can check how the profile name is tagged?

Bye

  Thorsten  

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

[F.J.Cruz]

El Miércoles, 8 de Febrero de 2006 23:11, Thorsten Schnebeck escribió:
> Am Mittwoch 08 Februar 2006 22:38 schrieb Francisco J. Cruz:
> > SVN commit 507273 by fjcruz:
>
> Hi Francisco,

Hi Thorsten,

>
> a small question about ICC. I am a newbie when it comes to cms practice but

Me too!! :-)

> I know the wider basics. So I setup some icc profiles
> 20D.icc for my cam, 171s.icm for my monitor and sRGB as system profile
>

I guess you mean workspace profile when you say "system profile". If I'm right
about this, maybe you'd have to choose an icc profile with a wider "color
gamut", like Adobe1998 or similar, that are intended to image edition. But
this is an advice only, you can use the profile you like, of course :-)

> The RAW file format of the 20D has a dynamic of 4096 levels of intensity.
> The IE uses 16bit dynamic or 65K levels per channel and the standard raw
> convertion results in a dark picture.
> I thought that when I apply a icc profile the 12bit will be extrapolated
> into the 16bit  sRGB color space. This does not happen when I test this
> stuff with 0.9.0-svn.
> Should this work?
>

As probably you know, digiKam use Dave Coffin's dcraw application, and in his
faq we can read this:

"Why is 16-bit output dark / flattened / unreadable?
If you want pretty pictures straight out of dcraw, stay with 8-bit output.
16-bit linear output is the best raw material for professional image editors
such as  PhotoShop and CinePaint, but it's no good for most image viewers."

After you apply the icc profile, you have to:

1. Adjust wite balance, specially exposure.
2. Adjust curves, you can try some curve files from cinepaint ("point and
shoot" and "white wedding" family can be good start points)

> A side note: My original Samsung icm profiles occurs unlabeled (no profile
> description) in digiKams profile set-up.
> Shall I mail you this profile so you can check how the profile name is
> tagged?
>

It's not necessary to do it, in fact there are a lot of profiles manufacturers
that don't "fill" all the fields.

> Bye
>

Bye, I hope I can help you and excuse my poor english. :-)

>   Thorsten
>

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

[Thorsten Schnebeck-2]

Am Donnerstag 09 Februar 2006 10:15 schrieb F.J.Cruz:
> El Miércoles, 8 de Febrero de 2006 23:11, Thorsten Schnebeck
escribió:

> > Am Mittwoch 08 Februar 2006 22:38 schrieb Francisco J. Cruz:
> > > SVN commit 507273 by fjcruz:
> >
> > Hi Francisco,
>
> Hi Thorsten,
>
> > a small question about ICC. I am a newbie when it comes to
> > cms practice but
>
> Me too!! :-)

:-)

> As probably you know, digiKam use Dave Coffin's dcraw
> application, and in his faq we can read this:
>
> "Why is 16-bit output dark / flattened / unreadable?
> If you want pretty pictures straight out of dcraw, stay with
> 8-bit output. 16-bit linear output is the best raw material for
> professional image editors such as  PhotoShop and CinePaint,
> but it's no good for most image viewers."

Yes, I know that. But how does CMS interfer with dynamic?
Shall I make a linear transformation to extent the 4k levels into
the 16k level or has CMS take place into this transformation.

Is there a correlation between an ICC-profile and the number of
colors or is profile processing level independent?

I do not understand what a camera profile makes?
I do not know how levels and colors come together?

> After you apply the icc profile, you have to:
>
> 1. Adjust wite balance, specially exposure.
> 2. Adjust curves, you can try some curve files from cinepaint
> ("point and shoot" and "white wedding" family can be good start
> points)

How can this manual adjustment be allowed when using an e.g.
colormetric system?

> > A side note: My original Samsung icm profiles occurs
> > unlabeled (no profile description) in digiKams profile
> > set-up.
> > Shall I mail you this profile so you can check how the
> > profile name is tagged?
>
> It's not necessary to do it, in fact there are a lot of
> profiles manufacturers that don't "fill" all the fields.

Ah! So, what about showing at least the filename when the "vendor
tag" is empty?

Bye

  Thorsten

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

[F.J.Cruz]

El Jueves, 9 de Febrero de 2006 13:12, Thorsten Schnebeck escribió:

A lot of things!! :-D

Well Thorsten, before you read what I'm going to say you, you have to take in
account I'm not an expert with color management stuff, I only know the API
that a Color Management System offers to me.

Ok, let's go:

Each device we use to produce/storage/modify an image has its own set of
colours, this is, each device can produce or reproduce a fixed set of colours
that we can call "the color gamut" of the device. This color gamut will vary
widely with differents devices. This means that some colors will not be the
same when produced on two different devices.

The role of color management is to determine what coded values are needed on a
given device to produce the desired color and this is done using the ICC
color profiles: digital data file in a standardized format, which defines the
color gamut of a specific device.

A Color Management Module (we are using Little-CMS) is a conversion engine
which translates the pixels colors from a color space to another color space.
A color profile is a set of tables of parameters and mathematical matrix
coefficients or raw color values describing the target gamut in a standard
format.

During the conversion, some colors of the asigned color profile will be out of
gamut and they will be clipped, this is, they'll be changed to a similar (but
different) color or de-saturated (pushed to the edge of the gamut).  There
are four primary algorithms for handling this conversion and they are called
"rendering intents": Perceptual Intent, Saturation Intent, Absolute
Colorimetric Intent, and Relative Colorimetric Intent.

On the other hand, the icc color profiles can be of three diferents types:

- Inputs profiles (cameras and scanners): an input profiles describes the
color gamut of a camera or scanner. All cameras and scanner "read" the color
in RGB. These are "one direction" profiles, this is,  we can translate from
device coordinates to absolut coordinates. The profile can also contain one
dimension curves that can be linears or non linears, altough the purpose of
theses curves are not specified and depend on the app which buids the
profile.

- Display profiles (monitors): a display profile describes the color gamut of
a TFT or CRT monitor or a workspace (we can thinkg about it as an "ideal"
monitor). It's a two-direcctions profile: we can do transform from it or to
it (from RGB to PCS or from PCS to RGB).

- Output profiles (printers and film recorders): these are two-directions
profiles too. An output profile can be RGB or CMYK.

Basically this is what a ICC color profile is and how it works.

About this:

> How can this manual adjustment be allowed when using an e.g.
> colormetric system?

I'm afraid I don't understand your question, sorry. :-(


> Ah! So, what about showing at least the filename when the "vendor
> tag" is empty?

I guess you are talking about info messages in dialog setup. These messages
show the path to the profile.

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

Am Donnerstag 09 Februar 2006 23:21 schrieb F.J.Cruz:
> A Color Management Module (we are using Little-CMS) is a conversion engine
> which translates the pixels colors from a color space to another color
> space. A color profile is a set of tables of parameters and mathematical
> matrix coefficients or raw color values describing the target gamut in a
> standard format.
[...]
> - Inputs profiles (cameras and scanners): an input profiles describes the
> color gamut of a camera or scanner. All cameras and scanner "read" the
> color in RGB. These are "one direction" profiles, this is,  we can
> translate from device coordinates to absolut coordinates. The profile can
> also contain one dimension curves that can be linears or non linears,
> altough the purpose of theses curves are not specified and depend on the
> app which buids the profile.

Ok, I make a new example. Lets focus on two colors, black and white :-)

My cam produces a jpeg, 8-Bit per channel so white is
RGB8=(255,255,255) and black is RGB8=(0,0,0)
If I use the RAW mode white is
RGB12=(4095,4095,4095) and black is RGB12=(0,0,0)
When I view a 16Bit PNG the color white is
RGB16=(65535,65535,65535) and black stays RGB16=(0,0,0)

So now I want to start using CMS. The cam's  JPEG are calibrated in sRGB. When
using RAW I have to apply an external profile. Like you said in your
description a input color like RGB12(white) will be translated to a target
like e.g. RGB16(white) . Thats my problem in understanding this stuff. The
color white is well defined in all color spaces, so when I use CMS why do I
have to manually adjust the target color range. White should be white, or?

Maybe the problem is, that we did not talk about format conversion so far but
only about device color ranges. Is a PNG-16bit file handled like an output
device?

> > Ah! So, what about showing at least the filename when the "vendor
> > tag" is empty?
>
> I guess you are talking about info messages in dialog setup. These messages
> show the path to the profile.

I attach a screenshot of the setup dialog. Please look at the monitor profile
(Monitorprofil) its set-up, as you see in the the info box but not shown in
the dialog.

Thanks for your patience :-)

Thorsten

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

[F.J.Cruz]

---- Thorsten Schnebeck <[hidden email]> escribió:

> Am Donnerstag 09 Februar 2006 23:21 schrieb F.J.Cruz:
> > A Color Management Module (we are using Little-CMS) is a conversion engine
> > which translates the pixels colors from a color space to another color
> > space. A color profile is a set of tables of parameters and mathematical
> > matrix coefficients or raw color values describing the target gamut in a
> > standard format.
> [...]
> > - Inputs profiles (cameras and scanners): an input profiles describes the
> > color gamut of a camera or scanner. All cameras and scanner "read" the
> > color in RGB. These are "one direction" profiles, this is,  we can
> > translate from device coordinates to absolut coordinates. The profile can
> > also contain one dimension curves that can be linears or non linears,
> > altough the purpose of theses curves are not specified and depend on the
> > app which buids the profile.
>
> Ok, I make a new example. Lets focus on two colors, black and white :-)
>
> My cam produces a jpeg, 8-Bit per channel so white is
> RGB8=(255,255,255) and black is RGB8=(0,0,0)
> If I use the RAW mode white is
> RGB12=(4095,4095,4095) and black is RGB12=(0,0,0)
> When I view a 16Bit PNG the color white is
> RGB16=(65535,65535,65535) and black stays RGB16=(0,0,0)
>
> So now I want to start using CMS. The cam's  JPEG are calibrated in sRGB. When
> using RAW I have to apply an external profile. Like you said in your
> description a input color like RGB12(white) will be translated to a target
> like e.g. RGB16(white) . Thats my problem in understanding this stuff. The
> color white is well defined in all color spaces, so when I use CMS why do I
> have to manually adjust the target color range. White should be white, or?
>

Well, are you sure all your photos have a pure white? because you have to remember that the "white" color depends on external factors, maybe the most importat is the ambient light: incandescent, fluorescent, sunlight, flash, etc. Your white color, or i have to say what your eyes see as a pure white color, is not the same from a color space to another. In any case, when you correct the white level you are doing something like this: "ok, let's me see what 'white' is the more white....ahm, this one, so all the rest have to been adjust from this".

> Maybe the problem is, that we did not talk about format conversion so far but
> only about device color ranges. Is a PNG-16bit file handled like an output
> device?
>

You have to forget all about file formats. A color transform using an ICC color profile and a Color Management Engine has no relation with the image file format. None of the image file formats are handled as any kind of devices, they are only data containers. When we talk about devices we mean physical devices: cameras, scanners, monitors, printers or film recorders.

> > > Ah! So, what about showing at least the filename when the "vendor
> > > tag" is empty?
> >
> > I guess you are talking about info messages in dialog setup. These messages
> > show the path to the profile.
>
> I attach a screenshot of the setup dialog. Please look at the monitor profile
> (Monitorprofil) its set-up, as you see in the the info box but not shown in
> the dialog.
>

Ok, now I see what you want to say. I'll look for a solution :-).
 
> Thanks for your patience :-)
>

No problem ;-).

> Thorsten


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

Am Freitag 10 Februar 2006 08:56 schrieb [hidden email]:

> Well, are you sure all your photos have a pure white? because
> you have to remember that the "white" color depends on external
> factors, maybe the most importat is the ambient light:
> incandescent, fluorescent, sunlight, flash, etc. Your white
> color, or i have to say what your eyes see as a pure white
> color, is not the same from a color space to another. In any
> case, when you correct the white level you are doing something
> like this: "ok, let's me see what 'white' is the more
> white....ahm, this one, so all the rest have to been adjust
> from this".

Ok, but an RGB12-white is nearly black in RGB16

> > Maybe the problem is, that we did not talk about format
> > conversion so far but only about device color ranges. Is a
> > PNG-16bit file handled like an output device?
>
> You have to forget all about file formats. A color transform
> using an ICC color profile and a Color Management Engine has no
> relation with the image file format. None of the image file
> formats are handled as any kind of devices, they are only data
> containers. When we talk about devices we mean physical
> devices: cameras, scanners, monitors, printers or film
> recorders.

So, this is my "missing-link" :-) If this does not happen then it
is clear why applying profiles does not lead to an
auto-transformation of color levels.

But would this not make sense(?)
I mean, I know the transformed RAW files are way to dark in 16-bit
so does it makes sense to linear stretch 0-4096 to 0-65535?
Now this starts to leave the area of CMS and is more a DImg raw
prosessing question :-)

Thanks

  Thorsten

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