Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: Qwerkey on November 09, 2019, 12:49:59 pm

Title: _RGB32 Values for Image (Not Displayed)
Post by: Qwerkey on November 09, 2019, 12:49:59 pm
Is there an equivalent of POINT(x,y) of the graphics screen for an undisplayed image?

I want to extract _RGB32 values for all x,y positions of an image which is loaded to memory (either by _NEWIMAGE or _LOADIMAGE) and which is the current _DEST but which is not yet displayed.

If this is possible, I expect that Steve has already told me (a number of times!!), but my one brain cell left hasn't retained that bit of data.  I've gone through all the Wiki statements and cannot find anything that returns such a value.

If this is not possible, I'd have to temporarily load the image, do POINT and make an array to keep the _RGB32 information and then clear the screen: that would be slightly messier.

Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: Cobalt on November 09, 2019, 01:04:43 pm
You need to set the _SOURCE to that image too for POINT to work. and don't forget to use an _UNSIGNED LONG variable for the result.
Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: SMcNeill on November 09, 2019, 01:13:40 pm
image = _LOADIMAGE(“yourimage.jpg”,32)
DIM M AS _MEM, o AS _OFFSET
M = _MEMIMAGE(image)
DO
    PRINT _MEMGET(M, M.OFFSET + o, _UNSIGNED LONG)
    o = o + 4
LOOP UNTIL o > M.SIZE

(And the last video I put up is about calculating the x/y offset with MEM.  I just got it up in time for your question here.). ;D
Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: Qwerkey on November 10, 2019, 04:16:18 am
Cobalt, thanks.  I really should have known that it is as easy as that.

Steve, I never even thought to use the _MEM method.  I'll be updating the R,G,B values of a hardware image* on the fly, so that's just what I need.  I'll update myself with your earlier videos as well.

* Edit: hardware images not allowed as _MEM objects (but works exactly as expected for the same image as software).  That's a nuisance.  Or are they already "_MEM objects"? 
Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: Petr on November 10, 2019, 05:13:34 am
Hi Qwerkey,

