RawLAB - Raw File loader with GUI (2023-03-21)

[wildeskraut]

30 minutes ago, toe_head2001 said:

@wildeskraut

I was able to load your image without any issues.

 

 

Please make sure you install 'Adobe DNG Converter' as the instructions say in the first post.

I already installed it, but I will re-do everything.
Furthermore: I can open the sample CR3 which is provided in the installing instructions. That is a little confusing IMHO.

Edited July 8, 2021 by wildeskraut

[wildeskraut]

39 minutes ago, toe_head2001 said:

@wildeskraut

I was able to load your image without any issues.

 

 

Please make sure you install 'Adobe DNG Converter' as the instructions say in the first post.

 

I found the problem: I am unable to open it directly from a folder which syncs with Nextcloud. If I copy the same file to my "Desktop" or any other folder, I am able to open it.

[operamint]

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.

[Rick Brewster]

@operamint, why is your code using reflection on the Stream it's given? That's strictly not allowed for plugins. You need to remove that sort of thing from your plugin ASAP, otherwise I'll have to block it.

 

[Rick Brewster]

I have edited the first post in this thread to remove the download links. 

 

DO NOT USE REFLECTION TO ACCESS THE INNER STREAM. You knew about this, yet you kept doing it anyway. Your plugin will be blocked in the app as well, up through version 1.0.5.2.

 

You will need to provide an update that does not do this.

[operamint]

> 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.

 

[Rick Brewster]

Don't use reflection, end of story. This is not open for debate. The rules are crystal clear on that. Not even for "fallback" paths.

[operamint]

> 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?

[operamint]

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.

Edited August 23, 2021 by operamint

[Rick Brewster]

The file name isn't provided because there's no contractual guarantee that the Stream is even for a file in the first place. It could be coming from an in-memory cache, or a file that's being decompressed on-the-fly, or a network location, etc.

 

If someone wants to load a 50-100MB file then they just have to pay the performance cost of having it copied into a temporary file first. I'd expect someone working with images that large to have a system capable of doing that. On a modern SSD (from the last ~10 years), 50-100MB is not a big deal at all.

[operamint]

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
}

 

Edited August 24, 2021 by operamint

[Rick Brewster]

I need to do some refactoring of the OnLoad/OnSave methods anyway. Providing the file name, but not the file path, will be a reasonable addition. It will be a nullable property, it's not guaranteed to be filled in. As long as you just need the file name for display purposes, or even just to make the temp file name match up, it should work well.

[operamint]

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.

Edited August 28, 2021 by operamint

[Rick Brewster]

12 hours ago, operamint said:

/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.

 

For the Store version, you can relaunch PDN using the paintdotnet: protocol, although that won't work with the portable version.

 

 

[skyone]

Hi, I updated Paint.Net to the last version (i.e. 4.3.7) and try to load a RAW image, but I had this error:

"This plugin is incompatible with this version of paint.net.
A mandatory update is available.

Website: h t t p s://forums.getpaint.net/topic/109057-rawfilelab-1052-raw-file-reader-with-gui-2021-08-20/ "

The link points to this pages ... I'm not able to find any update, but only the warning " Rick: Download links removed ... "

So, when an update is planned ?

Do I need to remove all files related to this plugin ?

Thanks so much for a kind reply,

Giulio

 

[Rick Brewster]

@skyone, @operamint may have decided not to publish an update 😕

[skyone]

On 1/22/2022 at 4:14 AM, Rick Brewster said:

@skyone, @operamint may have decided not to publish an update 😕

Hi Rick,

many thanks for the answer.

I'll remove this plugin and will use another.

Please don't show the message " ... a mandatory update is available ... " in the program, becouse it's misleading, and ...

in the plugin index page ( h t t p s ://forums.getpaint.net/topic/15260-plugin-index/) don't flag this plugin as "ACTIVE" becouse it's NOT !

Thanks so much for your hard work,

Giulio

 

[Rick Brewster]

Yeah I think it was just an oversight, or an optimistic labeling. I'll make sure 4.3.8 doesn't list it as having an update available in the app, and @Ego Eram Reputo can update the index.

[Ego Eram Reputo]

👍 Flagged INCOMPATIBLE for the next release of the Index.

[operamint]

Finally updated the plugin. Hope it works for you.

[Ego Eram Reputo]

3 hours ago, operamint said:

Finally updated the plugin. Hope it works for you.

 

Excellent. I'll have it resurrected and back in the Plugin Index next update.

[operamint]

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

[operamint]

Update to v1.1.1.0: A few nice changes.

[operamint]

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.

[mitchd]

Hi, I needed this plugin to open .arw files and plugin works for me but it automatically changes the picture from grayscale to colour ? What is the reason ? Is it possible to avoid that ?