extragear/graphics/digikam/utilities/imageeditor/editor

[F.J.Cruz]

SVN commit 488016 by fjcruz:

Real dynamic support for color management, using settings from dialog setup has been added. Please test and report.

CCMAIL:[hidden email]

 M  +26 -1     imagewindow.cpp  
 M  +3 -0      imagewindow.h  


--- trunk/extragear/graphics/digikam/utilities/imageeditor/editor/imagewindow.cpp #488015:488016
@@ -80,6 +80,7 @@
 #include "imageinfo.h"
 #include "imagepropertiessidebardb.h"
 #include "tagspopupmenu.h"
+#include "iccsettingscontainer.h"
 
 ImageWindow* ImageWindow::imagewindow()
 {
@@ -103,6 +104,8 @@
     m_dirtyImage            = false;
     m_view                  = 0L;
 
+    m_container             = new ICCSettingsContainer();
+
     // -- construct the view ---------------------------------
 
     QWidget* widget  = new QWidget(this);
@@ -526,6 +529,18 @@
     histogramType = (histogramType < 0 || histogramType > 5) ? 0 : histogramType;
     m_viewHistogramAction->setCurrentItem(histogramType);
     slotViewHistogram(); // update
+
+    // Settings for Color Management stuff
+    config->setGroup("Color Management");
+
+    m_container->enableCMSetting = config->readBoolEntry("EnableCM");
+    m_container->askOrApplySetting = config->readBoolEntry("BehaviourICC");
+    m_container->BPCSetting = config->readBoolEntry("BPCAlgorithm");
+    m_container->renderingSetting = config->readNumEntry("RenderingIntent");
+    m_container->inputSetting = config->readPathEntry("InProfileFile");
+    m_container->workspaceSetting = config->readPathEntry("WorkProfileFile");
+    m_container->monitorSetting = config->readPathEntry("MonitorProfileFile");
+    m_container->proofSetting = config->readPathEntry("ProofProfileFile");
 }
 
 void ImageWindow::saveSettings()
@@ -567,7 +582,17 @@
     {
         QApplication::setOverrideCursor(Qt::WaitCursor);
 
-        m_isReadOnly = m_canvas->load(m_urlCurrent.path());
+        // FIXME implement color management here
+        if (m_container->enableCMSetting)
+        {
+            kdDebug() << "enableCMSetting=true" << endl;
+            m_isReadOnly = m_canvas->load(m_urlCurrent.path(), m_container, m_instance);
+        }
+        else
+        {
+            kdDebug() << "imagewindow.cpp line 594" << endl;
+            m_isReadOnly = m_canvas->load(m_urlCurrent.path());
+        }
         
         m_rotatedOrFlipped = false;
 
--- trunk/extragear/graphics/digikam/utilities/imageeditor/editor/imagewindow.h #488015:488016
@@ -45,6 +45,7 @@
 
 class Canvas;
 class AlbumIconView;
+class ICCSettingsContainer;
 
 namespace Digikam
 {
@@ -149,6 +150,8 @@
     static ImageWindow     *m_instance;
 
     Canvas                 *m_canvas;
+
+    ICCSettingsContainer   *m_container;
     
     // Allow to use Image properties and
     // Comments/Tags dialogs from main window.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

Le Lundi 12 Décembre 2005 22:36, Francisco J. Cruz a écrit :
> Real dynamic support for color management, using settings from dialog setup
> has been added. Please test and report.

Of course i will do it (:=)))...

Paco, have you tested your implementation under valgrind ?

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

[Gilles Caulier]

Le Lundi 12 Décembre 2005 22:36, Francisco J. Cruz a écrit :
> SVN commit 488016 by fjcruz:
>
> Real dynamic support for color management, using settings from dialog setup
> has been added. Please test and report.

Linking problems using a full fresh (and purged) copy of svn :

