[digiKam-users] How to rebuild RAW thumbnails?

Cirrus cirrus at gatohaus.com
Sun Oct 7 14:56:37 BST 2018


Thanks for looking into this.  It's very kind of you.

Time for me to learn how to install from .tar     ;-)

On Wed, Oct 3, 2018 at 1:56 PM, Maik Qualmann <metzpinguin at gmail.com> wrote:

> The change is small, we still have time to test it until the final
> release.
> For normal NEF files, there is no performance degradation. Even color
> images
> in dark or with a closed lens lid are not identified as a grayscale image.
> Of
> course, loading a grayscale image takes a few seconds. Sepia-effect images
> are
> probably not recognized as a grayscale image.
>
> https://cgit.kde.org/digikam.git/commit/?
> id=e0d01f6283bde9cd9d78a11239d82234fc96a136
>
> Maik
>
> Am Mittwoch, 3. Oktober 2018, 18:28:35 CEST schrieb Cirrus:
> > Wow. That would be great.  :-)
> >
> > Imho, the thumbnail should reflect what the raw contains rather than what
> > the camera spit out as a secondary product.
> > (I'm not sure why Ricoh went with the opposite.)
> >
> > On Wed, Oct 3, 2018, 11:34 Maik Qualmann <metzpinguin at gmail.com> wrote:
> > > We can also automate the behavior by changing 2 lines of code. If the
> > > extracted preview image of a RAW file is a grayscale image, we will
> read
> > > the
> > > RAW image. Now would then RAW files always colored. Would this
> behavior be
> > > okay?
> > >
> > > Maik
> > >
> > > Am Mittwoch, 3. Oktober 2018, 12:09:43 CEST schrieb Cirrus:
> > > > As others have said, the value of seeing the b&w jpeg immediately
> after
> > > > taking a shot is nearly critical.  Plus the particular rendering this
> > > > camera produces is something I very much like.
> > > >
> > > > The point about the impact on speed in DK if the embedded raw
> thumbnail
> > >
> > > is
> > >
> > > > regenerated is a serious concern.  Although doing so should be
> optional
> > >
> > > and
> > >
> > > > a user would likely understand they are invoking a penalty.
> > > >
> > > > That said, darktable does this (as an option for a thumbnail outside
> of
> > >
> > > the
> > >
> > > > raw) and the penalty, to me, is quite minor. I'd very much like to
> have
> > >
> > > the
> > >
> > > > choice in DK.
> > > >
> > > > Given all the information everyone has kindly provided here (Thank
> > > > you!),
> > > > it doesn't seem like there's a easy solution.  I'll probably continue
> > >
> > > doing
> > >
> > > > organization and tagging in DK but move culling and rating over to
> > > > darktable.  So it goes.
> > > >
> > > > On Sat, Sep 29, 2018, 04:59 Gilles Caulier <caulier.gilles at gmail.com
> >
> > >
> > > wrote:
> > > > > Hi,
> > > > >
> > > > > Changing the color space in camera while shooting will affect
> preview
> > > > > included in RAW.
> > > > >
> > > > > RAW preview are mostly a small JPEG image embedded in RAW
> container.
> > > > > DK
> > > > > extract this JPEG as well to render icon view thumbnails. It's very
> > >
> > > very
> > >
> > > > > fast as no post processing is required.
> > > > >
> > > > > Using RAW image data will be really slower to render large albums,
> and
> > > > > will decrease DK performances. Even if libraw decoder can use fast
> RAW
> > > > > extraction method without to much post processing, the democaising
> of
> > > > > bayer
> > > > > matrix will be a bottleneck.
> > > > >
> > > > > Using sidecar can be a solution. Here i don't talk about XMP
> sidecar
> > >
> > > file,
> > >
> > > > > but the .thm file coming with RAW file (Canon generate this kind of
> > >
> > > file,
> > >
> > > > > as i know)...
> > > > >
> > > > > But this will introduce another dysfunction, as THM file include
> also
> > > > > metadata which do not correspond well with RAW metadata
> (incomplete).
> > > > > THM cannot be used as metadata source, and this will increase the
> > > > > complexity of metadata workflow.
> > > > >
> > > > > Gilles Caulier
> > > > >
> > > > > 2018-09-29 9:12 GMT+02:00 Andrew Goodbody <ajg02 at elfringham.co.uk
> >:
> > > > >> On 29/09/18 07:55, Maik Qualmann wrote:
> > > > >>> I did not understand the problem at first, but I can reproduce it
> > >
> > > with
> > >
> > > > >>> my
> > > > >>> Nikon. First of all, it is not a good idea to take a image in B&W
> > > > >>> digitally.
> > > > >>> There are many more ways to do it later, but for the JPEG the
> color
> > > > >>> information is lost. There is currently no option in digiKam to
> > >
> > > specify
> > >
> > > > >>> that a
> > > > >>> thumbnail should be created from the RAW image. It uses the
> > > > >>> "fastest"
> > > > >>> source
> > > > >>> and that is the preview image. That was of course stored by the
> > >
> > > camera
> > >
> > > > >>> in B&W.
> > > > >>>
> > > > >>> Maik
> > > > >>
> > > > >> Sounds like this could be a wishlist item for a 'sidecar-jpeg'
> which
> > > > >> could be used for raw files to contain a preview image developed
> > > > >> using
> > > > >> the
> > > > >> current edit settings for the raw file.
> > > > >>
> > > > >> Andrew
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20181007/a17fe15a/attachment.html>


More information about the Digikam-users mailing list