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