Édition des liens libdigikam.la (libtool)
../../digikam/utilities/imageeditor/editor/.libs/libdimgeditor.a(imagewindow.o):
In function `ImageWindow':
/home/gilles/Documents/Devel/SVN/trunk/graphics/digikam/utilities/imageeditor/editor/imagewindow.cpp:107:
undefined reference to `ICCSettingsContainer::ICCSettingsContainer()'
/home/gilles/Documents/Devel/SVN/trunk/graphics/digikam/utilities/imageeditor/editor/imagewindow.cpp:107:
undefined reference to `ICCSettingsContainer::ICCSettingsContainer()'
collect2: ld returned 1 exit status
gmake[4]: *** [libdigikam.la] Erreur 1

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

[F.J.Cruz]

---- Gilles Caulier <[hidden email]> escribió:
> Le Lundi 12 Décembre 2005 22:36, Francisco J. Cruz a écrit :
> > Real dynamic support for color management, using settings from dialog setup
> > has been added. Please test and report.
>
> Of course i will do it (:=)))...
>
> Paco, have you tested your implementation under valgrind ?
>
> Gilles

Yes, I tested it, but you must feel free to test it again yourself.

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

[F.J.Cruz]

---- Gilles Caulier <[hidden email]> escribió:

> Le Lundi 12 Décembre 2005 22:36, Francisco J. Cruz a écrit :
> > SVN commit 488016 by fjcruz:
> >
> > Real dynamic support for color management, using settings from dialog setup
> > has been added. Please test and report.
>
> Linking problems using a full fresh (and purged) copy of svn :
>
> Édition des liens libdigikam.la (libtool)
> ../../digikam/utilities/imageeditor/editor/.libs/libdimgeditor.a(imagewindow.o):
> In function `ImageWindow':
> /home/gilles/Documents/Devel/SVN/trunk/graphics/digikam/utilities/imageeditor/editor/imagewindow.cpp:107:
> undefined reference to `ICCSettingsContainer::ICCSettingsContainer()'
> /home/gilles/Documents/Devel/SVN/trunk/graphics/digikam/utilities/imageeditor/editor/imagewindow.cpp:107:
> undefined reference to `ICCSettingsContainer::ICCSettingsContainer()'
> collect2: ld returned 1 exit status
> gmake[4]: *** [libdigikam.la] Erreur 1
>
> Gilles
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

Have you fixed it Gilles? (Good morning too ;-))
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

Le Lundi 12 Décembre 2005 22:36, Francisco J. Cruz a écrit :
> Real dynamic support for color management, using settings from dialog setup
> has been added. Please test and report.

Just a little problem :

1/ Go to settings page, enable ICC profiles management, set ICC profiles path
and valid.

2/ Go again to ICC page and disable ICC profiles management.

3/ And go again to re-enable it : look like all old settings are lost.

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

[F.J.Cruz]

---- Gilles Caulier <[hidden email]> escribió:

> Le Lundi 12 Décembre 2005 22:36, Francisco J. Cruz a écrit :
> > Real dynamic support for color management, using settings from dialog setup
> > has been added. Please test and report.
>
> Just a little problem :
>
> 1/ Go to settings page, enable ICC profiles management, set ICC profiles path
> and valid.
>
> 2/ Go again to ICC page and disable ICC profiles management.
>
> 3/ And go again to re-enable it : look like all old settings are lost.
>
> My 10 cts €
>  
> Gilles

Ok, I'll work on it.

Paco.


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

[Gerhard Kulzer]

Bonjour Gilles,
I do my testing on Canon cr2 Raw formats every day, and its really coming good
now with the last changes. I also recovered Canon ICC profiles for all SLR
cameras (if someone is interested?).

However with the changes of Revision 488135 and the one before the ./configure
stops with the following message:
...
checking for lcms >= 1.12...
checking for lcms/lcms.h... (cached) no
checking for lcms.h... (cached) yes
yes
checking for digiKam in our sources... ./configure: line 39200: syntax error:
unexpected end of file

configure looks ok:
 if test "$all_tests" = "bad"; then
  39189   if test ! "$cache_file" = "/dev/null"; then
  39190     echo ""
  39191     echo "Please remove the file $cache_file after changing your
setup"
  39192     echo "so that configure will find the changes next time."
  39193     echo ""
  39194   fi
  39195 else
  39196   echo ""
  39197   echo "Good - your configure finished. Start make now"
  39198   echo ""
  39199 fi

Any idea?

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

[Gilles Caulier]

Le Mardi 13 Décembre 2005 11:58, vous avez écrit :
> Bonjour Gilles,
> I do my testing on Canon cr2 Raw formats every day, and its really coming
> good now with the last changes. I also recovered Canon ICC profiles for all
> SLR cameras (if someone is interested?).

Sure. You can copy this one at free.fr space :

http://digikam3rdparty.free.fr/ICCPROFILS/

