[digiKam-users] How to rebuild RAW thumbnails?

[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/20181003/b65b2f6e/attachment.html>