forums › forums › SQLyog › SQLyog: Bugs / Feature Requests › Blob image viewer problems
- This topic is empty.
-
AuthorPosts
-
-
June 7, 2005 at 10:48 pm #9043sergiusMember
This is in SQLyog 4.06 under Windows 2002.
The blob viewer window doesn't show PNG and TIF images. As far as I remember, at least PNG is supposed to be supported, according to your website. It does show JPEG and GIF. The saved images are correct, so the problem is not with the data. Clicking on the save button sometimes will cause SQLyog to start consuming 100 % of CPU time and hang.
-
June 7, 2005 at 11:10 pm #18092peterlaursenParticipant
the TIF's and PNG's are they
1) 24 bit images (8 bits pr. channel)
or
2) 48 bit images (16 bits pr. channel) ?
If you have a “better” digital camera the image-chip records the image with 12 bits/channel. If you transfer the RAW-images to your computer (instead of using the camera's RAW >> JPG conversion program – the so-called “image processor”) and convert the RAW's to TIF og PNG the “better” programs (such as Adobe Photoshop CS and CS2) will convert to the 48-bit version (unless you set it to make 24 bit formats) in order not to throw information away. PNG's and TIF's support 48 bit format – JPG's and GIF's don't
(actually with Photoshop CS2 you can make 96 bit (32 bit / channel) TIF's and PNG's).
I think that the BLOB-viewer in SQLyog will only work with 24 bit formats, so if that's not what you got, that could be the explanation.
I would like to repeat here that the BLOB-viewer should support the use of GNU GTK graphics library (the one that is use by the GIMP) as a plugin. Image formats develop so rapidly today with the developments in digital photography that it is not realistic that a company like webyog – that are database specialists, not graphics specialists – will be able to cover the developments in a satisfying way. And why waste time writing code that's freely available in better quality than you would ever be able to do yourself ?!
-
June 8, 2005 at 4:54 am #18093RiteshMember
SQLyog's BLOB Viewer only supports JPEG/GIF. PNG and TIFF are not supported as of now.
Quote:Clicking on the save button sometimes will cause SQLyog to start consuming 100 % of CPU time and hang.This is a known issue in Win 2K. It will be fixed in v4.07.
-
June 8, 2005 at 9:41 am #18094peterlaursenParticipant
will it work with 48-bit and 96-bit PNG's ?
-
June 8, 2005 at 9:59 am #18095RiteshMember
We have never tried the viewer with 48-bit and 96-bit PNGs.
-
June 8, 2005 at 10:24 am #18096peterlaursenParticipant
I just did a simple test with 48 bit PNG's…
They import and export OK, but they don't display as graphics in the viewer.
I tried to attach a 48 bit PNG here but it says “You cannot upload this type of file”. I could mail you a few ones if you want ??
-
June 11, 2005 at 3:54 am #18097RiteshMember
I have forwarded the issue to my development team.
-
June 29, 2005 at 10:06 am #18098RiteshMember
There was a bug with our image library that caused SQLyog to hang. We have fixed this issue.
We are now using a different image rendering library and starting from v4.07 BETA 4, you should be able to view images of GIF, JPEG, PNG, TIFF, BMP, PCX etc formats.
-
June 29, 2005 at 11:29 pm #18099sergiusMember
Excellent, thanks! Do you know when that version will be available?
-
June 30, 2005 at 12:55 am #18100peterlaursenParticipantQuote:Do you know when that version will be available?
Yesterday it was tomorrow (it is about 2 am here). So with some luck it will be as soon as the day after yesterday! 😀
Check the last post by Ritesh here:
-
June 30, 2005 at 8:43 am #18101RiteshMember
SQLyog 4.07 BETA 4 is now SQLyog 4.07 RC1. Check out http://www.webyog.com/forums/index.php?act…st=0&#entry6181 for more details.
-
June 30, 2005 at 1:10 pm #18102peterlaursenParticipant
not quite yet ..
It does not hang and it does not crash anymore. But graphics still not always shown. Attached pic won't show in browser after it has been saved. It a simple jpg. Any filesize limit on what BLOB-viewer can handle.
Most important: I also experienced corruption of binary data when saving from BLOB-viewer. Actually I exprienced that more often than I experienced that saved data were OK
It's not safe!
-
June 30, 2005 at 1:11 pm #18103peterlaursenParticipant
after saving from BLOB-viewer half of picture is missing.
-
June 30, 2005 at 1:42 pm #18104RiteshMemberQuote:Most important: I also experienced corruption of binary data when saving from BLOB-viewer. Actually I exprienced that more often than I experienced that saved data were OK
What is the size of the image?
A BLOB datatype has a limit of 64K. After that data is truncated by MySQL. Are you sure that image size is less then the datatype's max limit?
-
June 30, 2005 at 1:51 pm #18105peterlaursenParticipantQuote:A BLOB datatype has a limit of 64K
Sorry – I missed that!
I shall do some more extensive test with various formats, fiesizes, and variations on BLOBs and TEXTs types (LONGBLOB/TEXT, MEDIUMBLOB/TEXT etc) tonight.
Right now I'm preparing a dataset for an extensive test with the -LIKE-PARSER case 🙄
-
June 30, 2005 at 1:53 pm #18106RiteshMemberQuote:Right now I'm preparing a dataset for an extensive test with the -LIKE-PARSER case
I am eagerly waiting for the results.
-
June 30, 2005 at 3:30 pm #18107peterlaursenParticipantQuote:I am eagerly waiting for the results.
I have posted in the thread.
-
June 30, 2005 at 3:55 pm #18108peterlaursenParticipant
BTW:
With the final release you will provide doc's on which formats are supported ?!
-
June 30, 2005 at 4:02 pm #18109RiteshMember
Yes we will do.
We have tested the image library with the following image formats:
GIF, JPEG, PNG, TIFF, BMP, PCX
and it works great 😀
-
June 30, 2005 at 4:12 pm #18110peterlaursenParticipant
What about ICO and PSD ?
I intend to test with 48 bit formats later tonight (tif/png/psd) – also some BIG one's using MEDIUMBLOB's.
with the formats that support multilayered, transparent and animated data I shall try that too (to the extend that I have some relevant files… ).
-
June 30, 2005 at 9:18 pm #18111peterlaursenParticipant
First report on new BLOB-viewer:
ICO not supported
Animated GIF's not supported (would be nice if 1st frame was displayed)
both 48/24 bit TIFF's supported (both uncompressed and .lzh-compressed – other (more recent) compression algorithms not tested)
both 48/24 bits PNG supported. Only interlaced format-version tested.
24 bit PSD supported / 48 bit PSD not supported (browser tries to display but can't) (PSD is the native Abobe Photoshop format. Although proprietary use of it is widespread).
Native paint Shop Pro image format not supported (browser tries to display but can't).
With formats supporting layers only image-files with one layer only is tested.
All test done with LONGBLOB field definition (a 48 bith uncompressed TIFF is about 35 MB with my camera resolution!). The memory handling of SQLyog is not optimal for such big binary DATA. Program soon get's very slow. And fails to display graphics after a while. After closing and restarting SQLyog it again works for a while … I don't want to hear that that is “as expected” – other programs handle it smoothly!
But after all that's a start!
-
July 1, 2005 at 1:47 am #18112sergiusMember
It's a step ahead, for sure.
But the transparent-background PNG images are shown as black rectangles. When I save them as files and view them in a browser, they look fine.
And the installer screen still says version 4.06 🙂
-
July 1, 2005 at 2:25 am #18113peterlaursenParticipant
transparant GIF's seem to function reasonably although it is not “true transparancy”.
With the image below the circle in the middle is transparent area.
@Sergio: I believe that PNG-transparancy is quite new and not yet fully standardized. I believe I read about it on the Mozilla or Opera Website … Correct me if I am wrong -
July 1, 2005 at 3:58 am #18114RiteshMemberQuote:The memory handling of SQLyog is not optimal for such big binary DATA.
Sluggishness might happen for two reasons:
- SQLyog needs to get the complete image data as well as other result data to the client before we can display the image.
- The image library that we are using to display the images is taking time to implement/read the image.
-
July 1, 2005 at 4:09 am #18115peterlaursenParticipant
Yes, but I also experienced that Blob Viewer fails to display the graphics after a while. After closing down and restarting SQLyog it works again …
I don't say it's a big deal. You would rarely put big images like this in the DB – rather a pointer to its position within the file system. And reading image data from a Database Server is not the same to reading image data directly from file system.
Never the less I think you should keep an eye on it in the future. I have hundreds of 35 MB 48 bit TIFFs that you might test with. And then you'll also see how beautiful a place Denmark is 🙂
-
July 1, 2005 at 5:07 am #18116peterlaursenParticipant
What's happening here ?? Message appears when inserting into 4th (as far as I remember) row.
Seems like BLOB-viewer interface demands unique content of rows or a PK.
The rows where all columns are NULL have earlier had data in BLOB-fields. Maybe rows should have been deleted when BLOB's were deleted and leaving all colums as NULL ?
A minor issue that should not delay RC2 .. or whatever you may name it!
-
July 1, 2005 at 5:20 am #18117peterlaursenParticipant
SQLyog memory consumption after having opened the fourth big TIFF from BLOB viewer (save in between). Has been like that for about ½ hour now …
MySQL Server resource consumption is quite normal …
I know very well that this is abnormal use. But I can have open about 50 of those files in Photoshop at the same time before system load and performance becomes unacceptable.
Hardware is XP+ 1700, 512 MB RAM
-
July 1, 2005 at 5:47 am #18118peterlaursenParticipant
I had to delete all rows except for the first two to get BLOB viewer functional with that database again!
-
July 1, 2005 at 6:10 am #18119peterlaursenParticipant
And finally …
an attempt to insert the 6th image generated this error. I might have hit the maximum swapfile size.
When an image has been save to the base, why does it not free the memory ?
As of now memory consumption is rising MORE THAN proportional to the number of files opened.
I shall stop now.
But I have more than 50 programs managing memory more efficient than SQLyog.
That does not mean that SQLyog is not an excellent program. :wub:
But there is something to improve on over time here …
-
July 1, 2005 at 6:25 am #18120peterlaursenParticipant
Just want to add that this crash corrupted the database.
-
July 1, 2005 at 7:03 am #18121RiteshMember
Can you cut-n-paste the table sturcture?
It will be nice if you could zip and upload 6-7 of huge images on your server and give the link.
-
July 1, 2005 at 7:26 am #18122peterlaursenParticipant
simply:
CREATE TABLE `tablename1` (
`id` bigint(20) NOT NULL auto_increment,
`mytext` varchar(255) default NULL,
`c` longblob,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
You can downoad 10 images from
http://deepeter.dyndns.dk/Bigpics/CRW_0001.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0004.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0005.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0017.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0023.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0024.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0031.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0046.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0101.tif
http://deepeter.dyndns.dk/Bigpics/CRW_0119.tif
I have 128 kbit/sec in outgoing direction so it will take some time 😀
But it won't be faster for me to upload ..
Please give me a hint where you're finished!
-
July 1, 2005 at 7:29 am #18123peterlaursenParticipant
BTW: First table-type was MyISAM. I changed to InnoDB to be able to ROLLBACK …
-
July 1, 2005 at 7:33 am #18124peterlaursenParticipant
Hold it – I'll zip them !!
-
July 1, 2005 at 7:37 am #18125peterlaursenParticipant
http://deepeter.dyndns.dk/Bigpics/Bigpics.zip
272 MB – not reduced as much as I thought it would be.
have the “Bigzip” or the individual files as you like …
-
July 1, 2005 at 11:27 am #18126RiteshMember
The issue is due to the fact that we add the whole query (in this case around 35M:cool: to the history window too. Thus the memory is not being released even after you have ceased using Insert/Update window.
Starting from v4.07 RC2, SQLyog will only log queries less than 4K.
-
July 1, 2005 at 11:34 am #18127peterlaursenParticipant
Nice! and fine too that there is a logical explanation l! 😀
That also explain my experience that if I inserted ONE image, saved and closed SQLyog, opened SQLyog inserted ONE image, saved, closed SQLyog, opened SQLyog and so on, then I could insert an unlimited number of images.
BTW – if you liked my pic's there are more here http://www.deepeter.dk/Billedarkiv/Foretru…/Foretrukne.htm 😆
-
July 1, 2005 at 11:39 am #18128RiteshMember
Only one image did the trick. I was just looking for a 35MB image so that my developers could work on it.
-
July 1, 2005 at 11:54 am #18129peterlaursenParticipant
OK – I'll then shut down this outdated abacus of mine and go out to do some shopping for the weekend!
-
July 1, 2005 at 8:12 pm #18130peterlaursenParticipantQuote:Only one image did the trick
well – maybe you should have tried them all. It' s a lot better now, but still I experience that after inserting some 5-6 images the BLOB-viewer stop showing graphics. It is fixed when closing and restarting SQLyog. And the memoy management still does not impress me. But it has not crashed and no corruption of data has taken place with RC2.
But try yourself one day to create a DB with 25 of those images and decide for yoursef if that's want you want from a professional program …
I believe you still should improve on it over time …
-
-
AuthorPosts
- You must be logged in to reply to this topic.