>
> However with the changes of Revision 488135 and the one before the
> ./configure stops with the following message:
> ...
> checking for lcms >= 1.12...
> checking for lcms/lcms.h... (cached) no
> checking for lcms.h... (cached) yes
> yes
> checking for digiKam in our sources... ./configure: line 39200: syntax
> error: unexpected end of file
>
> configure looks ok:
>  if test "$all_tests" = "bad"; then
>   39189   if test ! "$cache_file" = "/dev/null"; then
>   39190     echo ""
>   39191     echo "Please remove the file $cache_file after changing your
> setup"
>   39192     echo "so that configure will find the changes next time."
>   39193     echo ""
>   39194   fi
>   39195 else
>   39196   echo ""
>   39197   echo "Good - your configure finished. Start make now"
>   39198   echo ""
>   39199 fi
>
> Any idea?
>
> Gerhard

By error, i had broken .configure file from DigikamImagePlugins this morning.
update a fresh svn solve this problem.
--
Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

Le Mardi 13 Décembre 2005 14:34, vous avez écrit :
> Am Dienstag, 13. Dezember 2005 12.01 schrieb Gilles Caulier:
> > Sure. You can copy this one at free.fr space :
> >
> > http://digikam3rdparty.free.fr/ICCPROFILS/
>
> Done

Waouh. Witch (c) driving these ICC files ?

>
> > By error, i had broken .configure file from DigikamImagePlugins this
> > morning. update a fresh svn solve this problem.
>
> Ok, it works again.
>
> Another problem I have with the RAW cr2 files, when I open them with IE the
> size is only 1/4, i.e. width and height are half the real size only.
>

Hum, i suspect a problem with dcraw program and CR2 file. Can you trying with
dcraw by command line to convert CR2 file to PNG for example ?

Another test can be done using biblelabs (www.bibblelabs.com) program, witch
using dcraw implementation inside to decode RAW files.

Nota : i remember a decoding problem with a CR2 file coming from you. Do you
remember the green _FROGS_ (:=))) :

http://digikam3rdparty.free.fr/Images_2_Test_DImg/RAW/CANON-EOS350D.CR2

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

> > Another problem I have with the RAW cr2 files, when I open
> > them with IE the size is only 1/4, i.e. width and height are
> > half the real size only.
>
> Hum, i suspect a problem with dcraw program and CR2 file. Can
> you trying with dcraw by command line to convert CR2 file to
> PNG for example ?
>
> Another test can be done using biblelabs (www.bibblelabs.com)
> program, witch using dcraw implementation inside to decode RAW
> files.
>
> Nota : i remember a decoding problem with a CR2 file coming
> from you. Do you remember the green _FROGS_ (:=))) :
>
> http://digikam3rdparty.free.fr/Images_2_Test_DImg/RAW/CANON-EOS
>350D.CR2
>
> Gilles

Aloha,

seems to be the "-h" option of the two dcraw commands in
libs/dimg/loaders/rawloader.cpp. Drop the option and you have ful
sized images in IE.

Bye

  Thorsten


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

[Gilles Caulier]

Le Mercredi 14 Décembre 2005 09:27, Thorsten Schnebeck a écrit :

> > > Another problem I have with the RAW cr2 files, when I open
> > > them with IE the size is only 1/4, i.e. width and height are
> > > half the real size only.
> >
> > Hum, i suspect a problem with dcraw program and CR2 file. Can
> > you trying with dcraw by command line to convert CR2 file to
> > PNG for example ?
> >
> > Another test can be done using biblelabs (www.bibblelabs.com)
> > program, witch using dcraw implementation inside to decode RAW
> > files.
> >
> > Nota : i remember a decoding problem with a CR2 file coming
> > from you. Do you remember the green _FROGS_ (:=))) :
> >
> > http://digikam3rdparty.free.fr/Images_2_Test_DImg/RAW/CANON-EOS
> >350D.CR2
> >
> > Gilles
>
> Aloha,
>
> seems to be the "-h" option of the two dcraw commands in
> libs/dimg/loaders/rawloader.cpp. Drop the option and you have ful
> sized images in IE.
>

What the problem with -h option ? The Raw decoding speed is decreased without
this option ? Please give me a feedback before to change...

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

[F.J.Cruz]

---- Gilles Caulier <[hidden email]> escribió:

