writing a jpeg file

Can anyone point me in the direction of some (Fortran) code to write lots of jpeg files from within a program.

Each integer array is relatively small -- one or two bytes and around 10000 columns x 5000 rows.

Currently, I've developed code to write the arrays to TIFF, and then I'm converting the images to JPEG, but it's too time consuming to do that in practice.

Quoted from Norm.Campbell Can anyone point me in the direction of some (Fortran) code to write lots of jpeg files from within a program.

How about using .NET and it's Bitmap class to to do this?

I think it would go something like:

1. Create a new Bitmap
2. Lock the bitmap's bits
3. Copy the image data into bitmap
4. Unlock the bitmap's bits
5. Save bitmap as jpg file

Hope this helps...

Thanks for making me think a bit differently.

From my quick read, PUT_DIB_BLOCK@ should be able to write a 1-byte RGB array, converted to char ( nval ), straight to a JPEG file.

Two questions:

I read in earlier posts that there was a problem in writing to JPEGs rather than BMPs. Has this been resolved?

Is there a routine that only handles a GREY-level input array? I'm trying to convert to JPEG because my TIFF files are too large.

Quoted from Norm.Campbell

Is there a routine that only handles a GREY-level input array? I'm trying to convert to JPEG because my TIFF files are too large.

Do you have any example data available somewhere? I might give it a try using .NET based approach...

Hi Paul

Should the code snippet below work? That is, can I create my own character array, and if so, have I done it correctly?

Why isn't my code loading PUT_DIB_BLOCK@ when I use

ftn95 /intl /dreal EMxxx_wcd_headers.for > ftn_compile.out /link

I get Error 29 Call to missing routine: _PUT_DIB_BLOCK#

Cheers

Norm

  integer *4 n_X_samples, n_Z_samples, nzr, n_X_W, n_Z_H, ndy, nerr

  character, Allocatable :: ch_BS_beam_sample ( : , : , : )

  Allocate ( ch_BS_beam_sample ( 3, nbr_X_samples ,  nbr_Z_samples ))

        do ico = 1, nbr_X_samples

           do irw = 1, nbr_Z_samples
             
              nBackscatter = n_BS_beam_sample(ico,irw)
             
              ch_BS_beam_sample(1,ico,irw)
 1                     = char ( 127 + nBackscatter )
             
              ch_BS_beam_sample(2,ico,irw)
 1                     = char ( 127 + nBackscatter )
             
              ch_BS_beam_sample(3,ico,irw)
 1                     = char ( 127 + nBackscatter )

           end do
           
        end do      

        nzr = 0
        
        n_X_samples = nbr_X_samples
        
        n_Z_samples = nbr_Z_samples 
        
        n_X_W = nbr_X_samples
        
        n_Z_H = nbr_Z_samples
        
        call PUT_DIB_BLOCK@ ( flno, ch_BS_beam_sample, 
 1                            n_X_samples, n_Z_samples,
 2                            nzr, nzr,
 3                            n_X_W, n_Z_H,
 4                            ndy, nerr )

'Call to missing routine':

      INCLUDE <WINDOWS.INS>

should solve the problem.

Regards - Wilfried

Many thanks, Wilfried

My code works fine. What a simple way to write a JPEG file!

Cheers

Norm

Norm,

One of the problems I have had with .jpg files is the compression or quality of the image. When dumping a screen to a .jpg file (using EXPORT_IMAGE@), there is an option SET_JPEG_QUALITY@. I don't know if it also applies to PUT_DIB_BLOCK@. You might want to check if you have any control of this for when you later wish to retrieve the information. The following is the note associated with EXPORT_IMAGE@:

Notes The quality of a JPEG image exported by EXPORT_IMAGE@ can be changed by calling the function SET_JPEG_QUALITY@ as follows:

REAL(KIND=2) FUNCTION SET_JPEG_QUALITY@( Q ) REAL(KIND=2) Q

Q is an input value in the range from 0.01D0 to 1.0D0 (use steps of 0.01). The function returns the old value should you wish to restore it afterwards. The default value of Q is 0.75D0

John

I'm having a problem with

     call GET_DIB_SIZE@ ( flnm, 
 1                        npxl, nlne,
 2                        nbpp, nerr )

     write (itt,'( '' jpeg width, height, # bytes : '', 3i6 )' )
 1                    npxl, nlne, nbpp

for a JPEG file, flnm = 'IMG_9382.jpg'; the code is returning zero for the width and height.

When I run it on the file, flnm = 'IMG_9382_L6.jpg', I get the correct width and height.

The latter file was created by reading the former into Photoshop, and exporting it as 'IMG_9382_L6.jpg.

I've copied the files across to

\\ftp.csiro.au\NormCampbell\digital still jpeg files

Would it be possible for someone to have a look at the file and GET_DIB_SIZE@ and tell me what I'm doing wrong.

Norm Campbell

I should have added that the problem seems to be with the way GET_DIB_* recognises (or fails to recognise) the file structure.

When I bypass GET_DIB_SIZE by setting the file size in the code,

then call GET_DIB_BLOCK@ ( flnm, ch_refl_P_L, npxl, nlne, nzr, nzr, npxl, nlne, nzr, nzr, nerr )

returns the same value for all elements in the array ( ichar ( ) = 0 or 128, depending on whether I run with or without sdbg) for the original file, and the correct values for the Photoshop-exported file.

I seem to recall that this issue has been raised before on this Forum. Try a search.

It is possible that the original files do not conform to standard (or at least the standard in place when the code was added to ClearWin+).

The error code returned by get_dib_size@ should be either zero for success or 2 for 'Bad read'.

nbpp is invariably 24.

Hi Paul

It was probably me that raised it before, since I had a similar problem some time back. I got around that by reading the important files into Photoshop, and exporting them. But this time there are simply too many.

Would you (or someone) have the time to do a dump of the offending file, and see where it differs from the 'standard' that GET_DIB_* is expecting?

Or (less preferable, as I'm not a programmer) perhaps you could send me the code that reads the JPEG file, and I'll see if I can work out what the problem is.

Clearly the file I've copied to the ftp site is sufficiently standard that Photoshop is able to read it.

Sorry but that would be a significant task. I am not sure that we could offer to do that anyway but at the moment the pressure is on to get a 64 bit release of FTN95 out as soon as possible.

Fair enough.

What about the code that lies behind GET_DIB_*?

Sorry but I am not in a position to be able to release this code. In the present case I am fairly sure that it would not help anyway.

Hi Paul

This problem has arisen again, this time with 10000s of jpeg files dumped from an AVI file.***

The files can be read by code written in C by a colleague who uses the standard jpeg library files, so the problem is with GET_DIB_*.

Is there any chance of seeing whether there is a simple fix, or whether the solution is more time consuming?

*** If someone has code for reading the individual frames from an AVI file, and writing them as jpegs, that would solve the immediate problem.

How about http://www.dvdvideosoft.com/products/dvd/Free-Video-to-JPG-Converter.htm

It is the Free-Video-to-JPG-Converter that is outputting the heavily-compressed jpegs that GET_DIB_* can't read. GET_DIB_* doesn't recognise the content of these jpegs (nor those from a number of other AVI > jpeg converters).

What I need to do is read the outputted jpegs, stretch the intensity values to maximise the colour range (and possibly also remove the differential illumination effect), and write a new set of jpegs.

If I read a jpeg into Photoshop and export it as a jpeg, then GET_DIB_* works fine.

I've had problems with jpegs from one type of camera which could not be read by the FTN95 routines. I used the batch processing facility of Irfanview (it is free) which allows conversion of one type if image to others but it will change jpegs to jpegs with the only change being that the when it writes out the converted, it can be read by the FTN95 system. Ian So basically if you open Irfanview and drop one image onto it, pres 'T' for the thumbnail view, select everything and use the 'File, Start Batch process with selected items' option of the thumbnail window. and hit the process button. It will remember your settings for next time.

Thanks, Ian, that could be a reasonable solution in the short term.

At present I have to convert all the files to uncompressed tiffs, using some C code that a colleague has written based on the standard jpeg library, and then use my own code to read the tiffs, process the files, and output them as jpegs.

This is messy, and I still think that Silverfrost should modify GET_DIB_* so that it can handle jpegs that conform to the current jpeg standards.

Norm