Usage of clipboard-data as Texture

[ReneMiner]

it's just an idea, maybe can be done somehow but I dunno how because I have no idea what format is used to store graphics on clipboard.

thinCore allows only to capture a text from clipboard - but thinCore is not a graphics-module.

My idea is to have a TBGL-function that creates a texture from some image-data currently to find on clipboard, very simple, perhaps alike this



Function TBGL_TextureFromClipboard(
Byval texID as Long,
Byval TBGL_TEX_Quality as Long,
Optional Byval lWidth as Long,
Byval lHeight as Long
) As Long

' return ID of texture on success
' return 0 if no data found on clipboard/ if function failed
' ---

' maybe:

%Size_POT = -1 ' size automatic to the nearest power-of-two
%Size_None = 0 ' leave size as is

TBGL_TextureFromClipboard( texID, %TBGL_TEX_CRISPANISO, %Size_POT, %Size_POT )


' --
' perhaps also have a reverse operation:

Function TBGL_TextureToClipboard( texID ) As Long
' return True if success
' return False if slot texID was empty


so basically one passes just the texture-slot, desired width & height and desired quality to create a texture from image-data on clipboard.
If Width and Height are passed and are above 0 then this would be the desired texure-size,
else the function should use either the next matching POT for Width, Height or both if below 0 and fill the leftover pixels with black on %TBGL_Data_RGB (24bit) or transparent on %TBGL_Data... that contains an alpha (32bit) or just leave the size unchanged if 0/None passed.

[Petr Schreiber]

Rene,

you are the man with excellent ideas, do you know it?

I think I would try to develop Clipboard_GetBitmap for core first - the output could be used along with already working TBGL_MakeTexture.

I took a note and will look into it on Sunday, will be fun!


Petr

[Petr Schreiber]

Hi Rene,

I did a bit of research, I think it would be fine to have something like:


Clipboard_IsImage

RGBAString = Clipboard_GetImage(width, height)

...where width, height is passed by reference to retrieve the dimensions.

What do you think about such a design? Should be TBGL_MakeTexture friendly...


Petr

[ReneMiner]

you mean like


If Clipboard_IsImage Then


Long w, h
String s = ClipBoard_GetImage(w,h)

Endif


would be fine already.

Should not be such a big problem to place the string in parts onto some other, final image-data in the desired size then to have some POT-side-length.
An advantage of this would be, to have the data to work with instantly as raw data instead of having to retrieve it using TBGL_GetTextureData.

Just for the Clipboard_IsImage: Is it needed at all?
Couldn't Clipboard_GetImage just return empty string if none there? Or would Clipboard_IsImage return the image-format in the first place/ 0 if none?
Addendum:



Clipboard_SetImage(s,w,h) ' place a string as 24/32-Bit-Map onto clipboard?

[Petr Schreiber]

Hi Rene,

good ideas, as usually. With today's hardware and drivers, there is no advantage in using RGB - I think it should simply return BGRA, as it is the fastest working format.

Could you please explain more on this please?:


Should not be such a big problem to place the string in parts onto some other, final image-data in the desired size then to have some POT-side-length.
An advantage of this would be, to have the data to work with instantly as raw data instead of having to retrieve it using TBGL_GetTextureData.



Petr

[ReneMiner]

intentionally I planned to retrieve (see topic) the BGRA-Data as string using TBGL_GetTextureData for further editing

(I intend to create some Texture-Editor currently, since my Gui-project is shelved and has to wait until I can call Type-Functions on a pointer- else I would have a few hundred functions depending on a global crutch, and I'm not in the mood to do it this way because calling type-functions on a pointer has to be implemented anyway some day, else the oop/private-scope-developement would get stuck.)

even better if I don't need to occupy some texture-slot just to get that Data from OS-clipboard into my TBGL-script, so I can let the user edit it before, i.e. I would have to re-new the data all the time anyway. And for finalizing textures I want to resize them to have some POT-side-length - but this is very app-specific, most important would be to retrieve the bitmap from clipboard in TB as first- (and of course also its size).

[John Spikowski]

Maybe you could send your app an e-mail or possibly use DDE for those illusive textures. I thought I have seen it all but this one definitely takes the prize.

[mike lobanovsky]

And for finalizing textures I want to resize them to have some POT-side-length

Why would you want to do it manually? All contemporary implementations of OpenGL do it transparently themselves on a call to OpenGL texture load functions of the glTexImageXX family.

[ReneMiner]

any other user-defined size would be fine too, not just POT,
and while I let the user edit the string containing the texture, it needs some function to resize it anyway, that should not be an issue. As you can see I posted this in TBGL-section because I thought chances are bigger to get a new TBGL-version in near future and I was hoping Petr would find a way to instantly place data from clipboard into some texture-slot - and that's why i suggested user-defineable sizes for the function...

[Petr Schreiber]

All contemporary implementations of OpenGL do it transparently themselves on a call to OpenGL texture load functions of the glTexImageXX family


Sadly, this is not 100% true, even as of 2014. In theory, they should, but even my beloved Nvidia sometimes surprises me badly with NPOT textures incorrectly aligned.

Rene, I will look into this during weekend again, stay tuned :)


Petr

[mike lobanovsky]

Nvidia sometimes surprises me badly with NPOT textures incorrectly aligned.

I think you won't ever have any problems with non-POT texture alignment if you set glTexParameteri(GL_CLAMP_TO_BORDER) for much cleaner poly edges even if the texture has edge alpha-transparences.

[John Spikowski]

Damn, I never thought POT could get this technical.

[Petr Schreiber]

Hi Mike,

sadly the issues I have observed have nothing to do with filtering, it is simply data corruption of some kind.
I was manipulating crops from photos at various sizes, so clamping to edge enabled and still... bad results - sometimes, for some sizes.


Petr

[Petr Schreiber]

Hi Rene,

I created an issue for your suggestion here (http://www.thinbasic.com/community/project.php?issueid=468).

In the attachement, please find first attempt at implementation of Clipboard_GetBitmap (module + test).


Petr

[ReneMiner]

cool. one step beyond :D

[Petr Schreiber]

Updated version, with Clipboard_SetBitmap(bgraData, width, height).

Let me know, if it works as you need!


Petr

[ReneMiner]

great, that'll keep me busy for ...some time... thanx Petr

[Petr Schreiber]

Ciao Rene,

did you have time to experiment with new functionality, does it work as you expect?


Petr

[John Spikowski]

While waiting to hear back from Rene, I have a quick question.

Have you made any progress with making TBGL non-thinBasic specific? With the PB developments or lack of them it might be worth considering.

[Petr Schreiber]

Hi John,

good question. I am considering multiple... things at the moment. It is one of the items on the table, but I can't make any promises on that at the moment.
Regarding PB, I didn't gave up yet. Gary Beene is on the boat with them now, and he is very powerful wizard.


Petr

[John Spikowski]

Yes. Gary is a PB hero. He has no vested interest in PB other than not wanting it to die with its founder. There has been no word on progress or what has been done to repair the damage. I'm the ultimate optimist (stealing my daughter from death's grip) but it takes a connected effort to make miracles happen. Everyday you wake up its a new reality. Progress waits for no one.