Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by midora

  1. No complains about unsafe code in plugins? 😉 I put the code in an extension method for Surfaces. Pointer operations are fast compared to for loops. If the stride is small then they are beating method calls because of the overhead. Sometimes your raster is not in BGRA order. This can be handled easily using pointers. Still I would like to avoid unsafe code at this level. So surface methods to copy from/to part of a row would be great. I.e. void CopyToRow(byte[] src, long srcOffset, int row, int column, int length); void CopyFromRow(byte[] dst, long dstOffset, int row, int column, int length); void CopyToRow(uint[] src, long srcOffset, int row, int column, int columns); void CopyFromRow(uin[] dst, long dstOffset, int row, int column, int columns); or for a whole raster void CopyToImage(byte[] src, int srcStride); void CopyFromImage(byte[] dst, int dstStride); void CopyToImage(uint[] src, int srcStride); void CopyFromImage(uint[] dst, int dstStride); Sorry that I have to use spoilers instead of code sections but I'm tired to wait that it opens here (and most of the time it fails).
  2. Assuming there is a pixel array containing all pixels of the image in BGRA top-left to bottom-right order. There are many surface methods (let's exclude the obsolete one) which may be helpful. So what's the proposed way for filetype plugins. Is unsafe code acceptable (like the following). is the surface data locked during the operation or is there the potential risk of a crash. I would prefer to use a paint.net method to copy from/to a raster but I didn't find a good method.
  3. Thanks for the effort @null54. I just found the topic about the Treatment. Then I looked for Treatment in the registry and found HKEY_CLASSES_ROOT\SystemFileAssociations\image Key: Treatment Value: 2 (means Photo Border) Then I checked the .pdn entry and found Key: PerceivedType Value: image And that's it. Setting this key to .bmrl shows the drop shadow after a restart of the FileExplorer. That's what I expected in the beginning: There must be a kind of file category marker. Now I have to figure out how do do this using the sharpshell library. Maybe I have to patch it...
  4. But this really sounds that if paint.net extends .bmp, ... with .pdn and all are getting the shadow then anything which uses CLSID_PhotoThumbnailProvider may be handled similar. Just have to understand how to do it for a try.
  5. And there is this topic which hints that paint.net uses CLSID_PhotoThumbnailProvider. I have to figure out how to use it...
  6. Maybe the issue is related to this comment: An implementation of this interface for photo thumbnails is supplied in Microsoft Windows as CLSID_PhotoThumbnailProvider. Applications that use the supplied implementation must define a constant CLSID identifier using the GUID {C7657C4A-9F68-40fa-A4DF-96BC08EB3551}.
  7. We know the documentation of these COM interfaces is limited. .NET 4.0 is needed to implement the interfaces in c#. I didn't expect that a lot of people are experienced with this. But you never know. The handler uses COM IThumbnailProvider and returns BGRA (or you couldn't see through 😉 No idea what's going on there. Just the standard image format thumbnails are showing the shadow AND .pdn. It's for sure not important but I really like to understand what's going on. In the moment the code for .bmrl draws the image a little bit higher into the bitmap just to reduce the missing shadow offset effect. This way the top line of the images in all the thumbnails is adjusted (otherwise the .bmrl thumbnails would sit a bit deeper). This seems to work for all thumbnail sizes. In the moment I'm creating a InfoTipHandler to show some properties of .bmrl files. Maybe paint.net could add one to show the dimensions of the image.
  8. Sorry the ReadMe file in the shellextensions zip was empty. Which makes it a bit difficult to install the dlls 😞 So here is a new zip WITH installation guide. bmp+bmrl.thumbnail.shellextension.zip Before installation (.bmrl already assigned to open with paint.net) After installation .bmps containing athe BMRL format are showing RL in the top left corners. And .bmrl files the image plus the associated application.
  9. The files with extension .bmp and .bmrl are using my new shell extension to create the thumbnails. The 'DropShadow bmrl.bmp' file ist just a renamed copy of the 'DropShadow.bmrl' which I saved from paint.net with the bmrl filetype plugin. This 'DropShadow bmrl.bmp' is just to show that thumbnails for files with .bmp extension but .bmrl content are showing now a thumbnail. This is not the case without the shell extension for .bmp because Windos detects these .bmp not as bitmap files. Same effect in Windows light mode. So the question is, how does Windows know that .pdn should get a drop shadow but not .bmrl (latest Windows 10).
  10. I'm wondering why the thumbnail of a .pdn file shows a drop shadow in FileExplorer icon views (or the preview panel). Typically just .bmps are showing the drop shadow and no other file types (on my Windows 10 laptop). Any idea/hint why this is the case for .pdn files? I would like to get it for .bmrl. I can not imagine that the drop shadow is part of the thumbnail. Because it uses exact the same colors as .bmps in dark and light mode. Does it depend on the type of registration?
  11. I created shell extensions to show thumbnails of .bmrl files and .bmp files (containing bmrl) in the Windows FileExplorer. (removed .zip) First time I did it in c# (based on a project on github, see readme). Astonishing that this works 😉 Maybe it would make sense to add a RL Marker to the .bmp thumbnails so that users already know that they can't be opened easily in a image processing tool.
  12. @lingfudeCould you also describe how the upload process to the device works and what tool you are using? Maybe it's not needed to rename the .bmrl file back to .bmp for upload. This would make things easier for you (and others).
  13. You should really use the project file proposed by @toe_head2001 It contains all standard references you typically need in en effect plugin. A resource file can be added via the properties of the project. There you can add icons and more. This will also create the right namespace you can reference in your source. Start the project from scratch add the required features and export it as template. Don't mix references. Use net 5.0.
  14. Easiest way may be to create a new file, change the dpi settings, save it as template and set it to readonly in the file explorer. You can then open this file as starting point for a new image.
  15. ImBMRL.FileType.dll.zipI forgot to remove the test output. It should work if you create a temporary folder TempTemp on c:/. But here is the version without the duplicate in this folder. ImBMRL.FileType.dll.zip
  16. This version of the plugin allows to save as .bmrl. There is a restriction in the amount of colors which can be handled (Not more than 251 different RGBAs in a row). The reason is that in this case a quantizer has to be called. But this a little bit special if you are working in a 16-bit 565 color space with 5-bit alpha. The source calls WuQuantizer16() to do the job. But this source is not included. If the source is available I would use this one. We may also quantize the BGRA image to 256 colors first. But not now. Typically icons are small enough that there is no issue with the code. Some png test images should be created to stress the save method.
  17. Obsolete just means you have to use an other variant and not just to remove something. EffectFlags.Configurable => new EffectOptions() { Flags = EffectFlags.Configurable }
  18. Verified 😉 Still I would prefer not to get a preview at all in this case instead a text like "No preview available". In the moment there is again the original image visible which shows transparency.
  19. OK, I replaced installed with used in the sentence above. Just if someone is confused about how a portable version can be installed.
  20. I would then start with a fresh one and add the code to this. It's much more difficult to adapt old ones.
  21. First to say, I have no experience using VS 2022 Preview but there may be no difference to VS 2019 which I'm using. You can right click your project in the SolutionExplorer and select 'Edit Project File'. Save will then adapt your dependencies. What's the content of you project file? Does it contain the following PropertyGroup? <PropertyGroup> <TargetFramework>net5.0-windows</TargetFramework> <UseWindowsForms>true</UseWindowsForms> </PropertyGroup> This will add Microsoft.WindowsDesktop.App.WindowsForms to Dependencies->FrameWorks You should also see the references to the paint.net dlls there. I.e. <ItemGroup> <Reference Include="PaintDotNet.Base"> <HintPath>..\..\..\..\Users\YOUR LOGIN NAME\Downloads\paint.net.4.300.7918.1291.portable.x64.scd.aot\PaintDotNet.Base.dll</HintPath> </Reference> <Reference Include="PaintDotNet.Core"> <HintPath>..\..\..\..\Users\YOUR LOGIN NAME\Downloads\paint.net.4.300.7918.1291.portable.x64.scd.aot\PaintDotNet.Core.dll</HintPath> </Reference> <Reference Include="PaintDotNet.Data"> <HintPath>..\..\..\..\Users\YOUR LOGIN NAME\Downloads\paint.net.4.300.7918.1291.portable.x64.scd.aot\PaintDotNet.Data.dll</HintPath> </Reference> </ItemGroup> You may change the relative references to fixed ones (to avoid problems if you are moving the project folder).
  22. OK, here is a quick shot for a .bmrl filetype supporting open. It requires paint.net 4.3.0 alpha and uses no obsolete methods 😉 As Rick mentioned the portable version of 4.3.0 can be used in parallel to the latest 4.2.16. You just can not run both at the same time. (Removed the old version of the plugin) And the example file provided by @lingfude. BMRL_example.zip
  23. Load and Save should respect the plugin associated to a file type selector in the open/save dialog box. I'm sure this has been asked before but I couldn't find it. And maybe I'm wrong and there is a misunderstanding how the things are working. In the moment the file type selector is just used to filter the view against the extensions defined in the selector. But the associated plugin is not used to execute the operation. Instead the extension determines which plugin or built-in function will be executed. This makes it difficult to add different .gif loaders or to load files with a somehow bad extension. I.e. these BMPs which are not Windows BMPs. Even if we are using a different extension like .bmrl in the selector, the selector would not be respected if we type *.bmp in the filename box and select a bmp file. Users may be confused if they are not selecting a specific file type selector in the dialog and the application uses the default loader/saver. I agree, but it also doesn't satisfy users in all cases.
  24. I added a new topic in the development area to continue the discussion about development. https://forums.getpaint.net/topic/118616-bmrl-filetype-development/
  25. Let's discuss here issues regarding the development of an .bmrl filetype plugin. There are .bmp files out there which do not contain Windows bitmap files. The signature is "RL" instead of "BM". Standard Windows viewers are not able to open these kind of .bmp files. The content of the the files is a run-length endcoded 8-bit indexed format which allows multiple palettes and an alpha channel. These files are used for iGO POI icons. We are not able to enhance or replace the built-in .bmp loader/saver so we have to choose a different filename extension and the user has to change the extension if she likes to edit the file in paint.net. My favorite extension is - in the moment - .bmrl . Because you just have to change the p to rl ,-) There seems to be no official specification describing the format. But we got a kind of reference implementation in c (open source). To implement load in c# is easy enough. Save is more tricky because standard color quantization does not respect an alpha channel . There are ideas how this can be done (if the reference implementation is not sufficient). Comments are welcome.
  • Create New...