| T O P I C R E V I E W |
| quantuz |
Posted - Oct 13 2014 : 12:32:00
Hi,
I have some low memory resource problem unhandled exception when loading camera raw using dcrawlib.dll
I load about 5 5000x4000 .cr2 images at the same time, when I get to the fifth image the XE debugger just suddenly exit my application and Im back at the XE editor enviroment, like I made a program reset.
I'm running XE2 IE 5.1 C-builder with the following code
aviIEIO_->AttachedIEBitmap = myiEBitmapPtr;
aviIEIO_->Params->RAW_ExtraParams = "-w -4 -o 1 -W";
aviIEIO_->LoadFromFile(myimage.cr2);
Is there a missing error handeling in the IE code? A assert or throw without a destination?
It works fine when I load same images as TIFF.
Best regards,
//Christer |
| 20 L A T E S T R E P L I E S (Newest First) |
| Uwe |
Posted - Nov 11 2014 : 09:04:22
I'll put together a little demo.
-Uwe |
| xequte |
Posted - Nov 11 2014 : 02:44:29
Hi Uwe
I am not seeing the same result as you. When I run my variation of Christer's demo that builds an in-memory array of Raw images it crashes after a certain number of images. I get the same result with my own CR2 files.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
| Uwe |
Posted - Nov 10 2014 : 18:43:02
Hi Nigel
quote:
...the crash is due to DCRAW no longer being able to allocate a contigiuous block of memory. When it cannot do this it crashes.
But then I have to ask again: why do certain CR2 files like Christers' crash DCRAW at the first attempt to open them, while the vast majority of CR2 images out there don't? There must be more to it than a faulty memory allocation.
-Uwe
|
| xequte |
Posted - Nov 10 2014 : 18:20:30
OK, from our investigation, the crash is due to DCRAW no longer being able to allocate a contigiuous block of memory. When it cannot do this it crashes. The failing in ImageEn is that the error is silent, but from the next release you can probe IO.Aborting, which will return True on such a failure.
This is why it does not crash with native ImageEn formats such as JPEG, which do not require contigious memory and generally have lower memory requirements.
So your options are to:
- Cache every image to disk (setting MinFileSize = 0 and Location = ieFile)
- Upgrade your application to 64bit.
Also, FYI, you can use a TImageEnMView to store your images, instead of an array which will autopmatically handle disk caching.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
| Uwe |
Posted - Nov 10 2014 : 16:24:40
Hi guys,
I asked Phil Harvey (the developer of ExifTool) to take a look at the image and he couldn't find anything obvious that is wrong with it. Baffles me, to be honest, but I thought I'd let you know.
Hope this helps
-Uwe |
| Uwe |
Posted - Nov 10 2014 : 09:29:34
Hi Nigel,
quote:
Though it will ultimately fail regardless of which parameters are used.
Which doesn't explain though why Christer's file is the only one I remember which has ever managed to kill both my program and Canon's very own DPP at the first attempt of loading it, while tens of thousands of other CR2 files (I own both the Canon 7D and 5D Mark III) open just fine.
Sorry, don't want to be a PITA. Just trying to understand what's going on here.
-Uwe |
| xequte |
Posted - Nov 09 2014 : 13:33:55
Hi Uwe
Yes, and I concur. Though it will ultimately fail regardless of which parameters are used.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
| Uwe |
Posted - Nov 07 2014 : 14:46:10
Hi Nigel
Thanks for the info.
quote:
...depending on some of the parameters I used. It does seem to be DCRAW related...
Well, isn't that what I suspected already in one of my posts above (10/31/14)?
-Uwe
|
| quantuz |
Posted - Nov 07 2014 : 13:18:36
Hi Nigel,
It is good to hear you could replicate the error, but can you apply some error handeling to catch the error insted of a crash?
Cheers,
//Christer |
| xequte |
Posted - Nov 07 2014 : 12:52:47
Hi Uwe
I converted his demo app IEMemTest to Delphi, simplified it and was able to reproduce the issue with between 10 and 30 images depending on some of the parameters I used. It does seem to be DCRAW related as using the same code to load an even larger JPEG image did not crash even with 100 images in memory.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
| Uwe |
Posted - Nov 06 2014 : 17:43:46
Nigel,
Would you mind to share under which conditions you were able to reproduce the problem? Unlike Christer and you, I can't load that image at all. Every single program crashes as soon as I try to read the file.
Thanks
-Uwe
|
| xequte |
Posted - Nov 06 2014 : 17:32:37
Hi Christer
Thanks. We have reproduced the problem and are investigating.
Nigel
Xequte Software
www.xequte.com
nigel@xequte.com
|
| Uwe |
Posted - Nov 01 2014 : 13:04:32
Christer,
Last try: can you test your demo program with two more images, please? First with the picture that was taken right before CASSIOPEJA_LIGHT_180s_1600iso_.CR2, and then with the one that was taken immediately afterwards?
Thanks
-Uwe |
| quantuz |
Posted - Nov 01 2014 : 12:17:02
Hi Uwe,
Yep have tried it on 3 different PC's Win7 and Win8, only crashes on the 8+ load try, so the image is ok as I can load it at least 8 times Before crash.
//Christer |
| Uwe |
Posted - Nov 01 2014 : 10:02:34
Hi Christer
quote:
The "Image\CASSIOPEJA_LIGHT_180s_1600iso_.CR2" dont crash the program until about the 9:th + load try so the image is NOT corupt!
I'm running out of ideas, to be honest. The sample image that you've provided is the only one out of a 500+ test suite of different camera RAW images that crashes both our programs as well as Canon's DPP. On all of my PC's and on a Win 8.1 Surface tablet. If the image isn't corrupt (I still believe it is), then there must be other factors that come into play on your system. Have you tried your demo program on another machine yet?
-Uwe |
| quantuz |
Posted - Nov 01 2014 : 02:50:32
Hi Uwe,
The "Image\CASSIOPEJA_LIGHT_180s_1600iso_.CR2" dont crash the program until about the 9:th + load try so the image is NOT corupt! I load OK the first 9 times for me. And I have played with the dcraw parameter as you can see in the source I use
aviIEIO_->Params->RAW_ExtraParams = "-w -4 -o 1 -W"; I need a raw images to process as it is mostly astronomy images my app processes, thats why its dark.
//Christer
|
| Uwe |
Posted - Oct 31 2014 : 18:34:48
Hi Christer,
As I had suspected already: it's the image that is crashing your program (and mine). If I load other RAW images from my test suite, I do not have any problems. Your application reads all images properly, increments the count by ten each time, and at some point displays the message that a file has been written to disk.
What I noticed though is that every image is displayed far too dark. Have you played with the DCRAW parameters by any chance? I'm asking because there are certain unsupported options that are able to cause a program crash. Same can happen if you call parameters in the wrong order, by the way.
-Uwe |
| quantuz |
Posted - Oct 31 2014 : 13:46:04
Hi!
Now I have build a new demo with IE 5.2 with the same crash problem when I load the .cr2 image in the /Image directory repeated number of times, it crashes for me when I load the image the 10:t time.
Just press the [Load raw] button and select the .cr2 image repeated a number of times, there is a compiled .exe in the Win32\Release\ dir.
Download link.
http://aragonsystem.com/Download/IEmemTestIE52.zip
Cheers,
//Christer |
| Uwe |
Posted - Oct 28 2014 : 11:04:31
quote:
The 32 bit hardly seems to load them at all
Would you mind to provide some sample files that don't load on your computer? I've never had problems opening files from the Canon EOS 600D/T3i or the Canon 5D Mark II with 32bit ImageEn/ dcrawlib.dll unless they were somehow corrupted. I'm really starting to wonder what you guys are doing to your files. Adding metadata in the wrong places? Damaged card reader or hard drive? Using software that messes up the internal file structure (Adobe Lightroom was suspected to do that to CR2 files for example)? A bug in your code? Or is it a bug in ImageEn after all and I was just lucky all these years? Dunno.
-Uwe |
| Fishous |
Posted - Oct 28 2014 : 09:22:24
I've also noticed some very odd behavior with CR2 files from a EOS T3i and the ImageEnView and the ImageEnMView. The 64 bit seems better, but it's still wonky.
The 32 bit hardly seems to load them at all, and the 64 ImageEnView works, but the ImageEnMView pulls in partial thumbnails, sometimes no thumbnail at all for the same files depending on how many there are. bmpFilt.pas kicks a "Not valid 256x256 Icon" exception, but oddly only once per try.
My Machine is a quad core with 8GB of ram, Win7 64 bit. I'll put together some details and start another thread. |
Search
