Images getting corrupted in Lightroom 4.2

Report · Oct 13, 2012

I have experienced this aswell. As mentioned in:

http://forums.adobe.com/message/4138626

and http://forums.adobe.com/thread/948417?tstart=0

My lightroom has after two weeks of playing with a fully working raw file corrupted it.

This is what the photo looked like originally http://500px.com/photo/14737987

As of today, I tried to reexport it with a diffrent watermark, the raw file corrupted. It exports a corrupted jpg and when I delete the .xmp metadatafile and try to import it again (same happens with it now when trying to import it to photoshop) the raw file now renders as corrupted in all software.

I have tried every possible way to reimport it, its just plain broken. If this should happen to my whole portfolio I would cry.

Report · Feb 21, 2013

Just heard from Crucial and they accept the results of the RAM tests and will replace the faulty chip under their lifetime warranty, they have even provided a 'freepost' mail label - great service from Crucial!

They want me to run more tests to determin which is the faulty chip (I have 4 x 4GB), do you have any idea how to do that via software or is it a case of taking each chip out and keep running the test again until I find a configuration that returns no errors?

Report · Feb 21, 2013

I am not an apple-boy.

Testing memory: http://macosx.com/forums/howto-faqs/299888-use-apple-hardware-test-other-diagnostics-test-hardware.h...

Memory modules should be treated in pairs (inserted, extracted, changed)

Test all (4) modules
if OK - I do not know
if FAIL - problem diagnosed
Extract 2 memory modules
1. I do not know if memory slots are color -coded, if YES pull off modules from the same color slots
2. In NOT, try 1st & 3rd - it should be a pair
Repeat test
1. if OK, send extracted to distriburor as fauly, end
2. if FAIL, extract other 2 and insert extracted in previous places
Repeat test
1. if OK, send extracted ... (2nd & 4th)
2. if FAIL send all modulest

And - maybe the problem is in dirt on contacts, so extract, clean (as lense) re-insert, repeat test.

Happy testing (not very exciting, but time-consuming)

Report · Feb 21, 2013

ChrisN45 wrote:
And - maybe the problem is in dirt on contacts, so extract, clean (as lense) re-insert, repeat test.

Indeed. - I've fixed many a ram (and every other variety of hardware-on-a-card) problem by simply re-inserting a half-dozen times (that used to be and probably still is standard practice in hardware labs, which is where I began my career - granted that was a looooooong time ago now - all software for the last x decades...). Sorry for personal comments... - bottom-line: I 2nd the notion: definitely worth trying re-insertion and/or cleaning first.

Cheers,

Rob

Report · Feb 21, 2013

CB-Images wrote:
You ask "How did the images go bad"?
I think I see what you are getting at - if Lightroom doesn't actually alter the original RAW file, it only writes data to the xmp file shouldn't my original RAW file still be intact...

Right, - the "obvious" way files are corrupted is by reading and subsequently writing them when hardware (e.g. bad ram) is failing (note: error may occur upon reading, or writing, but the writing part is a pre-requisite for the "presently being referred to" mode of failure). The other "obvious" way is if hard disk fails, since no writing required for image to become corrupt. Begs the question: what is the possibility that a proprietary raw file, never read/re-written, can become corrupt, when hard-disk is not failing? The general consensus from people like Jeff Schewe is "ain't never gonna happen". However, if it is (or seems to be) happening, curious minds like mine can't help but ask why/how... - I'm not sure I have the answer, but I certainly have the question .

Is it possible that what appears to be happening is actually not happening? Maybe. In other words, if there is some (potentially consistent) anomaly when reading a file that is good (on disk), one could erroneously conclude the file is bad, on disk. - food for thought...

PS - What usually happens before this question gets answered is:

* Hardware problem fixed, file corruption problem solved, and then "what was the question again?" (who cares) .

