| Author |
 Topic  |
|
quantuz
Sweden
55 Posts |
 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
284 Posts |
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
Sweden
55 Posts |
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
284 Posts |
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
Sweden
55 Posts |
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
284 Posts |
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 |
|
|
|
xequte
39142 Posts |
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
284 Posts |
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
39142 Posts |
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
|
|
|
|
quantuz
Sweden
55 Posts |
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 |
|
|
|
Uwe
284 Posts |
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
|
|
|
|
xequte
39142 Posts |
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
284 Posts |
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 |
|
|
|
Uwe
284 Posts |
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 |
|
|
|
xequte
39142 Posts |
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
284 Posts |
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
39142 Posts |
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
284 Posts |
Posted - Nov 11 2014 : 09:04:22
|
I'll put together a little demo.
-Uwe |
|
|
|
Topic |
|
Search
LoadFromFile dcrawlib problem
