A suggestion for additional Image Property functions
Locked
A suggestion for additional Image Property functions
 
|
Since version 1.53a we now have the very useful ability to set persistent image properties:
Property.get(key) Property.set(key,value) These are analogue to the existing List functions: List.get(key) List.set(key, value) We also have these List functions for reading/writing a key/value list as an entity: List.getList - Returns the list as a string. List.setList(list) - Loads the key/value pairs in the string list. What about adding equivalent functions for moving data from image properties to a List and vice versa: Property.getList - Returns the image properties as a string. Property.setList(list) - Sets the key/value pairs in the string list as image properties. Then we can write the current List as image properties, for persistent storage with the image: Property.setList(List.getList) Or the other way around: List.setList(Property.getList) I think this could make custom metadata handling even easier than it is today! Stein -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote:
> > Since version 1.53a we now have the very useful ability to set persistent image properties: > > Property.get(key) > Property.set(key,value) > > These are analogue to the existing List functions: > > List.get(key) > List.set(key, value) > > We also have these List functions for reading/writing a key/value list as an entity: > > List.getList - Returns the list as a string. > List.setList(list) - Loads the key/value pairs in the string list. > > What about adding equivalent functions for moving data from image properties to a List and vice versa: > > Property.getList - Returns the image properties as a string. > Property.setList(list) - Sets the key/value pairs in the string list as image properties. Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). -wayne > Then we can write the current List as image properties, for persistent storage with the image: > > Property.setList(List.getList) > > Or the other way around: > > List.setList(Property.getList) > > I think this could make custom metadata handling even easier than it is today! > > Stein -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
Thanks from me too.
Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. — Michael Ellis > On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: > >> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >> >> Since version 1.53a we now have the very useful ability to set persistent image properties: >> >> Property.get(key) >> Property.set(key,value) >> >> These are analogue to the existing List functions: >> >> List.get(key) >> List.set(key, value) >> >> We also have these List functions for reading/writing a key/value list as an entity: >> >> List.getList - Returns the list as a string. >> List.setList(list) - Loads the key/value pairs in the string list. >> >> What about adding equivalent functions for moving data from image properties to a List and vice versa: >> >> Property.getList - Returns the image properties as a string. >> Property.setList(list) - Sets the key/value pairs in the string list as image properties. > > Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). > > -wayne > >> Then we can write the current List as image properties, for persistent storage with the image: >> >> Property.setList(List.getList) >> >> Or the other way around: >> >> List.setList(Property.getList) >> >> I think this could make custom metadata handling even easier than it is today! >> >> Stein > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html Michael Ellis (Managing Director) Digital Scientific UK Ltd. http://www.dsuk.biz <http://www.dsuk.biz/> [hidden email] tel: +44(0)1223 911215 The Commercial Centre 6 Green End Cambridge CB23 7DY === END OF EMAIL === -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Good day Michael,
please allow me to state that this was possible already and I used it since years: set: List.set( "key1", val1 ); ... List.set( "keyN", valN ); setMetadata( "Info", List.getList() ); List.clear; get: List.setList( getMetadata( "Info" ) ); val1 = List.getValue( "key1" ); ... valN = List.getValue( "keyN" ); List.clear(); ...or do I miss something special? Regards Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 19.05.20 um 06:24 schrieb Michael Ellis: > Thanks from me too. > > Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. > > — Michael Ellis > > >> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: >> >>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >>> >>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>> >>> Property.get(key) >>> Property.set(key,value) >>> >>> These are analogue to the existing List functions: >>> >>> List.get(key) >>> List.set(key, value) >>> >>> We also have these List functions for reading/writing a key/value list as an entity: >>> >>> List.getList - Returns the list as a string. >>> List.setList(list) - Loads the key/value pairs in the string list. >>> >>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>> >>> Property.getList - Returns the image properties as a string. >>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >> >> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >> >> -wayne >> >>> Then we can write the current List as image properties, for persistent storage with the image: >>> >>> Property.setList(List.getList) >>> >>> Or the other way around: >>> >>> List.setList(Property.getList) >>> >>> I think this could make custom metadata handling even easier than it is today! >>> >>> Stein >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > Michael Ellis (Managing Director) > Digital Scientific UK Ltd. > http://www.dsuk.biz <http://www.dsuk.biz/> > [hidden email] > tel: +44(0)1223 911215 > > The Commercial Centre > 6 Green End > Cambridge > CB23 7DY > > === END OF EMAIL === > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
Hello Herbie,
I am not sure about your examples. The case in question is that with the latest changes added by Wayne, the ImagePlus now has a general set of name String properties that are saved and restored with the standard Image SaveAsTiff/SaveAsZip and Open ImageJ calls. As far as I am aware this is significant new functionality as before only a single “Info” property variously used by OME.TIFF (holding OME XML data) was honoured during saving and restoring. With best regards — Michael Ellis > On 19 May 2020, at 15:18, Herbie <[hidden email]> wrote: > > Good day Michael, > > please allow me to state that this was possible already and I used it since years: > > set: > List.set( "key1", val1 ); > ... > List.set( "keyN", valN ); > setMetadata( "Info", List.getList() ); > List.clear; > > get: > List.setList( getMetadata( "Info" ) ); > val1 = List.getValue( "key1" ); > ... > valN = List.getValue( "keyN" ); > List.clear(); > > ...or do I miss something special? > > Regards > > Herbie > > ::::::::::::::::::::::::::::::::::::::::::: > Am 19.05.20 um 06:24 schrieb Michael Ellis: >> Thanks from me too. >> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >> — Michael Ellis >>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: >>> >>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >>>> >>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>> >>>> Property.get(key) >>>> Property.set(key,value) >>>> >>>> These are analogue to the existing List functions: >>>> >>>> List.get(key) >>>> List.set(key, value) >>>> >>>> We also have these List functions for reading/writing a key/value list as an entity: >>>> >>>> List.getList - Returns the list as a string. >>>> List.setList(list) - Loads the key/value pairs in the string list. >>>> >>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>> >>>> Property.getList - Returns the image properties as a string. >>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>> >>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>> >>> -wayne >>> >>>> Then we can write the current List as image properties, for persistent storage with the image: >>>> >>>> Property.setList(List.getList) >>>> >>>> Or the other way around: >>>> >>>> List.setList(Property.getList) >>>> >>>> I think this could make custom metadata handling even easier than it is today! >>>> >>>> Stein >>> >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >> Michael Ellis (Managing Director) >> Digital Scientific UK Ltd. >> http://www.dsuk.biz <http://www.dsuk.biz/> <http://www.dsuk.biz/ <http://www.dsuk.biz/>> >> [hidden email] <mailto:[hidden email]> >> tel: +44(0)1223 911215 >> The Commercial Centre >> 6 Green End >> Cambridge >> CB23 7DY >> === END OF EMAIL === >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html <http://imagej.nih.gov/ij/list.html> > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html <http://imagej.nih.gov/ij/list.html> Digital Scientific UK Ltd. http://www.dsuk.biz <http://www.dsuk.biz/> [hidden email] tel: +44(0)1223 911215 The Commercial Centre 6 Green End Cambridge CB23 7DY === END OF EMAIL === -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Michael,
what I've provided is ImageJ macro code. It is written as metadata to a TIF-image and is human readable by choosing "Show Info...". However it is possible (and has been before) to do the same using Java: Properties props = new Properties(); props.setProperty( "key1", "value1" ); ... props.setProperty( "keyN", "valueN" ); StringWriter writer = new StringWriter(); props.store( writer, "" ); imp.setProperty( "Info", writer.getBuffer().toString() ); Not sure if we are speaking of the same feature but did you try the previously provided macro approach? Best regards Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 19.05.20 um 16:24 schrieb Michael Ellis: > Hello Herbie, > > I am not sure about your examples. The case in question is that with the latest changes added by Wayne, the ImagePlus now has a general set of name String properties that are saved and restored with the standard Image SaveAsTiff/SaveAsZip and Open ImageJ calls. As far as I am aware this is significant new functionality as before only a single “Info” property variously used by OME.TIFF (holding OME XML data) was honoured during saving and restoring. > > With best regards > — Michael Ellis > >> On 19 May 2020, at 15:18, Herbie <[hidden email]> wrote: >> >> Good day Michael, >> >> please allow me to state that this was possible already and I used it since years: >> >> set: >> List.set( "key1", val1 ); >> ... >> List.set( "keyN", valN ); >> setMetadata( "Info", List.getList() ); >> List.clear; >> >> get: >> List.setList( getMetadata( "Info" ) ); >> val1 = List.getValue( "key1" ); >> ... >> valN = List.getValue( "keyN" ); >> List.clear(); >> >> ...or do I miss something special? >> >> Regards >> >> Herbie >> >> ::::::::::::::::::::::::::::::::::::::::::: >> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>> Thanks from me too. >>> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >>> — Michael Ellis >>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: >>>> >>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >>>>> >>>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>>> >>>>> Property.get(key) >>>>> Property.set(key,value) >>>>> >>>>> These are analogue to the existing List functions: >>>>> >>>>> List.get(key) >>>>> List.set(key, value) >>>>> >>>>> We also have these List functions for reading/writing a key/value list as an entity: >>>>> >>>>> List.getList - Returns the list as a string. >>>>> List.setList(list) - Loads the key/value pairs in the string list. >>>>> >>>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>>> >>>>> Property.getList - Returns the image properties as a string. >>>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>>> >>>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>>> >>>> -wayne >>>> >>>>> Then we can write the current List as image properties, for persistent storage with the image: >>>>> >>>>> Property.setList(List.getList) >>>>> >>>>> Or the other way around: >>>>> >>>>> List.setList(Property.getList) >>>>> >>>>> I think this could make custom metadata handling even easier than it is today! >>>>> >>>>> Stein >>>> >>>> -- >>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>> Michael Ellis (Managing Director) >>> Digital Scientific UK Ltd. >>> http://www.dsuk.biz <http://www.dsuk.biz/> <http://www.dsuk.biz/ <http://www.dsuk.biz/>> >>> [hidden email] <mailto:[hidden email]> >>> tel: +44(0)1223 911215 >>> The Commercial Centre >>> 6 Green End >>> Cambridge >>> CB23 7DY >>> === END OF EMAIL === >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html <http://imagej.nih.gov/ij/list.html> >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html <http://imagej.nih.gov/ij/list.html> > Michael Ellis (Managing Director) > Digital Scientific UK Ltd. > http://www.dsuk.biz <http://www.dsuk.biz/> > [hidden email] > tel: +44(0)1223 911215 > > The Commercial Centre > 6 Green End > Cambridge > CB23 7DY > > === END OF EMAIL === > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
In reply to this post by Michael P Ellis
Thanks Wayne,
Yes this will make adding custom metadata to images easier. Today I already embed a lot of metadata in the info field, but since that also contains some other non-metadata information, I need to insert markers where my metadata starts and ends, in order to extract the metadata using regular expressions, and then parsing it as a list. With the ability to store lists directly as persistent image properties, this will be both easier and more robust. Stein -----Original Message----- From: ImageJ Interest Group <[hidden email]> On Behalf Of Michael Ellis Sent: 19. mai 2020 06:25 To: [hidden email] Subject: Re: A suggestion for additional Image Property functions Thanks from me too. Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. — Michael Ellis > On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: > >> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >> >> Since version 1.53a we now have the very useful ability to set persistent image properties: >> >> Property.get(key) >> Property.set(key,value) >> >> These are analogue to the existing List functions: >> >> List.get(key) >> List.set(key, value) >> >> We also have these List functions for reading/writing a key/value list as an entity: >> >> List.getList - Returns the list as a string. >> List.setList(list) - Loads the key/value pairs in the string list. >> >> What about adding equivalent functions for moving data from image properties to a List and vice versa: >> >> Property.getList - Returns the image properties as a string. >> Property.setList(list) - Sets the key/value pairs in the string list as image properties. > > Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). > > -wayne > >> Then we can write the current List as image properties, for persistent storage with the image: >> >> Property.setList(List.getList) >> >> Or the other way around: >> >> List.setList(Property.getList) >> >> I think this could make custom metadata handling even easier than it is today! >> >> Stein > > -- > ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7Ce9d77f3aac404479921b08d7fbae7f6a%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637254599215526492&sdata=WyrSoOPkqlsJtrvVGFGaEXfKEqWqhJ%2Bh%2FjLchSZuvfo%3D&reserved=0 Michael Ellis (Managing Director) Digital Scientific UK Ltd. https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7Ce9d77f3aac404479921b08d7fbae7f6a%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637254599215526492&sdata=yB%2BSsXS%2BDwp8rLDuf%2FN81kkyxPjrcSFvk9AYxgvKwIY%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7Ce9d77f3aac404479921b08d7fbae7f6a%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637254599215526492&sdata=yB%2BSsXS%2BDwp8rLDuf%2FN81kkyxPjrcSFvk9AYxgvKwIY%3D&reserved=0> [hidden email] tel: +44(0)1223 911215 The Commercial Centre 6 Green End Cambridge CB23 7DY === END OF EMAIL === -- ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7Ce9d77f3aac404479921b08d7fbae7f6a%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637254599215526492&sdata=WyrSoOPkqlsJtrvVGFGaEXfKEqWqhJ%2Bh%2FjLchSZuvfo%3D&reserved=0 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
In reply to this post by Herbie
Yes this approach works, but only when the list metadata is the _only_ metadata present. That is, the call setMetadata("Info", List.getList()); will erase anything stored in the Info field which is not part of your list. With the new functionality, the list can be stored in the persistent image properties instead, and the existing "Info" metadata can be used for other information. So we now have two ways to store metadata instead of just one, and the two can be in different formats.
Stein -----Original Message----- From: ImageJ Interest Group <[hidden email]> On Behalf Of Herbie Sent: 19. mai 2020 16:18 To: [hidden email] Subject: Re: A suggestion for additional Image Property functions Good day Michael, please allow me to state that this was possible already and I used it since years: set: List.set( "key1", val1 ); ... List.set( "keyN", valN ); setMetadata( "Info", List.getList() ); List.clear; get: List.setList( getMetadata( "Info" ) ); val1 = List.getValue( "key1" ); ... valN = List.getValue( "keyN" ); List.clear(); ...or do I miss something special? Regards Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 19.05.20 um 06:24 schrieb Michael Ellis: > Thanks from me too. > > Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. > > — Michael Ellis > > >> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: >> >>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >>> >>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>> >>> Property.get(key) >>> Property.set(key,value) >>> >>> These are analogue to the existing List functions: >>> >>> List.get(key) >>> List.set(key, value) >>> >>> We also have these List functions for reading/writing a key/value list as an entity: >>> >>> List.getList - Returns the list as a string. >>> List.setList(list) - Loads the key/value pairs in the string list. >>> >>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>> >>> Property.getList - Returns the image properties as a string. >>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >> >> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >> >> -wayne >> >>> Then we can write the current List as image properties, for persistent storage with the image: >>> >>> Property.setList(List.getList) >>> >>> Or the other way around: >>> >>> List.setList(Property.getList) >>> >>> I think this could make custom metadata handling even easier than it is today! >>> >>> Stein >> >> -- >> ImageJ mailing list: >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >> mrApeqmCvq1fmJ8Yw%3D&reserved=0 > > Michael Ellis (Managing Director) > Digital Scientific UK Ltd. > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d > suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 > 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 > 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D > &reserved=0 > <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. > dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb > 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 > 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 > D&reserved=0> > [hidden email] > tel: +44(0)1223 911215 > > The Commercial Centre > 6 Green End > Cambridge > CB23 7DY > > === END OF EMAIL === > > > -- > ImageJ mailing list: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage > j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no > %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af > %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrAp > eqmCvq1fmJ8Yw%3D&reserved=0 > -- ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrApeqmCvq1fmJ8Yw%3D&reserved=0 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Michael and Stein,
thanks for the details. I hope we shall see a solution where the "key value"-*pairs* are visible in the Info-window. For me it proved useful for "diagnostic" purposes... Herbie :::::::::::::::::::::::::::::::::::::::::: Am 20.05.20 um 00:32 schrieb Stein Rørvik: > Yes this approach works, but only when the list metadata is the _only_ metadata present. That is, the call setMetadata("Info", List.getList()); will erase anything stored in the Info field which is not part of your list. With the new functionality, the list can be stored in the persistent image properties instead, and the existing "Info" metadata can be used for other information. So we now have two ways to store metadata instead of just one, and the two can be in different formats. > > Stein > > -----Original Message----- > From: ImageJ Interest Group <[hidden email]> On Behalf Of Herbie > Sent: 19. mai 2020 16:18 > To: [hidden email] > Subject: Re: A suggestion for additional Image Property functions > > Good day Michael, > > please allow me to state that this was possible already and I used it since years: > > set: > List.set( "key1", val1 ); > ... > List.set( "keyN", valN ); > setMetadata( "Info", List.getList() ); > List.clear; > > get: > List.setList( getMetadata( "Info" ) ); > val1 = List.getValue( "key1" ); > ... > valN = List.getValue( "keyN" ); > List.clear(); > > ...or do I miss something special? > > Regards > > Herbie > > ::::::::::::::::::::::::::::::::::::::::::: > Am 19.05.20 um 06:24 schrieb Michael Ellis: >> Thanks from me too. >> >> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >> >> — Michael Ellis >> >> >>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: >>> >>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >>>> >>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>> >>>> Property.get(key) >>>> Property.set(key,value) >>>> >>>> These are analogue to the existing List functions: >>>> >>>> List.get(key) >>>> List.set(key, value) >>>> >>>> We also have these List functions for reading/writing a key/value list as an entity: >>>> >>>> List.getList - Returns the list as a string. >>>> List.setList(list) - Loads the key/value pairs in the string list. >>>> >>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>> >>>> Property.getList - Returns the image properties as a string. >>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>> >>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>> >>> -wayne >>> >>>> Then we can write the current List as image properties, for persistent storage with the image: >>>> >>>> Property.setList(List.getList) >>>> >>>> Or the other way around: >>>> >>>> List.setList(Property.getList) >>>> >>>> I think this could make custom metadata handling even easier than it is today! >>>> >>>> Stein >>> >>> -- >>> ImageJ mailing list: >>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >> >> Michael Ellis (Managing Director) >> Digital Scientific UK Ltd. >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >> &reserved=0 >> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >> D&reserved=0> >> [hidden email] >> tel: +44(0)1223 911215 >> >> The Commercial Centre >> 6 Green End >> Cambridge >> CB23 7DY >> >> === END OF EMAIL === >> >> >> -- >> ImageJ mailing list: >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage >> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no >> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af >> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrAp >> eqmCvq1fmJ8Yw%3D&reserved=0 >> > > -- > ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrApeqmCvq1fmJ8Yw%3D&reserved=0 > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
Wayne added the feature to list the property keys, but NOT the values in the Info window.
This makes sense because the values may well be strings used to encode huge amounts of data. Below is an example by Wayne for encoding an image as string and then assigning it as a String property of another image! You could of course write a plugin or script to enumerate the properties yourself. — Michael > The ImageJ 1.53a3 daily build adds setProp() and getProp() methods for saving and restoring string properties. The following JavaScript demonstrates how to use these new methods. Since they only work with strings, it also shows how to encode non-string objects, such images, into strings. > > -wayne > > img = IJ.createImage("Untitled", "8-bit black", 500, 500, 3); > clown = IJ.openImage("http://wsr.imagej.net/images/clown.jpg <http://wsr.imagej.net/images/clown.jpg>"); > bytes = new FileSaver(clown).serialize(); > string = Base64.getEncoder().encodeToString(bytes); > img.setProp("clown", string); > text = "Clown.jpg was serialized, set as an image\n" > + "property, the image was saved, re-opened,\n" > + "and clown.jpg was deserialized and displayed."; > img.setProp("text", text); > path = IJ.getDir("home")+"Downloads/Untitled.tif"; > IJ.saveAs(img, "Tiff", path); > img2 = IJ.openImage(path); > string2 = img2.getProp("clown"); > bytes2 = Base64.getDecoder().decode(string2); > clown2 = new Opener().deserialize(bytes2); > clown2.show(); > IJ.showMessage(img2.getProp("text")); > > On 20 May 2020, at 08:43, Herbie <[hidden email]> wrote: > > Dear Michael and Stein, > > thanks for the details. > > I hope we shall see a solution where the "key value"-*pairs* are visible in the Info-window. For me it proved useful for "diagnostic" purposes... > > Herbie > > :::::::::::::::::::::::::::::::::::::::::: > Am 20.05.20 um 00:32 schrieb Stein Rørvik: >> Yes this approach works, but only when the list metadata is the _only_ metadata present. That is, the call setMetadata("Info", List.getList()); will erase anything stored in the Info field which is not part of your list. With the new functionality, the list can be stored in the persistent image properties instead, and the existing "Info" metadata can be used for other information. So we now have two ways to store metadata instead of just one, and the two can be in different formats. >> Stein >> -----Original Message----- >> From: ImageJ Interest Group <[hidden email]> On Behalf Of Herbie >> Sent: 19. mai 2020 16:18 >> To: [hidden email] >> Subject: Re: A suggestion for additional Image Property functions >> Good day Michael, >> please allow me to state that this was possible already and I used it since years: >> set: >> List.set( "key1", val1 ); >> ... >> List.set( "keyN", valN ); >> setMetadata( "Info", List.getList() ); >> List.clear; >> get: >> List.setList( getMetadata( "Info" ) ); >> val1 = List.getValue( "key1" ); >> ... >> valN = List.getValue( "keyN" ); >> List.clear(); >> ...or do I miss something special? >> Regards >> Herbie >> ::::::::::::::::::::::::::::::::::::::::::: >> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>> Thanks from me too. >>> >>> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >>> >>> — Michael Ellis >>> >>> >>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: >>>> >>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >>>>> >>>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>>> >>>>> Property.get(key) >>>>> Property.set(key,value) >>>>> >>>>> These are analogue to the existing List functions: >>>>> >>>>> List.get(key) >>>>> List.set(key, value) >>>>> >>>>> We also have these List functions for reading/writing a key/value list as an entity: >>>>> >>>>> List.getList - Returns the list as a string. >>>>> List.setList(list) - Loads the key/value pairs in the string list. >>>>> >>>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>>> >>>>> Property.getList - Returns the image properties as a string. >>>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>>> >>>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>>> >>>> -wayne >>>> >>>>> Then we can write the current List as image properties, for persistent storage with the image: >>>>> >>>>> Property.setList(List.getList) >>>>> >>>>> Or the other way around: >>>>> >>>>> List.setList(Property.getList) >>>>> >>>>> I think this could make custom metadata handling even easier than it is today! >>>>> >>>>> Stein >>>> >>>> -- >>>> ImageJ mailing list: >>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>> >>> Michael Ellis (Managing Director) >>> Digital Scientific UK Ltd. >>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >>> &reserved=0 >>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >>> D&reserved=0> >>> [hidden email] >>> tel: +44(0)1223 911215 >>> >>> The Commercial Centre >>> 6 Green End >>> Cambridge >>> CB23 7DY >>> >>> === END OF EMAIL === >>> >>> >>> -- >>> ImageJ mailing list: >>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage >>> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no >>> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af >>> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrAp >>> eqmCvq1fmJ8Yw%3D&reserved=0 >>> >> -- >> ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrApeqmCvq1fmJ8Yw%3D&reserved=0 >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html Michael Ellis (Managing Director) Digital Scientific UK Ltd. http://www.dsuk.biz <http://www.dsuk.biz/> [hidden email] tel: +44(0)1223 911215 The Commercial Centre 6 Green End Cambridge CB23 7DY === END OF EMAIL === -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Michael,
I saw Wayne's example but I don't understand why we should store images as properties. Not everything that is possible makes sense (for me)... Human readable text, strings or numbers (metadata), stored with images proved useful for several purposes and if we can now be sure that they are not overwritten (did anybody encounter this case in practice?), the situation appears to be improved although these new "key value"-lists are no longer human readable. If users needs an additional software (plugin or macro) to read and report metadata, things appear unnecessarily complicated. But, as so often, I may not have grasped the idea. Best regards Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 20.05.20 um 09:56 schrieb Michael Ellis: > Wayne added the feature to list the property keys, but NOT the values in > the Info window. > > This makes sense because the values may well be strings used to encode > huge amounts of data. Below is an example by Wayne for encoding an image > as string and then assigning it as a String property of another image! > > You could of course write a plugin or script to enumerate the properties > yourself. > > — Michael > >> The ImageJ 1.53a3 daily build adds setProp() and getProp() methods for >> saving and restoring string properties. The following JavaScript >> demonstrates how to use these new methods. Since they only work with >> strings, it also shows how to encode non-string objects, such images, >> into strings. >> >> -wayne >> >> img = IJ.createImage("Untitled", "8-bit black", 500, 500, 3); >> clown = IJ.openImage("http://wsr.imagej.net/images/clown.jpg"); >> bytes = new FileSaver(clown).serialize(); >> string = Base64.getEncoder().encodeToString(bytes); >> img.setProp("clown", string); >> text = "Clown.jpg was serialized, set as an image\n" >> + "property, the image was saved, re-opened,\n" >> + "and clown.jpg was deserialized and displayed."; >> img.setProp("text", text); >> path = IJ.getDir("home")+"Downloads/Untitled.tif"; >> IJ.saveAs(img, "Tiff", path); >> img2 = IJ.openImage(path); >> string2 = img2.getProp("clown"); >> bytes2 = Base64.getDecoder().decode(string2); >> clown2 = new Opener().deserialize(bytes2); >> clown2.show(); >> IJ.showMessage(img2.getProp("text")); >> > >> On 20 May 2020, at 08:43, Herbie <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Dear Michael and Stein, >> >> thanks for the details. >> >> I hope we shall see a solution where the "key value"-*pairs* are >> visible in the Info-window. For me it proved useful for "diagnostic" >> purposes... >> >> Herbie >> >> :::::::::::::::::::::::::::::::::::::::::: >> Am 20.05.20 um 00:32 schrieb Stein Rørvik: >>> Yes this approach works, but only when the list metadata is the >>> _only_ metadata present. That is, the call setMetadata("Info", >>> List.getList()); will erase anything stored in the Info field which >>> is not part of your list. With the new functionality, the list can be >>> stored in the persistent image properties instead, and the existing >>> "Info" metadata can be used for other information. So we now have two >>> ways to store metadata instead of just one, and the two can be in >>> different formats. >>> Stein >>> -----Original Message----- >>> From: ImageJ Interest Group <[hidden email] >>> <mailto:[hidden email]>> On Behalf Of Herbie >>> Sent: 19. mai 2020 16:18 >>> To: [hidden email] <mailto:[hidden email]> >>> Subject: Re: A suggestion for additional Image Property functions >>> Good day Michael, >>> please allow me to state that this was possible already and I used it >>> since years: >>> set: >>> List.set( "key1", val1 ); >>> ... >>> List.set( "keyN", valN ); >>> setMetadata( "Info", List.getList() ); >>> List.clear; >>> get: >>> List.setList( getMetadata( "Info" ) ); >>> val1 = List.getValue( "key1" ); >>> ... >>> valN = List.getValue( "keyN" ); >>> List.clear(); >>> ...or do I miss something special? >>> Regards >>> Herbie >>> ::::::::::::::::::::::::::::::::::::::::::: >>> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>>> Thanks from me too. >>>> >>>> Adding simple to use, extensible persistent metadata IMO makes >>>> ImageJ1 adds a significant value for image app developers. >>>> >>>> — Michael Ellis >>>> >>>> >>>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email] >>>>>> <mailto:[hidden email]>> wrote: >>>>>> >>>>>> Since version 1.53a we now have the very useful ability to set >>>>>> persistent image properties: >>>>>> >>>>>> Property.get(key) >>>>>> Property.set(key,value) >>>>>> >>>>>> These are analogue to the existing List functions: >>>>>> >>>>>> List.get(key) >>>>>> List.set(key, value) >>>>>> >>>>>> We also have these List functions for reading/writing a key/value >>>>>> list as an entity: >>>>>> >>>>>> List.getList - Returns the list as a string. >>>>>> List.setList(list) - Loads the key/value pairs in >>>>>> the string list. >>>>>> >>>>>> What about adding equivalent functions for moving data from image >>>>>> properties to a List and vice versa: >>>>>> >>>>>> Property.getList - Returns the image properties as >>>>>> a string. >>>>>> Property.setList(list) - Sets the key/value pairs >>>>>> in the string list as image properties. >>>>> >>>>> Good suggestion. Property.getList and Property.setList(list) are in >>>>> the latest daily build (1.52b19). >>>>> >>>>> -wayne >>>>> >>>>>> Then we can write the current List as image properties, for >>>>>> persistent storage with the image: >>>>>> >>>>>> Property.setList(List.getList) >>>>>> >>>>>> Or the other way around: >>>>>> >>>>>> List.setList(Property.getList) >>>>>> >>>>>> I think this could make custom metadata handling even easier than >>>>>> it is today! >>>>>> >>>>>> Stein >>>>> >>>>> -- >>>>> ImageJ mailing list: >>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>> >>>> Michael Ellis (Managing Director) >>>> Digital Scientific UK Ltd. >>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >>>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >>>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >>>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >>>> &reserved=0 >>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >>>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >>>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >>>> D&reserved=0> >>>> [hidden email] >>>> tel: +44(0)1223 911215 >>>> >>>> The Commercial Centre >>>> 6 Green End >>>> Cambridge >>>> CB23 7DY >>>> >>>> === END OF EMAIL === >>>> >>>> >>>> -- >>>> ImageJ mailing list: >>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage >>>> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no >>>> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af >>>> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrAp >>>> eqmCvq1fmJ8Yw%3D&reserved=0 >>>> >>> -- >>> ImageJ mailing list: >>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrApeqmCvq1fmJ8Yw%3D&reserved=0 >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > Michael Ellis (Managing Director) > Digital Scientific UK Ltd. > http://www.dsuk.biz > [hidden email] <mailto:[hidden email]> > tel: +44(0)1223 911215 > > The Commercial Centre > 6 Green End > Cambridge > CB23 7DY > > === END OF EMAIL === > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
Wayne’s example is just illustrative that this mechanism can be used for attaching ANY persistent image metadata to ImageJ images.
As another example which would make perhaps more sense, say I want to implement a karyotyping application, I could use ImageJ ij.jar as a library and store the associated karyotyping information about the chromosomes within the Image string properties. Typically I might encode that extra data using JSON or XML. As with Wayne’s example the string is technically human readable insofar as the metatdata is Base64 encoded. It’s just there may be rather a lot of it. In my opinion, this new feature, is actually a landmark improvement to ImageJ particularly for itsImageJ’s use as a Jar library for imaging application development. The take home point is that if your fundamental document content is in anyway based upon an image, you can just use Image existing native Save/Open functionality and know you can attach any persistent extra metadata to the image without minimal fear of it being lost or overwritten by ImageJ or ImageJ Plugins In addition, the image remains immediately viewable in ImageJ with no additional plugins or support required. Again back to my hypothetical example of a karyotyper. I could create a karyotyper application using ij.jar as a library. My application would show the raw metaphase image but also the karyotype along with providing all the karyotype editing tools. However the basic karyotype document would still be openable in ImageJ where you would see the metaphase image. You can imagine many other examples. — Michael Ellis > On 20 May 2020, at 09:12, Herbie <[hidden email]> wrote: > > Dear Michael, > > I saw Wayne's example but I don't understand why we should store images as properties. Not everything that is possible makes sense (for me)... > > Human readable text, strings or numbers (metadata), stored with images proved useful for several purposes and if we can now be sure that they are not overwritten (did anybody encounter this case in practice?), the situation appears to be improved although these new "key value"-lists are no longer human readable. > > If users needs an additional software (plugin or macro) to read and report metadata, things appear unnecessarily complicated. > > But, as so often, I may not have grasped the idea. > > Best regards > > Herbie > > ::::::::::::::::::::::::::::::::::::::::::: > Am 20.05.20 um 09:56 schrieb Michael Ellis: >> Wayne added the feature to list the property keys, but NOT the values in the Info window. >> This makes sense because the values may well be strings used to encode huge amounts of data. Below is an example by Wayne for encoding an image as string and then assigning it as a String property of another image! >> You could of course write a plugin or script to enumerate the properties yourself. >> — Michael >>> The ImageJ 1.53a3 daily build adds setProp() and getProp() methods for saving and restoring string properties. The following JavaScript demonstrates how to use these new methods. Since they only work with strings, it also shows how to encode non-string objects, such images, into strings. >>> >>> -wayne >>> >>> img = IJ.createImage("Untitled", "8-bit black", 500, 500, 3); >>> clown = IJ.openImage("http://wsr.imagej.net/images/clown.jpg"); >>> bytes = new FileSaver(clown).serialize(); >>> string = Base64.getEncoder().encodeToString(bytes); >>> img.setProp("clown", string); >>> text = "Clown.jpg was serialized, set as an image\n" >>> + "property, the image was saved, re-opened,\n" >>> + "and clown.jpg was deserialized and displayed."; >>> img.setProp("text", text); >>> path = IJ.getDir("home")+"Downloads/Untitled.tif"; >>> IJ.saveAs(img, "Tiff", path); >>> img2 = IJ.openImage(path); >>> string2 = img2.getProp("clown"); >>> bytes2 = Base64.getDecoder().decode(string2); >>> clown2 = new Opener().deserialize(bytes2); >>> clown2.show(); >>> IJ.showMessage(img2.getProp("text")); >>> >>> On 20 May 2020, at 08:43, Herbie <[hidden email] <mailto:[hidden email]>> wrote: >>> >>> Dear Michael and Stein, >>> >>> thanks for the details. >>> >>> I hope we shall see a solution where the "key value"-*pairs* are visible in the Info-window. For me it proved useful for "diagnostic" purposes... >>> >>> Herbie >>> >>> :::::::::::::::::::::::::::::::::::::::::: >>> Am 20.05.20 um 00:32 schrieb Stein Rørvik: >>>> Yes this approach works, but only when the list metadata is the _only_ metadata present. That is, the call setMetadata("Info", List.getList()); will erase anything stored in the Info field which is not part of your list. With the new functionality, the list can be stored in the persistent image properties instead, and the existing "Info" metadata can be used for other information. So we now have two ways to store metadata instead of just one, and the two can be in different formats. >>>> Stein >>>> -----Original Message----- >>>> From: ImageJ Interest Group <[hidden email] <mailto:[hidden email]>> On Behalf Of Herbie >>>> Sent: 19. mai 2020 16:18 >>>> To: [hidden email] <mailto:[hidden email]> >>>> Subject: Re: A suggestion for additional Image Property functions >>>> Good day Michael, >>>> please allow me to state that this was possible already and I used it since years: >>>> set: >>>> List.set( "key1", val1 ); >>>> ... >>>> List.set( "keyN", valN ); >>>> setMetadata( "Info", List.getList() ); >>>> List.clear; >>>> get: >>>> List.setList( getMetadata( "Info" ) ); >>>> val1 = List.getValue( "key1" ); >>>> ... >>>> valN = List.getValue( "keyN" ); >>>> List.clear(); >>>> ...or do I miss something special? >>>> Regards >>>> Herbie >>>> ::::::::::::::::::::::::::::::::::::::::::: >>>> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>>>> Thanks from me too. >>>>> >>>>> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >>>>> >>>>> — Michael Ellis >>>>> >>>>> >>>>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email] <mailto:[hidden email]>> wrote: >>>>>> >>>>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email] <mailto:[hidden email]>> wrote: >>>>>>> >>>>>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>>>>> >>>>>>> Property.get(key) >>>>>>> Property.set(key,value) >>>>>>> >>>>>>> These are analogue to the existing List functions: >>>>>>> >>>>>>> List.get(key) >>>>>>> List.set(key, value) >>>>>>> >>>>>>> We also have these List functions for reading/writing a key/value list as an entity: >>>>>>> >>>>>>> List.getList - Returns the list as a string. >>>>>>> List.setList(list) - Loads the key/value pairs in the string list. >>>>>>> >>>>>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>>>>> >>>>>>> Property.getList - Returns the image properties as a string. >>>>>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>>>>> >>>>>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>>>>> >>>>>> -wayne >>>>>> >>>>>>> Then we can write the current List as image properties, for persistent storage with the image: >>>>>>> >>>>>>> Property.setList(List.getList) >>>>>>> >>>>>>> Or the other way around: >>>>>>> >>>>>>> List.setList(Property.getList) >>>>>>> >>>>>>> I think this could make custom metadata handling even easier than it is today! >>>>>>> >>>>>>> Stein >>>>>> >>>>>> -- >>>>>> ImageJ mailing list: >>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>>>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>>>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>>>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>> >>>>> Michael Ellis (Managing Director) >>>>> Digital Scientific UK Ltd. >>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >>>>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >>>>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >>>>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >>>>> &reserved=0 >>>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>>>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >>>>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >>>>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >>>>> D&reserved=0> >>>>> [hidden email] >>>>> tel: +44(0)1223 911215 >>>>> >>>>> The Commercial Centre >>>>> 6 Green End >>>>> Cambridge >>>>> CB23 7DY >>>>> >>>>> === END OF EMAIL === >>>>> >>>>> >>>>> -- >>>>> ImageJ mailing list: >>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage >>>>> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no >>>>> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af >>>>> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrAp >>>>> eqmCvq1fmJ8Yw%3D&reserved=0 >>>>> >>>> -- >>>> ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>> -- >>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>> >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >> Michael Ellis (Managing Director) >> Digital Scientific UK Ltd. >> http://www.dsuk.biz >> [hidden email] <mailto:[hidden email]> >> tel: +44(0)1223 911215 >> The Commercial Centre >> 6 Green End >> Cambridge >> CB23 7DY >> === END OF EMAIL === Michael Ellis (Managing Director) Digital Scientific UK Ltd. http://www.dsuk.biz <http://www.dsuk.biz/> [hidden email] tel: +44(0)1223 911215 The Commercial Centre 6 Green End Cambridge CB23 7DY === END OF EMAIL === -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Michael,
I'm not convinced. "In addition, the image remains immediately viewable in ImageJ with no additional plugins or support required." Sure, why not? I expect this. (I wrote about "key value"-*pairs* that are no longer visible when using the new technique.) Maybe metadata is not what I imagine it to be. If we speak of GIS-like behaviour (just a common example), then we don't speak about image-related metadata but about databases and your example fits well into this category. My needs are quite modest and image-centric: Simple metadata that is human readable without additional tools. Ok, I can and will stay with what was possible before and stop moaning about things that I obviously don't understand. Best regards Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 20.05.20 um 10:27 schrieb Michael Ellis: > Wayne’s example is just illustrative that this mechanism can be used for attaching ANY persistent image metadata to ImageJ images. > > As another example which would make perhaps more sense, say I want to implement a karyotyping application, I could use ImageJ ij.jar as a library and store the associated karyotyping information about the chromosomes within the Image string properties. Typically I might encode that extra data using JSON or XML. > > As with Wayne’s example the string is technically human readable insofar as the metatdata is Base64 encoded. It’s just there may be rather a lot of it. > > In my opinion, this new feature, is actually a landmark improvement to ImageJ particularly for itsImageJ’s use as a Jar library for imaging application development. The take home point is that if your fundamental document content is in anyway based upon an image, you can just use Image existing native Save/Open functionality and know you can attach any persistent extra metadata to the image without minimal fear of it being lost or overwritten by ImageJ or ImageJ Plugins > > In addition, the image remains immediately viewable in ImageJ with no additional plugins or support required. > > Again back to my hypothetical example of a karyotyper. I could create a karyotyper application using ij.jar as a library. My application would show the raw metaphase image but also the karyotype along with providing all the karyotype editing tools. > > However the basic karyotype document would still be openable in ImageJ where you would see the metaphase image. > > You can imagine many other examples. > > — Michael Ellis > > > > >> On 20 May 2020, at 09:12, Herbie <[hidden email]> wrote: >> >> Dear Michael, >> >> I saw Wayne's example but I don't understand why we should store images as properties. Not everything that is possible makes sense (for me)... >> >> Human readable text, strings or numbers (metadata), stored with images proved useful for several purposes and if we can now be sure that they are not overwritten (did anybody encounter this case in practice?), the situation appears to be improved although these new "key value"-lists are no longer human readable. >> >> If users needs an additional software (plugin or macro) to read and report metadata, things appear unnecessarily complicated. >> >> But, as so often, I may not have grasped the idea. >> >> Best regards >> >> Herbie >> >> ::::::::::::::::::::::::::::::::::::::::::: >> Am 20.05.20 um 09:56 schrieb Michael Ellis: >>> Wayne added the feature to list the property keys, but NOT the values in the Info window. >>> This makes sense because the values may well be strings used to encode huge amounts of data. Below is an example by Wayne for encoding an image as string and then assigning it as a String property of another image! >>> You could of course write a plugin or script to enumerate the properties yourself. >>> — Michael >>>> The ImageJ 1.53a3 daily build adds setProp() and getProp() methods for saving and restoring string properties. The following JavaScript demonstrates how to use these new methods. Since they only work with strings, it also shows how to encode non-string objects, such images, into strings. >>>> >>>> -wayne >>>> >>>> img = IJ.createImage("Untitled", "8-bit black", 500, 500, 3); >>>> clown = IJ.openImage("http://wsr.imagej.net/images/clown.jpg"); >>>> bytes = new FileSaver(clown).serialize(); >>>> string = Base64.getEncoder().encodeToString(bytes); >>>> img.setProp("clown", string); >>>> text = "Clown.jpg was serialized, set as an image\n" >>>> + "property, the image was saved, re-opened,\n" >>>> + "and clown.jpg was deserialized and displayed."; >>>> img.setProp("text", text); >>>> path = IJ.getDir("home")+"Downloads/Untitled.tif"; >>>> IJ.saveAs(img, "Tiff", path); >>>> img2 = IJ.openImage(path); >>>> string2 = img2.getProp("clown"); >>>> bytes2 = Base64.getDecoder().decode(string2); >>>> clown2 = new Opener().deserialize(bytes2); >>>> clown2.show(); >>>> IJ.showMessage(img2.getProp("text")); >>>> >>>> On 20 May 2020, at 08:43, Herbie <[hidden email] <mailto:[hidden email]>> wrote: >>>> >>>> Dear Michael and Stein, >>>> >>>> thanks for the details. >>>> >>>> I hope we shall see a solution where the "key value"-*pairs* are visible in the Info-window. For me it proved useful for "diagnostic" purposes... >>>> >>>> Herbie >>>> >>>> :::::::::::::::::::::::::::::::::::::::::: >>>> Am 20.05.20 um 00:32 schrieb Stein Rørvik: >>>>> Yes this approach works, but only when the list metadata is the _only_ metadata present. That is, the call setMetadata("Info", List.getList()); will erase anything stored in the Info field which is not part of your list. With the new functionality, the list can be stored in the persistent image properties instead, and the existing "Info" metadata can be used for other information. So we now have two ways to store metadata instead of just one, and the two can be in different formats. >>>>> Stein >>>>> -----Original Message----- >>>>> From: ImageJ Interest Group <[hidden email] <mailto:[hidden email]>> On Behalf Of Herbie >>>>> Sent: 19. mai 2020 16:18 >>>>> To: [hidden email] <mailto:[hidden email]> >>>>> Subject: Re: A suggestion for additional Image Property functions >>>>> Good day Michael, >>>>> please allow me to state that this was possible already and I used it since years: >>>>> set: >>>>> List.set( "key1", val1 ); >>>>> ... >>>>> List.set( "keyN", valN ); >>>>> setMetadata( "Info", List.getList() ); >>>>> List.clear; >>>>> get: >>>>> List.setList( getMetadata( "Info" ) ); >>>>> val1 = List.getValue( "key1" ); >>>>> ... >>>>> valN = List.getValue( "keyN" ); >>>>> List.clear(); >>>>> ...or do I miss something special? >>>>> Regards >>>>> Herbie >>>>> ::::::::::::::::::::::::::::::::::::::::::: >>>>> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>>>>> Thanks from me too. >>>>>> >>>>>> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >>>>>> >>>>>> — Michael Ellis >>>>>> >>>>>> >>>>>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email] <mailto:[hidden email]>> wrote: >>>>>>> >>>>>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email] <mailto:[hidden email]>> wrote: >>>>>>>> >>>>>>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>>>>>> >>>>>>>> Property.get(key) >>>>>>>> Property.set(key,value) >>>>>>>> >>>>>>>> These are analogue to the existing List functions: >>>>>>>> >>>>>>>> List.get(key) >>>>>>>> List.set(key, value) >>>>>>>> >>>>>>>> We also have these List functions for reading/writing a key/value list as an entity: >>>>>>>> >>>>>>>> List.getList - Returns the list as a string. >>>>>>>> List.setList(list) - Loads the key/value pairs in the string list. >>>>>>>> >>>>>>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>>>>>> >>>>>>>> Property.getList - Returns the image properties as a string. >>>>>>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>>>>>> >>>>>>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>>>>>> >>>>>>> -wayne >>>>>>> >>>>>>>> Then we can write the current List as image properties, for persistent storage with the image: >>>>>>>> >>>>>>>> Property.setList(List.getList) >>>>>>>> >>>>>>>> Or the other way around: >>>>>>>> >>>>>>>> List.setList(Property.getList) >>>>>>>> >>>>>>>> I think this could make custom metadata handling even easier than it is today! >>>>>>>> >>>>>>>> Stein >>>>>>> >>>>>>> -- >>>>>>> ImageJ mailing list: >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>>>>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>>>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>>>>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>>>>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>>> >>>>>> Michael Ellis (Managing Director) >>>>>> Digital Scientific UK Ltd. >>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >>>>>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >>>>>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >>>>>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >>>>>> &reserved=0 >>>>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>>>>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >>>>>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >>>>>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >>>>>> D&reserved=0> >>>>>> [hidden email] >>>>>> tel: +44(0)1223 911215 >>>>>> >>>>>> The Commercial Centre >>>>>> 6 Green End >>>>>> Cambridge >>>>>> CB23 7DY >>>>>> >>>>>> === END OF EMAIL === >>>>>> >>>>>> >>>>>> -- >>>>>> ImageJ mailing list: >>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage >>>>>> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no >>>>>> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af >>>>>> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrAp >>>>>> eqmCvq1fmJ8Yw%3D&reserved=0 >>>>>> >>>>> -- >>>>> ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>> -- >>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>>> >>>> -- >>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>> Michael Ellis (Managing Director) >>> Digital Scientific UK Ltd. >>> http://www.dsuk.biz >>> [hidden email] <mailto:[hidden email]> >>> tel: +44(0)1223 911215 >>> The Commercial Centre >>> 6 Green End >>> Cambridge >>> CB23 7DY >>> === END OF EMAIL === > > Michael Ellis (Managing Director) > Digital Scientific UK Ltd. > http://www.dsuk.biz <http://www.dsuk.biz/> > [hidden email] > tel: +44(0)1223 911215 > > The Commercial Centre > 6 Green End > Cambridge > CB23 7DY > > === END OF EMAIL === > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
Hi Herbie,
Do not know if this helps, but if you want to list all the persistent properties and their values var clown = IJ.openImage("http://wsr.imagej.net/images/clown.jpg"); clown.setProp("biz.dsuk.moon-phase", "waxing"); clown.setProp(“biz.dsuk.oven-temperatue", "220"); path = IJ.getDir("home")+"Downloads/Untitled.tif"; IJ.saveAs(clown, "Tiff", path); img2 = IJ.openImage(path); img2.show(); pa = img2.getPropertiesAsArray(); for ( i = 0; i < pa.length; i+=2) { IJ.log(pa[i] + ": " + pa[i+1]); } > On 20 May 2020, at 09:45, Herbie <[hidden email]> wrote: > > Dear Michael, > > I'm not convinced. > > "In addition, the image remains immediately viewable in ImageJ with no additional plugins or support required." > > Sure, why not? I expect this. > (I wrote about "key value"-*pairs* that are no longer visible when using the new technique.) > > Maybe metadata is not what I imagine it to be. If we speak of GIS-like behaviour (just a common example), then we don't speak about image-related metadata but about databases and your example fits well into this category. > > My needs are quite modest and image-centric: > Simple metadata that is human readable without additional tools. > Ok, I can and will stay with what was possible before and stop moaning about things that I obviously don't understand. > > Best regards > > Herbie > > ::::::::::::::::::::::::::::::::::::::::::: > Am 20.05.20 um 10:27 schrieb Michael Ellis: >> Wayne’s example is just illustrative that this mechanism can be used for attaching ANY persistent image metadata to ImageJ images. >> As another example which would make perhaps more sense, say I want to implement a karyotyping application, I could use ImageJ ij.jar as a library and store the associated karyotyping information about the chromosomes within the Image string properties. Typically I might encode that extra data using JSON or XML. >> As with Wayne’s example the string is technically human readable insofar as the metatdata is Base64 encoded. It’s just there may be rather a lot of it. >> In my opinion, this new feature, is actually a landmark improvement to ImageJ particularly for itsImageJ’s use as a Jar library for imaging application development. The take home point is that if your fundamental document content is in anyway based upon an image, you can just use Image existing native Save/Open functionality and know you can attach any persistent extra metadata to the image without minimal fear of it being lost or overwritten by ImageJ or ImageJ Plugins >> In addition, the image remains immediately viewable in ImageJ with no additional plugins or support required. >> Again back to my hypothetical example of a karyotyper. I could create a karyotyper application using ij.jar as a library. My application would show the raw metaphase image but also the karyotype along with providing all the karyotype editing tools. >> However the basic karyotype document would still be openable in ImageJ where you would see the metaphase image. >> You can imagine many other examples. >> — Michael Ellis >>> On 20 May 2020, at 09:12, Herbie <[hidden email]> wrote: >>> >>> Dear Michael, >>> >>> I saw Wayne's example but I don't understand why we should store images as properties. Not everything that is possible makes sense (for me)... >>> >>> Human readable text, strings or numbers (metadata), stored with images proved useful for several purposes and if we can now be sure that they are not overwritten (did anybody encounter this case in practice?), the situation appears to be improved although these new "key value"-lists are no longer human readable. >>> >>> If users needs an additional software (plugin or macro) to read and report metadata, things appear unnecessarily complicated. >>> >>> But, as so often, I may not have grasped the idea. >>> >>> Best regards >>> >>> Herbie >>> >>> ::::::::::::::::::::::::::::::::::::::::::: >>> Am 20.05.20 um 09:56 schrieb Michael Ellis: >>>> Wayne added the feature to list the property keys, but NOT the values in the Info window. >>>> This makes sense because the values may well be strings used to encode huge amounts of data. Below is an example by Wayne for encoding an image as string and then assigning it as a String property of another image! >>>> You could of course write a plugin or script to enumerate the properties yourself. >>>> — Michael >>>>> The ImageJ 1.53a3 daily build adds setProp() and getProp() methods for saving and restoring string properties. The following JavaScript demonstrates how to use these new methods. Since they only work with strings, it also shows how to encode non-string objects, such images, into strings. >>>>> >>>>> -wayne >>>>> >>>>> img = IJ.createImage("Untitled", "8-bit black", 500, 500, 3); >>>>> clown = IJ.openImage("http://wsr.imagej.net/images/clown.jpg"); >>>>> bytes = new FileSaver(clown).serialize(); >>>>> string = Base64.getEncoder().encodeToString(bytes); >>>>> img.setProp("clown", string); >>>>> text = "Clown.jpg was serialized, set as an image\n" >>>>> + "property, the image was saved, re-opened,\n" >>>>> + "and clown.jpg was deserialized and displayed."; >>>>> img.setProp("text", text); >>>>> path = IJ.getDir("home")+"Downloads/Untitled.tif"; >>>>> IJ.saveAs(img, "Tiff", path); >>>>> img2 = IJ.openImage(path); >>>>> string2 = img2.getProp("clown"); >>>>> bytes2 = Base64.getDecoder().decode(string2); >>>>> clown2 = new Opener().deserialize(bytes2); >>>>> clown2.show(); >>>>> IJ.showMessage(img2.getProp("text")); >>>>> >>>>> On 20 May 2020, at 08:43, Herbie <[hidden email] <mailto:[hidden email]>> wrote: >>>>> >>>>> Dear Michael and Stein, >>>>> >>>>> thanks for the details. >>>>> >>>>> I hope we shall see a solution where the "key value"-*pairs* are visible in the Info-window. For me it proved useful for "diagnostic" purposes... >>>>> >>>>> Herbie >>>>> >>>>> :::::::::::::::::::::::::::::::::::::::::: >>>>> Am 20.05.20 um 00:32 schrieb Stein Rørvik: >>>>>> Yes this approach works, but only when the list metadata is the _only_ metadata present. That is, the call setMetadata("Info", List.getList()); will erase anything stored in the Info field which is not part of your list. With the new functionality, the list can be stored in the persistent image properties instead, and the existing "Info" metadata can be used for other information. So we now have two ways to store metadata instead of just one, and the two can be in different formats. >>>>>> Stein >>>>>> -----Original Message----- >>>>>> From: ImageJ Interest Group <[hidden email] <mailto:[hidden email]>> On Behalf Of Herbie >>>>>> Sent: 19. mai 2020 16:18 >>>>>> To: [hidden email] <mailto:[hidden email]> >>>>>> Subject: Re: A suggestion for additional Image Property functions >>>>>> Good day Michael, >>>>>> please allow me to state that this was possible already and I used it since years: >>>>>> set: >>>>>> List.set( "key1", val1 ); >>>>>> ... >>>>>> List.set( "keyN", valN ); >>>>>> setMetadata( "Info", List.getList() ); >>>>>> List.clear; >>>>>> get: >>>>>> List.setList( getMetadata( "Info" ) ); >>>>>> val1 = List.getValue( "key1" ); >>>>>> ... >>>>>> valN = List.getValue( "keyN" ); >>>>>> List.clear(); >>>>>> ...or do I miss something special? >>>>>> Regards >>>>>> Herbie >>>>>> ::::::::::::::::::::::::::::::::::::::::::: >>>>>> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>>>>>> Thanks from me too. >>>>>>> >>>>>>> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >>>>>>> >>>>>>> — Michael Ellis >>>>>>> >>>>>>> >>>>>>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email] <mailto:[hidden email]>> wrote: >>>>>>>> >>>>>>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email] <mailto:[hidden email]>> wrote: >>>>>>>>> >>>>>>>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>>>>>>> >>>>>>>>> Property.get(key) >>>>>>>>> Property.set(key,value) >>>>>>>>> >>>>>>>>> These are analogue to the existing List functions: >>>>>>>>> >>>>>>>>> List.get(key) >>>>>>>>> List.set(key, value) >>>>>>>>> >>>>>>>>> We also have these List functions for reading/writing a key/value list as an entity: >>>>>>>>> >>>>>>>>> List.getList - Returns the list as a string. >>>>>>>>> List.setList(list) - Loads the key/value pairs in the string list. >>>>>>>>> >>>>>>>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>>>>>>> >>>>>>>>> Property.getList - Returns the image properties as a string. >>>>>>>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>>>>>>> >>>>>>>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>>>>>>> >>>>>>>> -wayne >>>>>>>> >>>>>>>>> Then we can write the current List as image properties, for persistent storage with the image: >>>>>>>>> >>>>>>>>> Property.setList(List.getList) >>>>>>>>> >>>>>>>>> Or the other way around: >>>>>>>>> >>>>>>>>> List.setList(Property.getList) >>>>>>>>> >>>>>>>>> I think this could make custom metadata handling even easier than it is today! >>>>>>>>> >>>>>>>>> Stein >>>>>>>> >>>>>>>> -- >>>>>>>> ImageJ mailing list: >>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>>>>>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>>>>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>>>>>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>>>>>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>> >>>>>>> Michael Ellis (Managing Director) >>>>>>> Digital Scientific UK Ltd. >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >>>>>>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >>>>>>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >>>>>>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >>>>>>> &reserved=0 >>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>>>>>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >>>>>>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >>>>>>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >>>>>>> D&reserved=0> >>>>>>> [hidden email] >>>>>>> tel: +44(0)1223 911215 >>>>>>> >>>>>>> The Commercial Centre >>>>>>> 6 Green End >>>>>>> Cambridge >>>>>>> CB23 7DY >>>>>>> >>>>>>> === END OF EMAIL === >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ImageJ mailing list: >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage >>>>>>> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no >>>>>>> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af >>>>>>> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrAp >>>>>>> eqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>> >>>>>> -- >>>>>> ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>>> -- >>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>>>> >>>>> -- >>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>>> Michael Ellis (Managing Director) >>>> Digital Scientific UK Ltd. >>>> http://www.dsuk.biz >>>> [hidden email] <mailto:[hidden email]> >>>> tel: +44(0)1223 911215 >>>> The Commercial Centre >>>> 6 Green End >>>> Cambridge >>>> CB23 7DY >>>> === END OF EMAIL === >> Michael Ellis (Managing Director) >> Digital Scientific UK Ltd. >> http://www.dsuk.biz <http://www.dsuk.biz/> >> [hidden email] >> tel: +44(0)1223 911215 >> The Commercial Centre >> 6 Green End >> Cambridge >> CB23 7DY >> === END OF EMAIL === >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html Michael Ellis (Managing Director) Digital Scientific UK Ltd. http://www.dsuk.biz <http://www.dsuk.biz/> [hidden email] tel: +44(0)1223 911215 The Commercial Centre 6 Green End Cambridge CB23 7DY === END OF EMAIL === -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
No, Michael and sorry,
it doesn't help! I know how to do it but it is not what I should like to see for users and for their feedback... As I wrote, I'm happy with what we have for years and I doubt that there are any cases in the real where important metadata in the Info window was overwritten. Furthermore, I don't like to see ImageJ mutate to a database, in the same sense as I don't want to see it mutate to a data graphing application etc. Best Regards Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 20.05.20 um 12:18 schrieb Michael Ellis: > Hi Herbie, > > Do not know if this helps, but if you want to list all the persistent > properties and their values > > var clown = IJ.openImage("http://wsr.imagej.net/images/clown.jpg"); > clown.setProp("biz.dsuk.moon-phase", "waxing"); > clown.setProp(“biz.dsuk.oven-temperatue", "220"); > path = IJ.getDir("home")+"Downloads/Untitled.tif"; > IJ.saveAs(clown, "Tiff", path); > img2 = IJ.openImage(path); > img2.show(); > > pa = img2.getPropertiesAsArray(); > for ( i = 0; i < pa.length; i+=2) { > IJ.log(pa[i] + ": " + pa[i+1]); > } > > >> On 20 May 2020, at 09:45, Herbie <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Dear Michael, >> >> I'm not convinced. >> >> "In addition, the image remains immediately viewable in ImageJ with no >> additional plugins or support required." >> >> Sure, why not? I expect this. >> (I wrote about "key value"-*pairs* that are no longer visible when >> using the new technique.) >> >> Maybe metadata is not what I imagine it to be. If we speak of GIS-like >> behaviour (just a common example), then we don't speak about >> image-related metadata but about databases and your example fits well >> into this category. >> >> My needs are quite modest and image-centric: >> Simple metadata that is human readable without additional tools. >> Ok, I can and will stay with what was possible before and stop moaning >> about things that I obviously don't understand. >> >> Best regards >> >> Herbie >> >> ::::::::::::::::::::::::::::::::::::::::::: >> Am 20.05.20 um 10:27 schrieb Michael Ellis: >>> Wayne’s example is just illustrative that this mechanism can be used >>> for attaching ANY persistent image metadata to ImageJ images. >>> As another example which would make perhaps more sense, say I want to >>> implement a karyotyping application, I could use ImageJ ij.jar as a >>> library and store the associated karyotyping information about the >>> chromosomes within the Image string properties. Typically I might >>> encode that extra data using JSON or XML. >>> As with Wayne’s example the string is technically human readable >>> insofar as the metatdata is Base64 encoded. It’s just there may be >>> rather a lot of it. >>> In my opinion, this new feature, is actually a landmark improvement >>> to ImageJ particularly for itsImageJ’s use as a Jar library for >>> imaging application development. The take home point is that if your >>> fundamental document content is in anyway based upon an image, you >>> can just use Image existing native Save/Open functionality and know >>> you can attach any persistent extra metadata to the image without >>> minimal fear of it being lost or overwritten by ImageJ or ImageJ Plugins >>> In addition, the image remains immediately viewable in ImageJ with no >>> additional plugins or support required. >>> Again back to my hypothetical example of a karyotyper. I could create >>> a karyotyper application using ij.jar as a library. My application >>> would show the raw metaphase image but also the karyotype along with >>> providing all the karyotype editing tools. >>> However the basic karyotype document would still be openable in >>> ImageJ where you would see the metaphase image. >>> You can imagine many other examples. >>> — Michael Ellis >>>> On 20 May 2020, at 09:12, Herbie <[hidden email] >>>> <mailto:[hidden email]>> wrote: >>>> >>>> Dear Michael, >>>> >>>> I saw Wayne's example but I don't understand why we should store >>>> images as properties. Not everything that is possible makes sense >>>> (for me)... >>>> >>>> Human readable text, strings or numbers (metadata), stored with >>>> images proved useful for several purposes and if we can now be sure >>>> that they are not overwritten (did anybody encounter this case in >>>> practice?), the situation appears to be improved although these new >>>> "key value"-lists are no longer human readable. >>>> >>>> If users needs an additional software (plugin or macro) to read and >>>> report metadata, things appear unnecessarily complicated. >>>> >>>> But, as so often, I may not have grasped the idea. >>>> >>>> Best regards >>>> >>>> Herbie >>>> >>>> ::::::::::::::::::::::::::::::::::::::::::: >>>> Am 20.05.20 um 09:56 schrieb Michael Ellis: >>>>> Wayne added the feature to list the property keys, but NOT the >>>>> values in the Info window. >>>>> This makes sense because the values may well be strings used to >>>>> encode huge amounts of data. Below is an example by Wayne for >>>>> encoding an image as string and then assigning it as a String >>>>> property of another image! >>>>> You could of course write a plugin or script to enumerate the >>>>> properties yourself. >>>>> — Michael >>>>>> The ImageJ 1.53a3 daily build adds setProp() and getProp() methods >>>>>> for saving and restoring string properties. The following >>>>>> JavaScript demonstrates how to use these new methods. Since they >>>>>> only work with strings, it also shows how to encode non-string >>>>>> objects, such images, into strings. >>>>>> >>>>>> -wayne >>>>>> >>>>>> img = IJ.createImage("Untitled", "8-bit black", 500, 500, 3); >>>>>> clown = IJ.openImage("http://wsr.imagej.net/images/clown.jpg"); >>>>>> bytes = new FileSaver(clown).serialize(); >>>>>> string = Base64.getEncoder().encodeToString(bytes); >>>>>> img.setProp("clown", string); >>>>>> text = "Clown.jpg was serialized, set as an image\n" >>>>>> + "property, the image was saved, re-opened,\n" >>>>>> + "and clown.jpg was deserialized and displayed."; >>>>>> img.setProp("text", text); >>>>>> path = IJ.getDir("home")+"Downloads/Untitled.tif"; >>>>>> IJ.saveAs(img, "Tiff", path); >>>>>> img2 = IJ.openImage(path); >>>>>> string2 = img2.getProp("clown"); >>>>>> bytes2 = Base64.getDecoder().decode(string2); >>>>>> clown2 = new Opener().deserialize(bytes2); >>>>>> clown2.show(); >>>>>> IJ.showMessage(img2.getProp("text")); >>>>>> >>>>>> On 20 May 2020, at 08:43, Herbie <[hidden email] >>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> wrote: >>>>>> >>>>>> Dear Michael and Stein, >>>>>> >>>>>> thanks for the details. >>>>>> >>>>>> I hope we shall see a solution where the "key value"-*pairs* are >>>>>> visible in the Info-window. For me it proved useful for >>>>>> "diagnostic" purposes... >>>>>> >>>>>> Herbie >>>>>> >>>>>> :::::::::::::::::::::::::::::::::::::::::: >>>>>> Am 20.05.20 um 00:32 schrieb Stein Rørvik: >>>>>>> Yes this approach works, but only when the list metadata is the >>>>>>> _only_ metadata present. That is, the call setMetadata("Info", >>>>>>> List.getList()); will erase anything stored in the Info field >>>>>>> which is not part of your list. With the new functionality, the >>>>>>> list can be stored in the persistent image properties instead, >>>>>>> and the existing "Info" metadata can be used for other >>>>>>> information. So we now have two ways to store metadata instead of >>>>>>> just one, and the two can be in different formats. >>>>>>> Stein >>>>>>> -----Original Message----- >>>>>>> From: ImageJ Interest Group <[hidden email] >>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> On >>>>>>> Behalf Of Herbie >>>>>>> Sent: 19. mai 2020 16:18 >>>>>>> To: [hidden email] <mailto:[hidden email]> >>>>>>> <mailto:[hidden email]> >>>>>>> Subject: Re: A suggestion for additional Image Property functions >>>>>>> Good day Michael, >>>>>>> please allow me to state that this was possible already and I >>>>>>> used it since years: >>>>>>> set: >>>>>>> List.set( "key1", val1 ); >>>>>>> ... >>>>>>> List.set( "keyN", valN ); >>>>>>> setMetadata( "Info", List.getList() ); >>>>>>> List.clear; >>>>>>> get: >>>>>>> List.setList( getMetadata( "Info" ) ); >>>>>>> val1 = List.getValue( "key1" ); >>>>>>> ... >>>>>>> valN = List.getValue( "keyN" ); >>>>>>> List.clear(); >>>>>>> ...or do I miss something special? >>>>>>> Regards >>>>>>> Herbie >>>>>>> ::::::::::::::::::::::::::::::::::::::::::: >>>>>>> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>>>>>>> Thanks from me too. >>>>>>>> >>>>>>>> Adding simple to use, extensible persistent metadata IMO makes >>>>>>>> ImageJ1 adds a significant value for image app developers. >>>>>>>> >>>>>>>> — Michael Ellis >>>>>>>> >>>>>>>> >>>>>>>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email] >>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> wrote: >>>>>>>>> >>>>>>>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik >>>>>>>>>> <[hidden email] <mailto:[hidden email]> >>>>>>>>>> <mailto:[hidden email]>> wrote: >>>>>>>>>> >>>>>>>>>> Since version 1.53a we now have the very useful ability to set >>>>>>>>>> persistent image properties: >>>>>>>>>> >>>>>>>>>> Property.get(key) >>>>>>>>>> Property.set(key,value) >>>>>>>>>> >>>>>>>>>> These are analogue to the existing List functions: >>>>>>>>>> >>>>>>>>>> List.get(key) >>>>>>>>>> List.set(key, value) >>>>>>>>>> >>>>>>>>>> We also have these List functions for reading/writing a >>>>>>>>>> key/value list as an entity: >>>>>>>>>> >>>>>>>>>> List.getList - Returns the list as a string. >>>>>>>>>> List.setList(list) - Loads the key/value pairs >>>>>>>>>> in the string list. >>>>>>>>>> >>>>>>>>>> What about adding equivalent functions for moving data from >>>>>>>>>> image properties to a List and vice versa: >>>>>>>>>> >>>>>>>>>> Property.getList - Returns the image properties >>>>>>>>>> as a string. >>>>>>>>>> Property.setList(list) - Sets the key/value >>>>>>>>>> pairs in the string list as image properties. >>>>>>>>> >>>>>>>>> Good suggestion. Property.getList and Property.setList(list) >>>>>>>>> are in the latest daily build (1.52b19). >>>>>>>>> >>>>>>>>> -wayne >>>>>>>>> >>>>>>>>>> Then we can write the current List as image properties, for >>>>>>>>>> persistent storage with the image: >>>>>>>>>> >>>>>>>>>> Property.setList(List.getList) >>>>>>>>>> >>>>>>>>>> Or the other way around: >>>>>>>>>> >>>>>>>>>> List.setList(Property.getList) >>>>>>>>>> >>>>>>>>>> I think this could make custom metadata handling even easier >>>>>>>>>> than it is today! >>>>>>>>>> >>>>>>>>>> Stein >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ImageJ mailing list: >>>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>>>>>>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>>>>>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>>>>>>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>>>>>>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>>> >>>>>>>> Michael Ellis (Managing Director) >>>>>>>> Digital Scientific UK Ltd. >>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >>>>>>>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >>>>>>>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >>>>>>>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >>>>>>>> &reserved=0 >>>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>>>>>>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >>>>>>>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >>>>>>>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >>>>>>>> D&reserved=0> >>>>>>>> [hidden email] >>>>>>>> tel: +44(0)1223 911215 >>>>>>>> >>>>>>>> The Commercial Centre >>>>>>>> 6 Green End >>>>>>>> Cambridge >>>>>>>> CB23 7DY >>>>>>>> >>>>>>>> === END OF EMAIL === >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ImageJ mailing list: >>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimage >>>>>>>> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no >>>>>>>> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af >>>>>>>> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrAp >>>>>>>> eqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>>> >>>>>>> -- >>>>>>> ImageJ mailing list: >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XUmrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>> -- >>>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>>>>> >>>>>> -- >>>>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>>>> Michael Ellis (Managing Director) >>>>> Digital Scientific UK Ltd. >>>>> http://www.dsuk.biz >>>>> [hidden email] <mailto:[hidden email]> >>>>> tel: +44(0)1223 911215 >>>>> The Commercial Centre >>>>> 6 Green End >>>>> Cambridge >>>>> CB23 7DY >>>>> === END OF EMAIL === >>> Michael Ellis (Managing Director) >>> Digital Scientific UK Ltd. >>> http://www.dsuk.biz <http://www.dsuk.biz/> >>> [hidden email] <mailto:[hidden email]> >>> tel: +44(0)1223 911215 >>> The Commercial Centre >>> 6 Green End >>> Cambridge >>> CB23 7DY >>> === END OF EMAIL === >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > Michael Ellis (Managing Director) > Digital Scientific UK Ltd. > http://www.dsuk.biz > [hidden email] <mailto:[hidden email]> > tel: +44(0)1223 911215 > > The Commercial Centre > 6 Green End > Cambridge > CB23 7DY > > === END OF EMAIL === > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
Isn't the TIFF format already a type of database?
I see the new Image Properties as nothing else than an easy way to add custom entries to that. Apparently the properties are stored as custom TIFF tags, so nothing has changed in the existing image structure, there is just a small addition to it. Many applications already store metadata as custom tags. Stein -----Original Message----- From: ImageJ Interest Group <[hidden email]> On Behalf Of Herbie Sent: 20. mai 2020 12:28 To: [hidden email] Subject: Re: A suggestion for additional Image Property functions No, Michael and sorry, it doesn't help! I know how to do it but it is not what I should like to see for users and for their feedback... As I wrote, I'm happy with what we have for years and I doubt that there are any cases in the real where important metadata in the Info window was overwritten. Furthermore, I don't like to see ImageJ mutate to a database, in the same sense as I don't want to see it mutate to a data graphing application etc. Best Regards Herbie ::::::::::::::::::::::::::::::::::::::::::: Am 20.05.20 um 12:18 schrieb Michael Ellis: > Hi Herbie, > > Do not know if this helps, but if you want to list all the persistent > properties and their values > > var clown = > IJ.openImage("https://eur03.safelinks.protection.outlook.com/?url=http > %3A%2F%2Fwsr.imagej.net%2Fimages%2Fclown.jpg&data=02%7C01%7Cstein. > rorvik%40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145 > b0b309e0210d8b32af%7C1%7C1%7C637255679876306307&sdata=34myehTNCX1B > NgvEpVp01O1dmsFgam7dIp%2FsrbiUMSA%3D&reserved=0"); > clown.setProp("biz.dsuk.moon-phase", "waxing"); > clown.setProp(“biz.dsuk.oven-temperatue", "220"); path = > IJ.getDir("home")+"Downloads/Untitled.tif"; > IJ.saveAs(clown, "Tiff", path); > img2 = IJ.openImage(path); > img2.show(); > > pa = img2.getPropertiesAsArray(); > for ( i = 0; i < pa.length; i+=2) { > IJ.log(pa[i] + ": " + pa[i+1]); > } > > >> On 20 May 2020, at 09:45, Herbie <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Dear Michael, >> >> I'm not convinced. >> >> "In addition, the image remains immediately viewable in ImageJ with >> no additional plugins or support required." >> >> Sure, why not? I expect this. >> (I wrote about "key value"-*pairs* that are no longer visible when >> using the new technique.) >> >> Maybe metadata is not what I imagine it to be. If we speak of >> GIS-like behaviour (just a common example), then we don't speak about >> image-related metadata but about databases and your example fits well >> into this category. >> >> My needs are quite modest and image-centric: >> Simple metadata that is human readable without additional tools. >> Ok, I can and will stay with what was possible before and stop >> moaning about things that I obviously don't understand. >> >> Best regards >> >> Herbie >> >> ::::::::::::::::::::::::::::::::::::::::::: >> Am 20.05.20 um 10:27 schrieb Michael Ellis: >>> Wayne’s example is just illustrative that this mechanism can be used >>> for attaching ANY persistent image metadata to ImageJ images. >>> As another example which would make perhaps more sense, say I want >>> to implement a karyotyping application, I could use ImageJ ij.jar as >>> a library and store the associated karyotyping information about the >>> chromosomes within the Image string properties. Typically I might >>> encode that extra data using JSON or XML. >>> As with Wayne’s example the string is technically human readable >>> insofar as the metatdata is Base64 encoded. It’s just there may be >>> rather a lot of it. >>> In my opinion, this new feature, is actually a landmark improvement >>> to ImageJ particularly for itsImageJ’s use as a Jar library for >>> imaging application development. The take home point is that if your >>> fundamental document content is in anyway based upon an image, you >>> can just use Image existing native Save/Open functionality and know >>> you can attach any persistent extra metadata to the image without >>> minimal fear of it being lost or overwritten by ImageJ or ImageJ >>> Plugins In addition, the image remains immediately viewable in >>> ImageJ with no additional plugins or support required. >>> Again back to my hypothetical example of a karyotyper. I could >>> create a karyotyper application using ij.jar as a library. My >>> application would show the raw metaphase image but also the >>> karyotype along with providing all the karyotype editing tools. >>> However the basic karyotype document would still be openable in >>> ImageJ where you would see the metaphase image. >>> You can imagine many other examples. >>> — Michael Ellis >>>> On 20 May 2020, at 09:12, Herbie <[hidden email] >>>> <mailto:[hidden email]>> wrote: >>>> >>>> Dear Michael, >>>> >>>> I saw Wayne's example but I don't understand why we should store >>>> images as properties. Not everything that is possible makes sense >>>> (for me)... >>>> >>>> Human readable text, strings or numbers (metadata), stored with >>>> images proved useful for several purposes and if we can now be sure >>>> that they are not overwritten (did anybody encounter this case in >>>> practice?), the situation appears to be improved although these new >>>> "key value"-lists are no longer human readable. >>>> >>>> If users needs an additional software (plugin or macro) to read and >>>> report metadata, things appear unnecessarily complicated. >>>> >>>> But, as so often, I may not have grasped the idea. >>>> >>>> Best regards >>>> >>>> Herbie >>>> >>>> ::::::::::::::::::::::::::::::::::::::::::: >>>> Am 20.05.20 um 09:56 schrieb Michael Ellis: >>>>> Wayne added the feature to list the property keys, but NOT the >>>>> values in the Info window. >>>>> This makes sense because the values may well be strings used to >>>>> encode huge amounts of data. Below is an example by Wayne for >>>>> encoding an image as string and then assigning it as a String >>>>> property of another image! >>>>> You could of course write a plugin or script to enumerate the >>>>> properties yourself. >>>>> — Michael >>>>>> The ImageJ 1.53a3 daily build adds setProp() and getProp() >>>>>> methods for saving and restoring string properties. The following >>>>>> JavaScript demonstrates how to use these new methods. Since they >>>>>> only work with strings, it also shows how to encode non-string >>>>>> objects, such images, into strings. >>>>>> >>>>>> -wayne >>>>>> >>>>>> img = IJ.createImage("Untitled", "8-bit black", 500, 500, 3); >>>>>> clown = >>>>>> IJ.openImage("https://eur03.safelinks.protection.outlook.com/?url >>>>>> =http%3A%2F%2Fwsr.imagej.net%2Fimages%2Fclown.jpg&data=02%7C0 >>>>>> 1%7Cstein.rorvik%40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7 >>>>>> Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637255679876316263&am >>>>>> p;sdata=76tZnLaKKp8d%2FxQpTzgaO92kDsFWn7al6bXr665Iib8%3D&rese >>>>>> rved=0"); >>>>>> bytes = new FileSaver(clown).serialize(); >>>>>> string = Base64.getEncoder().encodeToString(bytes); >>>>>> img.setProp("clown", string); >>>>>> text = "Clown.jpg was serialized, set as an image\n" >>>>>> + "property, the image was saved, re-opened,\n" >>>>>> + "and clown.jpg was deserialized and displayed."; >>>>>> img.setProp("text", text); >>>>>> path = IJ.getDir("home")+"Downloads/Untitled.tif"; >>>>>> IJ.saveAs(img, "Tiff", path); >>>>>> img2 = IJ.openImage(path); >>>>>> string2 = img2.getProp("clown"); >>>>>> bytes2 = Base64.getDecoder().decode(string2); >>>>>> clown2 = new Opener().deserialize(bytes2); >>>>>> clown2.show(); >>>>>> IJ.showMessage(img2.getProp("text")); >>>>>> >>>>>> On 20 May 2020, at 08:43, Herbie <[hidden email] >>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> wrote: >>>>>> >>>>>> Dear Michael and Stein, >>>>>> >>>>>> thanks for the details. >>>>>> >>>>>> I hope we shall see a solution where the "key value"-*pairs* are >>>>>> visible in the Info-window. For me it proved useful for >>>>>> "diagnostic" purposes... >>>>>> >>>>>> Herbie >>>>>> >>>>>> :::::::::::::::::::::::::::::::::::::::::: >>>>>> Am 20.05.20 um 00:32 schrieb Stein Rørvik: >>>>>>> Yes this approach works, but only when the list metadata is the >>>>>>> _only_ metadata present. That is, the call setMetadata("Info", >>>>>>> List.getList()); will erase anything stored in the Info field >>>>>>> which is not part of your list. With the new functionality, the >>>>>>> list can be stored in the persistent image properties instead, >>>>>>> and the existing "Info" metadata can be used for other >>>>>>> information. So we now have two ways to store metadata instead >>>>>>> of just one, and the two can be in different formats. >>>>>>> Stein >>>>>>> -----Original Message----- >>>>>>> From: ImageJ Interest Group <[hidden email] >>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> On >>>>>>> Behalf Of Herbie >>>>>>> Sent: 19. mai 2020 16:18 >>>>>>> To: [hidden email] <mailto:[hidden email]> >>>>>>> <mailto:[hidden email]> >>>>>>> Subject: Re: A suggestion for additional Image Property >>>>>>> functions Good day Michael, please allow me to state that this >>>>>>> was possible already and I used it since years: >>>>>>> set: >>>>>>> List.set( "key1", val1 ); >>>>>>> ... >>>>>>> List.set( "keyN", valN ); >>>>>>> setMetadata( "Info", List.getList() ); List.clear; >>>>>>> get: >>>>>>> List.setList( getMetadata( "Info" ) ); >>>>>>> val1 = List.getValue( "key1" ); >>>>>>> ... >>>>>>> valN = List.getValue( "keyN" ); >>>>>>> List.clear(); >>>>>>> ...or do I miss something special? >>>>>>> Regards >>>>>>> Herbie >>>>>>> ::::::::::::::::::::::::::::::::::::::::::: >>>>>>> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>>>>>>> Thanks from me too. >>>>>>>> >>>>>>>> Adding simple to use, extensible persistent metadata IMO makes >>>>>>>> ImageJ1 adds a significant value for image app developers. >>>>>>>> >>>>>>>> — Michael Ellis >>>>>>>> >>>>>>>> >>>>>>>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email] >>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> wrote: >>>>>>>>> >>>>>>>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik >>>>>>>>>> <[hidden email] <mailto:[hidden email]> >>>>>>>>>> <mailto:[hidden email]>> wrote: >>>>>>>>>> >>>>>>>>>> Since version 1.53a we now have the very useful ability to >>>>>>>>>> set persistent image properties: >>>>>>>>>> >>>>>>>>>> Property.get(key) >>>>>>>>>> Property.set(key,value) >>>>>>>>>> >>>>>>>>>> These are analogue to the existing List functions: >>>>>>>>>> >>>>>>>>>> List.get(key) >>>>>>>>>> List.set(key, value) >>>>>>>>>> >>>>>>>>>> We also have these List functions for reading/writing a >>>>>>>>>> key/value list as an entity: >>>>>>>>>> >>>>>>>>>> List.getList - Returns the list as a string. >>>>>>>>>> List.setList(list) - Loads the key/value pairs >>>>>>>>>> in the string list. >>>>>>>>>> >>>>>>>>>> What about adding equivalent functions for moving data from >>>>>>>>>> image properties to a List and vice versa: >>>>>>>>>> >>>>>>>>>> Property.getList - Returns the image >>>>>>>>>> properties as a string. >>>>>>>>>> Property.setList(list) - Sets the key/value >>>>>>>>>> pairs in the string list as image properties. >>>>>>>>> >>>>>>>>> Good suggestion. Property.getList and Property.setList(list) >>>>>>>>> are in the latest daily build (1.52b19). >>>>>>>>> >>>>>>>>> -wayne >>>>>>>>> >>>>>>>>>> Then we can write the current List as image properties, for >>>>>>>>>> persistent storage with the image: >>>>>>>>>> >>>>>>>>>> Property.setList(List.getList) >>>>>>>>>> >>>>>>>>>> Or the other way around: >>>>>>>>>> >>>>>>>>>> List.setList(Property.getList) >>>>>>>>>> >>>>>>>>>> I think this could make custom metadata handling even easier >>>>>>>>>> than it is today! >>>>>>>>>> >>>>>>>>>> Stein >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ImageJ mailing list: >>>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F >>>>>>>>> %2Fimag >>>>>>>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>>>>>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0 >>>>>>>>> 210d8b3 >>>>>>>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKG >>>>>>>>> HeHN0XU >>>>>>>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>>> >>>>>>>> Michael Ellis (Managing Director) Digital Scientific UK Ltd. >>>>>>>> <a href="https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F% >>>>>>>> 2Fwww.d >>>>>>>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46 >>>>>>>> a2e1cb4 >>>>>>>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1% >>>>>>>> 7C63725 >>>>>>>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47K >>>>>>>> tOeI%3D >>>>>>>> &reserved=0 >>>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>>>>>>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c4 >>>>>>>> 6a2e1cb >>>>>>>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1 >>>>>>>> %7C6372 >>>>>>>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47 >>>>>>>> KtOeI%3 >>>>>>>> D&reserved=0> >>>>>>>> [hidden email] >>>>>>>> tel: +44(0)1223 911215 >>>>>>>> >>>>>>>> The Commercial Centre >>>>>>>> 6 Green End >>>>>>>> Cambridge >>>>>>>> CB23 7DY >>>>>>>> >>>>>>>> === END OF EMAIL === >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ImageJ mailing list: >>>>>>>> <a href="https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F% >>>>>>>> 2Fimage >>>>>>>> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40si >>>>>>>> ntef.no >>>>>>>> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210 >>>>>>>> d8b32af >>>>>>>> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN >>>>>>>> 0XUmrAp >>>>>>>> eqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>>> >>>>>>> -- >>>>>>> ImageJ mailing list: >>>>>>> <a href="https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2 >>>>>>> Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik >>>>>>> %40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145 >>>>>>> b0b309e0210d8b32af%7C1%7C1%7C637255679876316263&sdata=vWOL%2 >>>>>>> FuEsArz%2B55ZtiDDLCWyvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >>>>>>> -- >>>>>>> ImageJ mailing list: >>>>>>> <a href="https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2 >>>>>>> Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik >>>>>>> %40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145 >>>>>>> b0b309e0210d8b32af%7C1%7C1%7C637255679876316263&sdata=vWOL%2 >>>>>>> FuEsArz%2B55ZtiDDLCWyvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >>>>>> >>>>>> -- >>>>>> ImageJ mailing list: >>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F >>>>>> imagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%4 >>>>>> 0sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b >>>>>> 309e0210d8b32af%7C1%7C1%7C637255679876316263&sdata=vWOL%2FuEs >>>>>> Arz%2B55ZtiDDLCWyvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >>>>> Michael Ellis (Managing Director) >>>>> Digital Scientific UK Ltd. >>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>>>> ww.dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C74072 >>>>> 5a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1 >>>>> %7C1%7C637255679876316263&sdata=iWaW8h8GxUmYivOZ0AWk2rqKVbQ%2F >>>>> kjggQ1p7js%2Bi4%2F4%3D&reserved=0 >>>>> [hidden email] <mailto:[hidden email]> >>>>> tel: +44(0)1223 911215 >>>>> The Commercial Centre >>>>> 6 Green End >>>>> Cambridge >>>>> CB23 7DY >>>>> === END OF EMAIL === >>> Michael Ellis (Managing Director) >>> Digital Scientific UK Ltd. >>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww >>> .dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C740725a91 >>> 27840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7 >>> C637255679876316263&sdata=iWaW8h8GxUmYivOZ0AWk2rqKVbQ%2FkjggQ1p7 >>> js%2Bi4%2F4%3D&reserved=0 >>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww >>> w.dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C740725a9 >>> 127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1% >>> 7C637255679876316263&sdata=iWaW8h8GxUmYivOZ0AWk2rqKVbQ%2FkjggQ1p >>> 7js%2Bi4%2F4%3D&reserved=0> [hidden email] >>> <mailto:[hidden email]> >>> tel: +44(0)1223 911215 >>> The Commercial Centre >>> 6 Green End >>> Cambridge >>> CB23 7DY >>> === END OF EMAIL === >>> -- >>> ImageJ mailing list: >>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fima >>> gej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sinte >>> f.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d >>> 8b32af%7C1%7C1%7C637255679876316263&sdata=vWOL%2FuEsArz%2B55ZtiD >>> DLCWyvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >> >> -- >> ImageJ mailing list: >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >> no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b3 >> 2af%7C1%7C1%7C637255679876316263&sdata=vWOL%2FuEsArz%2B55ZtiDDLCW >> yvo8Sg4HddsFGWlPusFcs%3D&reserved=0 > > Michael Ellis (Managing Director) > Digital Scientific UK Ltd. > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d > suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C740725a912784 > 0f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 > 5679876326218&sdata=1EaaUPRdlh52Uy1SfWxjj4t%2FO60azStldFyQffkFNpQ% > 3D&reserved=0 [hidden email] > <mailto:[hidden email]> > tel: +44(0)1223 911215 > > The Commercial Centre > 6 Green End > Cambridge > CB23 7DY > > === END OF EMAIL === > -- ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637255679876326218&sdata=bbnRZe31p0e%2B0F%2BsIHWZrD9AGGQ5WHT1rRnl5b5iHH8%3D&reserved=0 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
No problem Stein,
but storing images in images appears strange... The question is more what do you call metadata and at which point metadata becomes "primary" data. Databases in the sense I've mentioned (GIS: geographic information system) deal with data that is composed of many kinds of "primary" data (images, graphics, text documents, etc), not metadata, but with metadata as well. Regards Herbie :::::::::::::::::::::::::::::::::::::::::: Am 20.05.20 um 16:04 schrieb Stein Rørvik: > Isn't the TIFF format already a type of database? > I see the new Image Properties as nothing else than an easy way to add custom entries to that. > Apparently the properties are stored as custom TIFF tags, so nothing has changed in the existing image structure, there is just a small addition to it. Many applications already store metadata as custom tags. > > Stein > > -----Original Message----- > From: ImageJ Interest Group <[hidden email]> On Behalf Of Herbie > Sent: 20. mai 2020 12:28 > To: [hidden email] > Subject: Re: A suggestion for additional Image Property functions > > No, Michael and sorry, > > it doesn't help! > > I know how to do it but it is not what I should like to see for users and for their feedback... > > As I wrote, I'm happy with what we have for years and I doubt that there are any cases in the real where important metadata in the Info window was overwritten. > > Furthermore, I don't like to see ImageJ mutate to a database, in the same sense as I don't want to see it mutate to a data graphing application etc. > > Best Regards > > Herbie > > ::::::::::::::::::::::::::::::::::::::::::: > Am 20.05.20 um 12:18 schrieb Michael Ellis: >> Hi Herbie, >> >> Do not know if this helps, but if you want to list all the persistent >> properties and their values >> >> var clown = >> IJ.openImage("https://eur03.safelinks.protection.outlook.com/?url=http >> %3A%2F%2Fwsr.imagej.net%2Fimages%2Fclown.jpg&data=02%7C01%7Cstein. >> rorvik%40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145 >> b0b309e0210d8b32af%7C1%7C1%7C637255679876306307&sdata=34myehTNCX1B >> NgvEpVp01O1dmsFgam7dIp%2FsrbiUMSA%3D&reserved=0"); >> clown.setProp("biz.dsuk.moon-phase", "waxing"); >> clown.setProp(“biz.dsuk.oven-temperatue", "220"); path = >> IJ.getDir("home")+"Downloads/Untitled.tif"; >> IJ.saveAs(clown, "Tiff", path); >> img2 = IJ.openImage(path); >> img2.show(); >> >> pa = img2.getPropertiesAsArray(); >> for ( i = 0; i < pa.length; i+=2) { >> IJ.log(pa[i] + ": " + pa[i+1]); >> } >> >> >>> On 20 May 2020, at 09:45, Herbie <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> Dear Michael, >>> >>> I'm not convinced. >>> >>> "In addition, the image remains immediately viewable in ImageJ with >>> no additional plugins or support required." >>> >>> Sure, why not? I expect this. >>> (I wrote about "key value"-*pairs* that are no longer visible when >>> using the new technique.) >>> >>> Maybe metadata is not what I imagine it to be. If we speak of >>> GIS-like behaviour (just a common example), then we don't speak about >>> image-related metadata but about databases and your example fits well >>> into this category. >>> >>> My needs are quite modest and image-centric: >>> Simple metadata that is human readable without additional tools. >>> Ok, I can and will stay with what was possible before and stop >>> moaning about things that I obviously don't understand. >>> >>> Best regards >>> >>> Herbie >>> >>> ::::::::::::::::::::::::::::::::::::::::::: >>> Am 20.05.20 um 10:27 schrieb Michael Ellis: >>>> Wayne’s example is just illustrative that this mechanism can be used >>>> for attaching ANY persistent image metadata to ImageJ images. >>>> As another example which would make perhaps more sense, say I want >>>> to implement a karyotyping application, I could use ImageJ ij.jar as >>>> a library and store the associated karyotyping information about the >>>> chromosomes within the Image string properties. Typically I might >>>> encode that extra data using JSON or XML. >>>> As with Wayne’s example the string is technically human readable >>>> insofar as the metatdata is Base64 encoded. It’s just there may be >>>> rather a lot of it. >>>> In my opinion, this new feature, is actually a landmark improvement >>>> to ImageJ particularly for itsImageJ’s use as a Jar library for >>>> imaging application development. The take home point is that if your >>>> fundamental document content is in anyway based upon an image, you >>>> can just use Image existing native Save/Open functionality and know >>>> you can attach any persistent extra metadata to the image without >>>> minimal fear of it being lost or overwritten by ImageJ or ImageJ >>>> Plugins In addition, the image remains immediately viewable in >>>> ImageJ with no additional plugins or support required. >>>> Again back to my hypothetical example of a karyotyper. I could >>>> create a karyotyper application using ij.jar as a library. My >>>> application would show the raw metaphase image but also the >>>> karyotype along with providing all the karyotype editing tools. >>>> However the basic karyotype document would still be openable in >>>> ImageJ where you would see the metaphase image. >>>> You can imagine many other examples. >>>> — Michael Ellis >>>>> On 20 May 2020, at 09:12, Herbie <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>> Dear Michael, >>>>> >>>>> I saw Wayne's example but I don't understand why we should store >>>>> images as properties. Not everything that is possible makes sense >>>>> (for me)... >>>>> >>>>> Human readable text, strings or numbers (metadata), stored with >>>>> images proved useful for several purposes and if we can now be sure >>>>> that they are not overwritten (did anybody encounter this case in >>>>> practice?), the situation appears to be improved although these new >>>>> "key value"-lists are no longer human readable. >>>>> >>>>> If users needs an additional software (plugin or macro) to read and >>>>> report metadata, things appear unnecessarily complicated. >>>>> >>>>> But, as so often, I may not have grasped the idea. >>>>> >>>>> Best regards >>>>> >>>>> Herbie >>>>> >>>>> ::::::::::::::::::::::::::::::::::::::::::: >>>>> Am 20.05.20 um 09:56 schrieb Michael Ellis: >>>>>> Wayne added the feature to list the property keys, but NOT the >>>>>> values in the Info window. >>>>>> This makes sense because the values may well be strings used to >>>>>> encode huge amounts of data. Below is an example by Wayne for >>>>>> encoding an image as string and then assigning it as a String >>>>>> property of another image! >>>>>> You could of course write a plugin or script to enumerate the >>>>>> properties yourself. >>>>>> — Michael >>>>>>> The ImageJ 1.53a3 daily build adds setProp() and getProp() >>>>>>> methods for saving and restoring string properties. The following >>>>>>> JavaScript demonstrates how to use these new methods. Since they >>>>>>> only work with strings, it also shows how to encode non-string >>>>>>> objects, such images, into strings. >>>>>>> >>>>>>> -wayne >>>>>>> >>>>>>> img = IJ.createImage("Untitled", "8-bit black", 500, 500, 3); >>>>>>> clown = >>>>>>> IJ.openImage("https://eur03.safelinks.protection.outlook.com/?url >>>>>>> =http%3A%2F%2Fwsr.imagej.net%2Fimages%2Fclown.jpg&data=02%7C0 >>>>>>> 1%7Cstein.rorvik%40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7 >>>>>>> Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637255679876316263&am >>>>>>> p;sdata=76tZnLaKKp8d%2FxQpTzgaO92kDsFWn7al6bXr665Iib8%3D&rese >>>>>>> rved=0"); >>>>>>> bytes = new FileSaver(clown).serialize(); >>>>>>> string = Base64.getEncoder().encodeToString(bytes); >>>>>>> img.setProp("clown", string); >>>>>>> text = "Clown.jpg was serialized, set as an image\n" >>>>>>> + "property, the image was saved, re-opened,\n" >>>>>>> + "and clown.jpg was deserialized and displayed."; >>>>>>> img.setProp("text", text); >>>>>>> path = IJ.getDir("home")+"Downloads/Untitled.tif"; >>>>>>> IJ.saveAs(img, "Tiff", path); >>>>>>> img2 = IJ.openImage(path); >>>>>>> string2 = img2.getProp("clown"); >>>>>>> bytes2 = Base64.getDecoder().decode(string2); >>>>>>> clown2 = new Opener().deserialize(bytes2); >>>>>>> clown2.show(); >>>>>>> IJ.showMessage(img2.getProp("text")); >>>>>>> >>>>>>> On 20 May 2020, at 08:43, Herbie <[hidden email] >>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> wrote: >>>>>>> >>>>>>> Dear Michael and Stein, >>>>>>> >>>>>>> thanks for the details. >>>>>>> >>>>>>> I hope we shall see a solution where the "key value"-*pairs* are >>>>>>> visible in the Info-window. For me it proved useful for >>>>>>> "diagnostic" purposes... >>>>>>> >>>>>>> Herbie >>>>>>> >>>>>>> :::::::::::::::::::::::::::::::::::::::::: >>>>>>> Am 20.05.20 um 00:32 schrieb Stein Rørvik: >>>>>>>> Yes this approach works, but only when the list metadata is the >>>>>>>> _only_ metadata present. That is, the call setMetadata("Info", >>>>>>>> List.getList()); will erase anything stored in the Info field >>>>>>>> which is not part of your list. With the new functionality, the >>>>>>>> list can be stored in the persistent image properties instead, >>>>>>>> and the existing "Info" metadata can be used for other >>>>>>>> information. So we now have two ways to store metadata instead >>>>>>>> of just one, and the two can be in different formats. >>>>>>>> Stein >>>>>>>> -----Original Message----- >>>>>>>> From: ImageJ Interest Group <[hidden email] >>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> On >>>>>>>> Behalf Of Herbie >>>>>>>> Sent: 19. mai 2020 16:18 >>>>>>>> To: [hidden email] <mailto:[hidden email]> >>>>>>>> <mailto:[hidden email]> >>>>>>>> Subject: Re: A suggestion for additional Image Property >>>>>>>> functions Good day Michael, please allow me to state that this >>>>>>>> was possible already and I used it since years: >>>>>>>> set: >>>>>>>> List.set( "key1", val1 ); >>>>>>>> ... >>>>>>>> List.set( "keyN", valN ); >>>>>>>> setMetadata( "Info", List.getList() ); List.clear; >>>>>>>> get: >>>>>>>> List.setList( getMetadata( "Info" ) ); >>>>>>>> val1 = List.getValue( "key1" ); >>>>>>>> ... >>>>>>>> valN = List.getValue( "keyN" ); >>>>>>>> List.clear(); >>>>>>>> ...or do I miss something special? >>>>>>>> Regards >>>>>>>> Herbie >>>>>>>> ::::::::::::::::::::::::::::::::::::::::::: >>>>>>>> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>>>>>>>> Thanks from me too. >>>>>>>>> >>>>>>>>> Adding simple to use, extensible persistent metadata IMO makes >>>>>>>>> ImageJ1 adds a significant value for image app developers. >>>>>>>>> >>>>>>>>> — Michael Ellis >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email] >>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>> wrote: >>>>>>>>>> >>>>>>>>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik >>>>>>>>>>> <[hidden email] <mailto:[hidden email]> >>>>>>>>>>> <mailto:[hidden email]>> wrote: >>>>>>>>>>> >>>>>>>>>>> Since version 1.53a we now have the very useful ability to >>>>>>>>>>> set persistent image properties: >>>>>>>>>>> >>>>>>>>>>> Property.get(key) >>>>>>>>>>> Property.set(key,value) >>>>>>>>>>> >>>>>>>>>>> These are analogue to the existing List functions: >>>>>>>>>>> >>>>>>>>>>> List.get(key) >>>>>>>>>>> List.set(key, value) >>>>>>>>>>> >>>>>>>>>>> We also have these List functions for reading/writing a >>>>>>>>>>> key/value list as an entity: >>>>>>>>>>> >>>>>>>>>>> List.getList - Returns the list as a string. >>>>>>>>>>> List.setList(list) - Loads the key/value pairs >>>>>>>>>>> in the string list. >>>>>>>>>>> >>>>>>>>>>> What about adding equivalent functions for moving data from >>>>>>>>>>> image properties to a List and vice versa: >>>>>>>>>>> >>>>>>>>>>> Property.getList - Returns the image >>>>>>>>>>> properties as a string. >>>>>>>>>>> Property.setList(list) - Sets the key/value >>>>>>>>>>> pairs in the string list as image properties. >>>>>>>>>> >>>>>>>>>> Good suggestion. Property.getList and Property.setList(list) >>>>>>>>>> are in the latest daily build (1.52b19). >>>>>>>>>> >>>>>>>>>> -wayne >>>>>>>>>> >>>>>>>>>>> Then we can write the current List as image properties, for >>>>>>>>>>> persistent storage with the image: >>>>>>>>>>> >>>>>>>>>>> Property.setList(List.getList) >>>>>>>>>>> >>>>>>>>>>> Or the other way around: >>>>>>>>>>> >>>>>>>>>>> List.setList(Property.getList) >>>>>>>>>>> >>>>>>>>>>> I think this could make custom metadata handling even easier >>>>>>>>>>> than it is today! >>>>>>>>>>> >>>>>>>>>>> Stein >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ImageJ mailing list: >>>>>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F >>>>>>>>>> %2Fimag >>>>>>>>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>>>>>>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0 >>>>>>>>>> 210d8b3 >>>>>>>>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKG >>>>>>>>>> HeHN0XU >>>>>>>>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>>>> >>>>>>>>> Michael Ellis (Managing Director) Digital Scientific UK Ltd. >>>>>>>>> <a href="https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F% >>>>>>>>> 2Fwww.d >>>>>>>>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46 >>>>>>>>> a2e1cb4 >>>>>>>>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1% >>>>>>>>> 7C63725 >>>>>>>>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47K >>>>>>>>> tOeI%3D >>>>>>>>> &reserved=0 >>>>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>>>>>>>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c4 >>>>>>>>> 6a2e1cb >>>>>>>>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1 >>>>>>>>> %7C6372 >>>>>>>>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47 >>>>>>>>> KtOeI%3 >>>>>>>>> D&reserved=0> >>>>>>>>> [hidden email] >>>>>>>>> tel: +44(0)1223 911215 >>>>>>>>> >>>>>>>>> The Commercial Centre >>>>>>>>> 6 Green End >>>>>>>>> Cambridge >>>>>>>>> CB23 7DY >>>>>>>>> >>>>>>>>> === END OF EMAIL === >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> ImageJ mailing list: >>>>>>>>> <a href="https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F% >>>>>>>>> 2Fimage >>>>>>>>> j.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40si >>>>>>>>> ntef.no >>>>>>>>> %7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210 >>>>>>>>> d8b32af >>>>>>>>> %7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN >>>>>>>>> 0XUmrAp >>>>>>>>> eqmCvq1fmJ8Yw%3D&reserved=0 >>>>>>>>> >>>>>>>> -- >>>>>>>> ImageJ mailing list: >>>>>>>> <a href="https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2 >>>>>>>> Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik >>>>>>>> %40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145 >>>>>>>> b0b309e0210d8b32af%7C1%7C1%7C637255679876316263&sdata=vWOL%2 >>>>>>>> FuEsArz%2B55ZtiDDLCWyvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >>>>>>>> -- >>>>>>>> ImageJ mailing list: >>>>>>>> <a href="https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2">https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2 >>>>>>>> Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik >>>>>>>> %40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145 >>>>>>>> b0b309e0210d8b32af%7C1%7C1%7C637255679876316263&sdata=vWOL%2 >>>>>>>> FuEsArz%2B55ZtiDDLCWyvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >>>>>>> >>>>>>> -- >>>>>>> ImageJ mailing list: >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F >>>>>>> imagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%4 >>>>>>> 0sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b >>>>>>> 309e0210d8b32af%7C1%7C1%7C637255679876316263&sdata=vWOL%2FuEs >>>>>>> Arz%2B55ZtiDDLCWyvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >>>>>> Michael Ellis (Managing Director) >>>>>> Digital Scientific UK Ltd. >>>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw >>>>>> ww.dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C74072 >>>>>> 5a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1 >>>>>> %7C1%7C637255679876316263&sdata=iWaW8h8GxUmYivOZ0AWk2rqKVbQ%2F >>>>>> kjggQ1p7js%2Bi4%2F4%3D&reserved=0 >>>>>> [hidden email] <mailto:[hidden email]> >>>>>> tel: +44(0)1223 911215 >>>>>> The Commercial Centre >>>>>> 6 Green End >>>>>> Cambridge >>>>>> CB23 7DY >>>>>> === END OF EMAIL === >>>> Michael Ellis (Managing Director) >>>> Digital Scientific UK Ltd. >>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww >>>> .dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C740725a91 >>>> 27840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7 >>>> C637255679876316263&sdata=iWaW8h8GxUmYivOZ0AWk2rqKVbQ%2FkjggQ1p7 >>>> js%2Bi4%2F4%3D&reserved=0 >>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww >>>> w.dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C740725a9 >>>> 127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1% >>>> 7C637255679876316263&sdata=iWaW8h8GxUmYivOZ0AWk2rqKVbQ%2FkjggQ1p >>>> 7js%2Bi4%2F4%3D&reserved=0> [hidden email] >>>> <mailto:[hidden email]> >>>> tel: +44(0)1223 911215 >>>> The Commercial Centre >>>> 6 Green End >>>> Cambridge >>>> CB23 7DY >>>> === END OF EMAIL === >>>> -- >>>> ImageJ mailing list: >>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fima >>>> gej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sinte >>>> f.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d >>>> 8b32af%7C1%7C1%7C637255679876316263&sdata=vWOL%2FuEsArz%2B55ZtiD >>>> DLCWyvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >>> >>> -- >>> ImageJ mailing list: >>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>> no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b3 >>> 2af%7C1%7C1%7C637255679876316263&sdata=vWOL%2FuEsArz%2B55ZtiDDLCW >>> yvo8Sg4HddsFGWlPusFcs%3D&reserved=0 >> >> Michael Ellis (Managing Director) >> Digital Scientific UK Ltd. >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C740725a912784 >> 0f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >> 5679876326218&sdata=1EaaUPRdlh52Uy1SfWxjj4t%2FO60azStldFyQffkFNpQ% >> 3D&reserved=0 [hidden email] >> <mailto:[hidden email]> >> tel: +44(0)1223 911215 >> >> The Commercial Centre >> 6 Green End >> Cambridge >> CB23 7DY >> >> === END OF EMAIL === >> > > -- > ImageJ mailing list: https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimagej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef.no%7C740725a9127840f40d7308d7fcaa1cbb%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C637255679876326218&sdata=bbnRZe31p0e%2B0F%2BsIHWZrD9AGGQ5WHT1rRnl5b5iHH8%3D&reserved=0 > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: A suggestion for additional Image Property functions
|
|
In reply to this post by Herbie
> On May 20, 2020, at 3:43 AM, Herbie <[hidden email]> wrote:
> > Dear Michael and Stein, > > thanks for the details. > > I hope we shall see a solution where the "key value"-*pairs* are visible in the Info-window. For me it proved useful for "diagnostic" purposes… Upgrade to the latest ImageJ daily build (1.53b22) and the properties will be displayed by the Image>Show Info command. For example, run the Process>FFT>FFT Properties command, check “Complex Fourier Transform” and “Do forward transform”, click “OK”, select the “Complex of…” window, type “i” (Image>Show Info) and you will get a window showing something like: : Complex Fourier Transform Original height: 576 Original width: 720 -------------------------------------------- ImageJ 1.53b22; Java 1.8.0_172 [64-bit]; Mac OS X 10.12.6; 65MB of 3000MB (2%) Title: Complex of boats.gif Width: 1024 pixels Height: 1024 pixels Depth: 2 pixels Size: 8MB <snip> This is the code that saves the properties: imp.setProp(" ", type); imp.setProp("Original width", originalWidth); imp.setProp("Original height", originalHeight); The length of the value is displayed if it is longer than 80 characters, for exampleL clown-image: <256228 characters> Add a "HideInfo" property (e.g. set("HideInfo","true")) to prevent the properties from being displayed by the Image>Show Info command. -wayne > > Herbie > > :::::::::::::::::::::::::::::::::::::::::: > Am 20.05.20 um 00:32 schrieb Stein Rørvik: >> Yes this approach works, but only when the list metadata is the _only_ metadata present. That is, the call setMetadata("Info", List.getList()); will erase anything stored in the Info field which is not part of your list. With the new functionality, the list can be stored in the persistent image properties instead, and the existing "Info" metadata can be used for other information. So we now have two ways to store metadata instead of just one, and the two can be in different formats. >> Stein >> -----Original Message----- >> From: ImageJ Interest Group <[hidden email]> On Behalf Of Herbie >> Sent: 19. mai 2020 16:18 >> To: [hidden email] >> Subject: Re: A suggestion for additional Image Property functions >> Good day Michael, >> please allow me to state that this was possible already and I used it since years: >> set: >> List.set( "key1", val1 ); >> ... >> List.set( "keyN", valN ); >> setMetadata( "Info", List.getList() ); >> List.clear; >> get: >> List.setList( getMetadata( "Info" ) ); >> val1 = List.getValue( "key1" ); >> ... >> valN = List.getValue( "keyN" ); >> List.clear(); >> ...or do I miss something special? >> Regards >> Herbie >> ::::::::::::::::::::::::::::::::::::::::::: >> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>> Thanks from me too. >>> >>> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >>> >>> — Michael Ellis >>> >>> >>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: >>>> >>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >>>>> >>>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>>> >>>>> Property.get(key) >>>>> Property.set(key,value) >>>>> >>>>> These are analogue to the existing List functions: >>>>> >>>>> List.get(key) >>>>> List.set(key, value) >>>>> >>>>> We also have these List functions for reading/writing a key/value list as an entity: >>>>> >>>>> List.getList - Returns the list as a string. >>>>> List.setList(list) - Loads the key/value pairs in the string list. >>>>> >>>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>>> >>>>> Property.getList - Returns the image properties as a string. >>>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>>> >>>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>>> >>>> -wayne >>>> >>>>> Then we can write the current List as image properties, for persistent storage with the image: >>>>> >>>>> Property.setList(List.getList) >>>>> >>>>> Or the other way around: >>>>> >>>>> List.setList(Property.getList) >>>>> >>>>> I think this could make custom metadata handling even easier than it is today! >>>>> >>>>> Stein >>>> >>>> -- >>>> ImageJ mailing list: >>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>> >>> Michael Ellis (Managing Director) >>> Digital Scientific UK Ltd. >>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >>> &reserved=0 >>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >>> D&reserved=0> >>> [hidden email] >>> tel: +44(0)1223 911215 >>> >>> The Commercial Centre >>> 6 Green End >>> Cambridge >>> CB23 7DY >>> >>> === END OF EMAIL === >>> -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Dear Wayne,
perfect, very nice! set("HideInfo","true") appears quite useful as well! Thanks Herbie :::::::::::::::::::: Am 20.05.20 um 17:21 schrieb Wayne Rasband: >> On May 20, 2020, at 3:43 AM, Herbie <[hidden email]> wrote: >> >> Dear Michael and Stein, >> >> thanks for the details. >> >> I hope we shall see a solution where the "key value"-*pairs* are visible in the Info-window. For me it proved useful for "diagnostic" purposes… > > Upgrade to the latest ImageJ daily build (1.53b22) and the properties will be displayed by the Image>Show Info command. For example, run the Process>FFT>FFT Properties command, check “Complex Fourier Transform” and “Do forward transform”, click “OK”, select the “Complex of…” window, type “i” (Image>Show Info) and you will get a window showing something like: > > : Complex Fourier Transform > Original height: 576 > Original width: 720 > -------------------------------------------- > ImageJ 1.53b22; Java 1.8.0_172 [64-bit]; Mac OS X 10.12.6; 65MB of 3000MB (2%) > > Title: Complex of boats.gif > Width: 1024 pixels > Height: 1024 pixels > Depth: 2 pixels > Size: 8MB > <snip> > > This is the code that saves the properties: > > imp.setProp(" ", type); > imp.setProp("Original width", originalWidth); > imp.setProp("Original height", originalHeight); > > The length of the value is displayed if it is longer than 80 characters, for exampleL > > clown-image: <256228 characters> > > Add a "HideInfo" property (e.g. set("HideInfo","true")) to prevent the properties from being displayed by the Image>Show Info command. > > -wayne > > >> >> Herbie >> >> :::::::::::::::::::::::::::::::::::::::::: >> Am 20.05.20 um 00:32 schrieb Stein Rørvik: >>> Yes this approach works, but only when the list metadata is the _only_ metadata present. That is, the call setMetadata("Info", List.getList()); will erase anything stored in the Info field which is not part of your list. With the new functionality, the list can be stored in the persistent image properties instead, and the existing "Info" metadata can be used for other information. So we now have two ways to store metadata instead of just one, and the two can be in different formats. >>> Stein >>> -----Original Message----- >>> From: ImageJ Interest Group <[hidden email]> On Behalf Of Herbie >>> Sent: 19. mai 2020 16:18 >>> To: [hidden email] >>> Subject: Re: A suggestion for additional Image Property functions >>> Good day Michael, >>> please allow me to state that this was possible already and I used it since years: >>> set: >>> List.set( "key1", val1 ); >>> ... >>> List.set( "keyN", valN ); >>> setMetadata( "Info", List.getList() ); >>> List.clear; >>> get: >>> List.setList( getMetadata( "Info" ) ); >>> val1 = List.getValue( "key1" ); >>> ... >>> valN = List.getValue( "keyN" ); >>> List.clear(); >>> ...or do I miss something special? >>> Regards >>> Herbie >>> ::::::::::::::::::::::::::::::::::::::::::: >>> Am 19.05.20 um 06:24 schrieb Michael Ellis: >>>> Thanks from me too. >>>> >>>> Adding simple to use, extensible persistent metadata IMO makes ImageJ1 adds a significant value for image app developers. >>>> >>>> — Michael Ellis >>>> >>>> >>>>> On 18 May 2020, at 17:54, Wayne Rasband <[hidden email]> wrote: >>>>> >>>>>> On May 18, 2020, at 10:27 AM, Stein Rørvik <[hidden email]> wrote: >>>>>> >>>>>> Since version 1.53a we now have the very useful ability to set persistent image properties: >>>>>> >>>>>> Property.get(key) >>>>>> Property.set(key,value) >>>>>> >>>>>> These are analogue to the existing List functions: >>>>>> >>>>>> List.get(key) >>>>>> List.set(key, value) >>>>>> >>>>>> We also have these List functions for reading/writing a key/value list as an entity: >>>>>> >>>>>> List.getList - Returns the list as a string. >>>>>> List.setList(list) - Loads the key/value pairs in the string list. >>>>>> >>>>>> What about adding equivalent functions for moving data from image properties to a List and vice versa: >>>>>> >>>>>> Property.getList - Returns the image properties as a string. >>>>>> Property.setList(list) - Sets the key/value pairs in the string list as image properties. >>>>> >>>>> Good suggestion. Property.getList and Property.setList(list) are in the latest daily build (1.52b19). >>>>> >>>>> -wayne >>>>> >>>>>> Then we can write the current List as image properties, for persistent storage with the image: >>>>>> >>>>>> Property.setList(List.getList) >>>>>> >>>>>> Or the other way around: >>>>>> >>>>>> List.setList(Property.getList) >>>>>> >>>>>> I think this could make custom metadata handling even easier than it is today! >>>>>> >>>>>> Stein >>>>> >>>>> -- >>>>> ImageJ mailing list: >>>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fimag >>>>> ej.nih.gov%2Fij%2Flist.html&data=02%7C01%7Cstein.rorvik%40sintef. >>>>> no%7C569c46a2e1cb45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b3 >>>>> 2af%7C1%7C1%7C637254947785575505&sdata=7cmWfdQkZqd06g04YKGHeHN0XU >>>>> mrApeqmCvq1fmJ8Yw%3D&reserved=0 >>>> >>>> Michael Ellis (Managing Director) >>>> Digital Scientific UK Ltd. >>>> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.d >>>> suk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb4 >>>> 5e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C63725 >>>> 4947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3D >>>> &reserved=0 >>>> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >>>> dsuk.biz%2F&data=02%7C01%7Cstein.rorvik%40sintef.no%7C569c46a2e1cb >>>> 45e85a3408d7fbffa8a8%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C1%7C6372 >>>> 54947785575505&sdata=Zw3uWpVr0hv3iAncd1hc1UbhLXbWw0lOFayo47KtOeI%3 >>>> D&reserved=0> >>>> [hidden email] >>>> tel: +44(0)1223 911215 >>>> >>>> The Commercial Centre >>>> 6 Green End >>>> Cambridge >>>> CB23 7DY >>>> >>>> === END OF EMAIL === >>>> > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |