Saving ImageSets

Databases
1

I want to be able to save Icons in a database as a BLOB and load them from a DB (which may not be local in the future) for a desktop app… but in this HiDPi age they should be ImageSets not single pictures… unfortunately Picture.GetData does not work for ImageSets (so obviously not for Picture.LoadFromData either)

Is there a simpler way to do that besides setting up header and PictureValue tables to be able to store n-images for a single icon, retrieving them individually and creating the image set in code? (I say n and not 3 because I think imageSets can hold more than 3 and who knows what the future holds!)

While it’s that table setup and coding doable, it complicates things unnecessarily…

I did put a feature request in for this but who know if or when they might decide it is worthwhile to do.

Thanks,

  • karen
2

An “image set” is a group of pictures all wrapped up in another (more or less)
Each image is a single representation - basically one size & scale

So you use “indexed image” and “image count” to write each one to the db
http://documentation.xojo.com/index.php/Picture.ImageCount
http://documentation.xojo.com/index.php/Picture.IndexedImage
And you can use Use GetData for each one to save to the db

For the reverse use fromData and create several single representation pictures and put those in an array
And then create a new picture with the array of http://documentation.xojo.com/index.php/Picture.Constructor(width_as_Integer,_height_as_Integer,_bitmaps()_As_Picture)

And voila! you have an “image” which is a picture that contains pictures :slight_smile:

3

Norm,

Sometimes I think you scan posts too quickly and miss the main point…

You did not tell me anything I did not already know… and completely ignored my point about the added complexity of the DB tables needed to store a set of n multiple images, which is what I wanted to avoid.

I was hoping I had missed something…

As far as I can see one needs to do one of 3 things:

  1. Use two tables (header and item)
  2. use a single table that uses parent & Child Key fields (Not optimal design as only need human readable ID and description in one row for the set)
  3. Create you own methods to merge and split the binary data for each individual image to be able to store the whole set in one column of one row and retrieve them.

I know how to do the first 2, and I am reasonably sure I can figure out how to do #3 (though I don’t know how efficiently) … with #3 being the most simply reusable method.

If I do #3, I will probably subclass picture and override Picture.GetData… but unfortunately as FromData is a shared method, I can’t overload that and make usage consistent with other pictures (and thus intuitive).

I would have to either create another shared method or add a constructor that takes a memoryblock (or both)

BUT any of those is a lot more complicated than it should be, and I wanted to see if there was a way to avoid that complexity … As I said, I was hoping there was something I missed

IMO Xojo should do #3 under the hood using Picture.GetData and Picture.FromData. It is a natural extension of the methods for pictures that are ImageSets, and IMO should have been added when image sets were added.

Of course I might be wrong, but it seems to me if ImageSets had a design spec upfront that included that capability (and it really should have) it would not have been very difficult to add it at that point.

But as Xojo Inc did not need that capability for the IDE, such an obvious thing was missed at design time… and THAT type of lack of foresight historically has been what has frustrated me most with new features in Xojo and why they always seem to be incomplete, at least for a few years.

  • Karen
4

If you take the highest resolution image, and you scale it won’t that be enough ?
You basicly store the high resolution version and use p = New Picture and p.graphics.drawpicture to scale it
Graphics.DrawPicture

This way you would only need 1 blob storage for your high-res picture. you may cache the picture somewhere as file perhaps in the resolution your app may require.

5

@Derk Jochems: there is a difference in quality if you scale. The smaller the images the more noticeable the difference in quality. Xojo doesn’t even have a good algorithm for scaling.

@Karen Atkocius : it’s up to you how you want to handle storing images in a database.

6

[quote=354320:@Beatrix Willius]
@Karen Atkocius : it’s up to you how you want to handle storing images in a database.[/quote]

My point is that as one can save or load regular pictures with picture.getData and Picture.FromData for either a file or a single field from a DB, there is no reason it should not be that simple with a Picture that is an image set.

I was hoping it was that simple… I can deal with it as it is, but i expect more from a RAD environment.

  • karen
7

Are your icons all the same size?
If yes, why not use the GIS method ( la Google map)?
Maps may be huge files and very hard to display.
The Geographic Information Systems cut them in small pieces (small tiles) and display the wanted ones.
They also store coordinates but you don’t need that.
To do that, open an Offscreen picture and place the icons in it, next to each other.
then save the resulting picture in your BLOB.
Do the inverse method to extract the icons.
Hope this help.
jjc_Mtl

8

[quote=354500:@Jean-Jacques Chailloux]Are your icons all the same size?
If yes, why not use the GIS method (à la Google map)?
[/quote]

Thanks

But I want this to be configurable by end users and have no idea of how many icons that may be needed eventually. Because of that want the Icons to be in a browsable table, and I want each one to be an image set to deal with different screen resolutions.

I actually handled this in 2 two ways. Until I work with each method enough, I won’t be sure which way is most convenient.

I did subclass Picture (PictureSet), created my own binary format for a ImageSet data and overroad Picture.GetData and Picture.Save and shadowed Picture.FromData and Picture.Open that returns a PictureSet. I gave it an additional constructor that takes a single picture (that may or may not be an ImageSet)

Alternatively I created a module (ImageSet) and there added Extends methods that extended Picture with GetSetData and SaveSetData and added protected methods ImageSet.FromSetData and ImageSet.Open that return Pictures.

Either way lets me store ImageSets in a single field in a DB as a BLOB, or as a single file on disk, depending on specific needs.

That said IMO Xojo Inc should have added those capabilities when ImageSets were introduced

  • Karen