save as jpg

[Gwen Barnes]

Hi,

I'm have a question about saving images as jpg.  I set the quality to 100
under "edit, options, I/O options", but still, when I save a tiff as a jpeg,
I end up with jpeg artifacts.  If I use other programs, and save the same
tiff as a quality 100 jpg, I don't get the artifacts.  Is there a way to
save a full quality jpeg in ImageJ?  Any ideas what I need to do
differently?  Thanks.

-Gwen

[Joachim Wesner]

Hm, there was a similar thread with suggestions just recently in this
group, look up the archives for

'Better jpeg quality'

Mit freundlichen Grüßen / Best regards

Joachim Wesner

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy
Martyr | Colin Davis


                                                                           
             Gwen Barnes                                                  
             <gwen.barnes@GMAI                                            
             L.COM>                                                     An
             Gesendet von:              [hidden email]                
             ImageJ Interest                                         Kopie
             Group                                                        
             <[hidden email].                                       Thema
             GOV>                       save as jpg                        
                                                                           
                                                                           
             05.03.2008 22:54                                              
                                                                           
                                                                           
              Bitte antworten                                              
                    an                                                    
              ImageJ Interest                                              
                   Group                                                  
             <[hidden email].                                            
                   GOV>                                                    
                                                                           
                                                                           




Hi,

I'm have a question about saving images as jpg.  I set the quality to 100
under "edit, options, I/O options", but still, when I save a tiff as a
jpeg,
I end up with jpeg artifacts.  If I use other programs, and save the same
tiff as a quality 100 jpg, I don't get the artifacts.  Is there a way to
save a full quality jpeg in ImageJ?  Any ideas what I need to do
differently?  Thanks.

-Gwen



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Robert Dougherty]

I use .PNG instead. No artifacts.
Bob

[Wayne Brown-3]

I am not sure if this might be deemed as not relevant to the group, so
forgive me in advance if this is the case.  We produce scientific
imaging systems for a variety of applications, and we have customers who
use ImageJ.   We have had a debate going on for some time on the
necessity of providing camera control and image acquisition from within
the ImageJ environment.  We have yet to do this for our systems,
although we have had requests.

Does it make any difference whether you bring files output from separate
camera acquisition software into ImageJ, or use ImageJ itself for the
acquisition of the image?

I welcome your opinions.

Wayne Brown
Apogee Instruments Inc.
www.ccd.com

[Gabriel Landini]

On Thursday 06 March 2008, Wayne Brown wrote:

> I am not sure if this might be deemed as not relevant to the group, so
> forgive me in advance if this is the case.  We produce scientific
> imaging systems for a variety of applications, and we have customers who
> use ImageJ.   We have had a debate going on for some time on the
> necessity of providing camera control and image acquisition from within
> the ImageJ environment.  We have yet to do this for our systems,
> although we have had requests.
>
> Does it make any difference whether you bring files output from separate
> camera acquisition software into ImageJ, or use ImageJ itself for the
> acquisition of the image?

It is very refreshing to see the industry asking the user base for opinions.

Yes, it makes a huge difference.

If you can produce plugins that are callable from other plugins or from
macros, you open a large number of possibilities.

For instance, automatic uneven background corrections (I still have to see
that implemented in the software that is included with most cameras),
autofocus, autoexposure, mosaic capture, autosearch, averaging shots, time
lapsed analysis... there are many new possibilities.

So yes, please produce software that interfaces with IJ.
Rather than plugins that put up a dialog with buttons where one has to click
to capture, we need functions to control the camera which can be called from
IJ macros/plugins. If that is available, then one can create and modify the
capture software and capture images programmatically.

I hope it helps.

Gabriel

[Luciano Marpegan]

Hi everybody,
I have to measure the signal intensity from cells in time-lapse
movies. The cells move and their intensity and shape also change from
frame to frame. The shape is mostly circular so we use circular ROIs
to perform the measurements but if the diameter changes then we face
the problem of changing the size of our ROI or not. The way we solve
this is by using the same ROI for all the cells (we choose it so that
the biggest cell will fit in it) through all the movie, meaning that
for most of the cells we are also measuring a lot of the background.
The parameter we measure is integrated intensity.
Is there a better way to approach this type of measurements? I've
seen people using the 10 brightest pixels within the ROI or getting
the histogram within the ROIs and comparing their distributions but I
don't have the knowledge to determine what "should" be done and which
are the pros and cons of the different techniques. If there is
literature on this topic I would appreciate any suggestions.

Many Thanks,
Luciano

[dscho]

Hi,

