Topics

Image rotation libraries

Richard Russell
 

I have written a pair of highly compatible libraries (imglib.bbc), one for BB4W and one for BBCSDL, for loading and plotting images (.bmp, .jpg, .gif, .png) with optional scaling, rotation and flipping. Each library has four functions/procedures as follows:

PROC_imgInit: Call just once at the start of your program.
PROC_imgExit: Call just once at the end of your program (and when exiting on an error).
FN_imgLoad(): Load an image from a file, returning an integer 'handle'.
PROC_imgPlot(): Plot an image with a specified position, scale, rotation and flip.

A minimal program using them would be something like this:

      INSTALL @lib$ + "imglib"

      ON ERROR PROC_imgExit : OSCLI "REFRESH ON" : : REPORT : END
      ON CLOSE PROC_imgExit : QUIT
      PROC_imgInit

      img% = FN_imgLoad(@dir$ + "bbc256x.png")
      IF img% = 0 ERROR 100, "Couldn't load bbc256x.png"

      COLOUR 128+2
      *REFRESH OFF
      REPEAT
        a += 0.5
        CLS
        PROC_imgPlot(img%, 640, 500, 0.7, a, 0)
        *REFRESH
        IF INKEY$(-256) = "W" WAIT 2
      UNTIL FALSE
      END

The libaries can be found in the group's Files area.

Jerónimo Luis Dalla Via
 

Thank you very much!!!

 

Saludos,

 

Jerónimo

 

De: bb4w@groups.io [mailto:bb4w@groups.io] En nombre de Richard Russell
Enviado el: lunes, 30 de marzo de 2020 05:26
Para: bb4w@groups.io
Asunto: [bb4w] Image rotation libraries

 

I have written a pair of highly compatible libraries (imglib.bbc), one for BB4W and one for BBCSDL, for loading and plotting images (.bmp, .jpg, .gif, .png) with optional scaling, rotation and flipping. Each library has four functions/procedures as follows:

PROC_imgInit: Call just once at the start of your program.
PROC_imgExit: Call just once at the end of your program (and when exiting on an error).
FN_imgLoad(): Load an image from a file, returning an integer 'handle'.
PROC_imgPlot(): Plot an image with a specified position, scale, rotation and flip.

A minimal program using them would be something like this:

      INSTALL @lib$ + "imglib"

      ON ERROR PROC_imgExit : OSCLI "REFRESH ON" : : REPORT : END
      ON CLOSE PROC_imgExit : QUIT
      PROC_imgInit

      img% = FN_imgLoad(@dir$ + "bbc256x.png")
      IF img% = 0 ERROR 100, "Couldn't load bbc256x.png"

      COLOUR 128+2
      *REFRESH OFF
      REPEAT
        a += 0.5
        CLS
        PROC_imgPlot(img%, 640, 500, 0.7, a, 0)
        *REFRESH
        IF INKEY$(-256) = "W" WAIT 2
      UNTIL FALSE
      END

The libaries can be found in the group's Files area.


Libre de virus. www.avast.com

Richard Russell
 

The IMGLIB libraries that I recently published, for BB4W and BBCSDL, take a scale parameter (which determines the size of the rendered image) and a flip parameter (which controls whether the image is flipped horizontally and/or vertically). I am considering changing this interface so that instead they take a horizontal scale and a vertical scale, with flipping determined by the signs. So a horizontal scale factor of -1.0 would result in a horizontal flip.

This would provide the additional flexibility of being able to change the aspect ratio, whilst not increasing the number of parameters. What do you think? Is this a good idea? Obviously it's an incompatible change but I don't imagine very many people have already used the libraries. If I don't receive any major objections I will revise and re-publish the libraries.

Mark Moulding
 

I definitely like this proposed change - it seems more "logical" to me, as well as more efficient to use in some circumstances.
~~

Mark Moulding

nbadderley
 

I prefer your newly proposed notation.

Thanks for all the work you do. 

Geoff


On 17 Apr 2020, at 09:51, Richard Russell <news@...> wrote:

The IMGLIB libraries that I recently published, for BB4W and BBCSDL, take a scale parameter (which determines the size of the rendered image) and a flip parameter (which controls whether the image is flipped horizontally and/or vertically). I am considering changing this interface so that instead they take a horizontal scale and a vertical scale, with flipping determined by the signs. So a horizontal scale factor of -1.0 would result in a horizontal flip.

This would provide the additional flexibility of being able to change the aspect ratio, whilst not increasing the number of parameters. What do you think? Is this a good idea? Obviously it's an incompatible change but I don't imagine very many people have already used the libraries. If I don't receive any major objections I will revise and re-publish the libraries.

