forums › forums › SQLyog › SQLyog: Bugs / Feature Requests › Blob image viewer problems
- This topic is empty.
-
AuthorPosts
-
-
June 7, 2005 at 10:48 pm #9043
sergius
MemberThis 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 #18092
peterlaursen
Participantthe 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 #18093
Ritesh
MemberSQLyog'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 #18094
peterlaursen
Participantwill it work with 48-bit and 96-bit PNG's ?
-
June 8, 2005 at 9:59 am #18095
Ritesh
MemberWe have never tried the viewer with 48-bit and 96-bit PNGs.
-
June 8, 2005 at 10:24 am #18096
peterlaursen
ParticipantI 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 #18097
Ritesh
MemberI have forwarded the issue to my development team.
-
June 29, 2005 at 10:06 am #18098
Ritesh
MemberThere 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 #18099
sergius
MemberExcellent, thanks! Do you know when that version will be available?
-
June 30, 2005 at 12:55 am #18100
peterlaursen
ParticipantQuote: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 #18101
Ritesh
MemberSQLyog 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 #18102
peterlaursen
Participantnot 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 #18103
peterlaursen
Participantafter saving from BLOB-viewer half of picture is missing.
-
June 30, 2005 at 1:42 pm #18104
Ritesh
MemberQuote: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 OKWhat 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 #18105
peterlaursen
ParticipantQuote:A BLOB datatype has a limit of 64KSorry – 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 #18106
Ritesh
MemberQuote:Right now I'm preparing a dataset for an extensive test with the -LIKE-PARSER caseI am eagerly waiting for the results.
-
June 30, 2005 at 3:30 pm #18107
peterlaursen
ParticipantQuote:I am eagerly waiting for the results.I have posted in the thread.
-
June 30, 2005 at 3:55 pm #18108
peterlaursen
ParticipantBTW:
With the final release you will provide doc's on which formats are supported ?!
-
June 30, 2005 at 4:02 pm #18109
Ritesh
MemberYes 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 #18110
peterlaursen
ParticipantWhat 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 #18111
peterlaursen
ParticipantFirst 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 #18112
sergius
MemberIt'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 #18113
peterlaursen
Participanttransparant 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 #18114
Ritesh
MemberQuote: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 #18115
peterlaursen
ParticipantYes, 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 #18116
peterlaursen
ParticipantWhat'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 #18117
peterlaursen
ParticipantSQLyog 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 #18118
peterlaursen
ParticipantI 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 #18119
peterlaursen
ParticipantAnd 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 #18120
peterlaursen
ParticipantJust want to add that this crash corrupted the database.
-
July 1, 2005 at 7:03 am #18121
Ritesh
MemberCan 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 #18122
peterlaursen
Participantsimply:
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 #18123
peterlaursen
ParticipantBTW: First table-type was MyISAM. I changed to InnoDB to be able to ROLLBACK …
-
July 1, 2005 at 7:33 am #18124
peterlaursen
ParticipantHold it – I'll zip them !!
-
July 1, 2005 at 7:37 am #18125
peterlaursen
Participanthttp://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 #18126
Ritesh
MemberThe 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 #18127
peterlaursen
ParticipantNice! 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 #18128
Ritesh
MemberOnly 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 #18129
peterlaursen
ParticipantOK – 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 #18130
peterlaursen
ParticipantQuote:Only one image did the trickwell – 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.