Imagine (Lister plugin for viewing img files) v. 1.5.2 (Mar 27 2024)

[petermad]

version 1.3.4? I didn't installed Imagive itself, just WLX(64) plugin and sub-plugins.

Imagine WLX is 1.1.4 on www.ghisler.com/plugins.htm

Imagine WLX is 1.1.6 on totalcmd.net/plugring/imagine.html
Updated: 31.08.2023

Sejin Chun the author of Imagine does not regularily update totalcmd.net/plugring/imagine.html and apparantly Ghisler does not update www.ghisler.com/plugins.htm either regarding Imagine - for newest version of Imagine and it's plugins always go to: http://www.nyam.pe.kr/dev/imagine/#download

[Gral]

New version 1.3.9 (Jan 13 2024)

- Added: Support for QOI (Quite OK Image) file format
- Added: Support for CLIP (CLIP STUDIO PAINT) file format (plugin)
- Added: 'ICC Profile' button in Image Information dialog
- Added: Menu - 'Forward folder'
- Added: Menu - 'Backward folder'
- Added: System menu - 'Always on Top'
- Fixed: Zoom factor returns to 100% when minimized
- Fixed: Font settings sharing issue between High-DPI and Low-DPI
- Fixed: Incorrect size of File Association dialog in High-DPI environment

Telegram Animated Sticker / dotLottie Animation Format Plugin (TGS, LOTTIE) v0.1.2 (Jan 13 2024)
CLIP STUDIO PAINT Format Plugin (CLIP) v0.0.1 (Jan 13 2024)
Plugin SDK v1.5.2 (Jan 13 2024)

[norfie²]

Just for information: Imagine plugin crashed reproducibly with a lot of SVG files. After the same SVG file was displayed with Imagine.exe, the crash disappeared.

[petermad]

when running Imagine 1.3.9 as a plugin, and TC's Lister setting "Fit image to window" or "Fit only larger images to window" is enabled, then Imagine starts up showing a little 16 pixel wide image, and I have to press B twice go get a fitted image.

This only happens if DisplayWhileLoading=0 - if DisplayWhileLoading=1 there is no such problem.

[beb]

Imagine starts up showing a little 16 pixel wide image...

Met the same issue. But I didn't report it since I was playing with my .inis RedirectSections at the time and the issue had gone as soon as I finished setting up (hence, I attributed it to my own mistakes, - sometimes I got up to three [Lister] sections in the .inis).
I have set up the Imagine.ini\[Option]\DisplayWhileLoading=1 rather by chance, though.
Thank you for informing of the culprit in detail.
Now it's clear, this is a 'newly implemented' Imagne's bug.

[petermad]

Met the same issue. But I didn't report it

I have reported it to Sejin Chun - and he has confirmed the problem, which will be fixed in the next release

[beb]

Great!

Plugin_Archive, and Plugin_RAR have overlapping functions that make them incompatible.
Plugin_RAR has newly implemented rar5 support that however won't work unless a user completely removes Plugin_Archive...

Meanwhile, Imagine's bug related to its Archive vs RAR plugins conflict over rar5 format processing - is still there.
How to reproduce:

1. Make rar5 archive with some images inside
   (e.g. using cli: rar a -ma5 samplePictures_rar5.rar *.jpg, where '-ma5' explicitly indicates rar5 format archive to be created)
2. Take Imagine with all the plugins set up (specifically, the Archive and RAR plugins)
3. Using Imagine navigate to the samplePictures_rar5.rar and enter it.
   If both Archive and RAR plugins are installed you will see nothing there.
4. Close Imagine and delete its Archive plugin (Archive.plg*, and Ark*.dll files).
5. Using Imagine navigate to the samplePictures_rar5.rar and enter it again.
   Without the Archive plugin, now you see the images there as intended.

Both 32/64-bit versions of Imagine are affected, either as standalone or as a Total Commander plugin.

2petermad
Since you are in touch with the author, could you, please, be so kind as to report this bug as well?
Hope, the author can invest a bit of their time in fixing this one too.
Thank you!

[AntonyD]

Colleagues! What about the new problem with CTRL-C? On 1.3.8 I could copy a whole picture by this shortcut.
And after that- in any target program I could CTRL+V - paste this buffer. NOW I can only copy-paste the whole PATH
of the opened picture. And that's a bad design, imho...
Even the direct command from the context menu "Copy" doesn't work as well as it did in the previous version...

2petermad
Since you are in touch with the author, could you, please, be so kind as to report this bug as well?
Hope, the author can invest a bit of their time in fixing this one too.
Thank you!

[petermad]

2AntonyD
Hmm, Ctrl+C -> Ctrl+V still works fine for me in v. 1.3.9 from Imagines Display window.
It also works via the context menu Edit -> Copy2

From Imagines Browser window I can apparantly only copy-paste images if the file type is supported by the recipient - but that seem to be the same in Imagine 1.3.8.




beb
I have now written to Sejin Chun about the problem.

[beb]

2petermad
Thank you a lot.

[AntonyD]

2petermad
Ctrl-C you perform in Imagine's Display window but Ctrl-V you perform in some 3rd-party programs like WinWord, Excel, Paint, ....
And with 1.3.8 I could do that and could get whole Image copied in these apps - now with 1.3.9 I can only paste the full path as a text.
Browser window we do not touch in this report at all. Also "Edit -> Copy2" - we also do not touch.

[deus-ex]

AntonyD

Hi AntonyD, I just tried it:

• View an image with Imagine v1.3.9
• press Ctrl+C
• switch to another app that can handle images
• press Ctrl+V
• entire image is pasted

Do you have Imagine v1.3.8 still available to double-check whether it still works there for you?

[petermad]

2AntonyD

Ctrl-C you perform in Imagine's Display window but Ctrl-V you perform in some 3rd-party programs like WinWord, Excel, Paint,

That is what I tested - I tried pasting to another instance of Imagine, to IrfanView, XnView, MS-Paint and in the composer of my Email Client.

[petermad]

2beb
I have received this answer from Sejin Chun

Unfortunately, the file handling code in the Archive plugin was not written by me, so further modifications are not possible.
I'm considering deleting the Archive plugin.

[beb]

2petermad
Thank you.

Unfortunately, the file handling code in the Archive plugin was not written by me, so further modifications are not possible.
I'm considering deleting the Archive plugin.

Honestly, that's not what I've been dreaming about.
I thought there was an option to just remove (switch off) rar detection from the Archive plugin (of course if the author has the sources).
Still, that's up to the author what to do.
Anyway, whatever decision the author prefers, it would be better if the persisting conflict gets rid of, than left as it was.