Bug 444280 - Opening raw file in image editor crashes digiKam if output color space is Raw Profile (Windows OS only)
Summary: Opening raw file in image editor crashes digiKam if output color space is Raw...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-RAW (show other bugs)
Version: 7.5.0
Platform: Microsoft Windows Microsoft Windows
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-23 16:28 UTC by frizzo
Modified: 2022-01-16 15:07 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.6.0
Sentry Crash Report:


Attachments
output of DebugView64 (91.99 KB, text/plain)
2021-10-24 07:43 UTC, frizzo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description frizzo 2021-10-23 16:28:03 UTC
SUMMARY
Opening a Sony raw file .arw in image editor crashes digiKam V7.3.0
seems to happen with any .arw file. I tried several, all from Camera Model a7RM3 (ILCE-7RM3.
tiff and jpg files however can be edited.

STEPS TO REPRODUCE
1. select .arw file in thumbnail view
2. open image editor via GUI button or menu open (F4)
3. 

OBSERVED RESULT
image editor window opens, load bar shows 0%
application closes after a few seconds without any output.
no crash log is written.


EXPECTED RESULT
arw image can be modified in image editor


SOFTWARE/OS VERSIONS
Windows: 19043.1288

ADDITIONAL INFORMATION
Comment 1 Maik Qualmann 2021-10-23 18:00:54 UTC
With a test sample of this Sony camera from the web, I can neither reproduce a problem under Linux nor under a Windows10 or Windows11 VM.
We may need a test image with which the problem occurs and a DebugView log with an active debug environment variable, as described here for Windows:

https://www.digikam.org/contribute/

Maik
Comment 2 frizzo 2021-10-23 18:39:20 UTC
(In reply to Maik Qualmann from comment #1)
> With a test sample of this Sony camera from the web, I can neither reproduce
> a problem under Linux nor under a Windows10 or Windows11 VM.
> We may need a test image with which the problem occurs and a DebugView log
> with an active debug environment variable, as described here for Windows:
> 
> https://www.digikam.org/contribute/
> 
> Maik

Thanks for your swift response! I will provide a test image and the debug log.
Comment 3 frizzo 2021-10-23 20:33:12 UTC
(In reply to Maik Qualmann from comment #1)
> With a test sample of this Sony camera from the web, I can neither reproduce
> a problem under Linux nor under a Windows10 or Windows11 VM.
> We may need a test image with which the problem occurs and a DebugView log
> with an active debug environment variable, as described here for Windows:
> 
> https://www.digikam.org/contribute/
> 
> Maik

Hi Maik

I have some issues with getting the drmingw debugger to fly, keep trying. In the meantime: Can you send me the web link of your test image. I will try to reproduce the crash on my end with that image.
FRizzo
Comment 4 Maik Qualmann 2021-10-23 20:47:44 UTC
I tested it with this web sample: 

https://www.imaging-resource.com/PRODS/sony-a7r-iii/Y-35MM-DSC01650.ARW.HTM

Download DebugView from Microsoft, we may already find an answer in our debug logs (Debug environment variable must be set in the Windows environment editor). The debugger is not yet necessary.

Maik
Comment 5 frizzo 2021-10-23 21:10:39 UTC
Mi Maik

I tested with your image and digKam also crashed. So this suggests an installation specific issue on my end. I will install the DebugView tomorrow and send the log.

Your image is an uncompressed ARW (85 MB). My test images were compressed ARW (42 MB). But that does not make a difference, obviously.

BTW: Kudos for your short response times! Much appreciated. You should ask for a raise :-)

Good night for now.
FRizzo
Comment 6 frizzo 2021-10-24 07:43:12 UTC
Created attachment 142811 [details]
output of DebugView64

Hi Maik

I have attached DebugView64 output X99Pro-1.log. At the end I appended the entry from the Windows Event Viewer Application log.

As image I used your sample.

FYI:
- For whatever reason after the first run of DebugView64 on my machine I had to run it as Admin. Otherwise it would not log anything, even after a reboot.
- I have set QT_LOGGING_RULES=digikam*=true in the environment of the user running digiKam but not in the Admin's environment
- debug log line 584: 00000548	28.54960060	[19228] QLayout: Attempting to add QLayout "" to QWidget "", which already has a layout	

Greetings
FRizzo
Comment 7 Maik Qualmann 2021-10-24 08:22:04 UTC
I see some messages that do not come from digiKam, but seem to interact with digiKam:

----------------------------------------
COsInterface::SetApp: set Instance = 0x4b1c (19228), AppID = 0, Name = digikam()	
SystemState::SetForegroundApp - set foreground instance: [19228]	
Front app (foreground) is now digikam qt5152qwindowicon	
COsInterface::SetApp: Switching apps to digikam (19228)	
C:\Program Files\digiKam\digikam.exe
----------------------------------------

At the moment I cannot assign the messages to a program, I can find the same messages on the web about problem logs for the Krita program.
Can it be an anti-virus program?

Maik
Comment 8 frizzo 2021-10-24 08:31:09 UTC
(In reply to Maik Qualmann from comment #7)

Krita does not ring a bell and is not installed. 
Antivirus: I just have Windows Defender on this machine. 
I could post a second log of opening a tiff file which works for comparison. Would that be helpful?

FRizzo
Comment 9 Maik Qualmann 2021-10-24 08:49:02 UTC
No, logging a TIFF file does not help. I see the messages for the first time in a DebugView log that was sent to us. You have a program that "monitors" or "accompanies" the digiKam process. Was digiKam started via the icon or from a "program"? I can see, compared to my log, that it is probably crashing in LibRaw.

Maik
Comment 10 frizzo 2021-10-24 08:53:15 UTC
I started it with the icon pointing to "C:\Program Files\digiKam\digikam.exe"

FRizzo
Comment 11 Maik Qualmann 2021-10-24 10:05:04 UTC
Do you have a Wacom tablet? The reports could come from Wacom and would then be uncritical.

Maik
Comment 12 frizzo 2021-10-24 15:34:47 UTC
(In reply to Maik Qualmann from comment #11)
> Do you have a Wacom tablet? The reports could come from Wacom and would then
> be uncritical.
> 
> Maik

Yes, I have a tablet connected.
FRizzo
Comment 13 frizzo 2021-10-24 16:02:59 UTC
(In reply to Maik Qualmann from comment #9)
> No, logging a TIFF file does not help. I see the messages for the first time
> in a DebugView log that was sent to us. You have a program that "monitors"
> or "accompanies" the digiKam process. Was digiKam started via the icon or
> from a "program"? I can see, compared to my log, that it is probably
> crashing in LibRaw.
> 
> Maik

I have been playing around with Sysinternals process monitor, fishing in the dark:
Just before the WerFault.exe error handler is called a QueryNameInformationFile for \Program Files\digiKam\libMagickCore-7.Q16HDRI-6.dll is done.

Description:	
Company:	
Name:	digikam.exe
Version:	
Path:	C:\Program Files\digiKam\digikam.exe
Command Line:	"C:\Program Files\digiKam\digikam.exe" 
PID:	11260
Parent PID:	8808
Session ID:	1
User:	X99PRO\FritzR
Auth ID:	00000000:00046160
Architecture:	64-bit
Virtualized:	False
Integrity:	Medium
Started:	24.10.2021 11:22:33
Ended:	24.10.2021 11:23:11
Modules:
Qt5Concurrent.dll	0x80000	0x10000	C:\Program Files\digiKam\Qt5Concurrent.dll	The Qt Company Ltd.	5.15.2.0	01.01.1970 02:00:00
libopencv_imgcodecs451.dll	0x190000	0x3a000	C:\Program Files\digiKam\libopencv_imgcodecs451.dll		4.5.1	01.01.1970 02:00:00
Qt5MultimediaWidgets.dll	0x1d0000	0x1f000	C:\Program Files\digiKam\Qt5MultimediaWidgets.dll	The Qt Company Ltd.	5.15.2.0	01.01.1970 02:00:00
libssp-0.dll	0x1f0000	0xd000	C:\Program Files\digiKam\libssp-0.dll			01.01.1970 02:00:00
opengl32.dll	0xda0000	0x125000	C:\Windows\System32\opengl32.dll	Microsoft Corporation	10.0.19041.1081 (WinBuild.160101.0800)	28.02.1936 10:41:44
libopencv_ml451.dll	0x13f0000	0x8a000	C:\Program Files\digiKam\libopencv_ml451.dll		4.5.1	01.01.1970 02:00:00
Qt5Widgets.dll	0x1480000	0x5ba000	C:\Program Files\digiKam\Qt5Widgets.dll	The Qt Company Ltd.	5.15.2.0	01.01.1970 02:00:00
. . .
and a lot more

Also the C:\Program Files\digiKam\Qt5Concurrent.dll "is featured" a lot.

If useful I could upload the log (pml, csv or xml file?) But it's 40 - 120 MB depending on format. 

FRizzo
Comment 14 R Ramina 2021-11-11 17:55:01 UTC
Same issue here, using windos 64 bit version of DK 7.3 and Canon R6 and M6 cameras, CR2 and CR3 files. I also tried open CR2 files from Canon G12  and it also crashed. Note that previous versions of DK opened the CR2 files OK.
Comment 15 frizzo 2021-11-13 15:48:15 UTC
How can we proceed to pinpoint the root cause?

This is an excerpt of a C:\Users\xxxAppData\Local\CrashDumps dmp file . 

Loading unloaded module list
...................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1c14.c98): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
ntdll!NtWaitForMultipleObjects+0x14:
00007ff8`06ead8c4 c3              ret

Stack
[0x0]   ntdll!NtWaitForMultipleObjects + 0x14   
[0x1]   KERNELBASE!WaitForMultipleObjectsEx + 0xf0   
[0x2]   KERNELBASE!WaitForMultipleObjects + 0xe   
[0x3]   kernel32!WerpReportFaultInternal + 0x58a   
[0x4]   kernel32!WerpReportFault + 0xbe   
[0x5]   KERNELBASE!UnhandledExceptionFilter + 0x3d9   
[0x6]   ntdll!RtlUserThreadStart$filt$0 + 0xa2   
[0x7]   ntdll!_C_specific_handler + 0x96   
[0x8]   ntdll!RtlpExecuteHandlerForException + 0xf   
[0x9]   ntdll!RtlDispatchException + 0x244   
[0xa]   ntdll!KiUserExceptionDispatch + 0x2e   
[0xb]   msvcrt!output_l + 0x406   
[0xc]   msvcrt!snprintf + 0x83   
[0xd]   libdigikamcore!ZN6LibRaw14convert_to_rgbEv + 0x23e   
[0xe]   libdigikamcore!ZN6LibRaw13dcraw_processEv + 0x35d   
[0xf]   libdigikamcore!ZN7Digikam11DRawDecoder7Private14loadFromLibrawERK7QStringR10QByteArrayRiS7_S7_ + 0x55e   
[0x10]   DImg_RAW_Plugin!ZN20DigikamRAWDImgPlugin13DImgRAWLoader4loadERK7QStringPN7Digikam18DImgLoaderObserverE + 0xcc   
[0x11]   libdigikamcore!ZN7Digikam4DImg4loadERK7QStringiPNS_18DImgLoaderObserverERKNS_12DRawDecodingE + 0xa1f   
[0x12]   libdigikamcore!ZN7Digikam4DImg4loadERK7QStringPNS_18DImgLoaderObserverERKNS_12DRawDecodingE + 0x17   
[0x13]   libdigikamcore!ZN7Digikam4DImgC1ERK7QStringPNS_18DImgLoaderObserverERKNS_12DRawDecodingE + 0xaa   
[0x14]   libdigikamcore!ZN7Digikam17SharedLoadingTask7executeEv + 0x4dc   
[0x15]   libdigikamcore!ZN7Digikam14LoadSaveThread3runEv + 0x16a   
[0x16]   libdigikamcore!ZN7Digikam13DynamicThread7Private3runEv + 0x30   
[0x17]   Qt5Core!ZN11QThreadPool6cancelEP9QRunnable + 0x9a   
[0x18]   Qt5Core!ZN7QThread21setTerminationEnabledEb + 0x103   
[0x19]   kernel32!BaseThreadInitThunk + 0x14   
[0x1a]   ntdll!RtlUserThreadStart + 0x21
Comment 16 Maik Qualmann 2021-11-13 20:17:01 UTC
The last digiKam function in the trace is from LibRaw::convert_to_rgb(). Just why can't I reproduce it? Processor dependent? 
If you make a backup of your database, you are welcome to test the pre-release of digiKam-7.4.0, whether the problem is reproducible. 

https://files.kde.org/digikam/

Maik
Comment 17 frizzo 2021-11-13 22:10:50 UTC
I tried digiKam-7.4.0-20211113T144931-Win64. Unfortunately it crashes too. I am still using the test image Y-35MM-DSC01650.ARW. The stack trace also looks the same.

Running on:

Processor	Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz   3.00 GHz
Installed RAM	32.0 GB
System type	64-bit operating system, x64-based processor
Pen and touch	Pen support

Microsoft Windows [Version 10.0.19043.1348]
Edition	Windows 10 Pro
Version	21H1
Installed on	‎27.‎02.‎2021
OS build	19043.1348
Experience	Windows Feature Experience Pack 120.2212.3920.0

Regarding the lack of reproducibility I can't offer any clues. If you tell me what additional HW/SW config items you need to know I will post them.

FRizzo
Comment 18 frizzo 2021-11-13 22:15:14 UTC
(In reply to R Ramina from comment #14)
> Same issue here, using windos 64 bit version of DK 7.3 and Canon R6 and M6
> cameras, CR2 and CR3 files. I also tried open CR2 files from Canon G12  and
> it also crashed. Note that previous versions of DK opened the CR2 files OK.

Can you try to open the image https://www.imaging-resource.com/PRODS/sony-a7r-iii/Y-35MM-DSC01650.ARW.HTM
Just to be sure we talk about the same cause. Thanks
 
FRizzo
Comment 19 Maik Qualmann 2021-11-16 12:25:04 UTC
I organized a somewhat older notebook with an Intel Core I5 in order to be able to test the Windows version even better in the future. A fresh Windows 10 with all updates is installed. I cannot reproduce the problem with the ARW file, nor with CR2 or CR3 RAW images.

If I look at the trace from Comment 15 and the DebugView log from Comment 6 with the missing output of pass 2, it crashes within the LibRaw function for converting to RGB.
According to my research, there have been no changes to the code in LibRaw lately.

Maik
Comment 20 frizzo 2021-11-17 09:51:25 UTC
Mike,
thanks for your effort!
I will also install digikam on a second notebook which has much less additional SW installed than my desktop. Just in case there are some side-effects very deep under the hood. 
FRizzo
Comment 21 caulier.gilles 2021-11-29 09:48:53 UTC
Hi Maik,

See this issue about libraw memory allocation limitations :

https://github.com/LibRaw/LibRaw/issues/436

Gilles
Comment 22 frizzo 2021-12-14 11:15:44 UTC
FYI: I tried the last build of v 7.4.0 as per 2021-12-11-Win64 and the  issue still persists.

FRizzo
Comment 23 caulier.gilles 2022-01-14 21:49:15 UTC
Frizzo,

Did you use Color Management i digiKam ? If yes, did you use a specific color profile to convert ARW to RGB color space ?

Best

Gilles Caulier
Comment 24 frizzo 2022-01-14 22:23:10 UTC
Gilles,
I am just opening a local copy of the test image
https://www.imaging-resource.com/PRODS/sony-a7r-iii/Y-35MM-DSC01650.ARW.HTM
without any processing. The image is in sRGB color mode.
FRizzo
Comment 25 caulier.gilles 2022-01-15 05:34:01 UTC
H Frizzo,

No problem to open the ARW file here under Windows :

https://i.imgur.com/6BpAeXJ.png

Did you use a specific settings for the demosaicing ?

Best

Gilles
Comment 26 frizzo 2022-01-15 10:02:28 UTC
Gilles,

firstly, thanks for taking your time to look into this issue. 
To answer: No special settings - that is intentionally. I installed V7.4, select the image and F4. Where should I check for special settings?

Maik couldn't reproduce the issue either. So there is some side effect between a so far unknown application on my system and digikam. I use a program FastRaw Viewer 2.0.0. It also has an instance of libraw.dll (size 2'095'592) installed, libraw-r19.dll (size 1'133'056) for digikam. The size is very different, no idea if there is a possible clash. Anyway, the crash occurs regardless of FastRawViewer is running or not. If I deinstall it I might loose a lot of settings. So I will try to reproduce the issue on my laptop first.
FRizzo
Comment 27 caulier.gilles 2022-01-15 11:08:25 UTC
Hi Frizzo,

The Raw Image Editor settings is located to Settings dialog from digiKam.

Go to Settings/Configure digiKam/ImageEditor page :

https://i.imgur.com/E4qu9nR.png

Raw Behavior tab allow to set the rules to handle RAW file with editor. By default, it open file with a full automatized processing. Change it to use Import tool based on Libraw.

Note : the page named Raw default settings list all libraw configuration used when the full automatized decoding mode is used:

https://i.imgur.com/hIROC53.png

When you open RAw file in Import tool, editor show a large view on right sidebar with all settings that you can tune to optimzed decoding before loading file :

https://i.imgur.com/bYIZ3FE.png

Now about a possible incompatibility with FastRaw Viewer 2.0.0, definitively yes. I think you don't need to uninstall FastRaw as well. Go the C:/Program Files... and rename temporally the folder containing FastRaw and the famous libraw dll. Try to re-open digiKam to see if this solve your problem. If yes, we will see how to tune PATH to prevent this conflict.

Gilles Caulier
Comment 28 frizzo 2022-01-15 17:13:41 UTC
Hi Gilles
I worked through your suggestions. 
Results:
Test 1
- closed FastRawViewer
- Renamed FastRawViewer Installattion directory from C:\Program Files\LibRaw to C:\Program Files\LibRaw-temp
- start digiKam, select image, F4 -> crash

Test 2
reboot machine
repeat test1 sequence exactly -> crash

Test 3 - now put on seatbelts :-)
- start digiKam, changed setting to force libraw based import tool, select image, F4 -> IMPORT DIALOGUE OPENS CORRECTLY
- all side panel settings like on your screenshot, except for 16bits color. Selected it and import. IMPORT OK!!
- tried some edits e.g. local contrast, noise reduction - OK
- saved as TIF image - OK
- BTW it also imports with 8bit color.

Obviously the data is processed differently via the import tool. So thanks and congratulations! We have a work-around. If I can help further in determination of the cause I am glad to.
FRizzo
Comment 29 caulier.gilles 2022-01-15 17:27:27 UTC
Ok great advancement.

So i can conclude that crash only happen when you go back to the "Setup/Editor/Raw Behavior/Fast and Simple in 8 bits". Right ?

If yes, can you also reproduce the crash when you switch to "Setup/Editor/Raw Behavior/Using Default 16 bits Settings"

If the crash is no more reproducible, perhaps the origin come from a corrupted settings stored in digiKam configuration text file.

Giles Caulier
Comment 30 caulier.gilles 2022-01-15 17:30:03 UTC
Note, here under Windows, trying to open the ARW test file with the 8 bits or the 16 bits default settings do not crash digiKam...

Best

Gilles Caulier
Comment 31 frizzo 2022-01-15 17:32:16 UTC
(In reply to caulier.gilles from comment #29)
> Ok great advancement.
> 
> So i can conclude that crash only happen when you go back to the
> "Setup/Editor/Raw Behavior/Fast and Simple in 8 bits". Right ?
> 
> If yes, can you also reproduce the crash when you switch to
> "Setup/Editor/Raw Behavior/Using Default 16 bits Settings"
> 
> If the crash is no more reproducible, perhaps the origin come from a
> corrupted settings stored in digiKam configuration text file.
> 
> Giles Caulier

Both above settings still crash.
Comment 32 caulier.gilles 2022-01-15 17:38:24 UTC
Ok, now turn on again the Setup/Editor/Raw Behavior/Use RawImport tool.

Load the ARW image in editor. Import Tool appear. On the bottom of the right sidebar, you have a button named "Use Default". If you press it, this will ignore the RawImport toll settings and go back to default settings to decode image in editor.

Q : it crash also using this button ?

Gilles
Comment 33 frizzo 2022-01-15 18:17:29 UTC
(In reply to caulier.gilles from comment #32)
> Ok, now turn on again the Setup/Editor/Raw Behavior/Use RawImport tool.
> 
> Load the ARW image in editor. Import Tool appear. On the bottom of the right
> sidebar, you have a button named "Use Default". If you press it, this will
> ignore the RawImport toll settings and go back to default settings to decode
> image in editor.
> 
> Q : it crash also using this button ?
> 
> Gilles

Yes, it crashes.
Comment 34 caulier.gilles 2022-01-15 18:20:14 UTC
Ok fine, at least it homogeneous.

Now go back to Setup/Editor/Raw Behavior/Default Settings, change 8 bits to 16 bits demosaicing. Re-open Raw Import tool with ARW file and press Use Default. It crash again ?

Gilles
Comment 35 frizzo 2022-01-15 19:27:34 UTC
(In reply to caulier.gilles from comment #34)
> Ok fine, at least it homogeneous.
> 
> Now go back to Setup/Editor/Raw Behavior/Default Settings, change 8 bits to
> 16 bits demosaicing. Re-open Raw Import tool with ARW file and press Use
> Default. It crash again ?
> 
> Gilles

Not sure I understand correctly:
When I am on RawBehaviour 8/16 bit the crash occurs.
When I am on the work-around setting in RawBehaviour - Open raw import tool the import dialogue & side panel opens.
Did you mean then 
   - to go back to Settings/RawBehaviour and change the default to 16 bit?
   - and only then press the default button in the import tool side panel?
If I do that it crashes.

In the Settings - Image Editor - Raw Default settings panel there is no choice for 8 / 16 bit color depth.
FRizzo
Comment 36 caulier.gilles 2022-01-15 21:48:08 UTC
Yes, you right, there is no 8/16 bits choice in default settings.

And yes, in the default settings view, change one parameter, as for ex the Quality which must be bilinear. Use AAHD instead for ex. Valid as well, and reload the ARW to Import Tool, and press Default settings button to see if the crash is reproducible.

Gilles
Comment 37 frizzo 2022-01-15 22:51:18 UTC
(In reply to caulier.gilles from comment #36)
> Yes, you right, there is no 8/16 bits choice in default settings.
> 
> And yes, in the default settings view, change one parameter, as for ex the
> Quality which must be bilinear. Use AAHD instead for ex. Valid as well, and
> reload the ARW to Import Tool, and press Default settings button to see if
> the crash is reproducible.
> 
> Gilles

Yes, it crashes.
Comment 38 caulier.gilles 2022-01-16 04:03:54 UTC
Can you take a screenshot of the Setup/Editor/Raw Behavior/Default Settings view, with all settings visible ? I want to know if something special is configured here.

Gilles
Comment 39 caulier.gilles 2022-01-16 04:29:34 UTC
Ok, i found the problem.

In your debug view trace we have :

-- RAW DECODING SETTINGS --------------------------------	
00000588	38.80609131	[19228] -- autoBrightness:          true	
00000589	38.80609131	[19228] -- sixteenBitsImage:        false	
00000590	38.80609131	[19228] -- brightness:              1	
00000591	38.80609131	[19228] -- RAWQuality:              0	
00000592	38.80609131	[19228] -- inputColorSpace:         0	
00000593	38.80609131	[19228] -- outputColorSpace:        0	
00000594	38.80609131	[19228] -- RGBInterpolate4Colors:   false	
00000595	38.80609131	[19228] -- DontStretchPixels:       false	
00000596	38.80609131	[19228] -- unclipColors:            0	
00000597	38.80609131	[19228] -- whiteBalance:            1	
00000598	38.80609131	[19228] -- customWhiteBalance:      6500	
00000599	38.80609131	[19228] -- customWhiteBalanceGreen: 1	
00000600	38.80609131	[19228] -- halfSizeColorImage:      false	
00000601	38.80609131	[19228] -- enableBlackPoint:        false	
00000602	38.80609131	[19228] -- blackPoint:              0	
00000603	38.80609131	[19228] -- enableWhitePoint:        false	
00000604	38.80609131	[19228] -- whitePoint:              0	
00000605	38.80609131	[19228] -- NoiseReductionType:      0	
00000606	38.80609131	[19228] -- NoiseReductionThreshold: 0	
00000607	38.80609131	[19228] -- medianFilterPasses:      0	
00000608	38.80609131	[19228] -- inputProfile:            ""	
00000609	38.80609131	[19228] -- outputProfile:           ""	
00000610	38.80609131	[19228] -- deadPixelMap:            ""	
00000611	38.80609131	[19228] -- whiteBalanceArea:        QRect(0,0 0x0)	
00000612	38.80609131	[19228] -- dcbIterations:           -1	
00000613	38.80609131	[19228] -- dcbEnhanceFl:            false	
00000614	38.80609131	[19228] -- expoCorrection:          false	
00000615	38.80609131	[19228] -- expoCorrectionShift:     0.994	
00000616	38.80609131	[19228] -- expoCorrectionHighlight: 0	
00000617	38.80609131	[19228] ---------------------------------------------------------	

The problem come from this settings : outputColorSpace:        0	

This corresponding to Import tool settings view to the ouput color space from color management section. 0 want mean "Raw (no profile)"
When i set sRGB, all is fine, when i set RAW, it crash too on my computer. 

Gilles
Comment 40 caulier.gilles 2022-01-16 04:30:33 UTC
Maik,

Can you reproduce the crash too by tuning this setting on your computer ?

Gilles
Comment 41 caulier.gilles 2022-01-16 04:53:32 UTC
Note this crash in libraw with Raw profile output is specific to Microsoft. I cannot reproduce the crash under Linux:

https://i.imgur.com/DYpjDZo.png

Gilles
Comment 42 caulier.gilles 2022-01-16 04:58:51 UTC
Under MacOS, i do not crash too:

https://i.imgur.com/PQupipP.png

Gilles
Comment 43 caulier.gilles 2022-01-16 05:25:40 UTC
As Maik said in comment #16, it crash in Libraw function LibRaw::convert_to_rgb(). The function is here in digiKam core:

https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/rawengine/libraw/src/postprocessing/postprocessing_utils_dcrdefs.cpp#L21 

This is the current implementation in libraw : 

https://github.com/LibRaw/LibRaw/blob/master/src/postprocessing/postprocessing_utils_dcrdefs.cpp#L21
Comment 44 caulier.gilles 2022-01-16 05:55:16 UTC
I downloaded this Nikon NEF file :

http://www.rawsamples.ch/raws/nikon/RAW_NIKON_D750.NEF

If i process this Raw file under Raw Import and i set outpur color space to Raw, it crash too under Windows.

Conclusion : the bug in post processing method do not depend of RAW format and is always reproducible under Windows.

Gilles
Comment 45 caulier.gilles 2022-01-16 08:24:48 UTC
Git commit 69555431a591dba46d09f1bab51dc0d9b09f517f by Gilles Caulier.
Committed on 16/01/2022 at 08:23.
Pushed by cgilles into branch 'master'.

Update Libraw to snapshoot 20220116

M  +1    -0    NEWS
M  +1    -1    core/libs/rawengine/libraw/Changelog.txt
M  +5    -0    core/libs/rawengine/libraw/libraw/libraw.h
M  +1    -1    core/libs/rawengine/libraw/src/demosaic/xtrans_demosaic.cpp
M  +9    -2    core/libs/rawengine/libraw/src/libraw_c_api.cpp
M  +1    -1    core/libs/rawengine/libraw/src/metadata/misc_parsers.cpp
M  +1    -1    core/libs/rawengine/libraw/src/utils/open.cpp

https://invent.kde.org/graphics/digikam/commit/69555431a591dba46d09f1bab51dc0d9b09f517f
Comment 46 frizzo 2022-01-16 08:38:20 UTC
(In reply to caulier.gilles from comment #39)
> Ok, i found the problem.
> 
> In your debug view trace we have :
> 
> -- RAW DECODING SETTINGS --------------------------------	
> 00000588	38.80609131	[19228] -- autoBrightness:          true	
> 00000589	38.80609131	[19228] -- sixteenBitsImage:        false	
> 00000590	38.80609131	[19228] -- brightness:              1	
> 00000591	38.80609131	[19228] -- RAWQuality:              0	
> 00000592	38.80609131	[19228] -- inputColorSpace:         0	
> 00000593	38.80609131	[19228] -- outputColorSpace:        0	
> 00000594	38.80609131	[19228] -- RGBInterpolate4Colors:   false	
> 00000595	38.80609131	[19228] -- DontStretchPixels:       false	
> 00000596	38.80609131	[19228] -- unclipColors:            0	
> 00000597	38.80609131	[19228] -- whiteBalance:            1	
> 00000598	38.80609131	[19228] -- customWhiteBalance:      6500	
> 00000599	38.80609131	[19228] -- customWhiteBalanceGreen: 1	
> 00000600	38.80609131	[19228] -- halfSizeColorImage:      false	
> 00000601	38.80609131	[19228] -- enableBlackPoint:        false	
> 00000602	38.80609131	[19228] -- blackPoint:              0	
> 00000603	38.80609131	[19228] -- enableWhitePoint:        false	
> 00000604	38.80609131	[19228] -- whitePoint:              0	
> 00000605	38.80609131	[19228] -- NoiseReductionType:      0	
> 00000606	38.80609131	[19228] -- NoiseReductionThreshold: 0	
> 00000607	38.80609131	[19228] -- medianFilterPasses:      0	
> 00000608	38.80609131	[19228] -- inputProfile:            ""	
> 00000609	38.80609131	[19228] -- outputProfile:           ""	
> 00000610	38.80609131	[19228] -- deadPixelMap:            ""	
> 00000611	38.80609131	[19228] -- whiteBalanceArea:        QRect(0,0 0x0)	
> 00000612	38.80609131	[19228] -- dcbIterations:           -1	
> 00000613	38.80609131	[19228] -- dcbEnhanceFl:            false	
> 00000614	38.80609131	[19228] -- expoCorrection:          false	
> 00000615	38.80609131	[19228] -- expoCorrectionShift:     0.994	
> 00000616	38.80609131	[19228] -- expoCorrectionHighlight: 0	
> 00000617	38.80609131	[19228]
> ---------------------------------------------------------	
> 
> The problem come from this settings : outputColorSpace:        0	
> 
> This corresponding to Import tool settings view to the ouput color space
> from color management section. 0 want mean "Raw (no profile)"
> When i set sRGB, all is fine, when i set RAW, it crash too on my computer. 
> 
> Gilles

Gilles,
Looking at the time stamps of your posts???? Did you work all night???? Anyway Kudos and thanks!! I worked in corporate IT for 30+ years and this level of support and dedication you rarely find with paid contracts. 

FRizzo
Comment 47 caulier.gilles 2022-01-16 09:21:32 UTC
>Looking at the time stamps of your posts???? Did you work all night????

Ahah. Not at all. Just my dog which want to go out and awake me. After that, it's difficult to sleep again...

I update libraw source code in digiKam core. Windows installer is under compilation. I will test with this code. If it's reproducible, i will open an UPSTREAM bug in libraw project.

Gilles
Comment 48 frizzo 2022-01-16 09:25:51 UTC
(In reply to caulier.gilles from comment #47)
> >Looking at the time stamps of your posts???? Did you work all night????
> 
> Ahah. Not at all. Just my dog which want to go out and awake me. After that,
> it's difficult to sleep again...
> 
> I update libraw source code in digiKam core. Windows installer is under
> compilation. I will test with this code. If it's reproducible, i will open
> an UPSTREAM bug in libraw project.
> 
> Gilles

Goood boy/girl dog! :-)
Just to confirm: I set raw on import side panel -> crash too! You did nail it! Thanks again!
Comment 49 caulier.gilles 2022-01-16 10:16:38 UTC
Ok, the new Windows install just compiled crash also with the last Libraw source code from github.

I open this UPSTREAM bug : https://github.com/LibRaw/LibRaw/issues/444

Gilles Caulier
Comment 50 frizzo 2022-01-16 10:39:08 UTC
(In reply to frizzo from comment #48)
> (In reply to caulier.gilles from comment #47)
> > >Looking at the time stamps of your posts???? Did you work all night????
> > 
> > Ahah. Not at all. Just my dog which want to go out and awake me. After that,
> > it's difficult to sleep again...
> > 
> > I update libraw source code in digiKam core. Windows installer is under
> > compilation. I will test with this code. If it's reproducible, i will open
> > an UPSTREAM bug in libraw project.
> > 
> > Gilles
> 
> Goood boy/girl dog! :-)
> Just to confirm: I set raw on import side panel -> crash too! You did nail
> it! Thanks again!

Now I cut myself off the tree :-) because the import panel is also crashing before I can reset to rgb. Is there an ini or config file where I can reset that?
FRizzo
Comment 51 caulier.gilles 2022-01-16 11:21:12 UTC
Git commit 6f169c9f157b585df294983a17d51d91e186d0df by Gilles Caulier.
Committed on 16/01/2022 at 11:19.
Pushed by cgilles into branch 'master'.

backport LibRaw commit https://github.com/LibRaw/LibRaw/commit/5359d2ee34054792ab33cbde4718c9d35967d080

M  +5    -5    core/libs/rawengine/libraw/src/postprocessing/postprocessing_utils_dcrdefs.cpp

https://invent.kde.org/graphics/digikam/commit/6f169c9f157b585df294983a17d51d91e186d0df
Comment 52 caulier.gilles 2022-01-16 11:31:15 UTC
Look text configuration file in C:/Users/__your_account__/AppData/Local/digikamrc.

You must find a section name "RAW Import Settings" where all configuration from this tool is stored.

Else, wait a little bit, a LibRaw fix have been backported in digiKam core to fix your problem. New Windows installer is under process...

Gilles Caulier
Comment 53 frizzo 2022-01-16 12:00:27 UTC
(In reply to caulier.gilles from comment #52)
> Look text configuration file in
> C:/Users/__your_account__/AppData/Local/digikamrc.
> 
> You must find a section name "RAW Import Settings" where all configuration
> from this tool is stored.
> 
> Else, wait a little bit, a LibRaw fix have been backported in digiKam core
> to fix your problem. New Windows installer is under process...
> 
> Gilles Caulier

Found it, fixed it:
Output Color Space=1
Comment 54 caulier.gilles 2022-01-16 13:00:19 UTC
Great. My last commit from comment #51 and backported from LibRaw fix the crash.

I close this file now.

Frizzo, you can download the last Windows installer build one hour ago with release number 7.6.0 (yes, the 7.5.0 will be release today).

https://files.kde.org/digikam/

Best

Gilles Caulier
Comment 55 frizzo 2022-01-16 14:09:39 UTC
(In reply to caulier.gilles from comment #54)
> Great. My last commit from comment #51 and backported from LibRaw fix the
> crash.
> 
> I close this file now.
> 
> Frizzo, you can download the last Windows installer build one hour ago with
> release number 7.6.0 (yes, the 7.5.0 will be release today).
> 
> https://files.kde.org/digikam/
> 
> Best
> 
> Gilles Caulier

Gilles,
thanks a lot for a wonderful application so well maintained!
FRizzo
Comment 56 frizzo 2022-01-16 15:07:43 UTC
Gilles,

There is an issue unfortunately with V 7.6.0. See https://bugs.kde.org/show_bug.cgi?id=448597

I installed the Win64 debug installer.

FRizzo