rageworx / fl_imgtk Goto Github PK

I'm trying out fl_imgtk::rescale. I noticed inside ResizeEngine::scale that if the requested size was unchanged from the original, then a copy of the original is returned:

    if ( ( src->w() == dst_width) && ( src->h() == dst_height))
    {
        return (Fl_RGB_Image*)src->copy();
    }

As I expected in this scenario, calling discard_user_rgb_image on the rescaled image caused a crash. As the returned image in this case is not allocated by fl_imgtk.

This means the caller of fl_imgtk::rescale needs to write code to know when to call discard_user_rgb_image or not. [Of course, they should have written code to not call rescale in this scenario ...]

I'm thinking it might be better to return NULL in this situation?

[And my thanks for this library, I'm definitely using the rotate/flip functions, loving the performance!]

Testing in YAIV.

Load firefox_logo_2017.svg
Use 's' or up/down arrow keys to change zoom to something besides 100%.
Use 'z' key to change imgTk scaling method.

SIGSEGV in ResizeEngine::horizontalFilter

It's the end of my day otherwise I'd have dug into it further.

Drago and Reinhard has bug.
result image is stained, not looks like HDR.

record something here for debugging test of version 0.3.40.30

Found vertical black line occurs when it turned image 90 or 240 degrees.
Seems to a bug and be fixed.

I seems to need supporting single Y channel and Y+alpha channel ( depth 2 ) of Fl_RGB_Image.
Someone may love this feature for making some special viewer.

• additional ref. #16

By implementing fltk-cpp-barcode, QR code rendering failure by segmentation fault for out of buffer region.

Need to guard out boundary more efficient.

It will occurs with this condition.

• x1 is less than x2.
• y1 is less than y2.
• thickness more than 3.f.
  

By code,

Not applied zero alpha depth for 0xFFFFFF90 to 0xFFFFFF00.

It must be shaded to invisible white as like this,

Case of Reinhard tone mapping, its alpha channel affects to strange result for 32bit RGBA image.

• these methods has error,
  1. makegradation_h()
  2. makegradation_v()

Occording reference Fl_RGB_Image() constructor ( https://www.fltk.org/doc-1.3/classFl__RGB__Image.html ),
Fl_RGB_Image don't own referenced uchar buffer for own memory.
But it should set 'alloc_array' to 1 for deallocating memory from own array buffer when destruct class.

apprehend issue:
compatibility issue may occurs by using discard_user_rgb_image() API in the past.

Will support -

• shared object, DLL
• don't clean every time.
• install to system

This is my fault that didn't test well.

Need to fix this.

Any fastest way to draw antialiased polygon ?
Find a way.

I will be looking at using other bits of code soon, but here are some problems I discovered after grabbing the crop function. My thanks in advance for these functions!

1. Perhaps you have a macro in your headers someplace, but this: #pragma omp parellel should be "parallel".
2. I'm occasionally encountering images which are very large. You might consider using size_t to calculate the size of obuff.
3. This following chunk of code leaks obuff if rbuff is NULL.

        uchar* rbuff = (uchar*)src->data()[0];
        uchar* obuff = new uchar[ rw * rh * sd ];

        if ( ( rbuff != NULL ) && ( obuff != NULL ) )

4. This might a limitation of Microsoft's OMP implementation, but it complains the cntx and cnty loop variables need to be signed objects in the parallel for loops.
5. Something which I think is inadequately documented is the fact that the Fl_RGB_Image destructor does not free the memory buffer automatically. The programmer has to manually set the field alloc_array to non-zero, otherwise the buffer is leaked. So:

		return new Fl_RGB_Image(obuff, rw, rh, sd);

really should be:

		Fl_RGB_Image* retimg = new Fl_RGB_Image(obuff, rw, rh, sd);
                retimg->alloc_array = 1;
		return retimg;

One of tone mapping, Reinhard algorithm took some strange result by testing performance.

Tested 5790x8688 JPEG image at Intel i7-7700 ( 3.6GHz ), Windows 10 x86.64

First, with OpenMP. ( CPU going to 100% usage )

about 27 seconds.

Then with non-OpenMP. ( much less CPU usage ... )

about 15 seconds.

Hmm ??? Need more test ...
library compiled with MinGw-W64 gcc 10.2.0(rev9).

Supporting llvm-clang environments on Linux.

Will be tested on Ubuntu 22.04LTS.

even I use in my actual code I get same error
library is compiled using g++

$ cat test.cpp

#include "/home/oggy/projects/PicMe/fl_imgtk/lib/fl_imgtk.h"
#include <FL/Fl_PNG_Image.H>
int main(){
  Fl_PNG_Image* img = new Fl_PNG_Image("/home/oggy/Pictures/Square_200x200.png");
  fl_imgtk::rotate90(img);
}

$ g++ -lfltk -lfltk_images -std=c++11 -L /home/oggy/projects/PicMe/fl_imgtk/lib -l fl_imgtk test.cpp

/usr/bin/ld: /tmp/ccVPeWoH.o: in function `main':
test.cpp:(.text+0x3e): undefined reference to `fl_imgtk::rotate90(Fl_RGB_Image*)'
collect2: error: ld returned 1 exit status

Hi, I am using Artix Linux (Arch Linux based distro), I did not have llvm-g++ and llvm-gcc
I am not sure , llvm-g++ and llvm-gcc only available in MacOS.
On Linux we have clang and clang++

Testing with new branch of FLTK-1.3.5-2-ts/v1.4.0-dev ( https://github.com/rageworx/fltk-1.3.5-2-ts/tree/v1.4.0-dev )

In YAIV, inadvertently trying to zoom below 0%. This caused negative w or h values being sent to fl_imgtk::rescale.

Resulted in a crash rather than the expected nullptr return.

I've been having some problems with rotate180.

1. Images of depth 4 (e.g. PNG with transparency), the transparent bits aren't rotated properly.
2. Images of depth 1 seem to result in a memory corruption crash when displayed.

I believe these lines:

            fl_imgtk_swap_mem( &buff[ cnt * d ],
                               &buff[ (imgmax - cnt - 1) * d ],
                               3);

should be:

            fl_imgtk_swap_mem( &buff[ cnt * d ],
                               &buff[ (imgmax - cnt - 1) * d ],
                               d);

I.e. not hard-coding 24 bits of image depth.

Here is a depth 1 PNG file:
3016021.png.zip

And here is a depth 4 PNG:
19000.png.zip

It will be removed printing log of vector coordinations.

Fixing some OpenMP for() becomes error of graphical results.