Richard Russell
 

On Fri, Apr 17, 2020 at 11:54 AM, Mark Moulding wrote:
it seems more "logical" to me, as well as more efficient to use in some circumstances.
The original interface was a better fit to the underlying SDL2 API (which takes 'flip' as a parameter) so from that perspective the suggested change is probably a little less efficient.  It requires the flip to be calculated from the signs of the two scale factors, and then ABS used to make them positive:

      F% = -(s < 0) - 2*(t < 0) : s = ABSs : t = ABSt

In a stress test that line alone used up 2.6% of the total execution time, which is not entirely insignificant.  But "more logical" (or at least more elegant), possibly.

David Smith
 

Would there be other transorms such as shear as well as rotation? Could the parameters be imported into a transfoation matrix so people could understand the nuts and bolts of the method instead of just being a box tricks thus being more user friemdly? I was happy using GLlUT with C but now FRREGLUT has come along anf the command line syntax has changed. David Smith


Sent from Samsung Mobile



-------- Original message --------
From: Richard Russell <news@...>
Date: 17/04/2020 09:51 (GMT+00:00)
To: bb4w@groups.io
Subject: Re: [bb4w] Image rotation libraries


The IMGLIB libraries that I recently published, for BB4W and BBCSDL, take a scale parameter (which determines the size of the rendered image) and a flip parameter (which controls whether the image is flipped horizontally and/or vertically). I am considering changing this interface so that instead they take a horizontal scale and a vertical scale, with flipping determined by the signs. So a horizontal scale factor of -1.0 would result in a horizontal flip.

This would provide the additional flexibility of being able to change the aspect ratio, whilst not increasing the number of parameters. What do you think? Is this a good idea? Obviously it's an incompatible change but I don't imagine very many people have already used the libraries. If I don't receive any major objections I will revise and re-publish the libraries.

Richard Russell
 

On Fri, Apr 17, 2020 at 05:04 PM, David Smith wrote:
Would there be other transforms such as shear as well as rotation?
Don't quote me on this, but I think GDI+ (used by BB4W) probably can do shear, but SDL2 (used by BBCSDL) can't.  So since the objective is to have a pair of highly compatible libraries, shear isn't something that can be included.

Hans van der Hoeven
 

Dear Richard,

 

Yes, I do agree that this is a very sensible idea. Please do it.

 

Hans.

 

Van: bb4w@groups.io Namens Richard Russell
Verzonden: vrijdag 17 april 2020 10:51
Aan: bb4w@groups.io
Onderwerp: Re: [bb4w] Image rotation libraries

 

The IMGLIB libraries that I recently published, for BB4W and BBCSDL, take a scale parameter (which determines the size of the rendered image) and a flip parameter (which controls whether the image is flipped horizontally and/or vertically). I am considering changing this interface so that instead they take a horizontal scale and a vertical scale, with flipping determined by the signs. So a horizontal scale factor of -1.0 would result in a horizontal flip.

This would provide the additional flexibility of being able to change the aspect ratio, whilst not increasing the number of parameters. What do you think? Is this a good idea? Obviously it's an incompatible change but I don't imagine very many people have already used the libraries. If I don't receive any major objections I will revise and re-publish the libraries.

 

It's always best to be general if at all possible. So the change is the best way forw.qard.

Alan Roberts


--
This email has been checked for viruses by AVG.
https://www.avg.com

Richard Russell
 

On Sat, Apr 18, 2020 at 01:33 PM, alan836975 wrote:
It's always best to be general if at all possible.
I'm not sure, there's a fine line between "general" and "lax".  There were some distinct advantages to the original scheme: it was a better fit to the underlying SDL2 API and it discouraged changing the aspect ratio of an image, something that should be forbidden in normal circumstances (I have been sensitised by seeing 4:3 TV pictures stretched to 16:9 far too often!).  It was only the possibility of an 'abstract' image, not containing any 'real world' objects, needing to be stretched that persuaded me to allow aspect ratio changes.

 

I use a few graphics packages for drawing figures and so on, and they all offer a mixture of controls. I particularly like the way Corel Draw does it, two scaling boxes each allowing negative values. I've never had a problem with maintaining aspect ratio, but adding another control to disable one box and generate the value automatically to keep the aspect ratio right is the most obvious way out - that's what Paint Shop Pro does.

I fully agree with you about maintaining aspect ratios, stretched images annoy me intensely.

Alan Roberts


--
This email has been checked for viruses by AVG.
https://www.avg.com