On Thu, 6 Mar 2008, Gabriel Landini wrote:

> So yes, please produce software that interfaces with IJ.

Even better: just add a plugin to ImageJ, and benefit from the work of
Wayne and so many volunteers.  IOW: save money (that should appeal to
industry, no?).

Ciao,
Dscho

[Nico Stuurman-4]

Hello Wayne,

> I am not sure if this might be deemed as not relevant to the group,  
> so forgive me in advance if this is the case.  We produce scientific  
> imaging systems for a variety of applications, and we have customers  
> who use ImageJ.   We have had a debate going on for some time on the  
> necessity of providing camera control and image acquisition from  
> within the ImageJ environment.  We have yet to do this for our  
> systems, although we have had requests.
>
> Does it make any difference whether you bring files output from  
> separate camera acquisition software into ImageJ, or use ImageJ  
> itself for the acquisition of the image?

Thanks for considering making your cameras controllable from within  
ImageJ.  I am sure that quite a few people will appreciate this.  What  
might be even more useful is to build an 'adapter' for Micro-Manager (http://micro-manager.org 
).  This way, your cameras will not only work within ImageJ (and be  
completely controllable from ImageJ plugin code), but they can also be  
used together with lots of other hardware used in microscopy (for a  
list see http://valelab.ucsf.edu/~nico/MMwiki/index.php/ 
Device_Support).  As a bonus  your cameras will also run from Matlab  
scripts through Micro-Manager.

The advantage for plugin writers to control a camera through Micro-
Manager rather than through ImageJ plugins is that Micro-Manager  
exposes a uniform interface for all cameras, i.e., a plugin written  
for one camera will very likely also work for a camera from another  
vendor.

Best,

Nico


>
>
> I welcome your opinions.
>
> Wayne Brown
> Apogee Instruments Inc.
> www.ccd.com

[Joachim Wesner]

Hi list,

> So yes, please produce software that interfaces with IJ.
> Rather than plugins that put up a dialog with buttons where one has to
click
> to capture, we need functions to control the camera which can be called
from
> IJ macros/plugins. If that is available, then one can create and modify
the
> capture software and capture images programmatically.

Exactly, I myself are now planning for already some time to write an Image
Acquisition plugin for the Matrox MIL,
so that it should work with a large number of different framegrabbers and
hence cameras
(however, too busy with other things).

One problem that considerably "slows down" the development process is that
I have not yet come down with
a good (minimum) set of generic functions such a plugin should support and
how. Also, in many cases, some
possibility to - if needed - also have a "live" preview window (likely
within a second thread) with buttons etc. without
too much extra programming would be very nice too.

While I also see the absolute need for full "remote control", there
definitely MUST not be a obligatory TWAIN window
that pops up for every image that you want to grab.

So my point here is, could we, the people working or interested in such
plugins probably agree on a common standard
of ImageJ callable methods and the corresponding functionality to base
future plugins on? This would help me, other
users (that again built grabbing plugins based on those standards) and
manufacturers like Wayne Brown.

Any suggestions how to start this?

Mit freundlichen Grüßen / Best regards

Joachim Wesner
Projektleiter Optik Technologiesysteme

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy
Martyr | Colin Davis



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[dksamuel]

Please produce software that interfaces with IJ, atleast for basic
image viewing and capture from a PC (maybe any generic USB consumer
Camera) thanks Samuel India


On 3/6/08, Joachim Wesner <[hidden email]> wrote:

> Hi list,
>
> > So yes, please produce software that interfaces with IJ.
> > Rather than plugins that put up a dialog with buttons where one has to
> click
> > to capture, we need functions to control the camera which can be called
> from
> > IJ macros/plugins. If that is available, then one can create and modify
> the
> > capture software and capture images programmatically.
>
> Exactly, I myself are now planning for already some time to write an Image
> Acquisition plugin for the Matrox MIL,
> so that it should work with a large number of different framegrabbers and
> hence cameras
> (however, too busy with other things).
>
> One problem that considerably "slows down" the development process is that
> I have not yet come down with
> a good (minimum) set of generic functions such a plugin should support and
> how. Also, in many cases, some
> possibility to - if needed - also have a "live" preview window (likely
> within a second thread) with buttons etc. without
> too much extra programming would be very nice too.
>
> While I also see the absolute need for full "remote control", there
> definitely MUST not be a obligatory TWAIN window
> that pops up for every image that you want to grab.
>
> So my point here is, could we, the people working or interested in such
> plugins probably agree on a common standard
> of ImageJ callable methods and the corresponding functionality to base
> future plugins on? This would help me, other
> users (that again built grabbing plugins based on those standards) and
> manufacturers like Wayne Brown.
>
> Any suggestions how to start this?
>
> Mit freundlichen Grüßen / Best regards
>
> Joachim Wesner
> Projektleiter Optik Technologiesysteme
>
> Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
> Wetzlar  HRB 2432
> Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy
> Martyr | Colin Davis
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