> Le Mercredi 14 Décembre 2005 09:27, Thorsten Schnebeck a écrit :
> > > > Another problem I have with the RAW cr2 files, when I open
> > > > them with IE the size is only 1/4, i.e. width and height are
> > > > half the real size only.
> > >
> > > Hum, i suspect a problem with dcraw program and CR2 file. Can
> > > you trying with dcraw by command line to convert CR2 file to
> > > PNG for example ?
> > >
> > > Another test can be done using biblelabs (www.bibblelabs.com)
> > > program, witch using dcraw implementation inside to decode RAW
> > > files.
> > >
> > > Nota : i remember a decoding problem with a CR2 file coming
> > > from you. Do you remember the green _FROGS_ (:=))) :
> > >
> > > http://digikam3rdparty.free.fr/Images_2_Test_DImg/RAW/CANON-EOS
> > >350D.CR2
> > >
> > > Gilles
> >
> > Aloha,
> >
> > seems to be the "-h" option of the two dcraw commands in
> > libs/dimg/loaders/rawloader.cpp. Drop the option and you have ful
> > sized images in IE.
> >
>
> What the problem with -h option ? The Raw decoding speed is decreased without
> this option ? Please give me a feedback before to change...
>
> Gilles

Hi Gilles,

From dcraw output:

-h        Half-size color image (3x faster than -q)

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

[Gerhard Kulzer]

Am Mittwoch, 14. Dezember 2005 09.33 schrieb Gilles Caulier:

> Le Mercredi 14 Décembre 2005 09:27, Thorsten Schnebeck a écrit :
> > > > Another problem I have with the RAW cr2 files, when I open
> > > > them with IE the size is only 1/4, i.e. width and height are
> > > > half the real size only.
> > >
> > > Hum, i suspect a problem with dcraw program and CR2 file. Can
> > > you trying with dcraw by command line to convert CR2 file to
> > > PNG for example ?
> > >
> > > Another test can be done using biblelabs (www.bibblelabs.com)
> > > program, witch using dcraw implementation inside to decode RAW
> > > files.
> > >
> > > Nota : i remember a decoding problem with a CR2 file coming
> > > from you. Do you remember the green _FROGS_ (:=))) :
> > >
> > > http://digikam3rdparty.free.fr/Images_2_Test_DImg/RAW/CANON-EOS
> > >350D.CR2
> > >
> > > Gilles
> >
> > Aloha,
> >
> > seems to be the "-h" option of the two dcraw commands in
> > libs/dimg/loaders/rawloader.cpp. Drop the option and you have ful
> > sized images in IE.
>
> What the problem with -h option ? The Raw decoding speed is decreased
> without this option ? Please give me a feedback before to change...
>
> Gilles

Gilles, without the -h option it works as it should, I get the correct picture
size. Reading the dcraw help it is clear that -h divides the image by 4. So
there is no problem with dcraw, we have to leave out -h.

The downside is that it is very slow, for my cr2 of 3474x2312 pixels it takes
50sec to convert on a 3GHz i386 machine.

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

[Gilles Caulier]

Le Mercredi 14 Décembre 2005 13:30, vous avez écrit :

> Am Mittwoch, 14. Dezember 2005 09.33 schrieb Gilles Caulier:
> > Le Mercredi 14 Décembre 2005 09:27, Thorsten Schnebeck a écrit :
> > > > > Another problem I have with the RAW cr2 files, when I open
> > > > > them with IE the size is only 1/4, i.e. width and height are
> > > > > half the real size only.
> > > >
> > > > Hum, i suspect a problem with dcraw program and CR2 file. Can
> > > > you trying with dcraw by command line to convert CR2 file to
> > > > PNG for example ?
> > > >
> > > > Another test can be done using biblelabs (www.bibblelabs.com)
> > > > program, witch using dcraw implementation inside to decode RAW
> > > > files.
> > > >
> > > > Nota : i remember a decoding problem with a CR2 file coming
> > > > from you. Do you remember the green _FROGS_ (:=))) :
> > > >
> > > > http://digikam3rdparty.free.fr/Images_2_Test_DImg/RAW/CANON-EOS
> > > >350D.CR2
> > > >
> > > > Gilles
> > >
> > > Aloha,
> > >
> > > seems to be the "-h" option of the two dcraw commands in
> > > libs/dimg/loaders/rawloader.cpp. Drop the option and you have ful
> > > sized images in IE.
> >
> > What the problem with -h option ? The Raw decoding speed is decreased
> > without this option ? Please give me a feedback before to change...
> >
> > Gilles
>
> Gilles, without the -h option it works as it should, I get the correct
> picture size. Reading the dcraw help it is clear that -h divides the image
> by 4. So there is no problem with dcraw, we have to leave out -h.
>

I'm not agree with you. Why -h option working fine with other file formats,
and with any CR2 file that you have provide ? I suspect a problem in dcraw
with CR2 and -h option...

> The downside is that it is very slow, for my cr2 of 3474x2312 pixels it
> takes 50sec to convert on a 3GHz i386 machine.

