The BLOB (not the movie!)

[ADezii]

The tool I built in 1999 is still in use today in North America. It was created in Access 97 and updated to 2000. I just tested it as 2002 no difference. Since most of my tools are for global use I can't move to 2003 yet.

So here is my table of sizes all values in KB

Original DB size - 860; added jpeg - 84; final size - 948; DB increase 88

Original DB size - 948; added jpeg - 72; final size - 1024; DB increase 76

I can send you example tables if you would like. The trick is to keep the image packed until you need it (like zipping) the beauty of using the package tool is it activates the OLE object without a pause like zipping would.

Thanks for the added information.

1. How exactly is this Packing/Unpacking process implemented?
2. Is this process applicable to *.gifs and *.jpgs only?
3. You really sparked my interest, and i'm sure others would also be interested in your solution, also.

[FishVal]

Hi, zaidlig.

Do you mean Package object?
If so, then whether it has any advantage over BLOB but no code needed?
I mean - is there any form control which can display contents of package?

Regards,
Fish

[zaidlig]

Hi, zaidlig.

Do you mean Package object?
If so, then whether it has any advantage over BLOB but no code needed?
I mean - is there any form control which can display contents of package?

Regards,
Fish

Answers:

1a) Packing: to add an image right click the control > insert object > create new > object type - package. Now you can add your object lots of ways. I browse to my file drag to contents window and file > update and exit.

1b) To unpack just active the object by double clicking or with code.

2) I believe anything can be packaged. I've just used it on image objects, including PPS.

Yes Package object is a small exe that is from like Windows 3.0. Yes no code needed and less expansion then BLOB.

The package object is an OLE object and has only one display method - OLE activate - which activates whatever is packed.

You get the same effect if your zipped your images before storing as an OLE object. However zip.exe files adds more overhead - expanding the DB.

Also a neat thing about the Package OLE object as with other true OLE objects it can be activated directly from a table view.

[FishVal]

Answers:

1a) Packing: to add an image right click the control > insert object > create new > object type - package. Now you can add your object lots of ways. I browse to my file drag to contents window and file > update and exit.

1b) To unpack just active the object by double clicking or with code.

Well. I quite aware of that. Just wanted to make evidence we are mentioning the same.

2) I believe anything can be packaged. I've just used it on image objects, including PPS.

Sure every file may be packaged. Just like every file may be "blobbed".

The package object is an OLE object and has only one display method - OLE activate - which activates whatever is packed.

You get the same effect if your zipped your images before storing as an OLE object. However zip.exe files adds more overhead - expanding the DB.

Also a neat thing about the Package OLE object as with other true OLE objects it can be activated directly from a table view.

All that could be done with BLOBs via just a trivial coding (but operations from a table view of course).

Actually I would like to split the whole issue into two logical parts:

• storing/retrieving files - easily implemented with OLE packager and a bit more complicated but still easily with BLOBs
  So far the only advantage of OLE Packager over neat BLOBs is somewhat simpler implementation.
• representing files on form - somewhat more challenging task
  OLE Packager is too programmer friendly. No code needed as well no automation supported. Sure storing in BLOB doesn't help much here but at least doesn't disturb to retrieve neat file stored.

Regards,
Fish

P.S. Thanks anyway for taking part in the discussion.

[zaidlig]

The reason I used the package was the minimal size increase when storing images. Which is the biggest advantage over BLOBing. As indicated above a BLOB added 2 X the original file size while a package added 4KB plus the original file size.

That's huge if you have lots of images. Of if your users fail to resize images to reasonable size < 300 KB.

[FishVal]

The reason I used the package was the minimal size increase when storing images. Which is the biggest advantage over BLOBing. As indicated above a BLOB added 2 X the original file size while a package added 4KB plus the original file size.

That's huge if you have lots of images. Of if your users fail to resize images to reasonable size < 300 KB.

That is obviously a bug. There is no theoretical or practical reason for that. Moreover I have normal space growing with BLOBs in my application mentioned above.

Size: 1316k
Added JPG: 2854k
Result: 4192k
Added PNG: 71k
Result: 4264k

BTW its working more or less stable so far and I'll be glad to provide a sample as soon as I'll finish all makeups.

Regards,
Fish

[zaidlig]

