Re: [fpc-pascal] FPImage and mult-page TIFF support
In our previous episode, Mattias Gaertner said: > > Are there still no ways around the 64-bit storage format? I thought > > TLazintfImage was meant to be a step in that direction? > > There are various image formats (TLazintfImage, > TFPCompactImgRGBA8Bit, TFPCompactImgGrayAlpha8Bit, ..), so memory > consumption is as good as you want. I had meanwhile revisited the source, and it came back to me. The issues are (for e.g. fpreadbmp) - 1 method call per pixel to setpixel/setcolor - 1 virtual call per pixel to setpixel. - mandatory going through the various tfpcolor routines for shifting etc. - this all in a for loop without any optimization whatsoever. PCs are fast, but if you things like this and 64-bit arithmetic on millions of pixels individually you get already noticable delays in the human range. That said, I wouldn't change it. It is an existing interface and does cover many if not all cases. I would rather allow some bypasses for some extremely common cases in an extensible way. (so that people with special needs can $!@@ well implement their own) I thought about it a few years back, and the idea back then was to have something like: 1. have a event function that gets some src data and dest data info, and it is to return true if it is match. The match even could call information methods in the reader/writer and tcustimage again. The tfpcustimage level must implement this, and init it to nil (don't use) or some default for common cases. 2. if it is a match, it must return another event or adapter class that act for read as the readscanline/writescanline part of the bmpreader. This transfer class can also maintain its own custom buffer (readbmp.linebuf like) 3. the TFPCustomImage class needs some form of getlinepointer(y:integer) and maybe a way to check if it is safe to call. (since it might not make sense for some forms of images) However back then I was in a hurry, and I simply ported the PNG support subset that I need over, and didn't pursue or refine it further. I never looked beyond bmp and png needs to begin with. For me BMP is the base format because it works really well as a standarized header for raw pixel data. I only use png as a longer term storage format because of its compression in slower applications. (that can spare the time for compression) p.s. I've had long term sustained write speeds in excess of 100MByte/s in 2MB images on a Pentium D with a 15K raid array with only a mild buffer in its own thread. (Windows updating directory information might hold they system hundreds of ms, so you need to have some buffering at 50fps) with a setup much like this and a write format that matched pixeldata. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
Am 09.12.2016 10:05 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > The most widely used image editing software for X11 based > systems, The GIMP, doesn't even support 16bit color channel images. If I remember correctly the next major version of The GIMP is supposed to support 16-bit images and it's advertised as *the* feature. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Fri, 9 Dec 2016, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: Why FPImage uses 64bit per pixel is beyond me! The original author of FPImage clearly thought he/she saw something cool in that, but 99.9% of the time *nobody* needs that. It's causing more grief (and code to do conversions) than anything else. The 64bit is the maximum limit. I doubt the 99.9%. Image editing require more than 8bit per channel since decades. And that is why we decided to use 64-bit. I never got the one size to rule them all mentality. I understand that code for more complex code like advanced filters won't be written for various bitsizes and subformats. But run of the mills usage IMHO should be in the format closer to both disk and display. This is also a valid design choice. One we didn't make at the time. You can discuss for ages about it. It was decided at the time to use 64-bit for the API. To reduce memory usage, other storage formats have been introduced by e.g. Mattias. But the API remains 64 bit. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Fri, 9 Dec 2016 12:39:54 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: >[...] > Are there still no ways around the 64-bit storage format? I thought > TLazintfImage was meant to be a step in that direction? There are various image formats (TLazintfImage, TFPCompactImgRGBA8Bit, TFPCompactImgGrayAlpha8Bit, ..), so memory consumption is as good as you want. Maybe the docs should mention the alternatives of TFPMemoryImage more prominently. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
In our previous episode, Michael Van Canneyt said: > >> Why FPImage uses 64bit per pixel is beyond me! The original author of > >> FPImage clearly thought he/she saw something cool in that, but 99.9% > >> of the time *nobody* needs that. It's causing more grief (and code to do > >> conversions) than anything else. > > > > The 64bit is the maximum limit. I doubt the 99.9%. Image editing > > require more than 8bit per channel since decades. > > And that is why we decided to use 64-bit. I never got the one size to rule them all mentality. I understand that code for more complex code like advanced filters won't be written for various bitsizes and subformats. But run of the mills usage IMHO should be in the format closer to both disk and display. Simple Load,save,display of 24 and 32-bit RGBA are the bulk of the cases, with about 5 common storage permutations, some of which are not even supported by many programs. (but are by e.g. OpenGL) That said, for production I use own fcl-image derived png and bmp loaders for various performance and memory layout reasons for a decade, (industrial cameras can't seem to store 64-bit pixeldata) and I haven't researched recent fcl-image developments. Are there still no ways around the 64-bit storage format? I thought TLazintfImage was meant to be a step in that direction? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-09 09:04, Graeme Geldenhuys wrote: > What I'm > saying is that FPImage uses 16bit color channels, but literally only a > hand full (and I mean less than 5) of image editing programs support > 16bit color channel images. Impressively, the now discontinued cross-platform image editor Pixel32 (developed with FPC 2.0.4) supports 8bit, 16bit and 32bit color channel images. http://geldenhuys.co.uk/~graemeg/pixel_image_editor/ Such a pity the original author, Pavel Kanzelsberger, never released a final version or open sourced his efforts when he knew his product had no business traction. All that (very promising) effort gone to waste. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-09 09:14, Michael Van Canneyt wrote: > > The desire was to be able to support all possible channels when reading a > file. > That means 16bit. OK, I can see the logic behind that. Time for another coffee, to kick my brain into gear. ;-) Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Fri, 9 Dec 2016, Graeme Geldenhuys wrote: On 2016-12-09 07:28, Michael Van Canneyt wrote: The 64bit is the maximum limit. I doubt the 99.9%. Image editing require more than 8bit per channel since decades. And that is why we decided to use 64-bit. Sorry, maybe I'm getting confused with the meaning of all than. What I'm saying is that FPImage uses 16bit color channels, but literally only a hand full (and I mean less than 5) of image editing programs support 16bit color channel images. Most image viewers can't even display those either. eg: The most widely used image editing software for X11 based systems, The GIMP, doesn't even support 16bit color channel images. Yet everybody supports the defacto standard 8bits per channel images. So every time anybody works with FPImage, we have to do constant 16bit-to-8bit color translations. Where has the decision to default to 16bits per color channels come in useful in the history of FPImage? The desire was to be able to support all possible channels when reading a file. That means 16bit. That you don't use this feature in X% of cases was irrelevant. If we had decided to use 8 bit, then one day someone would come along with a 16bit channel file and we'd have to say "sorry, we don't support that", or read/write it with loss of information. It's obviously possible to question this decision, but it was taken more than 10 years ago. A bit late to change our minds now... Note that you don't need to store the image with full 64 bits per pixel. You can perfectly store an image with 1 bit (i.e. black/white) per pixel. But the API uses 16 bits per channel. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-09 07:28, Michael Van Canneyt wrote: >> > The 64bit is the maximum limit. I doubt the 99.9%. Image editing >> > require more than 8bit per channel since decades. > And that is why we decided to use 64-bit. Sorry, maybe I'm getting confused with the meaning of all than. What I'm saying is that FPImage uses 16bit color channels, but literally only a hand full (and I mean less than 5) of image editing programs support 16bit color channel images. Most image viewers can't even display those either. eg: The most widely used image editing software for X11 based systems, The GIMP, doesn't even support 16bit color channel images. Yet everybody supports the defacto standard 8bits per channel images. So every time anybody works with FPImage, we have to do constant 16bit-to-8bit color translations. Where has the decision to default to 16bits per color channels come in useful in the history of FPImage? Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Thu, 8 Dec 2016, Mattias Gaertner wrote: On Thu, 8 Dec 2016 14:09:53 + Graeme Geldenhuys wrote: On 2016-12-08 14:01, Mattias Gaertner wrote: That would be a 64bit per pixel image, wasting a lot of memory. Why FPImage uses 64bit per pixel is beyond me! The original author of FPImage clearly thought he/she saw something cool in that, but 99.9% of the time *nobody* needs that. It's causing more grief (and code to do conversions) than anything else. The 64bit is the maximum limit. I doubt the 99.9%. Image editing require more than 8bit per channel since decades. And that is why we decided to use 64-bit. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-08 16:24, Mattias Gaertner wrote: > Even rocket scientists can't read minds. :-) > Will you create the patch or should I? I'll create a patch. Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Thu, 8 Dec 2016 15:15:55 + Graeme Geldenhuys wrote: > On 2016-12-08 14:22, Mattias Gaertner wrote: >[...] > It's not rocket science. ;-) Even rocket scientists can't read minds. Will you create the patch or should I? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-08 14:22, Mattias Gaertner wrote: >> > This might be a good solution. Some ready-made event handlers. > Any idea how that should look like? In the TFPReaderTiff class, define public methods (possibly marked as virtual) as follows Here's one example: procedure TFPReaderTiff.CreateCompactTiffImage(Sender: TFPReaderTiff; IFD: TTiffIFD); var Desc: TFPCompactImgDesc; begin // free old image FreeAndNil(IFD.Img); Desc.HasAlpha := IFD.AlphaBits > 0; Desc.Gray := IFD.PhotoMetricInterpretation in [0,1]; Desc.Depth := Max(Max(Max(IFD.RedBits, IFD.GreenBits), IFD.BlueBits), IFD.GrayBits); IFD.Img := CreateFPCompactImg(Desc, IFD.ImageWidth, IFD.ImageHeight); end; You can then use those as follows: t := TFPReaderTiff.Create; t.OnCreateImage := @t.CreateCompactTiffImage; // <<-- here t.LoadFromStream(filestream, true); No need for every developer to go through the pain of having to figure out how to use TFPReaderTiff and how to implement OnCreateImage event handlers. In the FPDoc documentation of TFPReaderTIFF.OnCreateImage, list the available built-in event handlers that are there for convenience, and than you can implement your own if you have other needs. If having those convenience event handler inside the TFPTiffReader class is an issue, then create another unit with some other class where those are defined and can be easily referenced. It's not rocket science. ;-) Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Thu, 8 Dec 2016 14:09:53 + Graeme Geldenhuys wrote: > On 2016-12-08 14:01, Mattias Gaertner wrote: > > That would be a 64bit per pixel image, wasting a lot of memory. > > Why FPImage uses 64bit per pixel is beyond me! The original author of > FPImage clearly thought he/she saw something cool in that, but 99.9% > of the time *nobody* needs that. It's causing more grief (and code to do > conversions) than anything else. The 64bit is the maximum limit. I doubt the 99.9%. Image editing require more than 8bit per channel since decades. > > Or add some helper procedures, for some common cases. > > This might be a good solution. Some ready-made event handlers. Any idea how that should look like? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-08 14:01, Mattias Gaertner wrote: > That would be a 64bit per pixel image, wasting a lot of memory. Why FPImage uses 64bit per pixel is beyond me! The original author of FPImage clearly thought he/she saw something cool in that, but 99.9% of the time *nobody* needs that. It's causing more grief (and code to do conversions) than anything else. > Or add some helper procedures, for some common cases. This might be a good solution. Some ready-made event handlers. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Thu, 8 Dec 2016 12:12:27 + Graeme Geldenhuys wrote: > On 2016-12-07 17:47, Mattias Gaertner wrote: > >> > t := TFPReaderTiff.Create; > > t.OnCreateImage:=@... > > > > Thanks that solved it. > > But why can't TFPReaderTiff do that for us, or at least have a default > implementation (override'able by developers if really needed). The default implementation is for the normal use - reading only the biggest image: http://wiki.freepascal.org/fcl-image#Reading_an_image_file How should the default look like for lists of images? A variable with a default image class, and set as default to TFPMemoryImage? That would be a 64bit per pixel image, wasting a lot of memory. Or using CreateFPCompactImg, which creates a more compact image, but maybe the image will only support grayscale and/or no alpha. Or add some helper procedures, for some common cases. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-07 17:47, Mattias Gaertner wrote: >> > t := TFPReaderTiff.Create; > t.OnCreateImage:=@... > Thanks that solved it. But why can't TFPReaderTiff do that for us, or at least have a default implementation (override'able by developers if really needed). Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Wed, 7 Dec 2016 15:34:13 +
Graeme Geldenhuys wrote:
>[...]
> fs := TFileStream.Create('/tmp/multipage_tiff_example.tif', fmOpenRead);
> t := TFPReaderTiff.Create;
t.OnCreateImage:=@...
> t.LoadFromStream(fs, true);
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-07 11:43, Mattias Gaertner wrote:
> TFPReaderTiff and TFPWriterTiff support multiple IFD using multiple
> TFPCustomImage.
I just tried with FPC 3.1.1 and it fails. The initial loading of the
TIFF file works, it correctly tells me there are 10 images (confirmed
with the Unix 'identify' command, or with The Gimp). But when I try and
load the individual images, it fails. The t.Images[i].Img as seen in the
code below is always nil.
===
fs := TFileStream.Create('/tmp/multipage_tiff_example.tif', fmOpenRead);
t := TFPReaderTiff.Create;
t.LoadFromStream(fs, true);
Panel1.Caption := 'image count: ' + IntToStr(t.ImageCount);
i := 0;
if not assigned(t.Images[i].Img) then // <<-- always fails
begin
ShowMessage('failed to load image');
Exit;
end;
Image1.Picture.Assign(t.Images[i].Img);
Image1.Invalidate;
===
Regards,
Graeme
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
My public PGP key: http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On 2016-12-07 11:43, Mattias Gaertner wrote: > Do you mean multiple IFD? Yes. > TFPReaderTiff and TFPWriterTiff support multiple IFD using multiple > TFPCustomImage. Perfect, many thanks for the confirmation. Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
On Wed, 7 Dec 2016 09:58:13 + Graeme Geldenhuys wrote: > Hi, > > Does anybody know if FPImage supports multi-page TIFF's? Reading or > Writing. Do you mean multiple IFD? TFPReaderTiff and TFPWriterTiff support multiple IFD using multiple TFPCustomImage. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPImage and mult-page TIFF support
Hi, when I needed to read multi-page tiff files some years ago, I used TLazReaderTiff. I don't remember if multi-page code worked out of the box, but I had to extend tiff reader to handle some more exotic format that came from some imaging software (I think I didn't contribute the changes back - never found a time to create proper bug report...). Best regards, Žilvinas On 2016-12-07 11:58, Graeme Geldenhuys wrote: Hi, Does anybody know if FPImage supports multi-page TIFF's? Reading or Writing. Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
