operamint

You are welcome. Good to hear it works well. Near 500 downloads on this version and no complaints so far is always a good sign!

I don't think raw images are stored as greyscale in cameras, as nearly all camera image sensors capture colors by design. Greyscale is a post processing thing. This plugin can adjust brightness and compute exact colors from white balance / colorspace settings using the HDR raw data directly, though.

Update to v1.1.1.1 Fixed broken Custom multipliers in White balance settings Sorry about the frequent updates, hopefully last one for a while.

Update to v1.1.1.0: A few nice changes.

Minor update v1.1.0.1, larger metadata info, small load time optimization,

Finally updated the plugin. Hope it works for you.

Sorry for the late reply. The filename would help a lot, and I would reupload my plugin. Still, by missing the path I will have to remove the "Reopen" button, which reopens Pdn with the last opened raw image. This is quite convenient when multiple images are open in Pdn, and the plugin GUI is not in sync with the displayed image. Not a deal breaker though. /Add: Tbh, the Reopen feature is not safe, as it just uses default path to Pdn. I suppose I could look it up from a registry key, but then there is the Windows Store version as well, so this should be removed for now anyway.

Thanks for replying, Rick. Appreciated. Yes I agree with your last section - the copy cost isn't that bad, and it actually takes a rather small fraction of time compared to the unpacking of the raw file. Regarding the file name, as I mentioned it is a rather important feature for my plugin. A static function string Pdn.Document.GetFileStreamName(Stream input) would return null when there is no file name associated. Much the same as the common construct: if (input is FileStream fs) LoadFile(fs.Name); else LoadStream(input); - it's just that this always returns null on your special Stream /Add: working implementation using reflection public static string /*Pdn.Document.*/GetFileStreamName(Stream input) { // Is it a regular FileStream? if (input is FileStream fs1) return fs1.Name; // Is it a Pdn FileStream? FieldInfo fi = input.GetType().GetField("innerStream", BindingFlags.NonPublic | BindingFlags.Instance); if (fi != null && fi.GetValue(input) is FileStream fs) return fs.Name; return null; // not a FileStream }

Another, and the most severe consequence of not knowing the file name that is loaded, is that the GUI cannot display the file name. This is important for the plugin because it only shows the info about the last loaded raw file, and not the last file loaded currently displayed file in PDN. This renders the plugin far less useful and rather awkward. /ADD: I am not even sure it's worth uploading the new version without the file name information. It does provide some value for experimenting, but gets very confusing when switching between images in PDN. You may also not use the "Reload" (file with new dcraw parameters) button anymore. It's unfortunate, as the updated version now uses dcraw_emu from libraw which support Canon .CR3 natively, and the GUI shows more detailed raw metadata than previously.

> This is not open for debate I don't argue for using reflection. The source of the problem, which you may be aware of, is that to my limited knowledge the API for a FileType plugins does not provide a method for getting the file name it is reading. Many preprocessing tools does not provide an input stream interface, but file only (e.g. dcraw and dcraw_emu - however they do have stream output). So when you want to preprocess the input stream, it must first be copied to a temporary file and deleted after, which is cumbersome and inefficient when loading a 50 - 100MB raw file. Any technical reasons for leaving out this piece of information from the API?

> You knew about this, yet you kept doing it anyway FYI: No, the plugin did not RELY on that code to work. My understanding was that the intention of this rule was to prevent that plugins suddenly stopped working because of unofficial API usage. I respected that and made an automatic fallback that worked without reflection (slower), and would ensure that the plugin continued to work should there be any internal changes to this private API. There may be other reasons for not allowing using reflection at all (e.g. security), and I would not have used that code if I knew. If your intention is to reduce the number of contributors to your project, you are doing a good job. I already made a functional update of the plugin and removed the reflection code, so I'll post it and leave it at that.

Uploaded v1.0.5.2 Fix to allow opening CR3 and GPR files from read-only folders (via DNG Converter). Should fix the problem reported by wildeskraut. dcraw.exe now included - simplifies installation Added back source code! Sorry for my outburst last year, had a bad day probably.

@Ego Eram Reputo: Probably not the way you meant it, but is this the way you solve support questions? Just pointing people to use any old inferior similar plugin instead, rather than trying to resolve the problem? In fact, there are several things that is somewhat provoking in this forum. A total of 250kb is allowed to be uploaded in a dedicated plugin upload forum, including in-post images - seriously? In my case it results in that I am not able to upload dcraw, making it "half" a plugin, and users must chase for the rest elsewhere. I could possibly ask/beg for more space, but that is not my point. The plugin always seems to be low down in the plugin list, also after updates - not much point in doing so if nobody sees it. Finally, for your reference, RawFileLAB is technically superior in every way compared to that list of raw input plugins you referred to, even when removing the GUI component (which you can): it streams the data directly to DCRAW, whereas others first copy the input file and then loads it, making them much slower. it links to a version of DCRAW which is nearly twice as fast as the exe others have included the their plugin. it supports nearly twice as many raw file extensions as others, including extensions not supported by DCRAW, via use of DNG converter. I was inclined to take down the plugin, as I made initially for my own usage anyway, but I will leave it as some users actually appreciate it.

If you tried to open a SONY .SRF file, RawFileLAB 1.0.5.1 now supports that, I simply had not registered that extension in the plugin. SONY .ARW and .SR2 should work fine with older versions, though. It is highly recommended to upgrade for everyone, because v1.0.5.1 added support for 12 new file extensions, including a fix for the newest Adobe DNG Converter which is required for Canon .CR3 and GoPro .GPR files.

Uploaded v1.050, which adds support for direct loading of Canon CR3 files when free Adobe DNG Converter is installed.