Version: 0.8.0 (using KDE 3.4.2 Level "b" , SUSE 10.0) Compiler: Target: i586-suse-linux OS: Linux (i686) release 2.6.13-15.8-default My camera can be configured to store both jpeg and raw (nef) at the same time. Like this rln_0220.jpg rln_0220.nef So for every picture I have both an JPEG and a raw. (The raw does not show properly but that is another issue) Anyway my wish is to be able to configure digikam to view only the jpeg, but let some operations work on both. (NEF should be viewed as a negative and jpg as the processed image.)
---- Roger Larsson <roger.larsson@norran.net> escribió: [bugs.kde.org quoted mail] I don't know wich model your camera is , but thinking it works in the same way that Nikon D50 does, I think that you said, maybe make no sense. These are my reasons: - The jpeg file is a low resolution/low quality pictrue. On the other hand, this file has suffered some adjusts that the camera makes on all the images that have been captured in other formats that are not RAW one. Moreover this file is a 8-bits image. - The RAW file is the image as is capured by the camera sensor, this is, without any type of transform or adjust. This file is a 16-bits picture (well, really, it has 12-bits per pixel). - In short, we have two differents files: one of them is a low quality and transformed image (jpeg) and the other one is a high quality and without any adjust picture (nef), this is, the file contents the raw data of the subject as is caputred by the camera sensor, so, the changes you make to one of them don't produce the same results on the other. PS: excuse my poor english. Paco Cruz.
I was not specific enough. You never modify the image data contents of the NEF! But tags and possibly even EXIF information. I do not like to have to select twice as many files before each tag assign. Nor do I like to have to enter the same note twice. The same for rename, move, delete, and possibly even copy. Maybe a toggle in the toolbar to select if RAW+JPEG should be viewed as "one". Any image modifications of the JPEG can be viewed as a fresh processing from the raw (NEF). (Convert to black and white can probably some time in the future use the raw as source.)
I think the user is asking for something like Photoshop Element's "image stacks", in which you can put several similar images together (like different shoots of a same object, or different attemps at retouching it, or indeed, a raw image and its jpeg version). See here for a more thorough description : http://oceania.digitalmedianet.com/articles/viewarticle.jsp?id=29049 (I'd find such a feature very useful too)
This feature could be really useful in this way: If you want to edit it, the raw is always opened and settings changed so it looks the same as the jpeg. With "looks the same" I mean in applied color curve, gamma etc. Not pixel-wise, as the interpolation done by the pc is better, but all other settings like white balance, curve, profile etc. should be read out of the raw file, if possible, so we can produce images that look like on the preview of the tft on your camera. Then, if you want to edit it again, it opens the raw file with the settings you (or the camera) used for the jpeg.. If this would work, it would be really great. Unfortunately, at least nikon's *.nef format isn't fully known yet, and how to read all options from it correctly. There is at least no opensource program doing it that the raw converted picture looks like raw converted with nikon's software, or the jpeg the camera would produce... If we(or rather the people coding, as I'm too stupid) would come to that point, it would be very useful to stack pictures, and save each jpegs/pngs/etc. settings and then reopen the raw with that settings to further edit it, without loosing quality.
Re: Nikon EXIF format: EXIF.py from http://home.cfl.rr.com/genecash/digital_camera.html Works quite well. I do have an patch that adds - EXIF 2.2 tags - no crash on NEF files (uninitialized variable) - AFFocusPosition (D200 11 points + 7 points) I have also recognized a tag that I think is a the look up table (LUT, curve) Problem is that the author of EXIF.py does not read mail now due to spam...
Some additional comments. One problem is probably the fact that NEFs from Nikon are identified as TIFF files, i.e. images in their own right... Found another even better EXIF reader (made in Perl) http://www.sno.phy.queensu.ca/~phil/exiftool/ This tool reports the MIME type as MIME Type : image/x-raw Modifying the association helps gwenview a lot. And could also help digikam.
In digiKam implementation from svn trunk branch, i have fixed this RAW mime type problem. All work fine now. About metadata, We using Exiv2 library now, not libexif. Using current Exiv2 implementation (not the last 0.9.1 release), a new TIFF/EP file parser can handle EXIF/MARKERNOTE/IPTC from TIFF, DNG, CRW, CR2, NEF, PAF, etc. RAW file formats based on TIFF/EP. The parser need to be improved, but the results are impressive. http://www.digikam.org/?q=node/81 Gilles Caulier
*** Bug 147886 has been marked as a duplicate of this bug. ***
*** Bug 147933 has been marked as a duplicate of this bug. ***
Would it be possible to at least have the option to enable this kind of logic: If there are two files called something.jpg and something.raw (where something is a name and raw is a raw extension), do one of: - Show only raw - Show only JPEG - Show both depending on an option selection. I don't even really care if the JPEGs don't get displayed or tagged or whatnot. I mostly save them because they take up very little space and are good for previews on computers that don't have a fast RAW viewer (like digikam) installed. I never use the JPEGs for actual prints (I always convert the RAW into JPEG for that purpose). But this options would really, really help me (and probably a lot of others who have the same problem).
*** Bug 188968 has been marked as a duplicate of this bug. ***
*** Bug 151228 has been marked as a duplicate of this bug. ***
It would be also nice if the user could specify, where the raw files are. E.g. I use a separate directory ./raw to avoid mixing raw and jpeg previews (I tag only jpegs) to avoid redundancy in image viewers.
On my camera, the file are named IMG1234.DNG and IMG1235.jpg while they are both same picture. Lightroom manage to see this is the same file, but I don't know how. A kind of "stacked" feature would be great, when you file with different format are logicaly linked together.
Stibbons, probably there is an exposure number (and a kamera serial number) in the EXIF information. My Nikon has (in makernotes) Serial Number 40xxx93 Shutter Count 29287 (Yes, it is correct!) With these two you can identify each exposure and it is probably the best way to link images together. Thanks for reminding me.
Is this bug just a specific case of bug #121310 "Allow to have a group of pictures"? Should it be marked as a duplicate?
@16, IMO no. This is different type of grouping. Technically this can be done in similar ways(?) but from user point of view this is different problem.
In other hand: guys, I must say that I can't see a reason to shot the same scene both RAW and JPEGs together. I know that DSLR cameras have some configuration option, but tell me why you do this. I can't figure out why. I've never used this option, I use RAW or JPEG, but both?
I'm totally agree with Michael. For me too shot in both format at the same time is an heretic stuff. Personally, i always shot in RAW;, never in JPEG. why to surcharde my CF card with duplicate data ? why to bloat my hard-drive with duplicate images ? It's really a waste of time. Also JPEG is not dedicated for post processing. It's lesser quality limited to 8 bits color depth. Do you know ? To shoot in RAW, you will never lost data. You want JPEG : no problem to convert in batch quickly for web publishing or printing. With digiKam RAW handling is simple. Are you tried Raw import tool ? With 1.0.0, there is a new batch queue manager to process more than one action at the same time : Raw convert, resize, add border, sharpen, export to JPEG, etc... Just fill the queue with items, set batch tools/renaming/target, run it and take a coffee... Gilles Caulier
My Nikon D300 have VERY good raw to jpeg processing. And there is no point in adding any manual work most of the time. But in some situations that I know can be troublesome I shot in jpeg+raw. This allows me to correct any misstake the camera did. Nikons processing is soo good that I want a copy of it even when I know I will postprocess from RAW. (If I used Windows this would be less of a problem since I could use Nikon software to postprocess - using all stored camera settings) But if your camera does a poor job in converting to jpeg I can understand your view and use of RAW all the time. But the batch tool sounds nice!
Roger, look there : http://farm3.static.flickr.com/2510/3921847029_002e2a2e1d_o.png Gilles Caulier
Whether you convert to jpeg in camera or manually in your computer, at some point you wish to store both raw and jpeg (or tiff, or png, or whatever other format). And having two versions as separate images only makes unnecessary mess. This is why the images with the same base name (e.g. image001.raw, image001.jpg) should be shown as one with an optional possibility to expand this group (which can be easily remembered in the database). Take a look how geeqie handles this issue.
Note that this option should be able to handle not only JPEG+RAW files from camera but also: - JPEG/RAW + Audio notes (usually the same name but different ext.) - RAW + JPEGs (or other formats) produced in digiKam - XMP sidecars
(In reply to comment #20) > (If I used Windows this would be less of a problem since > I could use Nikon software to postprocess - using all stored camera settings) The same with Canon. In linux we are struggling with camera profiles and/or colour matrices of dcraw to finally imitate what the proprietary vendor's technology does in the camera or their software. (In reply to comment #22) > at some point you wish to store both raw and jpeg (or tiff, or png, ... It is also about comfort: majority of my images (family, travelling) are for web (i.e. JPEG is sufficient) and DSLRs do a good job automatically. If not, I still have the RAW file to try myself. If I decide to have a big print out, I use RAW. Last, but not least: I cannot tag Canon CR2 files (not supported yet) and do not want to convert to DNG (from reasons discussed elsewhere in the photography forums). My RAW files are about 25 MB, camera JPEG previews about 3 MB - not a big deal to have them for "free". From the reasons described above, storing of 8 or even 16 bit PNGs (20 or 90 MB) for all photos is an overkill. (And believe me, even for digital photography I still apply the old dark-room rule: "the best friend of a photographer is the garbage bin.")
Please take account comments 14 and 15: jpeg file may not have the same name (IMG1234.DNG and IMG1235.jpg). Use the Shutter Count IPTC value to find the matching file. I do use both of them, I shoot jpeg+dng most of the time and then just drop the dng if I only want the jpeg.
I have been using Lightroom for a long while, but really want to use DigiKam all the way. A few things are holding me back, and this is one of them. Having a stacking feature is invaluable when you want to really organise a lot of pictures. The mantra should be "Workflow, workflow, workflow!"
I also vote for this. It's not only RAW and JPEG. I also want to save the XCF (from GIMP) to be able to make changes later on. And maybe several versions of editing. And several sizes (on for the web, one for printing etc.). So with edited images I usually end up between 5 and 10 files. Having them grouped in digiKam would ease the tag assignment (all could get the same tags and rating optionally) and the browsing/ searching. And of course also deletion, renaming, copying etc. Almost all big management tools have this stacking feature - starting in F-Spot and going to Lightroom. So why are digiKam developers trying to say it is not necessary? Or am I just getting it wrong? Sorry for the criticism. I like digiKam a lot but this is something I can't understand.
We will have this feature, I plan to work on this for the next feature release, if time permits of course.
*** Bug 224789 has been marked as a duplicate of this bug. ***
*** Bug 246920 has been marked as a duplicate of this bug. ***
Hi. Is this issue still in the pipeline? The last statement was posted in December... I am still longing to work with the stacking feature... Thanks and keep up the good work!
*** Bug 249303 has been marked as a duplicate of this bug. ***
Hi, In the past I think shoot in Raw + Jpg has no sense. But Now in some cases I shoot in Raw + Jpg, i give you some exemples : - When you do à Wedding in some cases people want the pictures before you leave. - when you shoot at the studio some peole wants directely some pictures. - When you do a trip, and when you take pictures of some people and you want to give us a souvenir. in this case you need to shoot in Raw + Jpeg Raw for dont leave information for post processing and Jpeg as a Polaroid After at home on my hard drive I always have many versions of my photos. - Raw version for don't lose informations ... - Jpeg version for many Reasons ( - When I give my hard drive to my family they could directly use the pictures - To send to online development - Raw file is closed format with Jpeg I'm sure y could read my picture in 50 years - ... ) - Tiff 16Bit when I Work with graphic designer for printing Because it's really boring to see 3 close versions of the same image Because it's really boring to tag 3 versions of the same picture Because this option exist in all tools y use NX view, Capture NX, ... I hope this option will come into Digiam to group my pictures who have the same name but à different extension.
(In reply to comment #0) > Version: 0.8.0 (using KDE 3.4.2 Level "b" , SUSE 10.0) > Compiler: Target: i586-suse-linux > OS: Linux (i686) release 2.6.13-15.8-default > > My camera can be configured to store both > jpeg and raw (nef) at the same time. Like this > rln_0220.jpg > rln_0220.nef > > So for every picture I have both an JPEG and a raw. (The raw does not show properly but that is another issue) > > Anyway my wish is to be able to configure digikam to view only the jpeg, but > let some operations work on both. > (NEF should be viewed as a negative and jpg as the processed image.) If this issue is still available and valid: I support the wish to handle two versions of one pic simultaneously strongly!! This refers to several pairs of pic-formats: Canon: jpg + cr2 Canon: jpg + crw NIKON: jpg + nef Maybe an number of other file formats!? In my case, I have Canon _and_ NIKON- formats and therefore file-pairs (see above). I suggest to include the handling of _any_ metadata, flags, exif-data (as far as technically possible), geo-data and _any_ implicite data in pictures. Suggestion: There could be implemented some type of simple editor were a user could define the bi-directional relations. From that tim on, any possible action refers to both definied file-types. Why? Even on amateur-level, time is limited. The more time-efficient we can work on pics, the better we can concentrate on creative art-work. Even software is a tool. I hope ypu find this idea useful!!! Axel
Created attachment 60285 [details] groupingSnapshot.png in digikam 2.0 it's possible to group images manually Also .nef (nikon) files include the jpeg so it's really pointless to save both in camera. # Nikon D90 extract jpegs and assign the tags mkdir jpeg && for i in *.[nN][eE][fF] ; do exiftool -b -JpgFromRaw "${i}" > "jpeg/${i/./_}.jpg" # assegna ai jpeg gli exif exiftool -tagsFromFile "${i}" "jpeg/${i/./_}.jpg" done rm jpeg/*_original
Francesco, Yes, in Album icon view, you can group items, but not yet in camera gui icon view. This is not yet done because camera gui icon view must be ported to Qt4 model/view, as other parts of digiKam. So, this file cannot be yet closed... Gilles Caulier
(In reply to comment #36) > Francesco, > > Yes, in Album icon view, you can group items, but not yet in camera gui icon > view. > > This is not yet done because camera gui icon view must be ported to Qt4 > model/view, as other parts of digiKam. > > So, this file cannot be yet closed... > > Gilles Caulier ... Gilles: Thank you for pointing out this detail. For my opinion, a _manual_ grouping ability is quite limited for just the naked number of files prevents manual handling. Please compare to my statistics: digiKam version 2.0.0-beta5 AVI: 59 GIF: 99 JP2: 14 JPG: 63559 MPEG: 2 PGF: 2 PNG: 869 RAW-CR2: 631 RAW-CRW: 10960 RAW-DNG: 4 RAW-NEF: 31693 TIFF: 875 Gesamtzahl der Einträge: 108767 : Alben: 1734 Stichwörter: 49 : Datenbanktreiber: QSQLITE ... and you will recognize, that the number of Canon RAW-Files: cr2 = 631, crw = 10960 (and other) prohibit to even think about manual interaction!!! Axel
Francesco; note that the jpg embedded in nef is of lower quality that information you get. The extracted file is about 1 MB but exiftool tells me 3.9 MB...
yes, JPEG embeded in RAW is a reduced version used to display image on camera screen device or on a tv screen, with to process RAW file. It's a preview image. We use it in digiKam to show RAW preview... Gilles Caulier
*** Bug 279953 has been marked as a duplicate of this bug. ***
I agree with Axel. A batch merge tool is needed which simply has to search for files with the same name excluding suffix in the same album and group them. Maybe it could be intelligent enough to group also variants like: img_1234.jpg img_1234.cr2 img_1234-1.JPG IMG_1234_2.jpg One problem might be how to merge the meta data. Because sometimes my raw files have not the same meta (often less or none) data attached as the jpeg. This wasn't intentional so it would be nice the correct the missing meta data this way.
(In reply to comment #41) > I agree with Axel. A batch merge tool is needed which simply has to search for > files with the same name excluding suffix in the same album and group them. > > Maybe it could be intelligent enough to group also variants like: > > img_1234.jpg > img_1234.cr2 > img_1234-1.JPG > IMG_1234_2.jpg > > One problem might be how to merge the meta data. Because sometimes my raw files > have not the same meta (often less or none) data attached as the jpeg. This > wasn't intentional so it would be nice the correct the missing meta data this > way. Hello: I just got an idea: maybe there is technically easy method in combining the original issue "dealing more than one format of one pic" (NEF + jpg, crw + jpg, ...) in the context of versioning. I assume there is some database technology behind, and combining the ability of versioning PLUS handling several formats of one picture maybe very useful in the contect of workflow. Example of my workflow: - Shooting a pic produces NEF PLUS jpg. - creating a panorama creates PNG or TIF Other combinations may happen... Maybe a continous search for similar pics (in the background or when added first) could support this intention. Hope I could explain my thoughts Axel
> I just got an idea: maybe there is technically easy method in combining the > original issue "dealing more than one format of one pic" (NEF + jpg, crw + jpg, > ...) in the context of versioning. This is my plan...in fact, the JPG really is a version derived from the original RAW.
Am 14.11.2011 19:39, schrieb Marcel Wiesweg: > https://bugs.kde.org/show_bug.cgi?id=126149 > > > > > > --- Comment #43 from Marcel Wiesweg <marcel wiesweg gmx de> 2011-11-14 18:39:02 --- > >> I just got an idea: maybe there is technically easy method in combining the >> original issue "dealing more than one format of one pic" (NEF + jpg, crw + jpg, >> ...) in the context of versioning. > > This is my plan...in fact, the JPG really is a version derived from the > original RAW. > sounds great! Thank you for info Axel
Any update status for this ? It seems for now * a manual way is using grouping but nothing automated at all * on a native grouping or whatever name, still no progress. I make a short try to group some pictures w 2.6.0 and that does not seem to be really fast (I know group performance is not the subject of the bug but it makes the proposal not really usable ...; note that's only a short basic test)
No automatic grouping is not yet implemented. - What is not "really fast"? Manual grouping as such - sure. Any automatic grouping?
I tried previously a manual grouping by time on 2 images and I had to kill digikam in the end. Retried today normal grouping and grouping by time on 3 images and there was no problem. Don't know what happened.
Hello, I can confirm this request made sense (my photography workflow uses NEF+JPG) If there are two files called zzz.jpg and zzz.raw implement options in gwenview so to Show only raw Show only JPEG Show both Thanks Regards
I have reported a bug that is a closeby issue although it affects kscreensaver not gwenview (I suppose the same libraries are used) Screensaver diaporama does not skip raw photo files (like nef files) and displays a tiny picture https://bugs.kde.org/show_bug.cgi?id=304908
kscreensaver read NEF as TIFF/EP std image. It do not deal with RAW in fact. Try to use another RAW file format as CR2 or ARW, and it do not work. The tiny image from NEF is TIFF/EP thumbnail in fact loaded by QImage codec. To deal with all RAW file, it must use libkdcraw in fact. The RAW+JPEG import tool feature is planed for 3.0.0 by Islam Wazery, a student from GoSC 2012 : http://community.kde.org/Digikam/GSoC2012#Camera_User_Interface_Revamp Gilles Caulier
We just finished implementing a somewhat similar feature called "Group Selected Images By Regex" and added it to bug 318357
Am 27.01.2014 22:47, schrieb kde@sleif.de: > https://bugs.kde.org/show_bug.cgi?id=126149 > > --- Comment #51 from kde@sleif.de --- > We just finished implementing a somewhat similar feature called "Group Selected > Images By Regex" and added it to bug 318357 > Thankx for information. Does it handle metadata (delete obsolete XML-files), versioning, other file formats (created from EDITas dng, png, etc.) image too? (Just some thoughts from recent observations.) Available from digiKam 4.0? Axel
In the attachments I puts a small patch which adds the possibility to group images with the same file name but different file-endings. The smallest one is put in front, so that scrolling through the images is fastest.
Created attachment 94161 [details] Grouping by filetype.
Git commit 6ba84e73fc814afd322a454016dda7ada15865a7 by Maik Qualmann. Committed on 16/09/2015 at 17:09. Pushed by mqualmann into branch 'master'. apply patch #94161 from Christoph Huckle to group images with the same file name by filetype FIXED-IN: 4.14.0 M +2 -1 NEWS M +12 -0 app/items/digikamimageview.cpp M +1 -0 app/items/digikamimageview.h M +52 -0 app/items/imageviewutilities.cpp M +1 -0 app/items/imageviewutilities.h M +4 -0 app/utils/contextmenuhelper.cpp M +1 -0 app/utils/contextmenuhelper.h M +9 -0 app/views/tableview/tableview.cpp M +1 -0 app/views/tableview/tableview.h http://commits.kde.org/digikam/6ba84e73fc814afd322a454016dda7ada15865a7
Git commit 1a539187c019c7f3f944bd924b30c231894fb086 by Gilles Caulier. Committed on 24/09/2015 at 06:41. Pushed by cgilles into branch 'master'. remove dupplicate signal/slot connection M +0 -3 app/items/digikamimageview.cpp http://commits.kde.org/digikam/1a539187c019c7f3f944bd924b30c231894fb086
Git commit bbfc819a65d1815d6e2e69a63ac4029333b536c1 by Gilles Caulier. Committed on 24/09/2015 at 07:06. Pushed by cgilles into branch 'frameworks'. backport commit #6ba84e73fc814afd322a454016dda7ada15865a7 from git/master to frameworks branch M +12 -0 app/items/digikamimageview.cpp M +1 -0 app/items/digikamimageview.h M +52 -0 app/items/imageviewutilities.cpp M +1 -0 app/items/imageviewutilities.h M +4 -0 app/utils/contextmenuhelper.cpp M +2 -4 app/utils/contextmenuhelper.h M +9 -0 app/views/tableview/tableview.cpp M +1 -0 app/views/tableview/tableview.h http://commits.kde.org/digikam/bbfc819a65d1815d6e2e69a63ac4029333b536c1