From: Kai-Uwe B. <ku...@gm...> - 2010-08-15 07:05:15
|
Grepping the sources did not show a cmsFloat16Number type. Am I right in that Half is currently not supported by lcms? kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
From: Bob F. <bfr...@si...> - 2010-08-15 14:32:54
|
On Sun, 15 Aug 2010, Kai-Uwe Behrmann wrote: > Grepping the sources did not show a cmsFloat16Number type. Am I right in > that Half is currently not supported by lcms? Half support is quite challenging since there very little free sofware which supports converting to and from Half. OpenEXR is not suitable since it would represent a huge C++ dependency with limited portability. There is some portable C code which was contributed to the GraphicsMagick project which could be used in lcms to provide Half (and 24-bit float) support. The performance is unknown but it seems to work fine (at least visually) for sample 16 and 24-bit float TIFF files provided by Adobe. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Kai-Uwe B. <ku...@gm...> - 2010-08-15 15:35:42
|
Am 15.08.10, 09:32 -0500 schrieb Bob Friesenhahn: > On Sun, 15 Aug 2010, Kai-Uwe Behrmann wrote: >> Grepping the sources did not show a cmsFloat16Number type. Am I right in >> that Half is currently not supported by lcms? > > Half support is quite challenging since there very little free sofware which > supports converting to and from Half. OpenEXR is not suitable since it would > represent a huge C++ dependency with limited portability. There is some > portable C code which was contributed to the GraphicsMagick project which > could be used in lcms to provide Half (and 24-bit float) support. The > performance is unknown but it seems to work fine (at least visually) for > sample 16 and 24-bit float TIFF files provided by Adobe. HALF support in lcms seems quite a good option to me. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
From: <mar...@li...> - 2010-08-15 17:35:36
|
Quoting Kai-Uwe Behrmann <ku...@gm...>: > Grepping the sources did not show a cmsFloat16Number type. Am I right in > that Half is currently not supported by lcms? Right, still not supported but there are plans to provide formatters for that. This is the reason of using a special flag for floating point data. cmsFloat16Number and cmsInt16Number would both take 16 bits per component but the interpretation is completly different. Will take some releases to get that, though. Regards Marti |
From: Boudewijn R. <bo...@va...> - 2012-05-31 10:35:16
|
On Sunday 15 August 2010 Aug, mar...@li... wrote: > Quoting Kai-Uwe Behrmann <ku...@gm...>: > > > Grepping the sources did not show a cmsFloat16Number type. Am I right in > > that Half is currently not supported by lcms? > > Right, still not supported but there are plans to provide formatters > for that. This is the reason of using a special flag for floating > point data. cmsFloat16Number and cmsInt16Number would both take > 16 bits per component but the interpretation is completly different. > > Will take some releases to get that, though. Hm... I'm starting to get really interested in this at the moment, so I'm wondering if there's any news... I've finally been experimenting in Krita with lcms2's f32 and f64 support, and it works great. But I would also like to support f16, because that's what my users tell me they really need. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl |
From: <mar...@li...> - 2012-05-31 13:27:35
|
Hi Boudewijn, It would be certainly easy to support that by writting a plug-in. Regards Marti Boudewijn Rempt <bo...@va...> escribió: > On Sunday 15 August 2010 Aug, mar...@li... wrote: >> Quoting Kai-Uwe Behrmann <ku...@gm...>: >> >> > Grepping the sources did not show a cmsFloat16Number type. Am I right in >> > that Half is currently not supported by lcms? >> >> Right, still not supported but there are plans to provide formatters >> for that. This is the reason of using a special flag for floating >> point data. cmsFloat16Number and cmsInt16Number would both take >> 16 bits per component but the interpretation is completly different. >> >> Will take some releases to get that, though. > > Hm... I'm starting to get really interested in this at the moment, > so I'm wondering if there's any news... I've finally been > experimenting in Krita with lcms2's f32 and f64 support, and it > works great. But I would also like to support f16, because that's > what my users tell me they really need. > > -- > Boudewijn Rempt > http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > |
From: Kai-Uwe B. <ku...@gm...> - 2012-05-31 10:46:41
|
Am 31.05.12, 12:16 +0200 schrieb Boudewijn Rempt: > On Sunday 15 August 2010 Aug, mar...@li... wrote: >> Quoting Kai-Uwe Behrmann <ku...@gm...>: >> >>> Grepping the sources did not show a cmsFloat16Number type. Am I right in >>> that Half is currently not supported by lcms? >> >> Right, still not supported but there are plans to provide formatters >> for that. This is the reason of using a special flag for floating >> point data. cmsFloat16Number and cmsInt16Number would both take >> 16 bits per component but the interpretation is completly different. >> >> Will take some releases to get that, though. > > Hm... I'm starting to get really interested in this at the moment, so I'm wondering if there's any news... I've finally been experimenting in Krita with lcms2's f32 and f64 support, and it works great. But I would also like to support f16, because that's what my users tell me they really need. OpenEXR Half is the format of choice for movie picture exchange. Support inside lcms would bring Half to applications almost for free, with a win in memory foot print. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
From: <mar...@li...> - 2012-05-31 13:29:11
|
Okay, let me check if I could add this in the next release. Regards Marti Kai-Uwe Behrmann <ku...@gm...> escribió: > Am 31.05.12, 12:16 +0200 schrieb Boudewijn Rempt: >> On Sunday 15 August 2010 Aug, mar...@li... wrote: >>> Quoting Kai-Uwe Behrmann <ku...@gm...>: >>> >>>> Grepping the sources did not show a cmsFloat16Number type. Am I right in >>>> that Half is currently not supported by lcms? >>> >>> Right, still not supported but there are plans to provide formatters >>> for that. This is the reason of using a special flag for floating >>> point data. cmsFloat16Number and cmsInt16Number would both take >>> 16 bits per component but the interpretation is completly different. >>> >>> Will take some releases to get that, though. >> >> Hm... I'm starting to get really interested in this at the moment, >> so I'm wondering if there's any news... I've finally been >> experimenting in Krita with lcms2's f32 and f64 support, and it >> works great. But I would also like to support f16, because that's >> what my users tell me they really need. > > OpenEXR Half is the format of choice for movie picture exchange. Support > inside lcms would bring Half to applications almost for free, with a win > in memory foot print. > > kind regards > Kai-Uwe Behrmann > -- > developing for colour management > www.behrmann.name + www.oyranos.org > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > |
From: Boudewijn R. <bo...@va...> - 2012-05-31 14:07:58
|
On Thursday 31 May 2012 May, mar...@li... wrote: > > Okay, let me check if I could add this in the next release. That would be extremely cool :-) -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl |
From: Bob F. <bfr...@si...> - 2012-05-31 14:02:49
|
On Thu, 31 May 2012, Kai-Uwe Behrmann wrote: >> >> Hm... I'm starting to get really interested in this at the moment, so I'm wondering if there's any news... I've finally been experimenting in Krita with lcms2's f32 and f64 support, and it works great. But I would also like to support f16, because that's what my users tell me they really need. > > OpenEXR Half is the format of choice for movie picture exchange. Support > inside lcms would bring Half to applications almost for free, with a win > in memory foot print. The challenge with Half is finding portable C code to convert to and from Half. There is contributed code in GraphicsMagick for this (and also 24-bit floats) but it may not be entirely error-free or suitably fast. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Robin W. <rob...@ar...> - 2012-05-31 14:42:42
|
On 31/05/2012 15:02, Bob Friesenhahn wrote: > The challenge with Half is finding portable C code to convert to and > from Half. There is contributed code in GraphicsMagick for this (and > also 24-bit floats) but it may not be entirely error-free or suitably > fast. I forwarded this link to Marti earlier, but here it is again for the list as a whole: http://www.mathworks.com/matlabcentral/fileexchange/23173 That includes ieeehalfprecision.c - a lump of BSD licensed C code that converts 16bit floats to and from normal IEEE floats. Hopefully this will help whoever decides to try this. Robin |
From: <mar...@li...> - 2012-05-31 19:24:41
|
Thanks Robin, I have an implementation based on tables I did time ago. It is based on a paper from a conference I attendend time ago...I don't remember exactly. Sorry, I have to double check the origin. But the file you suggest seems also very good. In fact the conversion seems simple if you don't care about signed zeros, subnormal NaN... unfortunately we should deal with all that cases. Ok, the table-based implementation is neat but takes some memory, 2048 32bit words for mantissa table and there are other additional tables as well. I can include that in the lcms foundation, or pack it as a plug-in. The plug-in approach would need an extra call to initialize it, but then, only the clients using half float encoding will pay the extra tables overhead. Any preferences? I'm open to suggestions Regards Marti Robin Watts <rob...@ar...> escribió: > On 31/05/2012 15:02, Bob Friesenhahn wrote: >> The challenge with Half is finding portable C code to convert to and >> from Half. There is contributed code in GraphicsMagick for this (and >> also 24-bit floats) but it may not be entirely error-free or suitably >> fast. > > I forwarded this link to Marti earlier, but here it is again for the > list as a whole: > > http://www.mathworks.com/matlabcentral/fileexchange/23173 > > That includes ieeehalfprecision.c - a lump of BSD licensed C code that > converts 16bit floats to and from normal IEEE floats. > > Hopefully this will help whoever decides to try this. > > Robin > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > |
From: Kai-Uwe B. <ku...@gm...> - 2012-05-31 19:51:05
|
Am 31.05.12, 21:24 +0200 schrieb mar...@li...: > Ok, the table-based implementation is neat but takes some memory, 2048 > 32bit words for mantissa table and there are other additional tables > as well. > I can include that in the lcms foundation, or pack it as a plug-in. > The plug-in approach would need an extra call to initialize it, but then, > only the clients using half float encoding will pay the extra tables overhead. > > Any preferences? I'm open to suggestions It would be nice if loading a Half plugin requires no interaction or initialisation on user side. E.g. no call to cmsPlugin(plugin) So the lcms foundation appears a good candidate IMO. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
From: Boudewijn R. <bo...@va...> - 2012-05-31 19:51:59
|
On Thursday 31 May 2012 May, mar...@li... wrote: > > Thanks Robin, > > I have an implementation based on tables I did time ago. It is based > on a paper from a conference I attendend time ago...I don't remember > exactly. Sorry, I have to double check the origin. > > But the file you suggest seems also very good. In fact the conversion > seems simple if you don't care about signed zeros, subnormal NaN... > unfortunately we should deal with all that cases. > > Ok, the table-based implementation is neat but takes some memory, 2048 > 32bit words for mantissa table and there are other additional tables > as well. > I can include that in the lcms foundation, or pack it as a plug-in. > The plug-in approach would need an extra call to initialize it, but then, > only the clients using half float encoding will pay the extra tables overhead. > > Any preferences? I'm open to suggestions As an application developer, I'm totally fine with the packaged plugin approach, if distributions will package it. I can live both with the extra call and the extra memory requirement -- and I totally understand not wanting to burden every user of lcms2 with the memory requirement. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl |
From: Bob F. <bfr...@si...> - 2012-06-01 01:25:42
|
On Thu, 31 May 2012, Boudewijn Rempt wrote: > As an application developer, I'm totally fine with the packaged > plugin approach, if distributions will package it. I can live both > with the extra call and the extra memory requirement -- and I > totally understand not wanting to burden every user of lcms2 with > the memory requirement. The memory requirement described for the tables is trivial compared to the amount of memory required to perform other operations. I worry that plugins are more complex and pose more security issues. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: James C. <cl...@jh...> - 2012-06-02 21:17:24
|
The ieeehalfprecision.c file from the matlab package covers all possible half values quickly and efficiently, using only type punning to integers, bit comparisons (& and the like) and bit shifts. The licence is BSD and the api is super simple: int singles2halfp(void *target, void *source, int numel); int doubles2halfp(void *target, void *source, int numel); int halfp2singles(void *target, void *source, int numel); int halfp2doubles(void *target, void *source, int numel); All you'd want to do is touch it up a bit to use your lcms's cmsUInt16Number, cmsInt16Number, cmsUInt32Number and cmsInt32Number typedefs instead of ieeehalfprecision.c's current UINT16_TYPE, INT16_TYPE, UINT32_TYPE and INT32_TYPE typedefs. You shouldn't need it to be a plugin, just a (new) part of the default api. I can create a github fork and send a pull request of what I suggest if you like. -JimC -- James Cloos <cl...@jh...> OpenPGP: 1024D/ED7DAEA6 |
From: Bob F. <bfr...@si...> - 2012-06-02 22:08:34
|
Likewise, GraphicsMagick includes work by Richard Nolde which knows how to handle 16 and 24 bit floats. He actually wrote a full conversion suite between 16, 24, 32, and 64-bit floats. I only incorporated the specific functions that GraphicsMagick needs. This code has been in GraphicsMagick since 2008. The code has been verified on a wide-variety of CPU types. 24 bit floats are also important because they are supported in the TIFF file format, are supported by Photoshop, and because some GPUs (e.g. from AMD) support 24 bit floats. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: Kai-Uwe B. <ku...@gm...> - 2012-06-03 07:34:51
|
Bob Friesenhahn <bfr...@si...> schrieb: >Likewise, GraphicsMagick includes work by Richard Nolde which knows >how to handle 16 and 24 bit floats. He actually wrote a full >conversion suite between 16, 24, 32, and 64-bit floats. I only >incorporated the specific functions that GraphicsMagick needs. This >code has been in GraphicsMagick since 2008. The code has been >verified on a wide-variety of CPU types. > >24 bit floats are also important because they are supported in the >TIFF file format, are supported by Photoshop, and because some GPUs >(e.g. from AMD) support 24 bit floats. Given the MIT license in GraphicsMagic and little CMS, the GM implementation appears just from a license POV more appropriate than BSD licensed code. kind regards Kai-Uwe |
From: <mar...@li...> - 2012-06-03 13:37:55
|
Hi, Thanks everybody for your contribution. I'm right now working with Bob's approach because: - It handles 16 and 24 bits - The license is ok - I don't relly need top performance on those types, and the code is small. I tracked the origin of the previous code I was considering, and if anybody interested, is from a paper from Jeroen van der Zijp: ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf Clean and fast code, used by MESA. But I am not sure about the license. So, in this case of doubt, I prefer the safe side. The code suggested by James Clos (thanks Jim!) is also ok, but is under BSD license and that would mix licenses, which would be a pain for some people using the package. So, thanks again Bob, I hope integrating both formats (16 and 24 floating point) would take few days. Hopefully it will be ready for next release in July. All the best Marti Maria Kai-Uwe Behrmann <ku...@gm...> escribió: > Bob Friesenhahn <bfr...@si...> schrieb: > >> Likewise, GraphicsMagick includes work by Richard Nolde which knows >> how to handle 16 and 24 bit floats. He actually wrote a full >> conversion suite between 16, 24, 32, and 64-bit floats. I only >> incorporated the specific functions that GraphicsMagick needs. This >> code has been in GraphicsMagick since 2008. The code has been >> verified on a wide-variety of CPU types. >> >> 24 bit floats are also important because they are supported in the >> TIFF file format, are supported by Photoshop, and because some GPUs >> (e.g. from AMD) support 24 bit floats. > > Given the MIT license in GraphicsMagic and little CMS, the GM > implementation appears just from a license POV more appropriate than > BSD licensed code. > > kind regards > Kai-Uwe > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > |
From: Boudewijn R. <bo...@va...> - 2012-06-03 14:00:54
|
On Sun, 3 Jun 2012, mar...@li... wrote: > > Hi, > > Thanks everybody for your contribution. I'm right now working with > Bob's approach because: > > - It handles 16 and 24 bits > - The license is ok > - I don't relly need top performance on those types, and the code is small. > > I tracked the origin of the previous code I was considering, and > if anybody interested, is from a paper from Jeroen van der Zijp: > ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf > > Clean and fast code, used by MESA. But I am not sure about > the license. So, in this case of doubt, I prefer the safe side. > > The code suggested by James Clos (thanks Jim!) is > also ok, but is under BSD license and that would mix licenses, > which would be a pain for some people using the package. > > So, thanks again Bob, I hope integrating both formats (16 and 24 > floating point) would take few days. Hopefully it will be ready > for next release in July. > Yay! Boudewijn |
From: Bob F. <bfr...@si...> - 2012-06-03 15:29:25
|
On Sun, 3 Jun 2012, mar...@li... wrote: > > Hi, > > Thanks everybody for your contribution. I'm right now working with > Bob's approach because: > > - It handles 16 and 24 bits > - The license is ok > - I don't relly need top performance on those types, and the code is small. I assume (but don't know) that Richard Nolde can help resolve any residual issues found with his code. The main annoyance I am aware of is a compiler warning due to a cast because of the way the code automatically detects endianness. Probably this is easily fixed using a union or compile time knowledge. Bob > > I tracked the origin of the previous code I was considering, and > if anybody interested, is from a paper from Jeroen van der Zijp: > ftp://www.fox-toolkit.org/pub/fasthalffloatconversion.pdf > > Clean and fast code, used by MESA. But I am not sure about > the license. So, in this case of doubt, I prefer the safe side. > > The code suggested by James Clos (thanks Jim!) is > also ok, but is under BSD license and that would mix licenses, > which would be a pain for some people using the package. > > So, thanks again Bob, I hope integrating both formats (16 and 24 > floating point) would take few days. Hopefully it will be ready > for next release in July. > > All the best > Marti Maria > > > > > > Kai-Uwe Behrmann <ku...@gm...> escribió: > >> Bob Friesenhahn <bfr...@si...> schrieb: >> >>> Likewise, GraphicsMagick includes work by Richard Nolde which knows >>> how to handle 16 and 24 bit floats. He actually wrote a full >>> conversion suite between 16, 24, 32, and 64-bit floats. I only >>> incorporated the specific functions that GraphicsMagick needs. This >>> code has been in GraphicsMagick since 2008. The code has been >>> verified on a wide-variety of CPU types. >>> >>> 24 bit floats are also important because they are supported in the >>> TIFF file format, are supported by Photoshop, and because some GPUs >>> (e.g. from AMD) support 24 bit floats. >> >> Given the MIT license in GraphicsMagic and little CMS, the GM >> implementation appears just from a license POV more appropriate than >> BSD licensed code. >> >> kind regards >> Kai-Uwe >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Lcms-user mailing list >> Lcm...@li... >> https://lists.sourceforge.net/lists/listinfo/lcms-user >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
From: James C. <cl...@jh...> - 2012-06-03 19:00:09
|
>>>>> "mm" == marti maria <mar...@li...> writes: mm> Thanks everybody for your contribution. I'm right now working with mm> Bob's approach because: I don't have time right now for anything lengthy, but having been reminded that lcms and gm are both mit, I agree that the code used in gm is the better choice. The two approaches have only trivial differences anyway. (One uses char*s to look at and manipulate the bits, the other uses u?int16_t and u?int32_t.) -JimC -- James Cloos <cl...@jh...> OpenPGP: 1024D/ED7DAEA6 |