That is obviously a bug. There is no theoretical or practical reason for that. Moreover I have normal space growing with BLOBs in my application mentioned above.

Size: 1316k
Added JPG: 2854k
Result: 4192k
Added PNG: 71k
Result: 4264k

BTW its working more or less stable so far and I'll be glad to provide a sample as soon as I'll finish all makeups.

Regards,
Fish

I must have missed where you indicated the values in posting 4 above, were incorrect.

I only entered this discussion because in my experience the tip of the week was not true in all solutions. True the solution I created 9 years ago may not be the best solution for your particular situation (where flipping through images is critical). However I read somewhere that the packager functions were also built into IE which would feed your Web Browser control.

I will be updating the old solution during 2008. Will the BLOB solution allow editing the images after they have been stored in the native application? That is critical for my solution since after photos are stored they are often edited, trimmed, pointers added etc. before the report render is complete.

[ADezii]

I must have missed where you indicated the values in posting 4 above, were incorrect.

I only entered this discussion because in my experience the tip of the week was not true in all solutions. True the solution I created 9 years ago may not be the best solution for your particular situation (where flipping through images is critical). However I read somewhere that the packager functions were also built into IE which would feed your Web Browser control.

I will be updating the old solution during 2008. Will the BLOB solution allow editing the images after they have been stored in the native application? That is critical for my solution since after photos are stored they are often edited, trimmed, pointers added etc. before the report render is complete.

Will the BLOB solution allow editing the images after they have been stored in the native application? That is critical for my solution since after photos are stored they are often edited, trimmed, pointers added etc. before the report render is complete.

Yes, but that functionality was not incorporated into the Tip. I'm going on Vacation until Thursdy, when I return I'll Post that solution as soon as possible.

[zaidlig]

Yes, but that functionality was not incorporated into the Tip. I'm going on Vacation until Thursdy, when I return I'll Post that solution as soon as possible.

FishVal,

I just played with the packager solution and found that by simply copy and pasting the package object to a folder; it extracted the packed object which could then be viewed in the web Browser control. So it appears the packager can be automated for viewing as easily as BLOB.

ADezii,

The first technique is the most problematic primarily because of Server Errors (the Application launched to display the Image) and horrendous Database bloat because of the manner in which Access internally stores Images.

I say if you copy the package to a temp folder they can be displayed in the Web Browser control. No database blot if the are packaged.

[FishVal]

FishVal,

I just played with the packager solution and found that by simply copy and pasting the package object to a folder; it extracted the packed object which could then be viewed in the web Browser control. So it appears the packager can be automated for viewing as easily as BLOB.

That is what I actually staying on. Storing/retrieving files is a rather trivial task, may be achieved with Packager object or simply storing neat file data.
Packager has a substantial drawback as it may be easily operated via form control, while not allowing working via recordset or in-query invoked code.
Just imagine what a solution of batch processing will look like.

I will be updating the old solution during 2008. Will the BLOB solution allow editing the images after they have been stored in the native application? That is critical for my solution since after photos are stored they are often edited, trimmed, pointers added etc. before the report render is complete.

ROFL. Just today was thinking about this without any reason to even start thinking about this. Seems not a big deal. Though the obvious holes should be addressed.

Regards,
Fish

[Killer42]

I have a couple of questions about this thread...

• In post #12, ADezii made reference to converting JPG images to BMP format to reduce load time, at the expense of a substantial size increase. Has anyone tried using JPG format with less compression? Perhaps the level of compression will significantly affect the decompression speed.
  The trade-off between compression rate and image quality can be well worthwhile. When I copy photos from a digital camera (or pretty much anywhere) I often use Paint Shop Pro to increase the compression level to 42 (the setting is between 1 and 99). Apart from being the ultimate answer of course, this almost always shrinks the file size considerably, without significantly impacting on image quality.
• In post #19, FishVal said "OLE Packager is too programmer friendly". Could you please explain why this is a bad thing? You also mentioned no coding needed, which sounds ideal (though as a programmer I'm opposed to such a thing on philosophical grounds) but I think you also indicated that no "automation " is possible, which does sound like a problem.

P.S. Just for you trivia buffs, here are the details of a rather nice photo of a swimming duck...

