CONTENTS DELETED
The author has deleted this message.
|
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 Am Freitag, 28. September 2018, 02:54:51 CEST schrieb gatohaus: > I'm just starting to use digikam and am trying to get the RAW thumbnails in > the thumbnail view to show the color version of the image. > > I usually shoot with a GR2 and have it save as RAW + jpeg, with the jpeg > being b&w. In Digikam's thumbnail view the raw and jpeg are correctly > grouped together, but both appear as b&w. I've searched for a setting that > would force the regeneration of the raw thumbnail but have had no luck. > > For previews, I found the "Previews shows the full image" setting, but > nothing similar for thumbnails. > There's also the Maintenance tool with the Rebuild Thumbnails option. It > seems to still use the thumbnail contained within the raw, rather than > actually building a new one. > > Just to note that this idea is possible, Darktable has such settings to > render raw thumbnails. (I'd like to stick with Digikam though) > Oh, this is on Kubuntu 18.04. > > Thanks, > David > > <http://digikam.1695700.n4.nabble.com/file/t376734/digikam_rawthumbs.png> > > > > -- > Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html |
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 |
Hi,
Going back to Windows 10 from Manjaro Linux, where Beta 6 works OK BTW. digiKam starts, the wizard appears and settings are adjusted, welcome splash screen closes and nothing happens. There is no digiKam entry on the Task manager, digiKam simply closes. Restarting digiKam goes directly to the splash screen and closes again. Where can I find the logs? Iñigo. |
Hi, ...which crash violently at startup under Windows. With the weekly bundle published here : The problem is fixed to revert to last stable lensfun 0.3.2 Next DK 6.0.0-beta2, planed soon will be delayed a little bit to include new Exiv2 0.27RC planed next week end. Gilles Caulier 2018-09-29 9:23 GMT+02:00 Iñigo <[hidden email]>: Hi, |
In reply to this post by Andrew Goodbody
Hi, 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 <[hidden email]>: On 29/09/18 07:55, Maik Qualmann wrote: |
In reply to this post by Maik Qualmann
On 9/29/18 8:55 AM, 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. Hi I don't agree with that. When you want to make B&W image, you have to see world in B&W, then you can shot in B&W. B&W world is not a simple conversion, it's completely different from color world, because of the rendering/conversion of colors, the light, contrast, etc...It would be very long to explain here. Its' my professional experience for (too) many years... :) Regards |
On 29.09.18 15:28, [hidden email] wrote: > On 9/29/18 8:55 AM, 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. > Hi > I don't agree with that. When you want to make B&W image, you have to > see world in B&W, then you can shot in B&W. B&W world is not a simple > conversion, it's completely different from color world, because of the > rendering/conversion of colors, the light, contrast, etc...It would be > very long to explain here. Its' my professional experience for (too) > many years... :) > Regards > I agree. When I want to shoot b&w I switch the camera to b&w to have a better preview of the desired image. When you shoot in b&w you apply very different rules to shadows and lights. I am happy to have the thumbnails in digikam in b&w then, too, it helps me with the selection without the need to convert color pictures "in my mind". However, I only use the jpg's for selection purposes and then "develop" the final image from raw, deciding how I convert them to b&w. Of course I switch the camera to normal color mode when shooting in color. Another advantage of this is that later, much later, when I forgot about the original session and setting, I still know at a glace, whether I wanted it in color or b&w. -- Daniel Bauer photographer Basel Málaga https://www.patreon.com/danielbauer http://www.daniel-bauer.com |
In reply to this post by Gilles Caulier-4
On Sat, 29 Sep 2018 10:49:02 +0200
Gilles Caulier <[hidden email]> wrote: > > Next DK 6.0.0-beta2, planed soon will be delayed a little bit to > include new Exiv2 0.27RC planed next week end. > > Gilles Caulier > Very good news. Merci -- sknahT vyS |
In reply to this post by Gilles Caulier-4
CONTENTS DELETED
The author has deleted this message.
|
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 <[hidden email]> 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 <[hidden email]>: > >> 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 |
CONTENTS DELETED
The author has deleted this message.
|
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 <[hidden email]> 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 <[hidden email]> > > > > 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 <[hidden email]>: > > > >> 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 |
Free forum by Nabble | Edit this page |