_RGB32 Values for Image (Not Displayed)

[Qwerkey]

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.

[Cobalt]

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.

[SMcNeill]

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

[Qwerkey]

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"? 

[Petr]

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.

[Qwerkey]

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.

[Qwerkey]

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.  
39. _MEMFREE CMem
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.

[SMcNeill]

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!

[Qwerkey]

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.

[Petr]

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.

[Qwerkey]

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.

[SMcNeill]

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
4. END FUNCTION
5.  
6. FUNCTION ScreenOffset& (x, y)
7.     ScreenOffset& = (y * _WIDTH + x)
8. END FUNCTION
9.