• 16 million-colour BMP: 818KB
• JPG (level 1): 310KB (indistinguisha ble from BMP)
• JPG (level 42): 46KB (difference from BMP only visible if you switch back and forth)
• JPG (level 50): 32KB (slightly worse than at level 42)
• JPG (level 99): 7KB (Image sucks! Though when viewed small enough, works quite well as a thumbnail.)

[FishVal]

In post #19, FishVal said "OLE Packager is too programmer friendly". Could you please explain why this is a bad thing? You also mentioned no coding needed, which sounds ideal (though as a programmer I'm opposed to such a thing on philosophical grounds) but I think you also indicated that no "automation " is possible, which does sound like a problem.

I've meant - no coding needed for simple save/retrieve which on the one hand sounds good. On the other hand almost no additional functionality provided. At the same time working with neat stored file content becomes more difficult as it coffined in OLE wrapper. I don't see any other easy way to get it but via form with OLE control bound to a table field. So batch operations may become pretty resource consuming.

I think BLOB with some minor coding providing the same functionality as Packager is more suitable as it gives more options. Is that a too hard task to write some code? LOL.

Regards,
Fish

[ADezii]

I must have missed where you indicated the values in posting 4 above, were incorrect.

I only entered this discussion because in my experience the tip of the week was not true in all solutions. True the solution I created 9 years ago may not be the best solution for your particular situation (where flipping through images is critical). However I read somewhere that the packager functions were also built into IE which would feed your Web Browser control.

I will be updating the old solution during 2008. Will the BLOB solution allow editing the images after they have been stored in the native application? That is critical for my solution since after photos are stored they are often edited, trimmed, pointers added etc. before the report render is complete.

Will the BLOB solution allow editing the images after they have been stored in the native application? That is critical for my solution since after photos are stored they are often edited, trimmed, pointers added etc. before the report render is complete.

I've added increased functionality to the original BLOB's Tip, in that it now allows editing of the BLOB Image itself in the Image Editor of your choice. Simply download BLOBs_2.zip to see how this may be accomplished. An initial explanation of the process appears when you Open the Database.

[ADezii]

I have a couple of questions about this thread...

• In post #12, ADezii made reference to converting JPG images to BMP format to reduce load time, at the expense of a substantial size increase. Has anyone tried using JPG format with less compression? Perhaps the level of compression will significantly affect the decompression speed.
  The trade-off between compression rate and image quality can be well worthwhile. When I copy photos from a digital camera (or pretty much anywhere) I often use Paint Shop Pro to increase the compression level to 42 (the setting is between 1 and 99). Apart from being the ultimate answer of course, this almost always shrinks the file size considerably, without significantly impacting on image quality.
• In post #19, FishVal said "OLE Packager is too programmer friendly". Could you please explain why this is a bad thing? You also mentioned no coding needed, which sounds ideal (though as a programmer I'm opposed to such a thing on philosophical grounds) but I think you also indicated that no "automation " is possible, which does sound like a problem.

P.S. Just for you trivia buffs, here are the details of a rather nice photo of a swimming duck...

• 16 million-colour BMP: 818KB
• JPG (level 1): 310KB (indistinguisha ble from BMP)
• JPG (level 42): 46KB (difference from BMP only visible if you switch back and forth)
• JPG (level 50): 32KB (slightly worse than at level 42)
• JPG (level 99): 7KB (Image sucks! Though when viewed small enough, works quite well as a thumbnail.)

The trade-off between compression rate and image quality can be well worthwhile.

Good point, Killer but the main problem here is not Compression Rate vs Image Quality, but the Unpacking Progress Dialog that appears when the *.jpgs are dynamically loaded into the Image Control. Lowering the Compression Rate may/may not affect this to some degree.

[Killer42]

Good point, Killer but the main problem here is not Compression Rate vs Image Quality, but the Unpacking Progress Dialog that appears when the *.jpgs are dynamically loaded into the Image Control. Lowering the Compression Rate may/may not affect this to some degree.

True. My original thought (completely untested) was that a lower compression rate might also be faster to decompress, thus reducing the nuisance. Once I got onto the subject though, I think I got a bit carried away. :)

I've never seen the dialogue in question. Perhaps someone who has the opportunity could test the theory? Since we're talking about less compression, presumably the image quality won't be an issue.