This is a major problem ! We cannot frozen IE during 50 s to display one image
(:=)))...

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

> > > What the problem with -h option ? The Raw decoding speed is
> > > decreased without this option ? Please give me a feedback
> > > before to change...
> > >
> > > Gilles
> >
> > Gilles, without the -h option it works as it should, I get
> > the correct picture size. Reading the dcraw help it is clear
> > that -h divides the image by 4. So there is no problem with
> > dcraw, we have to leave out -h.
>
> I'm not agree with you. Why -h option working fine with other
> file formats, and with any CR2 file that you have provide ? I
> suspect a problem in dcraw with CR2 and -h option...
>
> Gilles

 
"-h" comandline option of dcraw correspondends to "half_size=1".
In dcraw there is this code:

    shrink = half_size && filters;
    iheight = (height + shrink) >> shrink;
    iwidth  = (width  + shrink) >> shrink;
    image = calloc (iheight*iwidth*sizeof *image + meta_length,
1);
    merror (image, "main()");
    meta_data = (char *) (image + iheight*iwidth);

So, based on "filters" it seems to be possible, that one format
shrinks and another does not shrink. I tested cr2 and x3f (BTW
the latter is not part of digiKams default supported raw format
extentions nor is any raw format part of the "Image Import..."
filter dialog):

x3f results to a full-sized image, cr2 to a half- (better
quad-)sized image when using "dcraw -h"

"filters" set or unset seems to be a result of
int CLASS identify (int will_decode)

I will forward this mail to the CRW-Decode ML and maybe
someone can help and explain, when -h shrinks, when it does not
shrink and what is this option all about. Can "-h" be used to
load and decode a RAW format in best quality?

Bye

  Thorsten

P.S.
cr2: Canon RAW
x3f: Foveon RAW

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

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

[dcoffin]

Hi Thorsten,

     "filters" being non-zero means two things.
First, that the image sensor is covered by a mosaic
of multi-colored filters, and second, that the camera
has not concealed this mosaic by interpolating it.

     "filters" is zero for all Foveon cameras, all
monochrome cameras, the Leaf Volare, and all Kodak
DCR images shot at less than full size.

     Any 2x2 block of a filter mosaic contains all
colors.  "-h" condenses that block into one pixel.
For images without filter mosaics, "-h" does nothing.

                                Dave Coffin  12/14/2005

On Wed, Dec 14, 2005 at 04:02:48PM +0100, Thorsten Schnebeck wrote:

> > > > What the problem with -h option ? The Raw decoding speed is
> > > > decreased without this option ? Please give me a feedback
> > > > before to change...
> > > >
> > > > Gilles
> > >
> > > Gilles, without the -h option it works as it should, I get
> > > the correct picture size. Reading the dcraw help it is clear
> > > that -h divides the image by 4. So there is no problem with
> > > dcraw, we have to leave out -h.
> >
> > I'm not agree with you. Why -h option working fine with other
> > file formats, and with any CR2 file that you have provide ? I
> > suspect a problem in dcraw with CR2 and -h option...
> >
> > Gilles
>  
> "-h" comandline option of dcraw correspondends to "half_size=1".
> In dcraw there is this code:
>
>     shrink = half_size && filters;
>     iheight = (height + shrink) >> shrink;
>     iwidth  = (width  + shrink) >> shrink;
>     image = calloc (iheight*iwidth*sizeof *image + meta_length,
> 1);
>     merror (image, "main()");
>     meta_data = (char *) (image + iheight*iwidth);
>
> So, based on "filters" it seems to be possible, that one format
> shrinks and another does not shrink. I tested cr2 and x3f (BTW
> the latter is not part of digiKams default supported raw format
> extentions nor is any raw format part of the "Image Import..."
> filter dialog):
>
> x3f results to a full-sized image, cr2 to a half- (better
> quad-)sized image when using "dcraw -h"
>
> "filters" set or unset seems to be a result of
> int CLASS identify (int will_decode)
>
> I will forward this mail to the CRW-Decode ML and maybe
> someone can help and explain, when -h shrinks, when it does not
> shrink and what is this option all about. Can "-h" be used to
> load and decode a RAW format in best quality?
>
> Bye
>
>   Thorsten
>
> P.S.
> cr2: Canon RAW
> x3f: Foveon RAW
>
> > _______________________________________________
> > Digikam-devel mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-devel
>
>
> _______________________________________________
> crw-decode mailing list
> [hidden email]
> https://mail.wonderland.org/mailman/listinfo/wonderland.org-crw-decode

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

