I think we better discuss the magnification issue in the developers section. The "feature request" section appends all messages, this will become awkward very soon.
I was thinking in fact of the magnification produced by the equipment, i. e., physical not
digital magnification. If you display your image on-screen you will have digital magnification and
in this case sizebars are very nice.
In scanning electron microscopy you can have magnifications from 100 to 100000 or more given
your equipment. If you have a simple optical
microscope the magnification is given by the
lenses you were using to see your samples.
In both cases you know the physical magnification
but you either don't know the image size or this
size is hard to obtain (my case).
The use for the magnification field would be for
comparison purposes, lets say that you want to
compare a SEM images with mag. 2000 with a optical
of mag. 1600. But you have lots of images.
It would be nice if you could search, lets say
all images between mag. 1500 and 2500.
Sizebars are unfortunately of no help in this case, especially if you have hundreds
of images.
I am considering writing a script or a even program if necessary for importing the description contained in *.txt produced by the SEM we are using.
This could happen when the user uploads such files. These files just provide the physical magnification and few other parameters such as
beam voltage and beam spot size.
On the other hand, Scanning Probe microscopes (Scanning tunneling, atomic force, lateral force, optical near-field etc.) display their images in
the way you did, X nm by Y nm (or microns).
Still it would be most helpful to compare such images (indeed my job here) with images from SEM or siomple optical microscopes. Thus indexing these images by a fized magnification would be very nice, the actual magnification (physical+digital) being less important in this cases.
what do you think of all this?
regards
Gerald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did the size bars wok for you? I forget to mention that it only works when gd works on your system.
I assume that your SEM images are digitized at one point in their life-time, presumably with a CCD-type camera. Then, if you know how the 'magnification' reported by the system relates to magnification onto the CCD, and you know the size of your CCD (which you all should), it is a trivial exercise to calculate the pixelsize.
Pixelsize is a fixed parameter, whereas magnification scales with display of your image (think about 72 dpi and 96 dpi monitors!). Magnification is therefore in modern days an inpractical parameter. Your import script could easily carry out the aforementioned calculations. Index/search your images based on pixelsize, not on magnification (and train your users!).
Otherwise, writing the import script is a very good idea. you can easily do that in php, it has very nice string parsing functions. It would be a great additional 'image type'. Please go ahaead and write it! Let me know which 'database fields' (and what type: float-int-string) you need and I'll take care of the database part.
The only thing that still needs to be done to integrate the script is the modifications on the template structure. I also remember why I did not make different template 'types' in the past. While uploading a file, you can select the Image type and template in the same form. If there are multiple template types you can not do that so easily any more (the choice of templates depends on the image type selected). We'll need to javascript around that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have set the pixelsize in some images, but I never saw the sizebars, gd is working, or at least is installed.
I think this discussion reveals some interesting points, and raises at least one important question: what is the ultimate goal of SIDB?
I know that your focus is on confocal (sorry for the redundancy here) microscopy. But if you would like to see SIDB gathering a broad audience among scientist then you will have to take a more open position on certain issues, like the one we are discussing.
I agree technically with your arguments, but I would like to see (or to use) an image database system which is truly geared towards the way scientist think. And many do think in terms of a magnification of their images. It matters very little if the actual on-screen magnification is 1000 or 1037.9943, what counts is either the order of magnitude of the mangification or the physical magnification while the image was accquired.
Why? Because the physics involved is different.
If you take an SEM image at mag. 100000 this is much different than taking one at 50000 and scaling it twice afterwards. There are issues of focus and astigmatism adjustments as well as
resolution.
Now the are also some other issues here. It is true that it is straightforward to calculate the correct image size, given all parameters and a knowledge about the pixelsize of the CCD. At least it is for me (since I am a physicist) and certainly for you. But tell that to someone without a technical background. Probably the first question will be "what is a CCD?". Retraining users will not help here, because they will never understand why they cannot just enter a very basic data about their images in some easy way.
I think that a system like SIDB is badly needed in science and likely to be very popular. How popular it will be depends on how useful it will becomes to its users. Keep that in mind.
Here is an example of the companion text file of a JEOL SEM microscope image:
$CM_FORMAT JEOL/EO
$CM_VERSION 1.0
$CM_COMMENT
$CM_DATE 2001-09-04
$CM_TIME 3:50:57 PM
$CM_OPERATOR GENERAL
$CM_INSTRUMENT JSM-5900
$CM_ACCEL_VOLT 15
$CM_MAG 20000
$CM_SIGNAL SEI
$$SM_MICRON_MARKER 1um
$$SM_FILM_NUMBER 0000
$$SM_TITLE JSM-5900
$$SM_WD 18
$$SM_SPOT_SIZE 15
$$SM_VACUUM
$$SM_PHOTO ON
$$SM_MERGE OFF
$$SM_TEXT
it should not be difficult to import these fields using the scripts I saw in install.php
If I understood it correctly, you read the file and store each line into a table entry. It doesn't seem dificult to adapt it. The image itself is either uncompressed tiff or bmp.
regards
Gerald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I have set the pixelsize in some images, but I never saw the sizebars, gd is working, or at least is installed.
Oops. That is worrysome. Are the main buttons changing color when you go over them with the mouse (that is proof that gd works)? When you press 'Modify Image metadata', do the fields 'Pixelsize (nm)' contain a value? If all that is the case. you might have to do some debugging (I can not do it since it works here). First, look in the html source of the page with the image (url should start with show.php?id=) for a line like:'<img align=right src="sizebar.php?xsize=50&ratio=0.39384615384615">' a few lines below <Body of the page starts here>. If it is there, the problem is in sizebar.php. If it is not there the problem is in show_inc.php between lines 49 and 67. Add some 'echo' statements to find out what is going on. one possibility is that the size in pixels of your image is not know (it should be displayed as number of pixels, x,y). In that case, a size bar cannot be calculated. I would not know why sidb could not get this value out of your images, though....
>I agree technically with your arguments, but I would like to see (or to use) an image database system which is truly geared towards the way scientist think. And many do think in terms of a magnification of their images.
Those are poorly trained scientists, and we are not Microsoft... In any case, if you want a field magnification in the 'SEM' image type, go ahead. You will still need to get the value for the pixelsize, though and therefore need some info about the CCD to do the conversion. Without this info, magnification is pretty meaningless.
>It matters very little if the actual on-screen magnification is 1000 or 1037.9943,
The problem is that the on screen magnification varies much more. When you project the image onto a wall you go to 20,000 fold or something.
The way I want to implement new image types is as follows: Define a table with all the fields specific to the new image type and a unique ID. When an image of this type is uploaded, present the standard fields plus the specific ones. Link the entry with specific fields to the image entry in the database. We will need to add a field in the table 'images' to store the links. Are these all the fields you want? If so, I'll adjust the database..
Subsequently, you will have to write the part that imports the images. You best implement a function in thumbnail_inc.php. You can probably call the function 'other_thumbnail' to read the image, get parameters like imagesize, and create the thumbnail. Then write a function that reads the text file (b.t.w., how are you going to get to this text file?) and imports the comments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Nico,
I think we better discuss the magnification issue in the developers section. The "feature request" section appends all messages, this will become awkward very soon.
I was thinking in fact of the magnification produced by the equipment, i. e., physical not
digital magnification. If you display your image on-screen you will have digital magnification and
in this case sizebars are very nice.
In scanning electron microscopy you can have magnifications from 100 to 100000 or more given
your equipment. If you have a simple optical
microscope the magnification is given by the
lenses you were using to see your samples.
In both cases you know the physical magnification
but you either don't know the image size or this
size is hard to obtain (my case).
The use for the magnification field would be for
comparison purposes, lets say that you want to
compare a SEM images with mag. 2000 with a optical
of mag. 1600. But you have lots of images.
It would be nice if you could search, lets say
all images between mag. 1500 and 2500.
Sizebars are unfortunately of no help in this case, especially if you have hundreds
of images.
I am considering writing a script or a even program if necessary for importing the description contained in *.txt produced by the SEM we are using.
This could happen when the user uploads such files. These files just provide the physical magnification and few other parameters such as
beam voltage and beam spot size.
On the other hand, Scanning Probe microscopes (Scanning tunneling, atomic force, lateral force, optical near-field etc.) display their images in
the way you did, X nm by Y nm (or microns).
Still it would be most helpful to compare such images (indeed my job here) with images from SEM or siomple optical microscopes. Thus indexing these images by a fized magnification would be very nice, the actual magnification (physical+digital) being less important in this cases.
what do you think of all this?
regards
Gerald
Did the size bars wok for you? I forget to mention that it only works when gd works on your system.
I assume that your SEM images are digitized at one point in their life-time, presumably with a CCD-type camera. Then, if you know how the 'magnification' reported by the system relates to magnification onto the CCD, and you know the size of your CCD (which you all should), it is a trivial exercise to calculate the pixelsize.
Pixelsize is a fixed parameter, whereas magnification scales with display of your image (think about 72 dpi and 96 dpi monitors!). Magnification is therefore in modern days an inpractical parameter. Your import script could easily carry out the aforementioned calculations. Index/search your images based on pixelsize, not on magnification (and train your users!).
Otherwise, writing the import script is a very good idea. you can easily do that in php, it has very nice string parsing functions. It would be a great additional 'image type'. Please go ahaead and write it! Let me know which 'database fields' (and what type: float-int-string) you need and I'll take care of the database part.
The only thing that still needs to be done to integrate the script is the modifications on the template structure. I also remember why I did not make different template 'types' in the past. While uploading a file, you can select the Image type and template in the same form. If there are multiple template types you can not do that so easily any more (the choice of templates depends on the image type selected). We'll need to javascript around that.
I have set the pixelsize in some images, but I never saw the sizebars, gd is working, or at least is installed.
I think this discussion reveals some interesting points, and raises at least one important question: what is the ultimate goal of SIDB?
I know that your focus is on confocal (sorry for the redundancy here) microscopy. But if you would like to see SIDB gathering a broad audience among scientist then you will have to take a more open position on certain issues, like the one we are discussing.
I agree technically with your arguments, but I would like to see (or to use) an image database system which is truly geared towards the way scientist think. And many do think in terms of a magnification of their images. It matters very little if the actual on-screen magnification is 1000 or 1037.9943, what counts is either the order of magnitude of the mangification or the physical magnification while the image was accquired.
Why? Because the physics involved is different.
If you take an SEM image at mag. 100000 this is much different than taking one at 50000 and scaling it twice afterwards. There are issues of focus and astigmatism adjustments as well as
resolution.
Now the are also some other issues here. It is true that it is straightforward to calculate the correct image size, given all parameters and a knowledge about the pixelsize of the CCD. At least it is for me (since I am a physicist) and certainly for you. But tell that to someone without a technical background. Probably the first question will be "what is a CCD?". Retraining users will not help here, because they will never understand why they cannot just enter a very basic data about their images in some easy way.
I think that a system like SIDB is badly needed in science and likely to be very popular. How popular it will be depends on how useful it will becomes to its users. Keep that in mind.
Here is an example of the companion text file of a JEOL SEM microscope image:
$CM_FORMAT JEOL/EO
$CM_VERSION 1.0
$CM_COMMENT
$CM_DATE 2001-09-04
$CM_TIME 3:50:57 PM
$CM_OPERATOR GENERAL
$CM_INSTRUMENT JSM-5900
$CM_ACCEL_VOLT 15
$CM_MAG 20000
$CM_SIGNAL SEI
$$SM_MICRON_MARKER 1um
$$SM_FILM_NUMBER 0000
$$SM_TITLE JSM-5900
$$SM_WD 18
$$SM_SPOT_SIZE 15
$$SM_VACUUM
$$SM_PHOTO ON
$$SM_MERGE OFF
$$SM_TEXT
it should not be difficult to import these fields using the scripts I saw in install.php
If I understood it correctly, you read the file and store each line into a table entry. It doesn't seem dificult to adapt it. The image itself is either uncompressed tiff or bmp.
regards
Gerald
>I have set the pixelsize in some images, but I never saw the sizebars, gd is working, or at least is installed.
Oops. That is worrysome. Are the main buttons changing color when you go over them with the mouse (that is proof that gd works)? When you press 'Modify Image metadata', do the fields 'Pixelsize (nm)' contain a value? If all that is the case. you might have to do some debugging (I can not do it since it works here). First, look in the html source of the page with the image (url should start with show.php?id=) for a line like:'<img align=right src="sizebar.php?xsize=50&ratio=0.39384615384615">' a few lines below <Body of the page starts here>. If it is there, the problem is in sizebar.php. If it is not there the problem is in show_inc.php between lines 49 and 67. Add some 'echo' statements to find out what is going on. one possibility is that the size in pixels of your image is not know (it should be displayed as number of pixels, x,y). In that case, a size bar cannot be calculated. I would not know why sidb could not get this value out of your images, though....
>I agree technically with your arguments, but I would like to see (or to use) an image database system which is truly geared towards the way scientist think. And many do think in terms of a magnification of their images.
Those are poorly trained scientists, and we are not Microsoft... In any case, if you want a field magnification in the 'SEM' image type, go ahead. You will still need to get the value for the pixelsize, though and therefore need some info about the CCD to do the conversion. Without this info, magnification is pretty meaningless.
>It matters very little if the actual on-screen magnification is 1000 or 1037.9943,
The problem is that the on screen magnification varies much more. When you project the image onto a wall you go to 20,000 fold or something.
The way I want to implement new image types is as follows: Define a table with all the fields specific to the new image type and a unique ID. When an image of this type is uploaded, present the standard fields plus the specific ones. Link the entry with specific fields to the image entry in the database. We will need to add a field in the table 'images' to store the links. Are these all the fields you want? If so, I'll adjust the database..
Subsequently, you will have to write the part that imports the images. You best implement a function in thumbnail_inc.php. You can probably call the function 'other_thumbnail' to read the image, get parameters like imagesize, and create the thumbnail. Then write a function that reads the text file (b.t.w., how are you going to get to this text file?) and imports the comments.