I assume that hardware images are loaded for OpenGL (as _glBindTexture), so they are not available for _MEM. Therefore, use MEM for software images and then convert them with COPYIMAGE, which after displaying (and if you no longer need them) delete with FREEIMAGE before creating another hardware image from the software image.
Maybe there is a better way, but what I am describing I used and it works.
Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: Qwerkey on November 10, 2019, 07:47:02 am
Ah, Petr, you describe exactly my default method (work on the (,32) image & then _COPYIMAGE(,33).  I secretly hoped that Steve would come back with "Oh, dear, dear, you silly idiot: here is a much better method!".  As the (,33) is actually on the screen, I suppose the best method would be to do the _MEM manipulations of the screen _RGBA32() values, as Steve has begun to show us in his videos.  It's just a pity that at least one of his students has managed to sneak in from the inveterately stupid department!


Quick Addendum:  Just tried the _MEM technique with the software image & copy to hardware image each loop.  It works.  Thanks Steve & Petr.
Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: Qwerkey on November 12, 2019, 07:45:20 am
And now another curiosity.

I used the _MEM technique for one of my images to change its colour on-the-fly: very successful thank you and exactly as Steve predicts.

However, I'm getting this oddity with a second image, where I want to blank off (set alpha to 0) certain sections of the image.  I'm using this set of commands for Image name MakeImg&:

Code: QB64: [Select]
  1. DIM CMem AS _MEM, COff AS _OFFSET
  2. CMem = _MEMIMAGE(MakeImg&)
  3.  
  4. COff = 0
  5. READ X1%, Y1%, X2%, Y2%
  6. FOR N% = X1% TO X2%
  7.     FOR M% = Y1% TO Y2%
  8.         '1st Blanking Routine
  9.         COff = 4 * (N% + M% * W%)
  10.         _MEMPUT CMem, CMem.OFFSET + COff + 2, 0 AS _UNSIGNED _BYTE 'Red
  11.         _MEMPUT CMem, CMem.OFFSET + COff + 1, 0 AS _UNSIGNED _BYTE 'Green
  12.         _MEMPUT CMem, CMem.OFFSET + COff + 0, 0 AS _UNSIGNED _BYTE 'Blue
  13.         _MEMPUT CMem, CMem.OFFSET + COff + 3, 255 AS _UNSIGNED _BYTE 'Alpha
  14.     NEXT M%
  15. NEXT N%
  16. READ X1%, Y1%, X2%, Y2%
  17. FOR N% = X1% TO X2%
  18.     FOR M% = Y1% TO Y2%
  19.         '2nd Blanking Routine - Why does this put two lots in???
  20.         COff = 4 * (N% + M% * W%)
  21.         _MEMPUT CMem, CMem.OFFSET + COff + 2, 0 AS _UNSIGNED _BYTE 'Red
  22.         _MEMPUT CMem, CMem.OFFSET + COff + 1, 0 AS _UNSIGNED _BYTE 'Green
  23.         _MEMPUT CMem, CMem.OFFSET + COff + 0, 0 AS _UNSIGNED _BYTE 'Blue
  24.         _MEMPUT CMem, CMem.OFFSET + COff + 3, 255 AS _UNSIGNED _BYTE 'Alpha
  25.     NEXT M%
  26. NEXT N%
  27. READ X1%, Y1%, X2%, Y2%
  28. FOR N% = X1% TO X2%
  29.     '3rd Blanking Routine
  30.     FOR M% = Y1% TO Y2%
  31.         COff = 4 * (N% + M% * W%)
  32.         _MEMPUT CMem, CMem.OFFSET + COff + 2, 0 AS _UNSIGNED _BYTE 'Red
  33.         _MEMPUT CMem, CMem.OFFSET + COff + 1, 0 AS _UNSIGNED _BYTE 'Green
  34.         _MEMPUT CMem, CMem.OFFSET + COff + 0, 0 AS _UNSIGNED _BYTE 'Blue
  35.         _MEMPUT CMem, CMem.OFFSET + COff + 3, 255 AS _UNSIGNED _BYTE 'Alpha
  36.     NEXT M%
  37. NEXT N%
  38.  
  40.  

The program lines cannot be used here.  I am blanking off 3 rectangular areas, labelled 1st, 2nd and 3rd Blanking Routine.

The 1st & 3rd routines correctly blank off the appropriate areas - see clouds1.png and clouds3.png

The 2nd routines correctly blanks off the appropriate area (see clouds2.png - right-hand black rectangle).  But there is also a second blank area to the left (not coded).

Any ideas where I'm going wrong?

The code is amended from that actually used where alpha is set to zero and not 255.  The 255 value was used to show you the blanking regions.

Incidentally, I had initially tried this blanking technique using PSET on the image rather than its _MEM object.  That technique would never set alpha to zero: another curiosity.

Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: SMcNeill on November 12, 2019, 10:19:35 am
I’m stumped.  Unless the image is being called and altered twice somehow, I don’t see any possible way for the code to generate two independent boxes.  If it started on one side of the screen and then wrapped all the way around to the other side, I’d say you were just using too large a width for your box.  That unaltered image on either side, however, rules that out — you’re creating two independent boxes, with space between them...

And I have no idea how that one little box routine is doing that!
Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: Qwerkey on November 12, 2019, 10:36:21 am
Steve, many thanks.  You have exactly the right answer.  Like you, I had noticed that it seemed something to do with the image RHS.  I had coded the blank off the RHS (and therefore into the LHS).  You could not see the values used, but that's what I'd done.  Another stupid, stupid mistake.
Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: Petr on November 12, 2019, 11:34:06 am
Hi Qwerkey. Just curiosity: What is RHS and LHS?  In your last source code - variable W%, it is for _WIDTH, right? W% is not defined there.
Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: Qwerkey on November 12, 2019, 12:11:46 pm
RHS/LHS right-hand side and left-hand side
W% in the code was indeed the width of the image.  Clever of you to work that out in absence of the bulk of the code.
Although Steve hasn't given us the full tutorial on accessing the _MEM pixel data of an image, I took a chance that the data are in column then row order, so to get the next row you index down a complete width's worth.

Title: Re: _RGB32 Values for Image (Not Displayed)
Post by: SMcNeill on November 12, 2019, 02:33:54 pm
Quote from: Qwerkey on November 12, 2019, 12:11:46 pm
RHS/LHS right-hand side and left-hand side
W% in the code was indeed the width of the image.  Clever of you to work that out in absence of the bulk of the code.
Although Steve hasn't given us the full tutorial on accessing the _MEM pixel data of an image, I took a chance that the data are in column then row order, so to get the next row you index down a complete width's worth.

The last video should cover that for you.

https://www.qb64.org/forum/index.php?topic=1731.msg110931#msg110931


Code: QB64: [Select]
  1.  FUNCTION Offset& (x, y)
  2.     xsize = UBOUND(A, 1) - LBOUND(A, 1) + 1 'the number of elements in X
  3.     Offset& = (y * xsize + x) 'Y * number of elements in X + X
  5.  
  6. FUNCTION ScreenOffset& (x, y)
  7.     ScreenOffset& = (y * _WIDTH + x)
  9.  

Text Only | Text with Attachments