Not sure if an unsubscribed person can mail to the ML, so I
forward the answer:

----------  Weitergeleitete Nachricht  ----------

Subject: Re: [CRW-DECODE] dcraw -h (was Re:
extragear/graphics/digikam/utilities/imageeditor/editor)
Date: Donnerstag 15 Dezember 2005 00:59
From: [hidden email]
To: Thorsten Schnebeck <[hidden email]>
Cc: digiKam developers <[hidden email]>,
[hidden email]

Hi Thorsten,

     "filters" being non-zero means two things.
First, that the image sensor is covered by a mosaic
of multi-colored filters, and second, that the camera
has not concealed this mosaic by interpolating it.

     "filters" is zero for all Foveon cameras, all
monochrome cameras, the Leaf Volare, and all Kodak
DCR images shot at less than full size.

     Any 2x2 block of a filter mosaic contains all
colors.  "-h" condenses that block into one pixel.
For images without filter mosaics, "-h" does nothing.

                                Dave Coffin  12/14/2005

On Wed, Dec 14, 2005 at 04:02:48PM +0100, Thorsten Schnebeck
wrote:

> > > > What the problem with -h option ? The Raw decoding speed
> > > > is decreased without this option ? Please give me a
> > > > feedback before to change...
> > > >
> > > > Gilles
> > >
> > > Gilles, without the -h option it works as it should, I get
> > > the correct picture size. Reading the dcraw help it is
> > > clear that -h divides the image by 4. So there is no
> > > problem with dcraw, we have to leave out -h.
> >
> > I'm not agree with you. Why -h option working fine with other
> > file formats, and with any CR2 file that you have provide ? I
> > suspect a problem in dcraw with CR2 and -h option...
> >
> > Gilles
>
> "-h" comandline option of dcraw correspondends to
> "half_size=1". In dcraw there is this code:
>
>     shrink = half_size && filters;
>     iheight = (height + shrink) >> shrink;
>     iwidth  = (width  + shrink) >> shrink;
>     image = calloc (iheight*iwidth*sizeof *image + meta_length,
> 1);
>     merror (image, "main()");
>     meta_data = (char *) (image + iheight*iwidth);
>
> So, based on "filters" it seems to be possible, that one format
> shrinks and another does not shrink. I tested cr2 and x3f (BTW
> the latter is not part of digiKams default supported raw format
> extentions nor is any raw format part of the "Image Import..."
> filter dialog):
>
> x3f results to a full-sized image, cr2 to a half- (better
> quad-)sized image when using "dcraw -h"
>
> "filters" set or unset seems to be a result of
> int CLASS identify (int will_decode)
>
> I will forward this mail to the CRW-Decode ML and maybe
> someone can help and explain, when -h shrinks, when it does not
> shrink and what is this option all about. Can "-h" be used to
> load and decode a RAW format in best quality?
>
> Bye
>
>   Thorsten
>
> P.S.
> cr2: Canon RAW
> x3f: Foveon RAW
>
> > _______________________________________________
> > Digikam-devel mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-devel
>
> _______________________________________________
> crw-decode mailing list
> [hidden email]
> https://mail.wonderland.org/mailman/listinfo/wonderland.org-crw
>-decode

-------------------------------------------------------

So this means -h is a simple but high speed demosaicing and not
suitable for bayer sensors.

Bye

  Thorsten

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

[Gerhard Kulzer]

Am Mittwoch, 14. Dezember 2005 16.02 schrieb Thorsten Schnebeck:

> > > > What the problem with -h option ? The Raw decoding speed is
> > > > decreased without this option ? Please give me a feedback
> > > > before to change...
> > > >
> > > > Gilles
> > >
> > > Gilles, without the -h option it works as it should, I get
> > > the correct picture size. Reading the dcraw help it is clear
> > > that -h divides the image by 4. So there is no problem with
> > > dcraw, we have to leave out -h.
> >
> > I'm not agree with you. Why -h option working fine with other
> > file formats, and with any CR2 file that you have provide ? I
> > suspect a problem in dcraw with CR2 and -h option...
> >
> > Gilles
>
> "-h" comandline option of dcraw correspondends to "half_size=1".
> In dcraw there is this code:
>
>     shrink = half_size && filters;
>     iheight = (height + shrink) >> shrink;
>     iwidth  = (width  + shrink) >> shrink;
>     image = calloc (iheight*iwidth*sizeof *image + meta_length,
> 1);
>     merror (image, "main()");
>     meta_data = (char *) (image + iheight*iwidth);
>
> So, based on "filters" it seems to be possible, that one format
> shrinks and another does not shrink. I tested cr2 and x3f (BTW
> the latter is not part of digiKams default supported raw format
> extentions nor is any raw format part of the "Image Import..."
> filter dialog):
>
> x3f results to a full-sized image, cr2 to a half- (better
> quad-)sized image when using "dcraw -h"
>
> "filters" set or unset seems to be a result of
> int CLASS identify (int will_decode)
>
> I will forward this mail to the CRW-Decode ML and maybe
> someone can help and explain, when -h shrinks, when it does not
> shrink and what is this option all about. Can "-h" be used to
> load and decode a RAW format in best quality?
>
> Bye
>
>   Thorsten
>
> P.S.
> cr2: Canon RAW
> x3f: Foveon RAW

