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.

Reuploaded 1.040 only added a link on the About page to an old but good tutorial on DCRAW.

I uploaded a new version that fixes the problem. I "updated" the "cheat" to get hold of the filename of the input stream, otherwise the "Reopen" feature will do nothing as the plugin does not know the name of the input file (admittedly not vital as it can be reopened from Pdn). However, if/when the cheat no longer works, it fallbacks to use "copy-stream-to-tempfile-and-load-it", so the plugin will still work fine. It will still function with older Pdn versions as well. As for .CR3 support, I am afraid we have to wait until someone adds support for that in dcraw or any other tool that can easily be called by the plugin.

Updated to v1.0.3.3. See first post. If you are using RAW files, please try it out and leave a comment.

Updated to v1.032. Dialog window is closed when Paint.net is closed.

Added source code for this plugin. Includes both the plugin dll and the dialog window projects in one solution.

Updated to v1.031, fixes some locale bugs with decimal separators.

I've added a new GUI tool, RAWFile LAB, which plays nicely along with the RAWFile import plugin. Enjoy.

RAW file importer plugin for Paint.NET based on LibRaw (dcraw_emu.exe) Features User can optionally adjust all input settings supported by DcRaw in the GUI, and reload image with modified DcRaw settings. Displays raw image metadata for the last raw image loaded into Paint.NET Non-intrusive: GUI can optionally be started minimized Supports 35 raw file extensions: .3fr, .arw, .bay, .cf2, .cr2, .cr3, .crw, .dc2, .dcr, .dng, .erf, .fff, .iiq, .k25, .kdc, .mdc, .mef, .mfw, .mos, .mrw, .nef, .nrw, .orf, .pef, .ptx, .pxn, .r3d, .raf, .raw, .rw2, .rwl, .sr2, .srf, .srw, .x3f Changes in 1.1.1.1 Fixed broken Custom multipliers in White balance settings Previous changes Updated the plugin, works with paint.net 5 Re-added Extract thumbnail option, using simple_dcraw.exe -e Displays camera type, date, ISO speed, shutter, aperture and focal length at the bottom of dialog. Reverted to display DcRaw options as default, raw file metadata in secondary tab. Removed greyed-out Reload button, and cleanup in code. Switched from original dcraw.exe to LibRaw. Supports most raw formats, including Canon .cr3 Larger metainfo window, and small load time optimization/cleanup Added "Start minimized" checkbox (on About tab), instead of remembering window state from last session. Installation RawLAB-v1.111.zip source code: RawLAB-v1.111_src.zip Unzip RawLab-v1.111.zip into the FileTypes plugin folder <my documents>\paint.net App Files\FileTypes Useful links Download | LibRaw for updates to LibRaw.

Hi, I just registered to comment on this! Rick, thanks for responding on this issue and xod for bringing it up again. I don't think this affects "only a small percentage of folks". In fact, I think this must affect a large percentage of users, the reason being: I have installed v4.0.6 (also tried v4.0.5) on at least 5 different PCs, some Windows 7, and some Windows 10. All have this issue! I wonder if this is a locale specific bug, as I live in Norway. The PC at work has English Windows 7 (but uses norwegian locale), the rest have Norwegian versions installed. For me, this is so annoying that I use v3.5.11 - the last version where window positions sticks. Thank you for an otherwise fantastic software! /edit: ps: Maximised main window does stick in v4.0.x, but that's it.