More food for thought: those who are vested in what they want the answer to be (or not to be), or what they think the answer should be (or shouldn't be), are sometimes blind to what the answer really may be (regardless of how smart they may otherwise be). - just ask my college astronomy teacher, or psychology professor, or... but, let's not get ahead of ourselves...

ok, I'm done, for now...

Cheers,

Rob

Report · Feb 21, 2013

Thanks Rob - I really do appreciate your comments and insight.

Things just got weirder!

I got up this morning and thought I would try a few things based on the fact that the CR2 might still be intact and its just the XMP data that is corrupt.

The first thing I tried was converting my CR2 image to a DNG file - guess what?

A perfect thumbnail appeared, I then opened this in the Develop module and was able to edit the DNG without any corruption taking place, obviously this is only the very early stages of the experiment but what it does prove, in my mind at least, is that it is as we all assumed - just the XMP data that gets corrupted.

Maybe if anyone else suffers the same problem they too could try converting their propriatory RAW file to DNG to see if that restores their RAW file too!

Can you think of any processes that can be done to test the stability of the DNG file?

Regards

Chris

Report · Feb 21, 2013

CB-Images wrote:
Can you think of any processes that can be done to test the stability of the DNG file?

Using the DNG Converter to convert a raw to DNG will put the image through error checking although the report doesn't really offer any further info in the event the raw fails to successfully convert to DNG.

It's possible (just thinking out loud) that when a file is being read into Develop, LR or ACR will cashe the raw file to make additional loads quicker. If on the read and write of the cahe something get's corrupt, it's possible that it's the cache file getting corrupted on the write to disk.

I really don't know...I do know for a fact that the ACR/LR engineers are familiar with this thread and engineers are looking into this issue. When I asked Eric about it, he gave me the answer I quaoted and then followed up with an email saying he was passing the question off to Thomas Knoll to see what he thought. No feedback from Thomas as yet (not sure he will respond).

Roab says:

"More food for thought: those who are vested in what they want the answer to be (or not to be), or what they think the answer should be (or shouldn't be), are sometimes blind to what the answer really may be (regardless of how smart they may otherwise be)".

If this was directed in my general direction, understand that I have no "want" or "should" be in this hunt...what I don't want is misinformation or FUD being spread becaue that helps nobody...nobody wants their images corrupted. Anything that can be done to eliminate corruption would be useful, right?

Report · Feb 21, 2013

Hi Jeff

Thanks for your comments and info that Adobe are monitoring the situation.

You say:

"Using the DNG Converter to convert a raw to DNG will put the image through error checking although the report doesn't really offer any further info in the event the raw fails to successfully convert to DNG."

If Lightroom doesn't read/write to the RAW file, just to the XMP file I don't understand how a previously 'uncorrupted' original RAW file can become 'corrupted'. If the original RAW has some form of corruption in it then surely this would point to hardware problems (card reader, cables, RAM, HDD etc) rather than anything Adobe or Lightroom had any control/influence over?

The only solution I can think of is if Lightroom or ACR employed some kind of 'check system' (before, during or after) the importing of the original images to confirm that the RAW files have been imported and reside on the HDD in an uncorrupted state. If some form of corruption is found then it will inform the user who could then take action i.e. either use another card reader, save to another HDD or keep the memory card and images safe until the problem has been diagnosed & rectified before importing them.

I suppose this will require a definition of 'what constitutes a corruption' to allow engineers to write a program that can check the RAW file, if indeed that is at all possible. It sounds simple in theory but may be impossible to impliment.

I hope my 'work around' of converting CR2 to DNG will be of benefit to some people, either those who experience similar problems or the Adobe engineers.

But it does raise 1 question in my mind - Is this an argument for NOT converting to DNG when importing images?

If we can convert corrupt CR2 files into DNG to remove the corruption, what would we do if we imported as DNG and then got the corruption because as I understand it the information that is contained within the XMP file on CR2 files is now stored within the DNG file. Does this mean that the process will work just one way - CR2 to DNG?

The old saying is true - The more you learn, the less you realise you actually know!

Report · Feb 22, 2013

CB-Images wrote:
I suppose this will require a definition of 'what constitutes a corruption' to allow engineers to write a program that can check the RAW file, if indeed that is at all possible. It sounds simple in theory but may be impossible to impliment.

Integrity checking codes are computed and written to DNG files, however there is no facility in Lightroom to read and verify them. They are like what's known in the biz as "write-only memory" (get it?).

It would be easy to expand the notion to include proprietary raws too, and just store the check codes in the catalog (and hopefully xmp too) instead of the raw file. Of course, this wouldn't do proprietary raw files any good either, if the codes aren't subsequently read, and checked (are you following this?).

Humans are really good at determining if raw data is corrupt (better than computers), so if user commanded Lightroom: "consider this to be the reference image for the future" it could compute check codes which could forever be used in the future to determine if image IO is correct or not.

It's a similar principle as the ecc codes in some kinds of ram, and the basis for how most forms of digital communication determine if received message is same as sent message.

In my opinion, such should be done upon import, in conjunction with a delete after import phase - i.e. once user inspects all images, and gives them his/her stamp of approval, check codes could be computed, and files could be subsequently and safely deleted from card, if user should so desire. As it stands, since Lr doesn't really know if imported images are corrupt after import, (or at any other time), it is not safe to delete from card, which is why the option is not offered, or so I assume.

If such image data integrity checking were implemented in Lightroom (and it is *NOT* very hard to do), then we would no longer have threads quite like this one, since Lightroom would know whether image data being presented was read the same as it was written the first time when approved... (and be able to inform user at first deviation)

So why hasn't Adobe implemented it? - good question. Probably the same reason so many other holes haven't been plugged that (in my opinion) should be - whatever that reason is - dunno.

Anyway, sorry for going off - this has been a pet peeve of mine for a long time...

Cheers,

Rob

Report · Feb 22, 2013

Integrity checking codes are computed and written to DNG files, however there is no facility in Lightroom to read and verify them. They are like what's known in the biz as "write-only memory" (get it?).

It would be easy to expand the notion to include proprietary raws too, and just store the check codes in the catalog (and hopefully xmp too) instead of the raw file. Of course, this wouldn't do proprietary raw files any good either, if the codes aren't subsequently read, and checked (are you following this?).

Errr - I think I follow that Rob.

If the check code were stored in the XMP files and its the XMP files that are getting corrupted then wouldn't that defeat the object?

Wouldn't it be better to store the check codes (once the images had been verified by the user) in a separate file - one that doesn't get written to again, that way they would always remain secure even if the XMP became corrupted again through hardware malfunction?

I know plenty of people like to 'knock' successful products but I really like it - I only have 1 issue with it and that is its performance, it really grinds to a halt when using the 'local adjustment' brush, I often have to wait 20 - 30 seconds for my screen to update - very, very frustrating!

Not just Adobe but plenty of other big companies seem to be very poor at communicating with customers until they have a new release and want your money but I suppose that is just a symptom of the world we have created for ourselves.

Anyhow I spent the day running checks on various RAM configurations and have identified the problem chip, it is now being packaged up and will be posted off tomorrow, so I'm running on only 8GB now. It made me think of my first computer and the days when 8MB was considered an enormous amount, how times have changed.

Well I have posted my problem, accepted help from yourself and others and I think I have contributed something useful to the pot of knowledge by proving that a corrupt CR2 file can be recovered by converting it to DNG. I hope it benefits others who might encounter similar problems in the future.

Report · Feb 22, 2013

CB-Images wrote:
Integrity checking codes are computed and written to DNG files, however there is no facility in Lightroom to read and verify them. They are like what's known in the biz as "write-only memory" (get it?).
It would be easy to expand the notion to include proprietary raws too, and just store the check codes in the catalog (and hopefully xmp too) instead of the raw file. Of course, this wouldn't do proprietary raw files any good either, if the codes aren't subsequently read, and checked (are you following this?).
Errr - I think I follow that Rob.

To help assure clarity: - things written but never read are of no value, writing them is done because DNG has specification that supports check codes, and DNG writer, well, writes them. Adobe just hasn't closed the loop / finished the job in Lightroom, by developing (and using) the software to read / evaluate them. Note: I suspect someone will correct if that statement is not 100% correct as it stands - everything I know is from experience: never seen the code, never talked to Adobe directly...

CB-Images wrote:
If the check code were stored in the XMP files and its the XMP files that are getting corrupted then wouldn't that defeat the object?

Reminder: Lightroom does not read the xmp files, it only writes them (for the purposes of this discussion I mean. (although it's true they can be read by force..., that's beside the current point). Thus corruptly written xmp files are of no consequence in Lightroom - none whatsoever (in the context currently being discussed). The settings Lr uses come from the catalog.

Wouldn't it be better to store the check codes (once the images had been verified by the user) in a separate file - one that doesn't get written to again, that way they would always remain secure even if the XMP became corrupted again through hardware malfunction?

The only purpose for having check codes in xmp is in case image was inadvertently deleted from catalog and then re-imported (or such things). In that case, xmp gets read, and Lr would do something like:

* read check codes from xmp.

* compute new check codes from raw data.

* compare computed check codes to those read from xmp.

* if same, proceed silently.

* if different, notify user and make user decide which image is the "corrupt" one, and store/overwrite the "bad" check codes. - not unlike resolving any other discrepancies in xmp metadata (take settings from catalog or those on disk...).

CB-Images wrote:
I know plenty of people like to 'knock' successful products but I really like it

I like it too. If I didn't, I wouldn't have invested thousands of hours developing plugins for it, and hundreds of hours supporting it in the forums. My criticisms are intended to be constuctive - anybody who thinks or claims otherwise is wrong. (PS - I am regularly accused of being a defender/fanboy by the bashers, whilst being accused of being a basher by the defender/fanboys - I guess that's the price of trying to remain as neutral/unbiased as possible).

CB-Images wrote:
I only have 1 issue with it and that is its performance, it really grinds to a halt when using the 'local adjustment' brush, I often have to wait 20 - 30 seconds for my screen to update - very, very frustrating!

Thankfully, I have no such performance issues.

CB-Images wrote:
Not just Adobe but plenty of other big companies seem to be very poor at communicating with customers until they have a new release and want your money but I suppose that is just a symptom of the world we have created for ourselves.

No comment.

CB-Images wrote:
Anyhow I spent the day running checks on various RAM configurations and have identified the problem chip...

Awesome! - please keep us posted when your Lr is exercised with the new ram.

CB-Images wrote:
It made me think of my first computer and the days when 8MB was considered an enormous amount, how times have changed.

One of the first computers I programmed had 8K, yes K meaning Kilo. No keyboard, no monitor - I programmed it in machine code (*not* assembly language - binary numbers only) using my thumb and a hex keypad for input. For output - an LED matrix with only one thing that could be displayed:

Absolute memory address in hex: data at that address, in hex.

(it was an industrial boiler controller. chemical cells were put in smoke stack to provide info to algorithm which solved system of simultaneous differential equations to determine optimal settings for controls... - $3/hr (shoulda taken the stock option - product / company was very successful for a time... - oh well, live and learn...).

Maybe Jeff Schewe was smart enough to accept some stock in exchange for the consulting work he's done for Adobe - dunno.

Sorry for going so far off topic.

CB-Images wrote:
a corrupt CR2 file can be recovered by converting it to DNG.

Still trying to wrap my head around that one - will consider commenting further in the future.

Dats all for now,

Rob

Report · Feb 23, 2013

So far as I am aware (a) while the DNG format has a number check codes, they cover only specific areas (the raw data, the original file if present, and the preview settings), not the whole file, and not the metadata. But (b) LR does check at least some of these; I've seen it flag up changes to raw data.

Sandy

Report · Feb 23, 2013

Thanks Sandy - I stand corrected: after testing it is clear, Lr does detect raw data corruption of DNG files. Now all we need is:

* the same technology employed for proprietary raw & rgb files, which do not enjoy the same benefit.

* an option to have integrity codes checked upon startup and/or shutdown and/or on demand and/or automatically in the background, etc..., so we don't have to wait until image is to be edited or exported to find out it is afu.

PS - point well taken that the check codes are not comprehensive, still - some of the most important bits are covered.

Cheers,

Rob

Report · Feb 22, 2013

Hi Chris,

CB-Images wrote:
Thanks Rob - I really do appreciate your comments and insight.

You're welcome .

CB-Images wrote:
Things just got weirder!

They often do .

CB-Images wrote:
I got up this morning and thought I would try a few things based on the fact that the CR2 might still be intact and its just the XMP data that is corrupt.
The first thing I tried was converting my CR2 image to a DNG file - guess what?
A perfect thumbnail appeared, I then opened this in the Develop module and was able to edit the DNG without any corruption taking place, obviously this is only the very early stages of the experiment but what it does prove, in my mind at least, is that it is as we all assumed - just the XMP data that gets corrupted.

So, if raw file was corrupt on disk before, it's the flavor of corruption that is tresholdy (may be read ok one time, and then not ok the next). It is probably more likely that the file was never corrupt on disk, like we (or I) once thought. Begging the question: why did it appear to be corrupt on disk, if it was not? - I dunno. If Jeff Schewe's theory is correct, that there is some ram caching of raw files, even in a read-only environment (he said he did not know if this was the case, and neither do I - I had previously assumed: not), that could explain it, but at this point, nobody (in this forum) knows...

One thing to note however, Lr doesn't care a whit what's been written to xmp. It neither knows nor cares if it wrote it correctly, and doesn't use it when rendering the raw next time around, so corrupt xmp file can happen due to hardware failure, if xmp is being saved, but that won't affect Lightroom, unless Photoshop (or other external app) was the one who wrote it (and/or Lr/user opted for attempting to read said xmp file afterward). Conversely, Photoshop (or other external app) might have a problem if Lr wrote a bum xmp file, since that's how Photoshop gets it's edit info from Lightroom. However, in either case, the result would be an error or wonky settings, *not* stripes n' rectangles.

Conclusion: previously apparent corruption came from reading, not writing, the raw file (disclaimer: that statment is subject to the above mentioned caveats).

PS - Ever since I corrected an Adobe employee who misspelled my name, I noticed a marked increase in how often Jeff Schewe misspells my name. Hmm... - probably just a coincidence...

Rob

Report · Feb 23, 2013

CB-Images wrote:
Can you think of any processes that can be done to test the stability of the DNG file?

Chris, - in case this wasn't apparent from recent posts - all you have to do is try and edit a DNG file in Lr's develop module - upon loading, the integrity check codes that cover the raw data are checked, and a banner will appear on the image if wonky. As Sandy pointed out, it may not catch 100% of problems, but it will catch most of them.

I wish the same were true of proprietary raw formats like CR2/NEF (and rgb) - I'm pretty sure it would be trivial to do (only difference I can think of is where the check codes are stored).

Rob

Report · Feb 24, 2013

Yes I can edit the DNG without any corruption being shown and the image can be sent to Photoshop for further processing and blending without issue too.

Well my knowledge of the inner workings of Lightroom is very minimal and I will leave it to others to work out what is actually occuring but all I will say is that after being imported and processed without any problems whatsoever 1 (one) image suddenly showed up as corrupted in the Lightroom Library module, this occured as the all the thumbnails appeared to be redrawing/updating themselves with corrections I had made the previous day and was not due to any intervention by myself at the time. I was just scrolling through my library when suddenly the thumnail changed from being OK/normal to the image I uploaded in a previous post (corrupted).

Subsequently and thanks to assistance from yourself and others I managed to confirm that I had a single 4GB RAM chip that was reportedly showing errors when checked by Rember. This was one of 4 x 4GB chips I had installed in my iMac.

When I converted my corrupt RAW file from CR2 to DNG the DNG file opened and did not show any corruption, this has subsequently been processed in Lightroom, then opened in Photoshop without showing any signs of corruption - to date!

Report · Feb 24, 2013

CB-Images wrote:
When I converted my corrupt RAW file from CR2 to DNG, the DNG file opened and did not show any corruption...

I'm still not sure about this part - hard to imagine humpty dumpty being put back together again... - must not have been very corrupt, whatever that means...

In any case, please let us know how you fare, e.g. after you get some miles on the new ram...

Thanks,

Rob

Report · Feb 25, 2013

Another note on ram-based image corruption (or apparent corruption).

Although we tend to think of image files as being read from the disk each time, they are *NOT* always. Modern operating systems make huge use of ram for caching disk data, even if the apps accessing them are completely unaware. No doubt the integrity of file data accessed depends on reliable ram as well as disk.

This could explain the phenomenon of a (seemingly) "corrupt" image file being readily convertible to a non-corrupt DNG - in one case, it was being re-read from corrupt ram, and in another case, it had been refreshed from disk (where it was not actually corrupt), into a different part of (good) ram (or something like that).

Thus, a previous statement I made: "one can assess whether a file is corrupt on disk by attempting to process it with more than one raw-rendering app" may have been less than 100% correct. i.e. all apps may be reading the same copy from ram via the OS. Thus, such validation would be more conclusive after rebooting OS (still not 100% conclusive if other hardware/ram is failing, but certainly more conclusive).

UPDATE: I don't understand the details of modern OS's disk caching well enough to chase this down all the way, but I do understand enough to question what's happening at the lower levels if what's happening seems to make no sense at the upper levels. In this vain, modern OS's are also vigilent about keeping disk fragmentation to a minimum even during normal use. Although I would expect one would need to write a file (in it's entirety, or last block when appending, not when updating via random access, e.g. catalog, or embedded xmp when pad remains) in order to have it's pieces consolidated on disk by OS, I'm not sure about it - it could be that the OS will take liberty, in circumstances I am not aware of, to relocate some or all of a file to keep disk structure efficient (I don't think so, because disk-defragmentation software still exists, despite being less necessary today than yester-year), and if so, the integrity of such would depend also on ram.

R

Message was edited by: Rob Cole

Adobe Community

Images getting corrupted in Lightroom 4.2