forums.silverfrost.com

[Norm.Campbell]

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.

[jalih]

[Norm.Campbell]

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.

[jalih]

[Norm.Campbell]

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 )

[Wilfried Linder]

"Call to missing routine":

[Norm.Campbell]

Many thanks, Wilfried

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

Cheers

Norm

[JohnCampbell]

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

[Norm.Campbell]

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

[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.

[PaulLaidler]

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.

[Norm.Campbell]

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.

[PaulLaidler]

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.

[Norm.Campbell]

Fair enough.

What about the code that lies behind GET_DIB_*?

[PaulLaidler]

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.