ufraw decodes cr2 to the correct size. Looking into its dcraw_api.c if found
this:

     * If scale is odd we need to "unshrink" it using the info in
     * hh->fourColorFilters before scaling it. */
    if (hh->filters!=0 && scale%2==1) {
        /* I'm skiping the last row/column if it is not a full row/column */
    f->height = h = hh->height / scale;
    f->width = w = hh->width / scale;
    fujiWidth = hh->fuji_width / scale;
    f->image = g_new0(dcraw_image_type, h * w);
    f4 = hh->fourColorFilters;
    for(r=0; r<h; r++) {
        for(c=0; c<w; c++) {
        for (cl=0; cl<hh->raw.colors; cl++) sum[cl] = count[cl] = 0;
        for (ri=0; ri<scale; ri++)
            for (ci=0; ci<scale; ci++) {
            sum[FC(f4, r*scale+ri, c*scale+ci)] +=
                hh->raw.image
                [(r*scale+ri)/2*hh->raw.width+(c*scale+ci)/2]
                [FC(f4, r*scale+ri, c*scale+ci)];
            count[FC(f4, r*scale+ri, c*scale+ci)]++;
            }
        for (cl=0; cl<hh->raw.colors; cl++)
            f->image[r*w+c][cl] =
                MAX(sum[cl]/count[cl] - hh->black,0);
        if (recombine) f->image[r*w+c][1] =
            (f->image[r*w+c][1] + f->image[r*w+c][3])>>1;
        }
    }
    } else {
    if (hh->filters!=0) scale /= 2;
        /* I'm skiping the last row/column if it is not a full row/column */
    f->height = h = hh->raw.height / scale;
    f->width = w = hh->raw.width / scale;
    fujiWidth = ( (hh->fuji_width+hh->shrink) >> hh->shrink ) / scale;
    f->image = g_new0(dcraw_image_type, h * w);
    norm = scale * scale;
    for(r=0; r<h; r++) {
        for(c=0; c<w; c++) {
        for (cl=0; cl<hh->raw.colors; cl++) {
            for (ri=0, s=0; ri<scale; ri++)
            for (ci=0; ci<scale; ci++)
                s += hh->raw.image
                [(r*scale+ri)*hh->raw.width+c*scale+ci][cl];
                    f->image[r*w+c][cl] = MAX(s/norm - hh->black,0);
        }
        if (recombine) f->image[r*w+c][1] =
            (f->image[r*w+c][1] + f->image[r*w+c][3])>>1;
        }
    }
    }

Looks like that what is needed after dcraw call.

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

[Gilles Caulier]

Le Vendredi 16 Décembre 2005 05:46, Gerhard Kulzer a écrit :

