Can digiKam write to Canon cr2 files?
Does it write to any raw files? Does anyone on the list allow it to write to their raw files? Elle _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Monday 26 August 2013 14:55:04 Elle Stone wrote:
> Can digiKam write to Canon cr2 files? No idea. > Does it write to any raw files? There is an option in the settings dialog (metadata section) to allow writing to RAW files, but it is still marked as experimental (in version 3.3.0) > Does anyone on the list allow it to write to their raw files? No way I'll allow any program to write to my RAW files: I consider them my 'negatives' and don't want any more risk than necessary of losing them. Writing to them increases the risk, so is a big nono for me. the Digikam database plus the XMP sidecars should be enough for normal use (with proper backups of course). Don't forget that most RAW formats have data in a obfuscated and unpublished format, so any interpretation is obtained through reverse engineering the format. That means there's a chance that part of some formats is misunderstood, and writing to such a format might make the file unreadable; perhaps not for the program that wrote the faulty data, but another program or a newer version could have a better, stricter, or just different interpretation of the RAW data, and fail to read such a file. Remco _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Elle Stone
Hello, On Mon, 26 Aug 2013, Elle Stone wrote: > Can digiKam write to Canon cr2 files? > > Does it write to any raw files? I don't know for Canon raw files, but as Digikam uses the exiv2 library, probably the answer is to be found in exiv2 supported formats. http://dev.exiv2.org/wiki/exiv2/Supported_image_formats And the above page says yes for CR2 files, so... And this page says also : « Be sure to test carefully if your applications work well with images modified by Exiv2. ». Sounds wise. > Does anyone on the list allow it to write to their raw files? I've abandonned using raw files these last two years, but in the past my raw images were readonly locked, always. I totally agree with what Remco said 15 mn ago, and I think too that sidecar files are the most safe way to keep/edit metadata with risk zero. When embedding metadata into images files comes necessary, it's always possible to write to a safe format, PNG or JPEG. Another good reason to use sidecar files comes when you use several programs to work on your images. Some are broken wrt metadata updating (e.g. The GIMP) and having metadata in a safe place (readonly sidecar files) is wise. Regards, Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Elle Stone
On 26/08/13 20:55, Elle Stone wrote:
> Does anyone on the list allow it to write to their raw files? If it ever gains the ability I will immediately stop using it and delete it from my disk! Just the thought of it ever touching the digital negatives... Never ever! _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Hmm, well, thanks all!
I actually only do use sidecar files for all the reasons listed above, for jpegs as well as raw files. But I was testing digiKam 3.4 in a test database where I needed to write directly to the images. Writing to the raw files didn't seem to work, though I kinda thought it already did. So I was wondering whether anyone on the list might be writing to their raw files. That "experimental" feature has been there a long time. Anyway, I do let exiftool write directly to my raw files, have done so for years. But you all have given me reason to rethink even that. From now on I'll also save a completely untouched original raw and write only to a copy. Elle -- http://ninedegreesbelow.com - color management & open source photography _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Hi all,
Raw metadata writting support is operated by Exiv2 in background. All format supported are managed by Exiv2, not digiKam. As i remember, only few TIFF/EP based raw format are supported, as NEF for ex. Considerate this feature as experimental. It's disabled by default in digiKam. Considerate XMP sidecar as the best universal alternative. Sure it's add new file in your collection, but size are negligible compared to image data. Gilles Caulier 2013/8/27 Elle Stone <[hidden email]>: > Hmm, well, thanks all! > > I actually only do use sidecar files for all the reasons listed above, > for jpegs as well as raw files. But I was testing digiKam 3.4 in a > test database where I needed to write directly to the images. Writing > to the raw files didn't seem to work, though I kinda thought it > already did. So I was wondering whether anyone on the list might be > writing to their raw files. That "experimental" feature has been there > a long time. > > Anyway, I do let exiftool write directly to my raw files, have done so > for years. But you all have given me reason to rethink even that. From > now on I'll also save a completely untouched original raw and write > only to a copy. > > Elle > > -- > http://ninedegreesbelow.com - color management & open source photography > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On 27/08/13 13:33, Gilles Caulier wrote:
> Considerate XMP sidecar as the best universal alternative. Sure it's > add new file in your collection, but size are negligible compared to > image data. Consider XMP sidecar files as the only viable way of storing meta data as writing to the RAW file or even the JPEG will create an backup nightmare as instead of needing to backup one small file you then would have to backup the full large image file! _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Gilles Caulier-4
Le 27/08/2013 13:33, Gilles Caulier a écrit :
> Considerate XMP sidecar as the best universal alternative. Sure it's > add new file in your collection, but size are negligible compared to > image data. true, but sidecar files a not standars and so can't be used to transfer metadata for example to online gallery just to point about the "universal" adjective. Of course I wont ever write to raw file, only to jpeg jdd -- http://www.dodin.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2013/8/27 jdd <[hidden email]>:
> Le 27/08/2013 13:33, Gilles Caulier a écrit : > > >> Considerate XMP sidecar as the best universal alternative. Sure it's >> add new file in your collection, but size are negligible compared to >> image data. > > > > true, but sidecar files a not standars and so can't be used to transfer > metadata for example to online gallery > It's completely wrong ! XMP is standardized by Adobe. But it's true that 3rd party applications are not able to manage it properly. But's it's another problem here... > just to point about the "universal" adjective. Of course I wont ever write > to raw file, only to jpeg This is what i do too. Typically, i shot RAW + JPEG in particular condition, where i know that JPEG can be a failure in workflow. ...else JPEG is really enough to work in 90% of case, and it's enough. I'm waiting that camera constructor use a replacement of JPEG supporting 16 bits color depth instead 8 bits... or why not, improve JPEG standard to support a better color depth. It's already the case of JPEG used in medecine which support lossless compression and 12 bits color depth. Note that an higher color to JPEG is possible, as DNG use it to store RAW data with 16 bits color depth... Gilles Caulier > > jdd > > > -- > http://www.dodin.org > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Karl Günter Wünsch
2013/8/27 Karl Günter Wünsch <[hidden email]>:
> On 27/08/13 13:33, Gilles Caulier wrote: >> Considerate XMP sidecar as the best universal alternative. Sure it's >> add new file in your collection, but size are negligible compared to >> image data. > Consider XMP sidecar files as the only viable way of storing meta data > as writing to the RAW file or even the JPEG will create an backup > nightmare as instead of needing to backup one small file you then would > have to backup the full large image file! Why it's a mess to backup image files + sidecar files at the same time ? both are stored in collection at the same place and use the same file name prefix.. Personalty, i backup my whole collection to a NAS using rsync without any problem. Restoring collection after a crash on host computer work like a charm. XMp side car will be parsed to restore DB... Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On 27/08/13 15:36, Gilles Caulier wrote:
> 2013/8/27 Karl Günter Wünsch <[hidden email]>: >> On 27/08/13 13:33, Gilles Caulier wrote: >>> Considerate XMP sidecar as the best universal alternative. Sure it's >>> add new file in your collection, but size are negligible compared to >>> image data. >> Consider XMP sidecar files as the only viable way of storing meta data >> as writing to the RAW file or even the JPEG will create an backup >> nightmare as instead of needing to backup one small file you then would >> have to backup the full large image file! > > Why it's a mess to backup image files + sidecar files at the same time > ? both are stored in collection at the same place and use the same > file name prefix.. were to write to the RAW or JPEG file, the XMP sidecar is the only viable solution that doesn't screw up the backup solution! _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Gilles Caulier-4
Le 27/08/2013 15:34, Gilles Caulier a écrit :
> I'm waiting that camera constructor use a replacement of JPEG > supporting 16 bits color depth instead 8 bits... then we need better screens :-)) and some time better eyes :-)) jdd -- http://www.dodin.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2013/8/27 jdd <[hidden email]>:
> Le 27/08/2013 15:34, Gilles Caulier a écrit : > > >> I'm waiting that camera constructor use a replacement of JPEG >> supporting 16 bits color depth instead 8 bits... > > > then we need better screens :-)) > > and some time better eyes :-)) But RAW is already 12 or 14 bits... The goal is not to improve rendering of colors on screen, but the change/fix/improvements done on image by post processing. With 8 bits color depth it's a source of data loss which will be less visible in 16 bits color depth... Also, i don't talk about the capability of camera to capture a largest spectrum of light, which will be stored in a better way with more color depth. Gilles Caulier > > > jdd > > > -- > http://www.dodin.org > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Le 27/08/2013 15:55, Gilles Caulier a écrit :
> But RAW is already 12 or 14 bits... well... raw is not an image :-( your 16 bits jpg is simply a standardised raw, witch is really needed jdd -- http://www.dodin.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
RAW is an image. It's a copy of internal sensor data not processed by
camera firmware. It's not a suitable as well image as JPEG, but it's an image that need post processing. In fact JPEG need also post processing to be show on screen as decompression for ex. Sure, RAW require more post computing, but it's an image. Read wikipedia page for details : http://en.wikipedia.org/wiki/Raw_image_format Gilles Caulier 2013/8/27 jdd <[hidden email]>: > Le 27/08/2013 15:55, Gilles Caulier a écrit : > > >> But RAW is already 12 or 14 bits... > > > well... raw is not an image :-( > > your 16 bits jpg is simply a standardised raw, witch is really needed > > > jdd > > > -- > http://www.dodin.org > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Le 27/08/2013 16:17, Gilles Caulier a écrit :
> RAW is an image. It's a copy of internal sensor data not processed by > camera firmware. it's an image as long as you think an undevelopped exposed film is an image... by the way it's an other discussion I should not have started, sorry, my fault jdd -- http://www.dodin.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by jdd@dodin.org
On Tuesday 27 August 2013 16:01:35 jdd wrote:
> Le 27/08/2013 15:55, Gilles Caulier a écrit : > > > But RAW is already 12 or 14 bits... > > well... raw is not an image :-( > > your 16 bits jpg is simply a standardised raw, witch is really needed Not quite, as jpeg usually uses a /lossy/ compression, which can induce visible artifacts (especially at high contrast edges, see the effect jpeg compression has on text or line drawings). And 12 bits is enough for most sensors afaik, and packs nicely (2 pixels in 3 bytes, easy to encode/decode); so 16 bits is a bit of overkill, and would slow down writing to the memory card. But yes, a really standard and open RAW format would be nice. Remco _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2013/8/27 Remco Viëtor <[hidden email]>:
> On Tuesday 27 August 2013 16:01:35 jdd wrote: >> Le 27/08/2013 15:55, Gilles Caulier a écrit : >> >> > But RAW is already 12 or 14 bits... >> >> well... raw is not an image :-( >> >> your 16 bits jpg is simply a standardised raw, witch is really needed > Not quite, as jpeg usually uses a /lossy/ compression, which can induce > visible artifacts (especially at high contrast edges, see the effect jpeg > compression has on text or line drawings). > > And 12 bits is enough for most sensors afaik, and packs nicely (2 pixels in > 3 bytes, easy to encode/decode); so 16 bits is a bit of overkill, and would > slow down writing to the memory card. Not really. As RAW as 12/14 bits depth, it's already the case. I'm sure that data are encode with 2 byte instead 1 for one color components by pixel. Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Elle Stone
On 27 Aug 2013, at 22:48, "Karl Günter Wünsch" <[hidden email]> wrote: > On 27/08/13 15:36, Gilles Caulier wrote: >> 2013/8/27 Karl Günter Wünsch <[hidden email]>: >>> On 27/08/13 13:33, Gilles Caulier wrote: >>>> Considerate XMP sidecar as the best universal alternative. Sure it's >>>> add new file in your collection, but size are negligible compared to >>>> image data. >>> Consider XMP sidecar files as the only viable way of storing meta data >>> as writing to the RAW file or even the JPEG will create an backup >>> nightmare as instead of needing to backup one small file you then would >>> have to backup the full large image file! >> >> Why it's a mess to backup image files + sidecar files at the same time >> ? both are stored in collection at the same place and use the same >> file name prefix.. > Nope, you read my comment wrong. It's a backup nightmare if the program > were to write to the RAW or JPEG file, the XMP sidecar is the only > viable solution that doesn't screw up the backup solution! > I don't understand this argument at all. Every better backup solution handles diffs automatically and usually a backup contains a lot of other files that get altered. Spreadsheets, text documents, source code files, binaries, you name it. Are they all a nightmare as well? Hell, you could even run a version control system on your images if you wished so... Out of practical experience, I use sidecars for RAW but write metadata to JPEGs for easier export handling. And my backup runs flawless... _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |