# How to delete a raw file while keeping the jpeg sidecar file?



## Marsu42 (Dec 29, 2012)

I usually shoot raw (converted to dng) with a small Canon "S3" jpeg sidecar for fast thumbnail browsing and cataloging outside Lightroom. For some files, I'd like to delete the raw file to save space and just keep the small jpeg sidecar for later reference - but of course "Delete photo" always deletes the main and sidecar file together.

The added problem is that all the keywords are inside the dng and not inside the sidecar jpeg, so manually deleting the dng and re-importing just the small jpeg removes all keywords and development settings.

Is there a way to delete a raw file while keeping the jpeg sidecar file with all keywords and development settings?


----------



## Victoria Bampton (Dec 30, 2012)

You'd have to import the JPEGs separately and then use the Syncomatic plug-in I mentioned in your other thread.  http://www.lightroomqueen.com/commu...ll-keywords-amp-hierarchy&p=124681#post124681  It'll manage to keywords and other metadata, and most Develop adjustments (which will look slightly different when applied to the JPEG) and it won't be able to copy crops across.  You'd probably be better to ditch the small JPEG and export finished low res JPEGs from LR as per your other thread, if you're going to do that.


----------



## Marsu42 (Dec 30, 2012)

Victoria Bampton said:


> You'd probably be better to ditch the small JPEG and export finished low res JPEGs from LR as per your other thread, if you're going to do that.



Yes, I thought so, it's just feels a little strange to me that LR does import "sidecar" jpeg files next to dng but you cannot do anything about or with them. I guess I'm not the only one shooting both raw and jpg and wants to decide which one to keep later on instead of changing settings in the camera while shooting.


----------



## Kiwigeoff (Dec 30, 2012)

Marsu, most people don't shoot both. Most shoot raw as there really is so much more flexibility. Why would you keep a jpeg when you have the original raw to keep??


----------



## Marsu42 (Dec 30, 2012)

Kiwigeoff said:


> Marsu, most people don't shoot both



Most people I know do shoot both, because the jpeg has in-camera processing so a) you can give the jpeg to a client right away and process the raw later on and b) if the shot is mediocre or unimportant you can (or could, if LR allows for it) ditch the raw and use the straight-out-of-camera jpeg for reference saving much processing time inside LR. Unfortunately autotone of LR4 is still semi-broken and needs constant manual corrections while a sooc jpeg mostly doesn't.

I still do find the sidecar handling inside LR strange because limited (or non-existant), but I know the correct answer since LR1.0 days is "If LR doesn't have it, you don't need it" :->


----------



## Jim Wilde (Dec 30, 2012)

Why don't you import the Raw+Jpeg "pair" as separate files? That way you can decide which one to keep and delete the other.....


----------



## Marsu42 (Dec 30, 2012)

TNG said:


> Why don't you import the Raw+Jpeg "pair" as separate files? That way you can decide which one to keep and delete the other.....



That would be one solution, but not and ideal one because a) I didn't do it yet so all old shots have sidecar files, b) the db load would probably double slowing lr down and c) it is not very often that I'm deleting the raw file and keeping the (small) jpg, so the "seperate" solution would be kind of overkill - though I like to keep the small jpeg around for easy browsing outside LR.


----------



## Hal P Anderson (Dec 30, 2012)

a) You _can_ separate them retroactively: change the preference to "Treat JPEG files next to raw files as separate photos" and then Synchronize the appropriate folder(s).

b) The size of the DB has very little to do with LR's performance.

c) That does sound like overkill. But you could bring into LR only the JPEGs that you want to swap with raws.

Hal


----------



## clee01l (Dec 30, 2012)

Marsu42 said:


> That would be one solution, but not and ideal one because a) I didn't do it yet so all old shots have sidecar files, b) the db load would probably double slowing lr down and c) it is not very often that I'm deleting the raw file and keeping the (small) jpg, so the "seperate" solution would be kind of overkill - though I like to keep the small jpeg around for easy browsing outside LR.


I think Victoria gave you the solution for your existing inventory. Importing JPEGs as a separate file will solve your future dilemmas.  Separate JPEGS only take up space on your HD. There is no additional overhead in LR LR can happily manage hundreds of thousands of image files If you have 50,000 JPEGS and 50,000 RAW files or 100,000 RAW files, it makes no difference in LR Performance.  For that matter there is no noticeable difference in performance for LR to have 50,000 or 100,000 image files of any type. 
If you have a current version of your OS (you need to fill in your profile BTW) you can view the embedded JPEG in your RAW file using Explorer/Finder or the simple image viewing program applets that are supplied with your OS. You done even need the standalone JPEG from the camera.

As an aside, Why are you doing this exercise anyway?  If an image file is worth keeping, it is worth keeping the original RAW file.  If the JPEG is "good enough" then the original RAW is always the better choice to retain. If the Original RAW is not "Good Enough" to keep then neither is the JPEG.  If HD storage is an issue, then get an EHD and free up local HD space.  LR can easily manage one catalog across several volumes.  My master image inventory is ~350GB and 70% of that is on an EHD.  Perhaps 150GB are images that should be deleted, but housekeeping chores like this often take a back seat. That I never look at these images that should be culled is not important. I've got a ways to go before I fill up my 1TB EHD dedicated for images.


----------



## Marsu42 (Dec 30, 2012)

clee01l said:


> As an aside, Why are you doing this exercise anyway?  If an image file is worth keeping, it is worth keeping the original RAW file.



Thanks for the embedding idea - and fyi: The shots I downsize and/or only keep as jpeg are completely braindead shots of signs or landmarks ("I was here" with gps tag), descriptions in the zoo or text panels (for later reading), I certainly don't need a hq raw file of these.

Concerning the issue if LR slows down with 100k shots in the db vs 50k - I know some people LR keeps up, but I have to say that isn't my personal experience, esp. backing up and optimizing a larger catalog takes ages.


----------



## clee01l (Dec 30, 2012)

Marsu42 said:


> Thanks for the embedding idea - and fyi: The shots I downsize and/or only keep as jpeg are completely braindead shots of signs or landmarks ("I was here" with gps tag), descriptions in the zoo or text panels (for later reading)


"Braindead" shots probably aren't worth keeping either. I have far too many of these floating around in my inventory too and I should probably take heed of my own good advice.


----------



## Marsu42 (Dec 31, 2012)

clee01l said:


> "Braindead" shots probably aren't worth keeping either.



Which basically is saying "If Lightroom doesn't have it, you don't need it"  ... but even after dumping lots of shots some remain that I like to keep around for reference, i.e. reminding me what was broken and never to duplicate the error. But for 90% of the cases I agree, it's just that 10% that just saved me a couple of dozen mb hd space by converting raw to jpeg and using syncomatic - just because there's plenty of processing power and hd space available for purchase, imho that doesn't mean I have to waste it.


----------



## Tony Jay (Jan 1, 2013)

After reading the entire thread the advice is good.
The logic of the OP is doubtful IMO.

Tony Jay


----------



## Marsu42 (Mar 2, 2013)

Tony Jay said:


> After reading the entire thread the advice is good. The logic of the OP is doubtful IMO.



Thanks , but after some time I discovered that I'm not the only one with doubtful logic, in fact Rob Cole has even written a plugin to do just what I wanted - I guess since RC is not a regular contributor his (free ) plugins get less coverage... 

http://www.robcole.com/Rob/ProductsAndServices/RawPlusJpegLrPlugin/


----------



## Jim Wilde (Mar 2, 2013)

That's a little misleading....Rob's plug-in is designed to simply find associated Raw and Jpeg pairs, with some added options such as *delete the Jpeg*. Rob can be a little cavalier at times, but I doubt even he would develop a plug-in with the express intention of finding and deleting Raw files.....however, if you are able to use it to do what you want then good luck to you.


----------



## clee01l (Mar 2, 2013)

Marsu42 said:


> Thanks , but after some time I discovered that I'm not the only one with doubtful logic, in fact Rob Cole has even written a plugin to do just what I wanted - I guess since RC is not a regular contributor his (free ) plugins get less coverage...


Actually, you first sentence is the correct one. "I'm not the only one with doubtful logic, in fact Rob Cole..."  Rob Cole uses unorthodox methods in his plugins that sometimes do not honor the LR API and sometimes take liberties with the LR database that have the potential of corrupting a users catalog file in a future version release of LR.


----------



## Marsu42 (Mar 3, 2013)

clee01l said:


> Actually, you first sentence is the correct one. "I'm not the only one with doubtful logic, in fact Rob Cole..."



 I still don't quite understand because imho there's no logic involved at all, it's just something I want to do to save disk space, you can either understand my priority or not. But that's really beside the point anyway, I originally posted here again to let fellow users wanting the same thing know there's a better (and free) solution to the problem than the export+syncomatic approach.



TNG said:


> Rob can be a little cavalier at times



So it's no coincidence his plugins are seldom mentioned? Surely it cannot be because his plugins are free and often duplicate or supersede the features of the commercial competition :-o ?



clee01l said:


> Rob Cole uses unorthodox methods in his plugins that sometimes do not honor the LR API and sometimes take liberties with the LR database that have the potential of corrupting a users catalog file in a future version release of LR.



What plugins are these, or could you please point me to the discussion threads? I'm using DevMeta and ExifMeta that enable me to do things I otherwise couldn't, so if you say (some of) his plugins corrupt the db I'd like to read more about it.


----------



## Jim Wilde (Mar 3, 2013)

Marsu42 said:


> So it's no coincidence his plugins are seldom mentioned? Surely it cannot be because his plugins are free and often duplicate or supersede the features of the commercial competition



You can infer whatever you like. I will generally only recommend plug-ins that I use myself or which I know other members of our team use. Read into that what you will.


----------



## Victoria Bampton (Mar 3, 2013)

Marsu42 said:


> So it's no coincidence his plugins are seldom mentioned? Surely it cannot be because his plugins are free and often duplicate or supersede the features of the commercial competition :-o ?



Nooooooo, nothing like that.  

Rob's plug-ins tend to be for geekier users :blush: with limited documentation.  Many come with the words "untested, but should work" which is a little too vague for us to recommend to many users.  Many of his plug-ins are very inventive, but when you push the limits quite so far, someone's liable to get hurt.

He's also walking a fine line, for example, during the LR4 beta period he created a plug-in which was in direct opposition to Adobe's "please don't try to upgrade your working catalogs" warning.  

So it's nothing personal against Rob, and we do recommend his plug-ins from time to time in very specific circumstances, but we have to be careful in what we recommend.

Plus he's written so many, it's difficult to remember what they all do!  I do wish he'd rearrange them into groups of similar plug-ins, and get rid of the awful brown website background that makes it hard to read!


----------



## Marsu42 (Mar 3, 2013)

TNG said:


> I will generally only recommend plug-ins that I use myself or which I know other members of our team use. Read into that what you will.



It's good to know that - because another generally accepted method is also to mention products (software or otherwise) that exist but are not tested. That why I was so surprised to find RC's plugin that does exactly what I want and the experts didn't give a hint/know about it.




Victoria Bampton said:


> Nooooooo, nothing like that.
> So it's nothing personal against Rob, and we do recommend his plug-ins from time to time in very specific circumstances, but we have to be careful in what we recommend.
> 
> Plus he's written so many, it's difficult to remember what they all do!  I do wish he'd rearrange them into groups of similar plug-ins, and get rid of the awful brown website background that makes it hard to read!



Thanks, I can understand that, the "geeky" as wall as the "many plugins" part  ... but I once did a feature/bug request on ExifMeta and he was very nice and responsive, so I think it's great he's releasing all these plugins for free that are too out of mainstream for Adobe.


----------