[Jon Harman-3]

Hi,

Are your images in color?

ImageJ uses the Sun jpeg writer with the default settings.  By default
these settings subsample colors, but not brightness.  This results in
significant degradation of the colors in an image, but to human eyes in
a color photo this is not noticeable.

For color medical images I would think this is not a good idea.

Jpeg may not be the best image compression algorithm, but its use on the
web is overwhelming.

Maybe a solution is to add a choice to the jpeg I/O options:
Disable color subsampling.

For ImageJ I think compression size is less important than quality.  So
I would recommend that the default for ImageJ should be to not do
subsampling.


Jon

Gwen Barnes wrote:

> Hi,
>
> I'm have a question about saving images as jpg.  I set the quality to 100
> under "edit, options, I/O options", but still, when I save a tiff as a jpeg,
> I end up with jpeg artifacts.  If I use other programs, and save the same
> tiff as a quality 100 jpg, I don't get the artifacts.  Is there a way to
> save a full quality jpeg in ImageJ?  Any ideas what I need to do
> differently?  Thanks.
>
> -Gwen
>

[Gwen Barnes]

That's the answer I was looking for, thanks!  It might also explain what I
was seeing in the images.  They're grayscale initially, but I annotate them
with colored lines.  It seemed to be the colored lines that were getting
blurred, but the rest of the image seemed unaffected.  For now I simply
won't use save as jpeg in imagej.  However, I would use a "turn off sub
sampling" option such as you mention, if one were added.

-Gwen

On Thu, Mar 6, 2008 at 8:18 AM, Jon Harman <[hidden email]>
wrote:

> Hi,
>
> Are your images in color?
>
> ImageJ uses the Sun jpeg writer with the default settings.  By default
> these settings subsample colors, but not brightness.  This results in
> significant degradation of the colors in an image, but to human eyes in
> a color photo this is not noticeable.
>
> For color medical images I would think this is not a good idea.
>
> Jpeg may not be the best image compression algorithm, but its use on the
> web is overwhelming.
>
> Maybe a solution is to add a choice to the jpeg I/O options:
> Disable color subsampling.
>
> For ImageJ I think compression size is less important than quality.  So
> I would recommend that the default for ImageJ should be to not do
> subsampling.
>
>
> Jon
>
> Gwen Barnes wrote:
> > Hi,
> >
> > I'm have a question about saving images as jpg.  I set the quality to
> 100
> > under "edit, options, I/O options", but still, when I save a tiff as a
> jpeg,
> > I end up with jpeg artifacts.  If I use other programs, and save the
> same
> > tiff as a quality 100 jpg, I don't get the artifacts.  Is there a way to
> > save a full quality jpeg in ImageJ?  Any ideas what I need to do
> > differently?  Thanks.
> >
> > -Gwen
> >
>

[ctrueden]

Hi Joachim,


> So my point here is, could we, the people working or interested in such
> plugins probably agree on a common standard
> of ImageJ callable methods and the corresponding functionality to base
> future plugins on? This would help me, other
> users (that again built grabbing plugins based on those standards) and
> manufacturers like Wayne Brown.
>
> Any suggestions how to start this?
>

Such an infrastructure is (among other things) what Micro-Manager provides,
right? Or have I misunderstood what you are asking for?

-Curtis

On Thu, Mar 6, 2008 at 2:51 AM, Joachim Wesner <
[hidden email]> wrote:

> Hi list,
>
> > So yes, please produce software that interfaces with IJ.
> > Rather than plugins that put up a dialog with buttons where one has to
> click
> > to capture, we need functions to control the camera which can be called
> from
> > IJ macros/plugins. If that is available, then one can create and modify
> the
> > capture software and capture images programmatically.
>
> Exactly, I myself are now planning for already some time to write an Image
> Acquisition plugin for the Matrox MIL,
> so that it should work with a large number of different framegrabbers and
> hence cameras
> (however, too busy with other things).
>
> One problem that considerably "slows down" the development process is that
> I have not yet come down with
> a good (minimum) set of generic functions such a plugin should support and
> how. Also, in many cases, some
> possibility to - if needed - also have a "live" preview window (likely
> within a second thread) with buttons etc. without
> too much extra programming would be very nice too.
>
> While I also see the absolute need for full "remote control", there
> definitely MUST not be a obligatory TWAIN window
> that pops up for every image that you want to grab.
>
> So my point here is, could we, the people working or interested in such
> plugins probably agree on a common standard
> of ImageJ callable methods and the corresponding functionality to base
> future plugins on? This would help me, other
> users (that again built grabbing plugins based on those standards) and
> manufacturers like Wayne Brown.
>
> Any suggestions how to start this?
>
> Mit freundlichen Grüßen / Best regards
>
> Joachim Wesner
> Projektleiter Optik Technologiesysteme
>
> Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
> Wetzlar  HRB 2432
> Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David
> Roy
> Martyr | Colin Davis
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

[Nico Stuurman-4]

Hi Joachim,

> Exactly, I myself are now planning for already some time to write an  
> Image
> Acquisition plugin for the Matrox MIL,
> so that it should work with a large number of different  
> framegrabbers and
> hence cameras
> (however, too busy with other things).
>
> One problem that considerably "slows down" the development process  
> is that
> I have not yet come down with
> a good (minimum) set of generic functions such a plugin should  
> support and
> how. Also, in many cases, some
> possibility to - if needed - also have a "live" preview window (likely
> within a second thread) with buttons etc. without
> too much extra programming would be very nice too.
>
> While I also see the absolute need for full "remote control", there
> definitely MUST not be a obligatory TWAIN window
> that pops up for every image that you want to grab.
>
> So my point here is, could we, the people working or interested in  
> such
> plugins probably agree on a common standard
> of ImageJ callable methods and the corresponding functionality to base
> future plugins on? This would help me, other
> users (that again built grabbing plugins based on those standards) and
> manufacturers like Wayne Brown.
>
> Any suggestions how to start this?

These were exactly the kind of problems we tried to address in our  
Micro-Manager (http://micro-manager.org) project.  Thus, we developed  
a simple, minimal API for a few device types commonly used in  
microscopy (cameras, stages, state devices, shutters, communication  
ports) and allowed for infinite extensions through 'Properties'.  This  
mechanism ensures that any camera will expose the same, common, set of  
capabilities to the API but can also expose anything else it finds  
useful.

Anything that can interface with the Micro-Manager Core (which  
includes our own GUI that is an ImageJ plugin, but can also be other  
ImageJ plugins, beanshell scripts, matlab scripts, or - in principle -  
other scripting languages like for instance Python) can use this API  
to interface to all the different hardware for which a Micro-Manager  
'adapter' (the code interfacing between the device or device driver  
and the Micro-Manager Core) exists (for a list see http://valelab.ucsf.edu/~nico/MMwiki/index.php/Device_Support)
.

The Micro-Manager GUI has  a live preview window, live histogram, ROI  
tool, auto-shutter, and also has facilities for setting up time-
lapses, z-stack, multi-channel images, multi-position images and live  
split view mode.  We are about to add a better programmatic interface  
to these more advanced features, making it easy to script your own  
multi-dimensional acquisition.

So, writing a Micro-Manager adapter for the Matrix MIL card (or for  
Apogee cameras) will instantly yield all this functionality and let  
anyone integrate this camera/frame grabber card into a complex  
microscope set-up.  Writing these adapters is quite straight forward,  
in part because there are many examples, in part because they are  
written in C++ which usually interfaces easily with the device SDK  
(the JNI step is taken care of by Micro-Manager at a higher level) and  
allows for debugging/testing in a C/C++ only environment.


Best regards,

Nico Stuurman

>
>
> Mit freundlichen Grüßen / Best regards
>
> Joachim Wesner
> Projektleiter Optik Technologiesysteme
>
> Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
> Wetzlar  HRB 2432
> Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr.  
> David Roy
> Martyr | Colin Davis
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

[Gabriel Landini]

On Thursday 06 March 2008, Nico Stuurman wrote:
> (the code interfacing between the device or device driver
> and the Micro-Manager Core) exists (for a list see
> http://valelab.ucsf.edu/~nico/MMwiki/index.php/Device_Support) .

Just for the record, I tried today the latest micromanager with the QCam
driver and a Qimaging Micropublisher 3Mpixels camera (colour) under windows
and it does not work.

So perhaps it could be corrected here, where it says "It should work with all
Qimaging cameras":

http://valelab.ucsf.edu/~nico/MMwiki/index.php/QCam

Regards,

Gabriel

[Joachim Wesner]

Nico, Curtis, sorry for my ignorance!!

I will take a detailed look at MicroManager and see how easy I can make a
Matrox/MIL plugin. Actually,
what I need is not so much miscrocopy oriented, but more around
interferogram analysis and judging
image quality (PSF, MTF), but it should be helpful too.

Cheers

Mit freundlichen Grüßen / Best regards

Joachim Wesner
Projektleiter Optik Technologiesysteme

Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
Wetzlar  HRB 2432
Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David Roy
Martyr | Colin Davis


                                                                           
             Curtis Rueden                                                
             <[hidden email]                                            
             U>                                                         An
             Gesendet von:              [hidden email]                
             ImageJ Interest                                         Kopie
             Group                                                        
             <[hidden email].                                       Thema
             GOV>                       Re: ImageJ for image capture      
                                                                           
                                                                           
             06.03.2008 17:48                                              
                                                                           
                                                                           
              Bitte antworten                                              
                    an                                                    
              ImageJ Interest                                              
                   Group                                                  
             <[hidden email].                                            
                   GOV>                                                    
                                                                           
                                                                           




Hi Joachim,


> So my point here is, could we, the people working or interested in such
> plugins probably agree on a common standard
> of ImageJ callable methods and the corresponding functionality to base
> future plugins on? This would help me, other
> users (that again built grabbing plugins based on those standards) and
> manufacturers like Wayne Brown.
>
> Any suggestions how to start this?
>

Such an infrastructure is (among other things) what Micro-Manager provides,
right? Or have I misunderstood what you are asking for?

-Curtis

On Thu, Mar 6, 2008 at 2:51 AM, Joachim Wesner <
[hidden email]> wrote:

> Hi list,
>
> > So yes, please produce software that interfaces with IJ.
> > Rather than plugins that put up a dialog with buttons where one has to
> click
> > to capture, we need functions to control the camera which can be called
> from
> > IJ macros/plugins. If that is available, then one can create and modify
> the
> > capture software and capture images programmatically.
>
> Exactly, I myself are now planning for already some time to write an

Image
> Acquisition plugin for the Matrox MIL,
> so that it should work with a large number of different framegrabbers and
> hence cameras
> (however, too busy with other things).
>
> One problem that considerably "slows down" the development process is
that
> I have not yet come down with
> a good (minimum) set of generic functions such a plugin should support
and

> how. Also, in many cases, some
> possibility to - if needed - also have a "live" preview window (likely
> within a second thread) with buttons etc. without
> too much extra programming would be very nice too.
>
> While I also see the absolute need for full "remote control", there
> definitely MUST not be a obligatory TWAIN window
> that pops up for every image that you want to grab.
>
> So my point here is, could we, the people working or interested in such
> plugins probably agree on a common standard
> of ImageJ callable methods and the corresponding functionality to base
> future plugins on? This would help me, other
> users (that again built grabbing plugins based on those standards) and
> manufacturers like Wayne Brown.
>
> Any suggestions how to start this?
>
> Mit freundlichen Grüßen / Best regards
>
> Joachim Wesner
> Projektleiter Optik Technologiesysteme
>
> Leica Microsystems CMS GmbH | GmbH mit Sitz in Wetzlar | Amtsgericht
> Wetzlar  HRB 2432
> Geschäftsführer:  Dr. Stefan Traeger | Dr. Wolf-Otto Reuter | Dr. David
> Roy
> Martyr | Colin Davis
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Nico Stuurman-4]

Hi Gabriel,

> On Thursday 06 March 2008, Nico Stuurman wrote:
>> (the code interfacing between the device or device driver
>> and the Micro-Manager Core) exists (for a list see
>> http://valelab.ucsf.edu/~nico/MMwiki/index.php/Device_Support) .
>
> Just for the record, I tried today the latest micromanager with the  
> QCam
> driver and a Qimaging Micropublisher 3Mpixels camera (colour) under  
> windows
> and it does not work.

Sorry about that.  It does say elsewhere that Micro-Manager only works  
with monochrome cameras.  We have been working a bit on color cameras,  
but need more time to finish that project.

> So perhaps it could be corrected here, where it says "It should work  
> with all
> Qimaging cameras":
>
> http://valelab.ucsf.edu/~nico/MMwiki/index.php/QCam

It is corrected now.  By the way, the wiki is open, so you can make  
these kind of corrections yourself too!

Best,


Nico


>
>
> Regards,
>
> Gabriel

[Joachim Wesner]

Hi again,

is there a printable version (PDF) of the documentation? (Users/Programmers
Guide etc.)

I really don´t like to work off printed HTML pages, even fancy ones!

Sincerely

Joachim


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________