![]() Plugins -> Plugin Manager (see notepad++'s plugin-manager & insert Choose repository (,, gitea instaces, ftp/http/https dir) & button) Plugins -> WWW webpage to pdf (via webkit22html/wkhtml2pdf) ![]() Plugins -> img2pdf.py (choose version to download & manpage-showing-as-txt-window button & interactive CLI-commands-passing textarea dialog Plugins -> Wipe/edit EXIF Image Orientation tag (via exiftool) Plugins -> Wipe/edit OwnerID metadata tag Tools -> Convert aGIF/MNG/APNG to mp4/mkv/gifv (via ffmpeg/libav) Tools -> Generate animated GIF frame-by-frame from images. Tools -> Compare multiple images via checksums. Tools -> Extract multipage animatedGIF/APNG/MNG into sequentially-title separate images (with a warning about optimized GIF frames lacking the full image-frame in their separate frames, just the needed image difference graphics.) - maybe use bundled gifsicle or libgif for that? View -> Frameless (apply remove-translucent-background bugfix for Linux)Īdjustments -> Rotate losslessly (for JPEGs/JPG/JP2000s) This 'super-big-file display mode (9main+more-chunk-boxes)' idea is inspired by an abandoned project of mine, which aimed at writing a simple JavaME image-viewer & html5 web-browser for JavaME - both of which would have been centered around this special zoom&pan&select display mode, which minimizes used RAM at the expense of the SDcard or internal-ROM filespace being written to in the form of temporary chunk files, generated on-the-fly & deleted ASAP when not needed.Įdit -> Export list. filespace is not enough to perform the operation for the current folder where the huge image file resides. If the user switches to another image (prev/next image in folder index) or switches to another tab or another nomacs window instance, all the generated sequentially-numbered temporary image-chunks files are deleted, unless focus is returned to that particular huge image file, upon which the entire operation is executed again (with a prior GUI warning if RAM won't be sufficient for the new generation and if HDD/SSD/etc. Special mode for displaying extremely big images, via chunking the original file into many sequentually-numbered temporary images of constrained user-defined horizontal X vertical pixels dimensions box, and displaying the big image with a pan tool and zoom-in/zoom-out tool and a cursor-selection-rectangle for copy/paste/cut/crop, and navigating the big image via the pan-tool sliding up/down/left/right which opens the other chunked parts of the huge image (thus, only the 8 chunks surrounding the current chunk are pre-loaded, while as the user slides around via pan-tool, the other image chunks are loaded on-the-fly and chunks which are outside of the 9 loaded chunks - are discarded from being loaded into RAM memory. Copy all opened tabs AND all window-instances (including all tabs within them) to folder. Copy all window-instances to folder (including all tabs within them). Copy all opened tabs AND all window-instances (including all tabs within them) to folder.Įdit -> Move all. The 3 most requested features for inclusion:Įdit -> Copy all. As far as I searched, most stuff in this list are not mentioned in currently-submitted issues. Thanks in advance for reading and considering these feature-request ideas for possible future inclusion in(to) nomacs! Sorry if any of them have already been submitted as separate issues BUT the nomacs issues-tracker is FULL of TOO MANY unclosed issues (over 350+!), so I can't search 50+ times to avoid including a duplicate of already-submitted issues. ![]() And the GNOME Image Viewer does not detect any metadata at all.Here's an unsorted dump of feature-request ideas for implementing in the nomacs image-editor (I am posting this as 1 issue instead of posting it as 30+ issues which would be considered more offensive for anyone else who is also planning on submitting an issue to the issues tracker of nomacs project on .). You will notice that Flickr detects some metadata in test.png, but not all of it - for instance it does not detect the keywords (which should read "list, of, keywords") added using XnView. Normally, reopening the Edit IPTC/XMP dialog repopulates the fields with previously entered metadata but for PNG files, if I go to Edit IPTC/XMP again, the fields show up in the dialog as empty. I can see the metadata I entered in the bottom left "Info" pane in XnView. I should correct my original issue apparently the metadata isn't entirely empty. I filled out all metadata fields with dummy text, so Headline should say "Headline," Byline should say "byline," etc. There doesn't seem to be a way to upload images in the forum, and I didn't immediately see your email anywhere, Pierre, so I uploaded a test PNG I created to Flickr. Thanks for continuing to take a look at this with me.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |