Image and video viewers

[ThorstenOtto]

For me the new version works (but i compiled it from source):

Screenshot_20230923_191633.png

However i had to change

Code: Select all

--- a/external/qdbmp/qdbmp.cpp
+++ b/external/qdbmp/qdbmp.cpp
@@ -1,4 +1,4 @@
-#include "QDBMP.H"
+#include "qdbmp.h"

This might work on a case-insensitive filesystem like macos has, but not on linux.

I also find exporting to PI1/Pi3 rather strange. Those are not very well suited for true-color formats. Instead of adding hundreds of image formats, a common one like png should be enough. Further conversion could then be done by zview or vision. Might also be interesting to write an import module for those.

[medmed]

Hi,
No progress bar and with drag and drop, no pic displayed

Could you try this one and give me the debug output from console?

[medmed]

Thanks for feedback,

Code: Select all

--- a/external/qdbmp/qdbmp.cpp
+++ b/external/qdbmp/qdbmp.cpp
@@ -1,4 +1,4 @@
-#include "QDBMP.H"
+#include "qdbmp.h"

This might work on a case-insensitive filesystem like macos has, but not on linux.

It's fixed.

I also find exporting to PI1/Pi3 rather strange. Those are not very well suited for true-color formats.

The main reason is that the palette used is only the default palette from GEM desktop.
What I wanted was to not have to load/switch to a different palette for viewing each picture on st(f/e), tt or falcon.

Instead of adding hundreds of image formats, a common one like png should be enough.

I wanted to make implementation of new format easy:
- it just needs for a read and a write functions, a copy past form lib examples in the dummy skeleton should do the stuff...
- easy icons customization and further all an easy to customize code (this is the case for me but not necessarily for everyone haha)
- embedded all in one program, with no needs for other files installed elsewhere in the os, who could work without nvdi... with no menu...
Just one window to show most of images and that's it....

Further conversion could then be done by zview or vision. Might also be interesting to write an import module for those.

Agreed, but I'll have to pass some times to understand modules logic here.
Zview is very great and I guess produce specific palettes for each export plus needs edDi cookie. It's a must have and I love it
mm_pic just use a different approach.
I don't know too much about vision, I'll try it asap.

[marss]

Voila

[medmed]

Voila

Thanks Marss,

Found a bug.

Should be fixed with the version attached.

I'll push changes when you'll confirm it's ok for you.

[marss]

Super. It is working
Using the scroll bars horizontal and vertical is not smooth... maybe in the next version ?
Would be cool to take advantage of the Radeon

[medmed]

Super. It is working
Using the scroll bars horizontal and vertical is not smooth... maybe in the next version ?
Would be cool to take advantage of the Radeon

Great!
This is because of the white veil transparency computes when you scroll.
I'll remove that and let it enabled only for Aranym for now so next release should be smoother

For the radeon I have to find some simple docs to know what functions could be used there.

[mikro]

Using Radeon in a GEM application shouldn't actually require anything. Its VDI contains its own blitting routines.

[medmed]

Using Radeon in a GEM application shouldn't actually require anything. Its VDI contains its own blitting routines.

Yes It should be managed by the driver. But don't know if there's some integrated functions on the card firmware for alpha blending for example... I guess not.

[medmed]

Super. It is working
Using the scroll bars horizontal and vertical is not smooth... maybe in the next version ?
Would be cool to take advantage of the Radeon

As you wished,

Next release

New format supported (read):
- SVG
Bugfix:
- Fix regression from v0.3 who crashed in 16bpp && 24bpp graphics modes
Misc:
- Make scrolling smoother on older computers ( _MCH cookie < 5 )

[marss]

Thanks for this new version
The white veil is still visible ;(
Scrolling up and down with the arrows is fine but scrolling with by pushing the scrollbar is a problem.

[medmed]

Thanks for this new version
The white veil is still visible ;(
Scrolling up and down with the arrows is fine but scrolling with by pushing the scrollbar is a problem.

Are you sure you used the last release?

I've tried on Hatari Falcon in 16bpp and there's no veil.

[marss]

Version 0.4
This is a video... https://drive.google.com/file/d/1pnzuxz ... sp=sharing

[medmed]

Version 0.4
This is a video... https://drive.google.com/file/d/1pnzuxz ... sp=sharing

Thanks Marss,

I think there's some unneeded refresh...

I'll check it out tomorrow.

[marss]

Super

[medmed]

Super

I think I've found. I'll fix it asap.

This should be fixed in the archive attached below.

[marss]

It is way better
This is a video... https://drive.google.com/file/d/1AUePsg ... sp=sharing

[medmed]

It is way better
This is a video... https://drive.google.com/file/d/1AUePsg ... sp=sharing

Cool.

It remains some flickering with resizing as I see, I think Thorsten is right, export is enough and I better focus on optimizations now

Thanks Marss.

[mikro]

@medmed: my suggestion (which you are completely free to ignore ;)): with your experience with the format, I'd contribute your HEIF and WEBP work as zView or even better ImgView/Vision (they use the same format) plugins.

And focus on H264 / AAC playback as there's a plenty of room for optimisation. ;)

[lp]

ImgView can load and save WebP as I managed to use the library. Apple's HEIC I haven't tried yet, was contemplating if I would try to make a plugin.

[medmed]

@medmed: my suggestion (which you are completely free to ignore ): with your experience with the format, I'd contribute your HEIF and WEBP work as zView or even better ImgView/Vision (they use the same format) plugins.

Hi Mikro,

I really understand your point of view.

But it seems that I will need to build an ldg lib for each format?

Code: Select all

struct _ldg_funcs {
	boolean	__CDECL ( *decoder_init)	(const char *, struct _img_info *);
	void 	__CDECL ( *decoder_quit)	(struct _img_info *);
	boolean	__CDECL ( *decoder_read)	(struct _img_info *, uint8 *);
	void	__CDECL ( *decoder_get_txt)	(struct _img_info *, txt_data *);
	void 	__CDECL ( *encoder_quit)	(struct _img_info *);
	boolean	__CDECL ( *encoder_write)	(struct _img_info *, uint8 *);
	boolean	__CDECL ( *encoder_init)	(const char *, struct _img_info *);
	void 	__CDECL ( *set_jpg_option)  (int16 set_quality, int /* J_COLOR_SPACE */ set_color_space, boolean set_progressive);
	void 	__CDECL ( *set_tiff_option) (int16 set_quality, uint16 set_encode_compression);
};

Which wasn't my goal at all:

It seems that dev community on Atari platform today is very reduced even for C.
For a newcomer, having to learn the LDG workload and how to implement a simple read or write function in an existing application wrote many years ago could be discouraged. Don't we need some refresh here ? So we have people complaining about no new software and people complaining about why don't use the ten year's old source code to adapt currents libraries in it haha...(I'm joking)
I do what I can with the motivation I have.
And what would be the added value? If there's a need then people with some time and mastering this modules logic will do the stuff (like lp did for webp).
Moreover some of this old app aren't adapted to containers images (TIFF Multipages).

I've implemented svg format in about 30min (reading how nanosvg works), it should be the same for other format. So how much it will take to make it works in zview?

mm_pic can easily manage them. It dither images to the classic desktop palette (16/256 colors). No needs to search for an ldg somewhere, copy it to the right place. The binary size stay reasonable (less that 4mbytes). It can work without nvdi. It handles screen cropping at any resolution. It resizes, rotates and allow to export raw data for xaaes wallpaper for example (without having to enlarge an already sized image to the entire screen and press some keys crossing fingers to have some mfd file somwhere)... It's trivial to implement any formats as the engine only waits after an argb buffer so libraries examples are easy and fast to implement.

Next features I want (or dream ) will be no rsc at all & json configuration file.

It's the way I learn and increase my skill.

And focus on H264 / AAC playback as there's a plenty of room for optimisation.

Yes agreed.
The fact is that to do so I will need to learn assembly programming + dsp programming first.
The bottleneck is aac decoding : On a raspberryPi4 Aranym JIT (BTW performances on it seems equal to V4sa) aac decode 1 second in 3 seconds so can't render anything. I've build mm_mp4 with Thorsten's libs and gcc12 and perfs seems better but not enough.

[medmed]

ImgView can load and save WebP as I managed to use the library. Apple's HEIC I haven't tried yet, was contemplating if I would try to make a plugin.

Hi Lp,

To do so you'll have to handle multiple images in one HEIC file. On this screenshot you have only one heic file containing 5 images.

[mikro]

But it seems that I will need to build an ldg lib for each format?

...

Which wasn't my goal at all:

LDG is used only for zView (which is indeed quite old, maybe even 'obsolete'). ImgView/Vision uses its own format. To quote Lonny:

Yet another plugin format? Quite frankly I wasn't all pleased with the LDG
solution. If you don't use 'C' you're forced to install LDG.PRG (TSR) and
it's plagued with a memory leak. SLB is ok, but they're not usable from plain
TOS. SLB with callbacks is even worse as the complexity of the GFA-Basic code
required to use them seems to outweigh their usefulness just to save a few
bytes. My dream is to have these work on all operating systems without being
forced to install anything. I'm hoping others will adopt them and find them
useful.

Which seems quite close to your point of view. Of course, you're free to do whatever pleases you, that was merely a suggestion from my side to let you focus on cooler stuff than GEM bitmap handling. :)

[ThorstenOtto]

SLB is ok, but they're not usable from plain TOS.

That's not quite right. The loading functions that i use for example "simulate" Slbopen() on plain TOS, using Pexec(). Thats not the same of course as on a multitasking system, but its good enough for the purpose.

SLB with callbacks is even worse as the complexity of the GFA-Basic code
required to use them seems to outweigh their usefulness just to save a few
bytes.

The callbacks are not only to save a few bytes. They are initially there to "redirect" the Malloc() calls (and other resources, like file handles) to the main application. If you don't do that, memory allocated by the SLB is (from GEMDOS point of view) still assigned to the application, but maintained internally by the SLB, and is therefor lost when you unload it. That gets even worse when you load more than one SLB, like zview does.
I agree that its currently a bit complicated, but the cleanest solution i could think of.

BTW, afaik Vision can also use the Zview codecs, so it doesn't have to be done twice.

[PeterS]

I used to use Imagecopy then BitmapView came along with loads of modules that could be used in a painting program as well.

Then Vision and zView arrived. Vision never worked nicely for me on the Milan and zView has a few limitations (zooming is broken) but it's good enough and pdf handling is good.

Great to see new formats supported but I'd prefer to stick to an existing app.

Just my two 'penneth.