Bug 128669

If you can see a difference, well take JPEG pictures, not RAW.

Your comment is a non sence for me. Please look in the web what is a RAW file exactly (:=)))

Regards

Gilles

I can see no difference between a jpeg generated (raw+jpeg) and the thumbnail (also jpg) which is integrated in the raw file. The quality of the preview generated by digikam (dcraw -2 -w -a -q 0) isn't very good in the comparison to the embedded jpeg, so why waste time?
If I want to process high quality pictures or change some settings (e.g. white balance) I take the raw and process it with ufraw&gimp.

gimp support only 8 bits color depth image, digiKam support 16 bits color depth image. This is the difference.

Gilles Caulier

Digikam doesn't use 16 bit at this point.
But I think the discussion is going in the wrong direction. Should we start an email exchange? If you want I could provide you some test images to substantiate my suggestion.

When you open a RAW file in editor, the image is decoded in 16 bits / color /pixel depth ! The image is stored like this in memory.

Image editor is not a simple image viewer, it's an editor. When you will apply color filter or transformation and saved it into PNG or TIFF file, the target image is encoded with 16 bits color depth, like UFRAW do !

You talking about a simple image viewer on the screen. This feature is Slideshow kipi plugin, not image editor. And yes, this part must support embeded JPEG into RAW to display image on the screen.

Gilles

The 16bit is only for the svn-version true. At the moment i'm stuck with 8bit.

What would be the right application (ImageEditor/ShowFoto/X-Plugin) to see through several hundred raw files and tagging/rating them? I can't do that with the Slideshow-Plugin. Maybe digikam can use a "quick-view" button for imageeditor which make use of the -e option.

thanks for your patience,

Marcus.

In First, 8 bits only support with RAW can be added into 0.9.0. Actually only 16 bits mode is enable. The code is ready to use 8 bits, only one new option must be add into IOFiles setup dialog page.

About to render RAW files on screen outside editor, if i understand your viewpoint, you would separate viewing and editing features. Right ? but Slideshow is a simple tool to view image... Why not improving this tool to render RAW files using embedded jpeg preview ?

Gilles

About the 8bit/16bit you got me wrong I welcome the possibility to use 16bit, but you do no recommend using 0.9.0-svn for production use => i have to go with 8bit at the moment.

I would separate editing (noise reduction, sharpening ...) and rating/previewing images. My current 'workflow' is the following (i shoot raw only):
1. getting the images from cf
(2. backup)
3. sorting out bad images (sharpness, light, different versions of the same images...).  I use the embedded thumbnails (dcraw -e) for the decision.
4. importing it into digikam
5. rating/tagging the image
6. editing images worth editing (e.g. more than 3 stars)
(7. backup again)

I would welcome doing steps 1-3 within digikam and furthermore to combine steps 3 and 5 to one step. I have several other wishes for rating the images (magnifier, light table for comparison of two or three images...) but at this point I'm satisfied with a quick possibility to sort out images or tagging them :-)

SVN commit 549928 by cgilles:

digikam from trunk : option to toogle RAW decoding picture in 8 bits like digiKam >= 0.8.1 does. This mode is more speed than 16-bits decoding and color correction is automatized by dcraw. 

Use this mode if you don't use ICC color management and if 8 bits color depth is enough for you.

CCMAIL: digikam-devel@kde.org
CCBUGS: 128669, 127991   

 M  +20 -19    libs/dimg/loaders/rawloader.cpp  
 M  +5 -1      utilities/imageeditor/editor/editorwindow.cpp  
 M  +27 -15    utilities/setup/setupiofiles.cpp  

SVN commit 552644 by cgilles:

digikam from trunk : new fast image preview mode embedded on main interface.

- Separate Preview and Edit of picture. Preview is embedded into main interface, Edit is dedicaced to image editor.
- digiKam album content area can be now toogled between the current image collection thumbs or the current preview of image selected in collection
- To toogle between these views press F3. You can also press ESC to go out of preview mode.
- You can change current image preview using wheel mouse or these keyboard shorcuts : page up, page down, home, end.
- The preview image background use the current color of the selected digiKam theme.
- Preview of RAW files are computed by dcraw using -e option. It's very fast.

There is a screenshot at this url :

http://digikam3rdparty.free.fr/Screenshots/image_preview_on_main_interface.png


TODO : 

- Extract JPEG, PNG, and TIFF preview from Exif Makernote using Exiv2. Need to adapt Exiv2 library for that.
- Loading preview image outside the main interface thread using a new digiKam KIO-Slave.
- Moving keyboard shortcuts of preview widget into main digiKam interface instance to share it with image properties sidebar tabs
- Add RMB menu in this mode or just a link to Edit current image in editor. Need users feedback for that.


CCMAIL: digikam-devel@kde.org
BUG: 127991, 128669, 128914



 M  +2 -2      Makefile.am  
 M  +1 -1      albumiconview.cpp  
 A             albumwidgetstack.cpp   [License: GPL]
 A             albumwidgetstack.h   [License: GPL]
 M  +19 -9     digikamapp.cpp  
 M  +1 -0      digikamapp.h  
 M  +3 -1      digikamui.rc  
 M  +315 -216  digikamview.cpp  
 M  +28 -53    digikamview.h  
 A             imagepreviewwidget.cpp   [POSSIBLY UNSAFE: popen] [License: GPL]
 A             imagepreviewwidget.h   [License: GPL]

Is using the fast extraction the reason why the editor shows different colours for RAW pictures compared to the big preview in digikam? You can see the difference in the attached screenshot.

Created attachment 29718 [details]
screenshot

the same picture shown in the editor and digikam with different colours