> Am Mittwoch, 14. Dezember 2005 16.02 schrieb Thorsten Schnebeck:
> > > > > What the problem with -h option ? The Raw decoding speed is
> > > > > decreased without this option ? Please give me a feedback
> > > > > before to change...
> > > > >
> > > > > Gilles
> > > >
> > > > Gilles, without the -h option it works as it should, I get
> > > > the correct picture size. Reading the dcraw help it is clear
> > > > that -h divides the image by 4. So there is no problem with
> > > > dcraw, we have to leave out -h.
> > >
> > > I'm not agree with you. Why -h option working fine with other
> > > file formats, and with any CR2 file that you have provide ? I
> > > suspect a problem in dcraw with CR2 and -h option...
> > >
> > > Gilles
> >
> > "-h" comandline option of dcraw correspondends to "half_size=1".
> > In dcraw there is this code:
> >
> >     shrink = half_size && filters;
> >     iheight = (height + shrink) >> shrink;
> >     iwidth  = (width  + shrink) >> shrink;
> >     image = calloc (iheight*iwidth*sizeof *image + meta_length,
> > 1);
> >     merror (image, "main()");
> >     meta_data = (char *) (image + iheight*iwidth);
> >
> > So, based on "filters" it seems to be possible, that one format
> > shrinks and another does not shrink. I tested cr2 and x3f (BTW
> > the latter is not part of digiKams default supported raw format
> > extentions nor is any raw format part of the "Image Import..."
> > filter dialog):
> >
> > x3f results to a full-sized image, cr2 to a half- (better
> > quad-)sized image when using "dcraw -h"
> >
> > "filters" set or unset seems to be a result of
> > int CLASS identify (int will_decode)
> >
> > I will forward this mail to the CRW-Decode ML and maybe
> > someone can help and explain, when -h shrinks, when it does not
> > shrink and what is this option all about. Can "-h" be used to
> > load and decode a RAW format in best quality?
> >
> > Bye
> >
> >   Thorsten
> >
> > P.S.
> > cr2: Canon RAW
> > x3f: Foveon RAW
>
> ufraw decodes cr2 to the correct size. Looking into its dcraw_api.c if
> found this:
>
>      * If scale is odd we need to "unshrink" it using the info in
>      * hh->fourColorFilters before scaling it. */
>     if (hh->filters!=0 && scale%2==1) {
>         /* I'm skiping the last row/column if it is not a full row/column
> */ f->height = h = hh->height / scale;
>     f->width = w = hh->width / scale;
>     fujiWidth = hh->fuji_width / scale;
>     f->image = g_new0(dcraw_image_type, h * w);
>     f4 = hh->fourColorFilters;
>     for(r=0; r<h; r++) {
>         for(c=0; c<w; c++) {
>         for (cl=0; cl<hh->raw.colors; cl++) sum[cl] = count[cl] = 0;
>         for (ri=0; ri<scale; ri++)
>             for (ci=0; ci<scale; ci++) {
>             sum[FC(f4, r*scale+ri, c*scale+ci)] +=
>                 hh->raw.image
>                 [(r*scale+ri)/2*hh->raw.width+(c*scale+ci)/2]
>                 [FC(f4, r*scale+ri, c*scale+ci)];
>             count[FC(f4, r*scale+ri, c*scale+ci)]++;
>             }
>         for (cl=0; cl<hh->raw.colors; cl++)
>             f->image[r*w+c][cl] =
>                 MAX(sum[cl]/count[cl] - hh->black,0);
>         if (recombine) f->image[r*w+c][1] =
>             (f->image[r*w+c][1] + f->image[r*w+c][3])>>1;
>         }
>     }
>     } else {
>     if (hh->filters!=0) scale /= 2;
>         /* I'm skiping the last row/column if it is not a full row/column
> */ f->height = h = hh->raw.height / scale;
>     f->width = w = hh->raw.width / scale;
>     fujiWidth = ( (hh->fuji_width+hh->shrink) >> hh->shrink ) / scale;
>     f->image = g_new0(dcraw_image_type, h * w);
>     norm = scale * scale;
>     for(r=0; r<h; r++) {
>         for(c=0; c<w; c++) {
>         for (cl=0; cl<hh->raw.colors; cl++) {
>             for (ri=0, s=0; ri<scale; ri++)
>             for (ci=0; ci<scale; ci++)
>                 s += hh->raw.image
>                 [(r*scale+ri)*hh->raw.width+c*scale+ci][cl];
>                     f->image[r*w+c][cl] = MAX(s/norm - hh->black,0);
>         }
>         if (recombine) f->image[r*w+c][1] =
>             (f->image[r*w+c][1] + f->image[r*w+c][3])>>1;
>         }
>     }
>     }
>
> Looks like that what is needed after dcraw call.
>

Hum, this is want mean that ufraw lib has included dcraw source code and do
not use an external dcraw instance to decode RAW files. This is not the case
in digiKam whitch use actually a dcraw program.

This is want mean too, like i have already said before than there is a
decoding problem with any CR2 file, like your GREN FROGS pictures (:=)))

Nota : i have tried to display GREEN FROGS pictures using bibblepro program :
the result are the same than digiKam. This is want mean than

1 / bibblepro use dcraw source code in and CR2 decoding is wrong.
2 / or GREEN FROG file is corrupted.

... but this is strange to find the same result with digiKam and bibblepro,
especially if bibblepro use an dedicaced implementation non-depending of
dcraw. Like it's descripbe in this article :

http://users.tkk.fi/~stanhua/rawcomp/

... bibblepro is dcraw decoding implementation seem to be different.

Gilles


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