<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
I am having the exact problems as well. Can only get it running for a few mins if I start a new database, otherwise it crashes on launch. <br><br>Not sure how to troubleshoot either, just moved from the Linux version to windows. <br><br>Win7. <br><br>-Eric<br><br><div><div id="SkyDrivePlaceholder"></div>> From: digikam-users-request@kde.org<br>> Subject: Digikam-users Digest, Vol 80, Issue 50<br>> To: digikam-users@kde.org<br>> Date: Sun, 22 Jan 2012 12:00:05 +0000<br>> <br>> Send Digikam-users mailing list submissions to<br>>       digikam-users@kde.org<br>> <br>> To subscribe or unsubscribe via the World Wide Web, visit<br>>      https://mail.kde.org/mailman/listinfo/digikam-users<br>> or, via email, send a message with subject or body 'help' to<br>>    digikam-users-request@kde.org<br>> <br>> You can reach the person managing the list at<br>>  digikam-users-owner@kde.org<br>> <br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of Digikam-users digest..."<br>> <br>> <br>> Today's Topics:<br>> <br>>    1. batch rename (Andreas T. Ege)<br>>    2. Re: re JPEG lossiness, PNG (Simon Oosthoek)<br>>    3. Where does "grouped" pictures dissapear? (Anders Lund)<br>>    4. Re: Where does "grouped" pictures dissapear? (Anders Lund)<br>>    5. Re: re JPEG lossiness, PNG (Remco Vi?tor)<br>>    6. Re: re JPEG lossiness, PNG (Andrew Goodbody)<br>>    7. 2.5 windows build broken for me (Bryce Schober)<br>> <br>> <br>> ----------------------------------------------------------------------<br>> <br>> Message: 1<br>> Date: Sat, 21 Jan 2012 16:20:00 +0000<br>> From: "Andreas T. Ege" <andreas@spheniscid.net><br>> To: digikam-users@kde.org<br>> Subject: [Digikam-users] batch rename<br>> Message-ID: <4F1AE5B0.2060105@spheniscid.net><br>> Content-Type: text/plain; charset=ISO-8859-15; format=flowed<br>> <br>> Hello,<br>> <br>> when batch renaming files, I infrequently get the message 'file does not <br>> exist' after renaming 50-80% of the files, causing the batch to stop. <br>> Doesn't happen all the time, but sometimes I need 2-3 goes to rename <br>> images in a folder. I usually use 'name-##[e]' to rename.<br>> Has just happened again on some 32 images, and I filed a bug report <br>> about it.<br>> <br>> And very rarely it happens, that the batch completely mixes up the file <br>> order, renaming the images by some order I can't grasp.<br>> Haven't filed a bug report yet, has happened recently when I didn't have <br>> the time, and not since.<br>> <br>> -- <br>> Andreas Ege<br>> <br>>               24 The Birches<br>>                  Shobdon<br>>                  Herefordshire HR6 9NG<br>>                  GB<br>>                  Mobile: +44.(0)7526.315292<br>>                  Tel.: +44.(0)1568.709166<br>>                  http://spheniscid.net<br>> <br>> <br>> ------------------------------<br>> <br>> Message: 2<br>> Date: Sat, 21 Jan 2012 19:58:22 +0100<br>> From: Simon Oosthoek <somlist@xs4all.nl><br>> To: digiKam - Home Manage your photographs as a professional with the<br>>       power of open source <digikam-users@kde.org><br>> Subject: Re: [Digikam-users] re JPEG lossiness, PNG<br>> Message-ID: <4F1B0ACE.8040407@xs4all.nl><br>> Content-Type: text/plain; charset=ISO-8859-1<br>> <br>> On 14/01/12 17:15, Jean-Fran?ois Rabasse wrote:<br>> ><br>> > JPEG can compress in a lossless way, until the algorithm bumps against<br>> > some limits. GIF does so, PNG does so. But JPEG can boost compression<br>> > efficiency if the user accept some losses.<br>> > That's what Marie-No?lle Augendre said, on this thread :<br>> > "I guess that to produce something smaller, you'll have to loose<br>> > something."<br>> > Definitely right, there's no magic at all, and Santa Claus doesn't<br>> > exist:-)<br>> <br>> Maybe I've missed a part of the discussion, but the main concern with<br>> Jpeg is, AFAIK, that jpeg is 8-bits, so always loses something when<br>> using RAW as the reference, since RAW formats usually have 10-16 bits<br>> per colour available as bandwidth and most SLR sensors have the ability<br>> to provide that dynamic range to a certain extend, converting from RAW<br>> to JPEG will at least cost you the difference in expressibility of<br>> colour and brightness (e.g. 12 bits in RAW to JPEG: 4096 to 256 shades).<br>> Even if no loss was caused by the JPEG algorithm, JPEG loses something.<br>> <br>> This is why PNG and JPG2000 are popular choices; they allow 16-bit<br>> values to be preserved and allow lossless compression (meaning it is<br>> reversible to "RAW" in theory)<br>> <br>> /Simon<br>> <br>> <br>> ------------------------------<br>> <br>> Message: 3<br>> Date: Sat, 21 Jan 2012 20:09:48 +0100<br>> From: Anders Lund <anders@alweb.dk><br>> To: digikam-users@kde.org<br>> Subject: [Digikam-users] Where does "grouped" pictures dissapear?<br>> Message-ID: <201201212009.48866.anders@alweb.dk><br>> Content-Type: text/plain;  charset="iso-8859-15"<br>> <br>> Hi,<br>> <br>> Using digikam 2.5 is mostly a pleasure, but sometimes it does not do what it <br>> is supposed to.<br>> <br>> For example, typically I edit a photo, importing the raw and proccessing it, <br>> and then press "save changes". Sometimes this creates a new version in the <br>> photos version tab, but sometimes not.<br>> <br>> I dragged such a image onto the original, and accepted "group to here", and it <br>> dissapeared... Where did it go? :0<br>> <br>> Oh, and the behavior when saving should be consistent!<br>> -- <br>> Anders<br>> <br>> <br>> ------------------------------<br>> <br>> Message: 4<br>> Date: Sat, 21 Jan 2012 20:17:52 +0100<br>> From: Anders Lund <anders@alweb.dk><br>> To: "digiKam - Home Manage your photographs as a professional with the<br>>         power of open source" <digikam-users@kde.org><br>> Subject: Re: [Digikam-users] Where does "grouped" pictures dissapear?<br>> Message-ID: <201201212017.52997.anders@alweb.dk><br>> Content-Type: Text/Plain;  charset="iso-8859-1"<br>> <br>> On L?rdag den 21. januar 2012, Anders Lund wrote:<br>> > Hi,<br>> > <br>> > Using digikam 2.5 is mostly a pleasure, but sometimes it does not do what<br>> > it is supposed to.<br>> > <br>> > For example, typically I edit a photo, importing the raw and proccessing<br>> > it, and then press "save changes". Sometimes this creates a new version in<br>> > the photos version tab, but sometimes not.<br>> > <br>> > I dragged such a image onto the original, and accepted "group to here", and<br>> > it dissapeared... Where did it go? :0<br>> <br>> Nm, I found it. But the behavior is odd. I created a new edit, and this time, <br>> it was added to the raw photo version tab, but it is displayed in a kind of <br>> layered display with the first edit, which is grouped with the raw but not <br>> recognized as a version of that.<br>>  <br>> > Oh, and the behavior when saving should be consistent!<br>> <br>> !<br>> <br>> -- <br>> Anders<br>> <br>> <br>> ------------------------------<br>> <br>> Message: 5<br>> Date: Sat, 21 Jan 2012 20:49:57 +0100<br>> From: Remco Vi?tor <remco.vietor@wanadoo.fr><br>> To: digiKam - Home Manage your photographs as a professional with the<br>>   power of open source <digikam-users@kde.org><br>> Subject: Re: [Digikam-users] re JPEG lossiness, PNG<br>> Message-ID: <1838203.pBcQ8o2xgG@manticore><br>> Content-Type: text/plain; charset="iso-8859-1"<br>> <br>> On Saturday 21 January 2012 19:58:22 Simon Oosthoek wrote:<br>> > This is why PNG and JPG2000 are popular choices; they allow 16-bit<br>> > values to be preserved and allow lossless compression (meaning it is<br>> > reversible to "RAW" in theory)<br>> No, it is not: RAW files have as many pixels as the resulting PNG files (in <br>> theorie at least), but each represents only one colour channel out of three <br>> (or four*). The different colours are arranged in a matrix (Bayer matrix), so <br>> that a square of 4 pixels has the three colours, with green being present <br>> twice.<br>> To get the image on which we work (and which is stored as PNG or whatever), <br>> those colours are interpolated, so the original values are replaced by <br>> calculated values, and the missing colours are added for each pixel.Due to <br>> this interpolation, there is no guarantee that you can recover the original <br>> values.<br>> <br>> Note that the term "lossless" as applied to a compression algorithm only <br>> implies that the compression is reversible. RAW -> PNG is a bit more than just <br>> a compression, and there is no guarantee that all steps are reversible.<br>> <br>> *: certain systems use 2 different greens<br>> <br>> <br>> ------------------------------<br>> <br>> Message: 6<br>> Date: Sat, 21 Jan 2012 22:51:59 +0000<br>> From: Andrew Goodbody <ajg02@elfringham.co.uk><br>> To: digiKam - Home Manage your photographs as a professional with the<br>>    power of open source <digikam-users@kde.org><br>> Subject: Re: [Digikam-users] re JPEG lossiness, PNG<br>> Message-ID: <4F1B418F.3070705@elfringham.co.uk><br>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>> <br>> On 21/01/12 15:25, Peter Mc Donough wrote:<br>> >> OK, not listed, but it may work anyway. Did you try it? If it did not<br>> >> work did you provide sample files to Dave Coffin for him to implement<br>> >> the support?<br>> ><br>> > No, I didn't. When I bought the camera, at that time I used jpeg - it<br>> > was a special offer and has suited my idea of a DSLR since - there were<br>> > at least three newer Olympus DSLR camera model generations.<br>> > Later I gave RAW a try and browsing the web I couldn't find any demand<br>> > for a RAW profile of my "new" camera, so asking for one especially for<br>> > me seems to be a waste of the "resource" Dave Coffin.<br>> <br>> It would not be especially for you. It would be for you and for all the <br>> other people out there who also looked for support and did not find it <br>> and then also did nothing. So your failure to send samples to Dave <br>> Coffin is actually depriving other people. Just because you could find <br>> no published demand for support does not mean the demand does not exist, <br>> merely that those that want it have not published about it.<br>> Why not let Dave Coffin be the judge of what is a waste of his time?<br>> <br>> > In fact, Digikam could read the original raw file and I didn't notice<br>> > any problems. On the other hand, I don't know enough about RAW files for<br>> > deciding what, if anything, was missing or faulty.<br>> ><br>> > What I read in the web was an unhappiness about propriatary RAW formats.<br>> > There may be a good reason for propriatary formats - the obvious one I<br>> > see and don't like is that a user may stick to one brand because his<br>> > valuable photos are of in a certain RAW type.<br>> <br>> Sounds like a bogus reason to me. I would question if anyone thought <br>> that way. Raw formats change even in the same brand from one generation <br>> of camera to another. The solution is to have software support for both <br>> old and new format. Lots of bigger reasons for sticking to one brand eg <br>> investment in lenses and other accessories.<br>> <br>> > What brough me to Adobe DNG were several discussions, among them:<br>> ><br>> > http://mansurovs.com/dng-vs-raw<br>> <br>> Interesting article. I had not noticed the reduction in the size of DNG <br>> files in comparison to raw files from the camera. I wonder why that is. <br>> One possibility is that a PC has the computing resources to be able to <br>> do a better compression than the camera processor. So that would not be <br>> a feature of DNG per se, merely the recompression of the data with more <br>> resources available to do it. I wonder how the file size of those <br>> cameras that produce DNG natively compares.<br>> Unfortunately the article is not clear about issues such as the reduced <br>> size does not apply if you opt to embed the original raw file, quite the <br>> reverse in fact. Also manufacturer developing programs can write to <br>> their own raw file format so you do not necessarily have sidecar files. <br>> Also it is likely that open source will, in time, gain the ability to <br>> write to other raw formats (I think it can already write to some but not <br>> all). Some of the advantages and disadvantages depend on the particular <br>> software in use and do not really apply in practice.<br>> <br>> > The version I have, DNGConverter 6.5, runs under standard Wine in<br>> > Opensuse 11.4 64bit and of course in virtualized Windows XP.<br>> <br>> digikam, darktable, rawtherapee, dcraw, ufraw etc all run natively in <br>> Linux. BTW digikam can do the conversion from camera raw to DNG.<br>> <br>> > I am very pro open standards and when I buy my next camera I will check<br>> > before whether its RAW format is supported under Linux.<br>> ><br>> > Peter<br>> <br>> I also am very pro open standards and would prefer all cameras to <br>> produce raw files in a truly open standard format. Unfortunately even <br>> DNG is not truly open. While Adobe have published the specification <br>> there is no open process for developing it. DNG is owned and controlled <br>> by Adobe.<br>> <br>> Andrew<br>> <br>> <br>> ------------------------------<br>> <br>> Message: 7<br>> Date: Sat, 21 Jan 2012 16:08:28 -0800<br>> From: Bryce Schober <bryce.schober@gmail.com><br>> To: digikam-users@kde.org<br>> Subject: [Digikam-users] 2.5 windows build broken for me<br>> Message-ID:<br>>         <CAJpxd07Mo+j0af_7TWaWbRnL5P5ezs4jm0Q2tZNxj8xDKB3DPw@mail.gmail.com><br>> Content-Type: text/plain; charset="iso-8859-1"<br>> <br>> I installed the 2.5.0 windows build, but it doesn't show any of my photos,<br>> and crashes a lot. One of the crashes I tried to get the stackdump, but the<br>> crash handler just locked up.<br>> <br>> What can I do to help track down this problem? It seems like others are<br>> having similar issues with the 2.5 build.<br>> <br>> <><  <><  <><<br>> Bryce Schober<br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20120121/79d099a7/attachment-0001.html><br>> <br>> ------------------------------<br>> <br>> _______________________________________________<br>> Digikam-users mailing list<br>> Digikam-users@kde.org<br>> https://mail.kde.org/mailman/listinfo/digikam-users<br>> <br>> <br>> End of Digikam-users Digest, Vol 80, Issue 50<br>> *********************************************<br></div>                                       </div></body>
</html>