Board index » delphi » D3 TBitmap and odd sizes and JPEG->BMP

D3 TBitmap and odd sizes and JPEG->BMP

I have a TBitmap that I create at startup. When I use the NViewLib to
load a jpeg and then use the TBitmap to save it as a bmp, two things
occur:
1) The jpeg was 640x480 and 34k; the bmp saves as the same dimensions
but comes out at 1,201 kb.
2) It has a blue cast, rather like it had been filtered.

What I want to do is convert jpeg's that I have into 256-color bmp's to
store in a FoxPro database (no, I have no option about the db format,
it's a legacy system and stinks), and approx 3000 of them.

I tried using the jpeg library that ships with Delphi 3, but converting
a jpeg to bmp using that seems impossible.

What I did was to place an image on the form (as I could noy figure out
how to use a TBitmap to do this) and LoadFromFile'd a jpeg.

Than I assigned the Image1.Picture.Graphic to a TBitmap that was
instantiated at FormCreate. Then SaveToFile'd the bitmap, which gave the
problems {1) and 2)}  mentioned above.

When I tried instantiating both a TBitmap and a TJpegImage, it took ages
but worked. It seems that with a TJpegImage it has to be created and
destroyed every time, because LoadFromFile will not load a new file into
the TJpegImage if it already contains an image.

Any help with this please? What's the best and quickest way to do this,
as we will be having loads more images to process?

 

Re:D3 TBitmap and odd sizes and JPEG->BMP


Hi,
Two things.  First, why not use an FLL to view the jpegs?  (We sell
one.)  Two, if you are going from jpeg to 256 color bmps, be careful as
color mapping is not a strongpoint of the free jpeg stuff.  Our VCL will
do it, or I can give you a windows batch utility that will do 3000
images in about 3000 seconds, with excellent color control.
Let me know,
jack
--
********************************************************************
      Jack Berlin - http://www.jpg.com/ - 813-875-7575 x303
      Note that email address is modified to avoid spammers
          Pegasus Imaging Corp - the BETTER JPEG people!
********************************************************************

Quote
p...@goldstyle.demon.co.uk wrote:

> I have a TBitmap that I create at startup. When I use the NViewLib to
> load a jpeg and then use the TBitmap to save it as a bmp, two things
> occur:
> 1) The jpeg was 640x480 and 34k; the bmp saves as the same dimensions
> but comes out at 1,201 kb.
> 2) It has a blue cast, rather like it had been filtered.

> What I want to do is convert jpeg's that I have into 256-color bmp's to
> store in a FoxPro database (no, I have no option about the db format,
> it's a legacy system and stinks), and approx 3000 of them.

> I tried using the jpeg library that ships with Delphi 3, but converting
> a jpeg to bmp using that seems impossible.

> What I did was to place an image on the form (as I could noy figure out
> how to use a TBitmap to do this) and LoadFromFile'd a jpeg.

> Than I assigned the Image1.Picture.Graphic to a TBitmap that was
> instantiated at FormCreate. Then SaveToFile'd the bitmap, which gave the
> problems {1) and 2)}  mentioned above.

> When I tried instantiating both a TBitmap and a TJpegImage, it took ages
> but worked. It seems that with a TJpegImage it has to be created and
> destroyed every time, because LoadFromFile will not load a new file into
> the TJpegImage if it already contains an image.

> Any help with this please? What's the best and quickest way to do this,
> as we will be having loads more images to process?

Re:D3 TBitmap and odd sizes and JPEG->BMP


Quote
> What I want to do is convert jpeg's that I have into 256-color bmp's to
> store in a FoxPro database (no, I have no option about the db format,
> it's a legacy system and stinks), and approx 3000 of them.

Do I understand well if I say you only need the bmp files resulting from
a plain transformation of jpeg files?... In other words, you do not have
to put a specific treatment, action or filter on the transformed
files?...

Well, why don't you try and use Paint Shop Pro which does batch
transformations from a image format to another?...

--
Jean-Yves TOUMIT.

mailto:jtou...@rfv.insa-lyon.fr
http://rfv-pc28.insa-lyon.fr

Re:D3 TBitmap and odd sizes and JPEG->BMP


Quote
p...@goldstyle.demon.co.uk wrote:

> I have a TBitmap that I create at startup. When I use the NViewLib to
> load a jpeg and then use the TBitmap to save it as a bmp, two things
> occur:
> 1) The jpeg was 640x480 and 34k; the bmp saves as the same dimensions
> but comes out at 1,201 kb.

        Wow. If you do the arithmetic this comes out to 4 bytes per pixel.
NViewLib must be saving these things as 32-bit bitmaps. I'd heard about
32-bit bitmaps but never seen one.

Quote
> 2) It has a blue cast, rather like it had been filtered.

        Maybe whatever you're using to look at them is confused by the
32-bit-per-pixel format?

        If you want smaller files you need to reduce the number of colors
in the bitmap one way or another.

Quote
> What I want to do is convert jpeg's that I have into 256-color bmp's to
> store in a FoxPro database (no, I have no option about the db format,
> it's a legacy system and stinks), and approx 3000 of them.

> I tried using the jpeg library that ships with Delphi 3, but converting
> a jpeg to bmp using that seems impossible.

        All you have to do is say

var J: TJPEGImage; b: TBitmap;
begin
 J:= TJPEGImage.Create;
 b:= TBitmap.Create;
 b.PixelFormat:= pf24Bit;
 J.LoadfromFile('whatever.jpg');
 b.Assign(J);
 b.SaveToFile('whatever.bmp');
 J.Free;
 b.Free;
end;

        I'm pretty sure you don't need to set the PixelFormat that way,
I believe it should happen automatically when you assign the jpeg to the
bmp. But it can't hurt.

        This doesn't take forever as you state below, it's as fast as you
could expect. You'll get a 24-bit bmp file if you do this, should be
3/4 the size of the bmps you describe above.

        NOTE: What I just said works works. Code that you think does the
same thing may or may not work (I've been getting a lot of comments
about how what I say doesn't work, when in fact what doesn't work
is something other than what I said. Try _exactly_ the above before
deciding that it doesn't work or that it takes a long time.)

        NOTE: If you want smaller bitmaps then you need to reduce
the colors - first you have to decide what palette you want and
then dither. Possibly you'll be happier using a third-party library
for this anyway. But what you say about converting TJPEGImage to
TBitmap just isn't so - it works perfectly and very fast, I do it
all the time.

Quote
> What I did was to place an image on the form (as I could noy figure out
> how to use a TBitmap to do this) and LoadFromFile'd a jpeg.

        You should use a TImage for _displaying_ images. Using a
Timage just to do this sort of conversion wastes a lot of time
(drawing to the screen is slow). Also when you draw to the screen
you may get unwanted effects due to whatever color mode you're
in - if you do something as above ionstead your video driver
shouldn't come into the picture at all.
        If someday you want to load an unknown file type
(bmp or jpg) but you don't need to display it then the thing
to use is TPicture.

--
David Ullrich

sig.txt not found

Re:D3 TBitmap and odd sizes and JPEG->BMP


In article <34EDCF97.6...@math.okstate.edu>, David Ullrich
<ullr...@math.okstate.edu> writes

Quote
>p...@goldstyle.demon.co.uk wrote:

>> I have a TBitmap that I create at startup. When I use the NViewLib to
>> load a jpeg and then use the TBitmap to save it as a bmp, two things
>> occur:
>> 1) The jpeg was 640x480 and 34k; the bmp saves as the same dimensions
>> but comes out at 1,201 kb.
>       Wow. If you do the arithmetic this comes out to 4 bytes per pixel.
>NViewLib must be saving these things as 32-bit bitmaps. I'd heard about
>32-bit bitmaps but never seen one.

In fact, I slipped up there. Using the jpeg library gave me that result,
not the NViewLib, and on two diffrent machines (just in case there was
something else going on of which I know nothing).

The weired thing is that if I open the bmp's created with this in
PhotoImpact, I get the strange color cast. If Quikview is used, it reads
them correctly. Obviously PhotoImpact cannot handle 32-bits, if that is
the issue. I was wondering where the extra data came from, thanks for
the explanation.

Quote

>       All you have to do is say

>var J: TJPEGImage; b: TBitmap;
>begin
> J:= TJPEGImage.Create;
> b:= TBitmap.Create;
> b.PixelFormat:= pf24Bit;
> J.LoadfromFile('whatever.jpg');
> b.Assign(J);
> b.SaveToFile('whatever.bmp');
> J.Free;
> b.Free;
>end;

Yes, I have done this and it works fine. It is a bit impractical however
on large quantities of images. If I have not mentioned this before, they
are all 640x480. When I used NViewLib, which has several drawbacks on
other issues, the speed went up by at least 100%, if not a lot more.

Quote
>       I'm pretty sure you don't need to set the PixelFormat that way,
>I believe it should happen automatically when you assign the jpeg to the
>bmp. But it can't hurt.

The help says something to the effect that images loaded into a bitmap
will take on the same pixel format as in the jpeg. The jpegimage
pixelformat needs to be set to get the desired result in the bmp, in my
case being 8-bit color for storage reasons.

Quote

>       This doesn't take forever as you state below, it's as fast as you
>could expect. You'll get a 24-bit bmp file if you do this, should be
>3/4 the size of the bmps you describe above.

On a 64MB Pentium II 233 with SCSI HD it takes between .48 and .59 of a
second so far. 3000+ gives me almost 1/2 an hour for my coffee; a good
argument for running it on a 386 ;-).

Quote
>Code that you think does the
>same thing may or may not work (I've been getting a lot of comments
>about how what I say doesn't work,

Not from me, I assure you. Honestly. Hand-on-processor.

Quote
>       NOTE: If you want smaller bitmaps then you need to reduce
>the colors - first you have to decide what palette you want and
>then dither. Possibly you'll be happier using a third-party library
>for this anyway. But what you say about converting TJPEGImage to
>TBitmap just isn't so - it works perfectly and very fast, I do it
>all the time.

What I found really strange was that if I put a TImage on the form and
include the jpeg unit in the uses, the image will happily load jpegs and
bmp's one after another until I assign the Image to a TBitmap, after
which the TImage no longer loaded a new image using LoadFromFile.

Quote

>> What I did was to place an image on the form (as I could noy figure out
>> how to use a TBitmap to do this) and LoadFromFile'd a jpeg

This is because a TBitmap will not load a jpeg like a TImage will.

Quote
>       You should use a TImage for _displaying_ images. Using a
>Timage just to do this sort of conversion wastes a lot of time
>(drawing to the screen is slow).

I set the TImage to invisible, so the drawing issues should be resolved.

What really annoys me is the fact that .fpt files are *not* supported
natively the way Borland claims. I have to store these iamges in a
FoxPro table for historical reasons, but having set the Levels to 25 as
per the Borland advice I was still unable to enter or retrieve images to
the table. Blah, Borland!! (sound of raspberry being blown)
--
Dani Epstein

Re:D3 TBitmap and odd sizes and JPEG->BMP


Quote
Dani Epstein wrote:
> [...]

> >       All you have to do is say

> >var J: TJPEGImage; b: TBitmap;
> >begin
> > J:= TJPEGImage.Create;
> > b:= TBitmap.Create;
> > b.PixelFormat:= pf24Bit;
> > J.LoadfromFile('whatever.jpg');
> > b.Assign(J);
> > b.SaveToFile('whatever.bmp');
> > J.Free;
> > b.Free;
> >end;

> Yes, I have done this and it works fine. It is a bit impractical however
> on large quantities of images. If I have not mentioned this before, they
> are all 640x480. When I used NViewLib, which has several drawbacks on
> other issues, the speed went up by at least 100%, if not a lot more.

        I don't believe that NViewLib is converting those jpegs to
24-bit bitmap bitmaps 100% faster than this does. I believe that
you could be using code that you _think_ is the same as this that's
a lot slower.

Quote
> >       I'm pretty sure you don't need to set the PixelFormat that way,
> >I believe it should happen automatically when you assign the jpeg to the
> >bmp. But it can't hurt.

> The help says something to the effect that images loaded into a bitmap
> will take on the same pixel format as in the jpeg. The jpegimage
> pixelformat needs to be set to get the desired result in the bmp, in my
> case being 8-bit color for storage reasons.

        ??? Are you saying you have 8-bit (color, not grayscale) jpegs?
There's no such thing, so that can't be what you mean. (Unless you
_are_ talking about grayscale jpeg's - that would be different.)

        You say "The jpegimage pixelformat needs to be set to get
the desired result in the bmp, in my case being 8-bit color for storage
reasons.". Yes, TJPEGImag does have a PixelFormat property. The
data in the jpg file is 24-bit (unless it's grayscale). Presumably
setting pixelformat:= 8Bit does some dithering - that would be why
it takes so long(?)
        Except if you're doing that then you're going to get 8-bit
bmps for output, not 32-bit bmps. A lot of your story makes no
sense. (When NViewLib does it all 100% faster is it outputting
8-bit or 24-bit bitmaps? If you're getting 24-bit or 32-bit bitmaps
from NViwLib but 8-bit bitmaps from Delphi then that would explain
why the Delphi version is slower, it's doing much more work.)

- Show quoted text -

Quote

> >       This doesn't take forever as you state below, it's as fast as you
> >could expect. You'll get a 24-bit bmp file if you do this, should be
> >3/4 the size of the bmps you describe above.

> On a 64MB Pentium II 233 with SCSI HD it takes between .48 and .59 of a
> second so far. 3000+ gives me almost 1/2 an hour for my coffee; a good
> argument for running it on a 386 ;-).

> >Code that you think does the
> >same thing may or may not work (I've been getting a lot of comments
> >about how what I say doesn't work,

> Not from me, I assure you. Honestly. Hand-on-processor.

> >       NOTE: If you want smaller bitmaps then you need to reduce
> >the colors - first you have to decide what palette you want and
> >then dither. Possibly you'll be happier using a third-party library
> >for this anyway. But what you say about converting TJPEGImage to
> >TBitmap just isn't so - it works perfectly and very fast, I do it
> >all the time.

> What I found really strange was that if I put a TImage on the form and
> include the jpeg unit in the uses, the image will happily load jpegs and
> bmp's one after another until I assign the Image to a TBitmap, after
> which the TImage no longer loaded a new image using LoadFromFile.

        Does this mean that you're using a TImage to convert jpg's
to bitmaps? If _that's_ what you're doing I believe that it's slower
than using NViewLib. Why not try the code I suggested instead.

        If you _are_ using a TImage then don't say any more about
how slow the code I suggested is until you've TRIED it.

Quote

> >> What I did was to place an image on the form (as I could noy figure out
> >> how to use a TBitmap to do this) and LoadFromFile'd a jpeg

> This is because a TBitmap will not load a jpeg like a TImage will.

> >       You should use a TImage for _displaying_ images. Using a
> >Timage just to do this sort of conversion wastes a lot of time
> >(drawing to the screen is slow).

> I set the TImage to invisible, so the drawing issues should be resolved.

        An invisible TImage is still a component. And I _think_ that an
invisible TImage still maintains an internal bitmap to display when
it becomes visible. This would make it a lot slower than a TBitmap.

        Pardon my skepticism, but (unless you're talking about grayscale
jpgs) I _know_ that there's at least one spot where what you're doing
is _not_ what you say you're doing. HAVE you tried using code EXACTLY
like what I posted to do this conversion? Not code that "obviously"
does the same thing, code that's identical to what I posted???

        If you're using a TImage don't - try what I suggested instead.
        Whatever you _are_ doing, when you compare the Delphi and the
NViewLib routines are you making certain first that they're doing the
same thing?

--
David Ullrich

sig.txt not found

Re:D3 TBitmap and odd sizes and JPEG->BMP


In article <34F1D095.4...@math.okstate.edu>, David Ullrich
<ullr...@math.okstate.edu> writes

Quote
>Dani Epstein wrote:
>> [...]
>       I don't believe that NViewLib is converting those jpegs to
>24-bit bitmap bitmaps 100% faster than this does. I believe that
>you could be using code that you _think_ is the same as this that's
>a lot slower.

If I do this:

AJpeg:=TJpegObject.Create;
AJpeg.LoadFromFile('Whatever.jpg');
Image1.Picture.Assign(AJpeg);
AJpeg.Free;

and stick it in a loop, it takes approximately twice as long than if I
simply stick this in a loop:

Image1.Picture.LoadFromFile('Whatever.jpg');

and both do the identical function. What I find really strange that if I
try to put this in a loop:

Image1.Picture.LoadFromFile('Whatever.jpg');
ABitmap.Assign(Image1.Picture); (either Image1.Picture or
.Picture.Bitmap; I can't remember off thetop of my head)
ABitmap.SaveToFile('whatever.bmp');

the TImage will only load a jpeg *once*, thereafter the picture remains
the same. What have I missed here?

On the subject of NVviewLib, what I did was used it to load a jpeg into
a bitmap.canvas having set the pixelformat of the bitmap to pf8bit which
is 256 color, and saved it as a bmp.

This worked out quicker than creating a TJpegImage, loading a file into
it, assigning it to a Tbitmap, saving the bitmap to file, freeing the
TJpegImage and then the bitmap. Of course it is quite likely that my
code is {*word*99}, but I wonder whether it is possible that the Delphi jpeg
object is a little slow?

Quote

>> >       I'm pretty sure you don't need to set the PixelFormat that way,
>> >I believe it should happen automatically when you assign the jpeg to the
>> >bmp. But it can't hurt.

Yes, the pixel format only ha to be set in the jpeg if you want to
choose between jf8bit or jf24bit; in my case I wanted to reduce the
colors of a 24-bit jpeg to an 8-bit bmp.

Quote
>       ??? Are you saying you have 8-bit (color, not grayscale) jpegs?
>There's no such thing, so that can't be what you mean. (Unless you
>_are_ talking about grayscale jpeg's - that would be different.)

I feel rather obtuse :-(. I am probably confusing 256-color bitmaps with
8-bit. I was under the impression that 256-color and 8-bit color were
one and the same.

Quote

>       You say "The jpegimage pixelformat needs to be set to get
>the desired result in the bmp, in my case being 8-bit color for storage
>reasons.". Yes, TJPEGImag does have a PixelFormat property. The
>data in the jpg file is 24-bit (unless it's grayscale). Presumably
>setting pixelformat:= 8Bit does some dithering - that would be why
>it takes so long(?)

Yes, that's probably why it takes so long, only if I use NViewLib to
load the jpeg into a TBitmap with the PixelFormat set to 8-bit, it
appears to work quicker. Perhaps it is only a subjective "longer."

Quote

>       Except if you're doing that then you're going to get 8-bit
>bmps for output, not 32-bit bmps.

I am still trying to reproduce that 32-bit effect.

Quote
>A lot of your story makes no
>sense.

That's exactly what my therapist says to me.

Quote
>(When NViewLib does it all 100% faster is it outputting
>8-bit or 24-bit bitmaps? If you're getting 24-bit or 32-bit bitmaps
>from NViwLib but 8-bit bitmaps from Delphi then that would explain
>why the Delphi version is slower, it's doing much more work.)

NViewLib is outputting 24-bit to a TBitmap which has its PixelFormat set
to 8-bit.

Quote

>       Does this mean that you're using a TImage to convert jpg's
>to bitmaps? If _that's_ what you're doing I believe that it's slower
>than using NViewLib. Why not try the code I suggested instead.

No, I *tried* using a TImage to do that because the code is so much
simpler, but because of the problem outlined above (concerning loading a
fresh image after assigning to and saving from a TBitmap) in the end I
created a new TJpegImage for every conversion. Please accept my
apologies for not making myself sufficiently clear, but the code you
kindly suggested is precisely what I was using before starting this
thread.

Quote

>       If you _are_ using a TImage then don't say any more about
>how slow the code I suggested is until you've TRIED it.

I assure you that at no time did I mean to suggest the code you supplied
was in any way slow at all. As I state above, it is precisely what I
used in the end myself, and found to be rather sluggish.

Quote
>       Pardon my skepticism, but (unless you're talking about grayscale
>jpgs) I _know_ that there's at least one spot where what you're doing
>is _not_ what you say you're doing. HAVE you tried using code EXACTLY
>like what I posted to do this conversion? Not code that "obviously"
>does the same thing, code that's identical to what I posted???

Er, yes.
--
Dani Epstein

Other Threads