Bug 126149 - Album icon view stores both jpeg and raw (nef), handle both as one [patch]
Summary: Album icon view stores both jpeg and raw (nef), handle both as one [patch]
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: Albums-ItemGroup (show other bugs)
Version: 2.6.0
Platform: unspecified Linux
: NOR wishlist with 608 votes (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-24 08:50 UTC by Roger Larsson
Modified: 2017-07-31 16:36 UTC (History)
27 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.14.0


Attachments
groupingSnapshot.png (210.01 KB, image/png)
2011-05-24 22:40 UTC, Francesco Riosa
Details
Grouping by filetype. (7.43 KB, patch)
2015-08-22 07:44 UTC, Christoph Huckle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roger Larsson 2006-04-24 08:50:05 UTC
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.)
Comment 1 F.J. Cruz 2006-04-24 11:48:44 UTC
---- 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.
Comment 2 Roger Larsson 2006-04-24 13:53:07 UTC
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.)
Comment 3 glaurent 2006-04-24 14:28:20 UTC
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)
Comment 4 Dennis Gnad 2006-04-24 17:16:00 UTC
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.
Comment 5 Roger Larsson 2006-04-24 21:20:44 UTC
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...
Comment 6 Roger Larsson 2006-04-26 12:33:07 UTC
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.
Comment 7 caulier.gilles 2006-04-26 19:08:21 UTC
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
Comment 8 Arnd Baecker 2007-07-15 10:53:25 UTC
*** Bug 147886 has been marked as a duplicate of this bug. ***
Comment 9 Mikolaj Machowski 2007-07-16 22:05:51 UTC
*** Bug 147933 has been marked as a duplicate of this bug. ***
Comment 10 david 2007-09-08 20:33:25 UTC
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).
Comment 11 Mikolaj Machowski 2009-04-06 19:57:05 UTC
*** Bug 188968 has been marked as a duplicate of this bug. ***
Comment 12 caulier.gilles 2009-06-19 14:27:14 UTC
*** Bug 151228 has been marked as a duplicate of this bug. ***
Comment 13 Milan Knížek 2009-08-03 21:40:16 UTC
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.
Comment 14 Stibbons 2009-08-12 14:41:57 UTC
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.
Comment 15 Roger Larsson 2009-08-12 17:05:16 UTC
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.
Comment 16 DGardner 2009-09-14 14:26:29 UTC
Is this bug just a specific case of bug #121310 "Allow to have a group of pictures"? Should it be marked as a duplicate?
Comment 17 Mikolaj Machowski 2009-09-14 18:00:53 UTC
@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.
Comment 18 Michał S. 2009-09-15 08:57:54 UTC
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?
Comment 19 caulier.gilles 2009-09-15 09:29:47 UTC
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
Comment 20 Roger Larsson 2009-09-15 10:14:02 UTC
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!
Comment 21 caulier.gilles 2009-09-15 10:33:23 UTC
Roger, look there :

http://farm3.static.flickr.com/2510/3921847029_002e2a2e1d_o.png

Gilles Caulier
Comment 22 Maciej Dems 2009-09-15 11:44:23 UTC
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.
Comment 23 Mikolaj Machowski 2009-09-15 15:46:16 UTC
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
Comment 24 Milan Knížek 2009-09-15 19:24:35 UTC
(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.")
Comment 25 Stibbons 2009-09-15 21:34:15 UTC
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.
Comment 26 Oceanwatcher 2009-10-24 00:59:26 UTC
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!"
Comment 27 Mathias Lindner 2009-12-29 14:09:50 UTC
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.
Comment 28 Marcel Wiesweg 2009-12-29 15:01:23 UTC
We will have this feature, I plan to work on this for the next feature release, if time permits of course.
Comment 29 Julien Narboux 2010-01-29 16:59:30 UTC
*** Bug 224789 has been marked as a duplicate of this bug. ***
Comment 30 Michael G. Hansen 2010-08-06 18:36:18 UTC
*** Bug 246920 has been marked as a duplicate of this bug. ***
Comment 31 Mathias Lindner 2010-09-06 08:35:17 UTC
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!
Comment 32 caulier.gilles 2010-09-13 05:48:48 UTC
*** Bug 249303 has been marked as a duplicate of this bug. ***
Comment 33 CROUZILLAT Sylvain 2010-12-26 23:25:03 UTC
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.
Comment 34 Axel Krebs 2011-05-22 21:00:27 UTC
(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
Comment 35 Francesco Riosa 2011-05-24 22:40:43 UTC
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
Comment 36 caulier.gilles 2011-05-24 22:46:39 UTC
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
Comment 37 Axel Krebs 2011-05-24 22:59:29 UTC
(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
Comment 38 Roger Larsson 2011-05-26 07:42:48 UTC
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...
Comment 39 caulier.gilles 2011-05-26 08:04:50 UTC
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
Comment 40 Marcel Wiesweg 2011-08-12 17:34:27 UTC
*** Bug 279953 has been marked as a duplicate of this bug. ***
Comment 41 René Fritz 2011-11-12 11:47:04 UTC
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.
Comment 42 Axel Krebs 2011-11-13 16:33:32 UTC
(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
Comment 43 Marcel Wiesweg 2011-11-14 18:39:02 UTC
> 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.
Comment 44 Axel Krebs 2011-11-14 19:02:15 UTC
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
Comment 45 julien.t43+kde 2012-07-07 00:45:54 UTC
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)
Comment 46 Marcel Wiesweg 2012-07-08 11:28:05 UTC
No automatic grouping is not yet implemented.
-
What is not "really fast"? Manual grouping as such - sure. Any automatic grouping?
Comment 47 julien.t43+kde 2012-07-08 12:48:34 UTC
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.
Comment 48 emmanuel.manchester314 2012-08-10 07:02:19 UTC
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
Comment 49 emmanuel.manchester314 2012-08-10 07:15:37 UTC
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
Comment 50 caulier.gilles 2012-08-10 07:28:59 UTC
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
Comment 51 kde 2014-01-27 23:47:03 UTC
We just finished implementing a somewhat similar feature called "Group Selected Images By Regex" and added it to bug 318357
Comment 52 Axel Krebs 2014-01-28 06:49:59 UTC
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
Comment 53 Christoph Huckle 2015-08-22 07:42:50 UTC
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.
Comment 54 Christoph Huckle 2015-08-22 07:44:16 UTC
Created attachment 94161 [details]
Grouping by filetype.
Comment 55 Maik Qualmann 2015-09-16 17:11:48 UTC
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
Comment 56 caulier.gilles 2015-09-24 06:42:26 UTC
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
Comment 57 caulier.gilles 2015-09-24 07:06:53 UTC
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