-
Notifications
You must be signed in to change notification settings - Fork 5
/
TODO
93 lines (80 loc) · 2.92 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
Deal with extra samples in TIFF images.
ImageSources will need to carry around a collection of parasites - data from the source file that the stack
doesn't know how to deal with. Clipping paths will fall into this category, but ICC profiles won't, since
the stack is capable of dealing with those.
Need to deal with some parasites being file-format-specific.
enum ISParasiteType {ISPARA_UNKNOWN, ISPARA_CLIPPATH};
enum ISParasiteApplicability {ISPARA_UNKNOWN, ISPARA_UNIVERSAL, ISPARA_TIFF, ISPARA_JPEG};
class ISParasite : public BinaryBlob
{
public:
ISParasite(const char *buf,int buzsize,ISParasiteType type,ISParasiteApplicability applic=ISPARA_UNIVERSAL) : BinaryBlob(buf,bufsize), type(type)
{
}
virtual ~ISParasite
{
}
// Query a parasite for applicability. For example, the TIFF saver will query if(para.Applicable(ISPARA_TIFF))
bool Applicable(ISParasiteApplicability app)
{
if(applic==ISPARA_UNIVERSAL || app=ISPARA_UNIVERSAL || applic==app)
return(true);
else
return(false);
}
protected:
ISParasiteType type;
ISParasiteApplicability applic;
};
Two ways this can be handled: Either each imagesource will "steal" the parasites from the previous one, or we use reference counting.
Refcounting is probably the best best, at least initially, since it allows, for example, to save the four channels individually. The "stealing"
model would leave only the first saver able to access the parasite.
std::map<RefCountPtr> ISParasites
Should be OK copy-constructor-wise?
Need an "ImageSink" superclass, upon which CachedImage, PixbufFromImageSource and the Image Savers will be based.
The sinks will have a ProcessRow() function, as well as a ProcessImage(Progress &) function.
The advantage of this is that several imagesinks can in this way operate on the same image, like so:
(ImageSource_Tee would be much improved by using refcountptr.)
RefCountPtr<ImageSource> source(ISLoadImage("filename"));
CachedImage_Deferred img1(source);
CachedImage_Deferred img2(source);
TIFFSaver saver("filenameout",source);
for(int row=0;row<source->height;++row)
{
img1.ProcessRow(row);
img2.ProcessRow(row);
saver.ProcessRow(row);
}
class ImageSink
{
public:
ImageSink(ImageSource *source) : source(source)
{
}
virtual ~ImageSink()
{
if(source)
delete source;
}
virtual bool ProcessImage(Progress *prog=NULL)
{
for(int i=0;i<source->height;++i)
{
ProcessRow(i);
if(prog)
{
if(!prog->DoProgress(i,source->height-1))
return(false);
}
}
return(true);
}
virtual void ProcessRow(int row)
{
}
protected:
ImageSource *source;
};
Need a variant of the JobQueue system for handling UI events, to avoid the problems currently caused by events being pumped from within signal handlers.
| Investigate using smart pointers for ref counting and figure out how that would interact with gtk idle handlers.
| Need to use a map between addresses and refcounters; merely using a templated class will cause problems with polymorphism.