I see from the changelog that some changes have been done to Image Sequence to allow drag-and-drop.
These changes has caused the use of Image Sequence in macros to be severely broken since 1.53d. See the below demo macro to reproduce the problem. I am trying this with daily build 1.53e with Java 8 on Windows 10/64 but the problem is also present in 1.53d. It seems that the problem is simply that the previously available options were removed from the new dialog. But instead of warning the user that the functionality was removed, it is just silently ignored, giving the wrong results. So, can the previously available options be migrated to the new dialog? Or can the new dialog be renamed to something else, restoring the old one, so that existing macros will work? My workflow completely depends on the ability to open virtual stacks with specified slice spacing as I work with very large stacks (16GB to 64GB) so always needing to open all slices in memory is not an alternative, especially not over a slow network or when working on a computer with less than 128GB of RAM. Stein ----------------------- dir = "C:/Users/steinr/Temp/"; path1 = dir + "t1-head/"; path2 = dir + "t1-rendering/"; File.makeDirectory(path1); File.makeDirectory(path2); run("Close All"); //create two example dirs with image sequences run("T1 Head (16-bits)"); run("Image Sequence... ", "format=TIFF save="+dir+"t1-head/"); run("T1 Head Renderings"); run("Image Sequence... ", "format=TIFF save="+dir+"t1-rendering/"); //load generated folders as image stacks using some of the available options //open 25 slices at 50% size: run("Image Sequence...", "open=&path1 starting=5 increment=5 scale=50 sort"); //1.53c and before: options works as expected //1.53d and after: options are silently ignored giving the wrong results //open 12 slices virtual: run("Image Sequence...", "open=&path2 increment=3 sort use"); //1.53c and before: options works as expected //1.53d and after: options are silently ignored giving the wrong results //re-open path1 run("Image Sequence...", "open=&path1 file=.tif sort use"); //1.53c and before: path1 (t1-head) was opened as requested //1.53d and after: path2 (t1-rendering) was silently opened instead of path1; I don't understand why //trying a wrong path path3 = "X:/some/non/existant/path/"; run("Image Sequence...", "open=&path3 file=.tif sort use"); //1.53c and before: macro exits with an error message //1.53d and after: t1-rendering was silently opened instead of giving an error message run("Tile"); -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
> On Sep 12, 2020, at 5:38 AM, Stein Rørvik <[hidden email]> wrote:
> > I see from the changelog that some changes have been done to Image Sequence to allow drag-and-drop. > These changes has caused the use of Image Sequence in macros to be severely broken since 1.53d. This regression is fixed in ImageJ 1.53e, now available via the Help>Update ImageJ command. -wayne > > See the below demo macro to reproduce the problem. > I am trying this with daily build 1.53e with Java 8 on Windows 10/64 but the problem is also present in 1.53d. > > It seems that the problem is simply that the previously available options were removed from the new dialog. > But instead of warning the user that the functionality was removed, it is just silently ignored, giving the wrong results. > > So, can the previously available options be migrated to the new dialog? > Or can the new dialog be renamed to something else, restoring the old one, so that existing macros will work? > > My workflow completely depends on the ability to open virtual stacks with specified slice spacing as I work with very large stacks (16GB to 64GB) so always needing to open all slices in memory is not an alternative, especially not over a slow network or when working on a computer with less than 128GB of RAM. > > Stein > ----------------------- > > dir = "C:/Users/steinr/Temp/"; > path1 = dir + "t1-head/"; > path2 = dir + "t1-rendering/"; > File.makeDirectory(path1); > File.makeDirectory(path2); > run("Close All"); > > //create two example dirs with image sequences > run("T1 Head (16-bits)"); > run("Image Sequence... ", "format=TIFF save="+dir+"t1-head/"); > run("T1 Head Renderings"); > run("Image Sequence... ", "format=TIFF save="+dir+"t1-rendering/"); > > //load generated folders as image stacks using some of the available options > > //open 25 slices at 50% size: > run("Image Sequence...", "open=&path1 starting=5 increment=5 scale=50 sort"); > //1.53c and before: options works as expected > //1.53d and after: options are silently ignored giving the wrong results > > //open 12 slices virtual: > run("Image Sequence...", "open=&path2 increment=3 sort use"); > //1.53c and before: options works as expected > //1.53d and after: options are silently ignored giving the wrong results > > //re-open path1 > run("Image Sequence...", "open=&path1 file=.tif sort use"); > //1.53c and before: path1 (t1-head) was opened as requested > //1.53d and after: path2 (t1-rendering) was silently opened instead of path1; I don't understand why > > //trying a wrong path > path3 = "X:/some/non/existant/path/"; > run("Image Sequence...", "open=&path3 file=.tif sort use"); > //1.53c and before: macro exits with an error message > //1.53d and after: t1-rendering was silently opened instead of giving an error message > > run("Tile"); -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
> On Sep 13, 2020, at 6:26 AM, Stein Rørvik <[hidden email]> wrote:
> > Thanks for the quick fix, it seems to work fine now. > > I see that the "number" option is now supported from macro, but there is no field for it in the dialog. > I assume that this is because the new dialog does not "pre-scan" the image folder as the previous version did; > however it would perhaps still make sense to include it, perhaps as a blank field or with a default value "all" to give the user information about the possibility to open a specified number of images. The 1.53e23 daily build adds a “Count” field with a default value of “—“. > I also have another issue with Image Sequence which is not a bug, but a suggestion for an improvement: > > My image sequence folders (output from a micro-CT) usually include a zip file with metadata (a group of text files) at the start of the folder, like this: > > metadata.zip > myimage01.tif > myimage02.tif > myimage03.tif > ... > > If I specify ".tif" as a file pattern it works as expected. > > If I do not do that, I get an error message dialog that "this Zip archive does not contain a TIF.." > which is logical as it tries to open the first file as an image. The problem is that this halts the macro, and does not provide the filename of the file that failed to open. With the 1.53e23 daily build, the error message is written to the Log window and it includes the file path. -wayne > What about instead of providing this halting error message dialog, just silently continue and instead write the warning along with the failing filename in the log window? That will give the user a better option to investigate the file that was not included. When launching Image Sequence from the GUI, this is what happens; the error message is shown in the Log window instead of a dialog, but the filename is still not shown. > > Stein > > -----Original Message----- > From: ImageJ Interest Group <[hidden email]> On Behalf Of Wayne Rasband > Sent: 13. september 2020 02:10 > To: [hidden email] > Subject: Re: Use of Image Sequence in macros is broken since 1.53d > >> On Sep 12, 2020, at 5:38 AM, Stein Rørvik <[hidden email]> wrote: >> >> I see from the changelog that some changes have been done to Image Sequence to allow drag-and-drop. >> These changes has caused the use of Image Sequence in macros to be severely broken since 1.53d. > > This regression is fixed in ImageJ 1.53e, now available via the Help>Update ImageJ command. > > -wayne > >> >> See the below demo macro to reproduce the problem. >> I am trying this with daily build 1.53e with Java 8 on Windows 10/64 but the problem is also present in 1.53d. >> >> It seems that the problem is simply that the previously available options were removed from the new dialog. >> But instead of warning the user that the functionality was removed, it is just silently ignored, giving the wrong results. >> >> So, can the previously available options be migrated to the new dialog? >> Or can the new dialog be renamed to something else, restoring the old one, so that existing macros will work? >> >> My workflow completely depends on the ability to open virtual stacks with specified slice spacing as I work with very large stacks (16GB to 64GB) so always needing to open all slices in memory is not an alternative, especially not over a slow network or when working on a computer with less than 128GB of RAM. >> >> Stein >> ----------------------- >> >> dir = "C:/Users/steinr/Temp/"; >> path1 = dir + "t1-head/"; >> path2 = dir + "t1-rendering/"; >> File.makeDirectory(path1); >> File.makeDirectory(path2); >> run("Close All"); >> >> //create two example dirs with image sequences >> run("T1 Head (16-bits)"); >> run("Image Sequence... ", "format=TIFF save="+dir+"t1-head/"); >> run("T1 Head Renderings"); >> run("Image Sequence... ", "format=TIFF save="+dir+"t1-rendering/"); >> >> //load generated folders as image stacks using some of the available >> options >> >> //open 25 slices at 50% size: >> run("Image Sequence...", "open=&path1 starting=5 increment=5 scale=50 >> sort"); //1.53c and before: options works as expected //1.53d and >> after: options are silently ignored giving the wrong results >> >> //open 12 slices virtual: >> run("Image Sequence...", "open=&path2 increment=3 sort use"); //1.53c >> and before: options works as expected //1.53d and after: options are >> silently ignored giving the wrong results >> >> //re-open path1 >> run("Image Sequence...", "open=&path1 file=.tif sort use"); //1.53c >> and before: path1 (t1-head) was opened as requested //1.53d and after: >> path2 (t1-rendering) was silently opened instead of path1; I don't >> understand why >> >> //trying a wrong path >> path3 = "X:/some/non/existant/path/"; >> run("Image Sequence...", "open=&path3 file=.tif sort use"); //1.53c >> and before: macro exits with an error message //1.53d and after: >> t1-rendering was silently opened instead of giving an error message >> >> run("Tile"); -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Thank you for adding the count field, it works as advertised.
I think "count" is a better word than "number" here. I see both works from a macro. Perhaps you can spell out "Inc" as "Increment" in the dialog as well, there is space for it. A related suggestion: Now that the new Import Sequence dialog works well, what about replacing the dialog that appears today when drag-and-dropping a folder onto the ImageJ window with the new Import Sequence dialog? For this to work, there must be an additional checkbox "Open as separate windows" or similar to enable opening the images as separate windows instead of stack. That is what happens today if you say "No" to the "Import as stack" question you get when drag-and-dropping a folder on ImageJ. The advantage with the Import Sequence dialog is that it gives more control, and it is more clear what will happen when you press OK. Stein -----Original Message----- From: ImageJ Interest Group <[hidden email]> On Behalf Of Wayne Rasband Sent: 14. september 2020 16:03 To: [hidden email] Subject: Re: Use of Image Sequence in macros is broken since 1.53d > On Sep 13, 2020, at 6:26 AM, Stein Rørvik <[hidden email]> wrote: > > Thanks for the quick fix, it seems to work fine now. > > I see that the "number" option is now supported from macro, but there is no field for it in the dialog. > I assume that this is because the new dialog does not "pre-scan" the > image folder as the previous version did; however it would perhaps still make sense to include it, perhaps as a blank field or with a default value "all" to give the user information about the possibility to open a specified number of images. The 1.53e23 daily build adds a “Count” field with a default value of “—“. > I also have another issue with Image Sequence which is not a bug, but a suggestion for an improvement: > > My image sequence folders (output from a micro-CT) usually include a zip file with metadata (a group of text files) at the start of the folder, like this: > > metadata.zip > myimage01.tif > myimage02.tif > myimage03.tif > ... > > If I specify ".tif" as a file pattern it works as expected. > > If I do not do that, I get an error message dialog that "this Zip archive does not contain a TIF.." > which is logical as it tries to open the first file as an image. The problem is that this halts the macro, and does not provide the filename of the file that failed to open. With the 1.53e23 daily build, the error message is written to the Log window and it includes the file path. -wayne > What about instead of providing this halting error message dialog, just silently continue and instead write the warning along with the failing filename in the log window? That will give the user a better option to investigate the file that was not included. When launching Image Sequence from the GUI, this is what happens; the error message is shown in the Log window instead of a dialog, but the filename is still not shown. > > Stein > > -----Original Message----- > From: ImageJ Interest Group <[hidden email]> On Behalf Of Wayne > Rasband > Sent: 13. september 2020 02:10 > To: [hidden email] > Subject: Re: Use of Image Sequence in macros is broken since 1.53d > >> On Sep 12, 2020, at 5:38 AM, Stein Rørvik <[hidden email]> wrote: >> >> I see from the changelog that some changes have been done to Image Sequence to allow drag-and-drop. >> These changes has caused the use of Image Sequence in macros to be severely broken since 1.53d. > > This regression is fixed in ImageJ 1.53e, now available via the Help>Update ImageJ command. > > -wayne > >> >> See the below demo macro to reproduce the problem. >> I am trying this with daily build 1.53e with Java 8 on Windows 10/64 but the problem is also present in 1.53d. >> >> It seems that the problem is simply that the previously available options were removed from the new dialog. >> But instead of warning the user that the functionality was removed, it is just silently ignored, giving the wrong results. >> >> So, can the previously available options be migrated to the new dialog? >> Or can the new dialog be renamed to something else, restoring the old one, so that existing macros will work? >> >> My workflow completely depends on the ability to open virtual stacks with specified slice spacing as I work with very large stacks (16GB to 64GB) so always needing to open all slices in memory is not an alternative, especially not over a slow network or when working on a computer with less than 128GB of RAM. >> >> Stein >> ----------------------- >> >> dir = "C:/Users/steinr/Temp/"; >> path1 = dir + "t1-head/"; >> path2 = dir + "t1-rendering/"; >> File.makeDirectory(path1); >> File.makeDirectory(path2); >> run("Close All"); >> >> //create two example dirs with image sequences >> run("T1 Head (16-bits)"); >> run("Image Sequence... ", "format=TIFF save="+dir+"t1-head/"); >> run("T1 Head Renderings"); >> run("Image Sequence... ", "format=TIFF save="+dir+"t1-rendering/"); >> >> //load generated folders as image stacks using some of the available >> options >> >> //open 25 slices at 50% size: >> run("Image Sequence...", "open=&path1 starting=5 increment=5 scale=50 >> sort"); //1.53c and before: options works as expected //1.53d and >> after: options are silently ignored giving the wrong results >> >> //open 12 slices virtual: >> run("Image Sequence...", "open=&path2 increment=3 sort use"); //1.53c >> and before: options works as expected //1.53d and after: options are >> silently ignored giving the wrong results >> >> //re-open path1 >> run("Image Sequence...", "open=&path1 file=.tif sort use"); //1.53c >> and before: path1 (t1-head) was opened as requested //1.53d and after: >> path2 (t1-rendering) was silently opened instead of path1; I don't >> understand why >> >> //trying a wrong path >> path3 = "X:/some/non/existant/path/"; run("Image Sequence...", >> "open=&path3 file=.tif sort use"); //1.53c and before: macro exits >> with an error message //1.53d and after: >> t1-rendering was silently opened instead of giving an error message >> >> run("Tile"); -- 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%7Cbe6ddd34e1794356b96e08d858b73347%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637356891157206872&sdata=X4U%2BMPwd8LGYe7TJHa58qVBuiBU%2B64z7vLpGxHJR1i8%3D&reserved=0 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
> On Sep 17, 2020, at 4:51 PM, Stein Rørvik <[hidden email]> wrote:
> > Thank you for adding the count field, it works as advertised. > I think "count" is a better word than "number" here. I see both works from a macro. > > Perhaps you can spell out "Inc" as "Increment" in the dialog as well, there is space for it. > > A related suggestion: > > Now that the new Import Sequence dialog works well, what about replacing the dialog that appears today when drag-and-dropping a folder onto the ImageJ window with the new Import Sequence dialog? With the 1.53f2 daily build, the Import>Image Sequence dialog is used when drag-and-dropping a folder onto the ImageJ window and “Inc:” in the dialog is replaced with “Step:”. -wayne > For this to work, there must be an additional checkbox "Open as separate windows" or similar to enable opening the images as separate windows instead of stack. That is what happens today if you say "No" to the "Import as stack" question you get when drag-and-dropping a folder on ImageJ. The advantage with the Import Sequence dialog is that it gives more control, and it is more clear what will happen when you press OK. > > Stein > > -----Original Message----- > From: ImageJ Interest Group <[hidden email]> On Behalf Of Wayne Rasband > Sent: 14. september 2020 16:03 > To: [hidden email] > Subject: Re: Use of Image Sequence in macros is broken since 1.53d > >> On Sep 13, 2020, at 6:26 AM, Stein Rørvik <[hidden email]> wrote: >> >> Thanks for the quick fix, it seems to work fine now. >> >> I see that the "number" option is now supported from macro, but there is no field for it in the dialog. >> I assume that this is because the new dialog does not "pre-scan" the >> image folder as the previous version did; however it would perhaps still make sense to include it, perhaps as a blank field or with a default value "all" to give the user information about the possibility to open a specified number of images. > > The 1.53e23 daily build adds a “Count” field with a default value of “—“. > >> I also have another issue with Image Sequence which is not a bug, but a suggestion for an improvement: >> >> My image sequence folders (output from a micro-CT) usually include a zip file with metadata (a group of text files) at the start of the folder, like this: >> >> metadata.zip >> myimage01.tif >> myimage02.tif >> myimage03.tif >> ... >> >> If I specify ".tif" as a file pattern it works as expected. >> >> If I do not do that, I get an error message dialog that "this Zip archive does not contain a TIF.." >> which is logical as it tries to open the first file as an image. The problem is that this halts the macro, and does not provide the filename of the file that failed to open. > > With the 1.53e23 daily build, the error message is written to the Log window and it includes the file path. > > -wayne > > >> What about instead of providing this halting error message dialog, just silently continue and instead write the warning along with the failing filename in the log window? That will give the user a better option to investigate the file that was not included. When launching Image Sequence from the GUI, this is what happens; the error message is shown in the Log window instead of a dialog, but the filename is still not shown. >> >> Stein >> >> -----Original Message----- >> From: ImageJ Interest Group <[hidden email]> On Behalf Of Wayne >> Rasband >> Sent: 13. september 2020 02:10 >> To: [hidden email] >> Subject: Re: Use of Image Sequence in macros is broken since 1.53d >> >>> On Sep 12, 2020, at 5:38 AM, Stein Rørvik <[hidden email]> wrote: >>> >>> I see from the changelog that some changes have been done to Image Sequence to allow drag-and-drop. >>> These changes has caused the use of Image Sequence in macros to be severely broken since 1.53d. >> >> This regression is fixed in ImageJ 1.53e, now available via the Help>Update ImageJ command. >> >> -wayne >> >>> >>> See the below demo macro to reproduce the problem. >>> I am trying this with daily build 1.53e with Java 8 on Windows 10/64 but the problem is also present in 1.53d. >>> >>> It seems that the problem is simply that the previously available options were removed from the new dialog. >>> But instead of warning the user that the functionality was removed, it is just silently ignored, giving the wrong results. >>> >>> So, can the previously available options be migrated to the new dialog? >>> Or can the new dialog be renamed to something else, restoring the old one, so that existing macros will work? >>> >>> My workflow completely depends on the ability to open virtual stacks with specified slice spacing as I work with very large stacks (16GB to 64GB) so always needing to open all slices in memory is not an alternative, especially not over a slow network or when working on a computer with less than 128GB of RAM. >>> >>> Stein >>> ----------------------- >>> >>> dir = "C:/Users/steinr/Temp/"; >>> path1 = dir + "t1-head/"; >>> path2 = dir + "t1-rendering/"; >>> File.makeDirectory(path1); >>> File.makeDirectory(path2); >>> run("Close All"); >>> >>> //create two example dirs with image sequences >>> run("T1 Head (16-bits)"); >>> run("Image Sequence... ", "format=TIFF save="+dir+"t1-head/"); >>> run("T1 Head Renderings"); >>> run("Image Sequence... ", "format=TIFF save="+dir+"t1-rendering/"); >>> >>> //load generated folders as image stacks using some of the available >>> options >>> >>> //open 25 slices at 50% size: >>> run("Image Sequence...", "open=&path1 starting=5 increment=5 scale=50 >>> sort"); //1.53c and before: options works as expected //1.53d and >>> after: options are silently ignored giving the wrong results >>> >>> //open 12 slices virtual: >>> run("Image Sequence...", "open=&path2 increment=3 sort use"); //1.53c >>> and before: options works as expected //1.53d and after: options are >>> silently ignored giving the wrong results >>> >>> //re-open path1 >>> run("Image Sequence...", "open=&path1 file=.tif sort use"); //1.53c >>> and before: path1 (t1-head) was opened as requested //1.53d and after: >>> path2 (t1-rendering) was silently opened instead of path1; I don't >>> understand why >>> >>> //trying a wrong path >>> path3 = "X:/some/non/existant/path/"; run("Image Sequence...", >>> "open=&path3 file=.tif sort use"); //1.53c and before: macro exits >>> with an error message //1.53d and after: >>> t1-rendering was silently opened instead of giving an error message >>> >>> run("Tile"); -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Thanks,
this works great! Step is a better word than inc or increment. I see the "Open as separate images" choice appear when drag and dropping, but not when doing "Import → Image Sequence". I think the separate images choice should be there in the latter case too, as it will enable us to open a group of images separately via a macro. Today I often open a group of images matching a pattern in a folder, and do that by importing them as a stack with the file filter and then doing "Stack to Images". Having the checkbox available there too will make this easier. Stein -----Original Message----- From: ImageJ Interest Group <[hidden email]> On Behalf Of Wayne Rasband Sent: 18. september 2020 16:16 To: [hidden email] Subject: Re: Use of Image Sequence in macros is broken since 1.53d > On Sep 17, 2020, at 4:51 PM, Stein Rørvik <[hidden email]> wrote: > > Thank you for adding the count field, it works as advertised. > I think "count" is a better word than "number" here. I see both works from a macro. > > Perhaps you can spell out "Inc" as "Increment" in the dialog as well, there is space for it. > > A related suggestion: > > Now that the new Import Sequence dialog works well, what about replacing the dialog that appears today when drag-and-dropping a folder onto the ImageJ window with the new Import Sequence dialog? With the 1.53f2 daily build, the Import>Image Sequence dialog is used when drag-and-dropping a folder onto the ImageJ window and “Inc:” in the dialog is replaced with “Step:”. -wayne > For this to work, there must be an additional checkbox "Open as separate windows" or similar to enable opening the images as separate windows instead of stack. That is what happens today if you say "No" to the "Import as stack" question you get when drag-and-dropping a folder on ImageJ. The advantage with the Import Sequence dialog is that it gives more control, and it is more clear what will happen when you press OK. > > Stein > > -----Original Message----- > From: ImageJ Interest Group <[hidden email]> On Behalf Of Wayne > Rasband > Sent: 14. september 2020 16:03 > To: [hidden email] > Subject: Re: Use of Image Sequence in macros is broken since 1.53d > >> On Sep 13, 2020, at 6:26 AM, Stein Rørvik <[hidden email]> wrote: >> >> Thanks for the quick fix, it seems to work fine now. >> >> I see that the "number" option is now supported from macro, but there is no field for it in the dialog. >> I assume that this is because the new dialog does not "pre-scan" the >> image folder as the previous version did; however it would perhaps still make sense to include it, perhaps as a blank field or with a default value "all" to give the user information about the possibility to open a specified number of images. > > The 1.53e23 daily build adds a “Count” field with a default value of “—“. > >> I also have another issue with Image Sequence which is not a bug, but a suggestion for an improvement: >> >> My image sequence folders (output from a micro-CT) usually include a zip file with metadata (a group of text files) at the start of the folder, like this: >> >> metadata.zip >> myimage01.tif >> myimage02.tif >> myimage03.tif >> ... >> >> If I specify ".tif" as a file pattern it works as expected. >> >> If I do not do that, I get an error message dialog that "this Zip archive does not contain a TIF.." >> which is logical as it tries to open the first file as an image. The problem is that this halts the macro, and does not provide the filename of the file that failed to open. > > With the 1.53e23 daily build, the error message is written to the Log window and it includes the file path. > > -wayne > > >> What about instead of providing this halting error message dialog, just silently continue and instead write the warning along with the failing filename in the log window? That will give the user a better option to investigate the file that was not included. When launching Image Sequence from the GUI, this is what happens; the error message is shown in the Log window instead of a dialog, but the filename is still not shown. >> >> Stein >> >> -----Original Message----- >> From: ImageJ Interest Group <[hidden email]> On Behalf Of Wayne >> Rasband >> Sent: 13. september 2020 02:10 >> To: [hidden email] >> Subject: Re: Use of Image Sequence in macros is broken since 1.53d >> >>> On Sep 12, 2020, at 5:38 AM, Stein Rørvik <[hidden email]> wrote: >>> >>> I see from the changelog that some changes have been done to Image Sequence to allow drag-and-drop. >>> These changes has caused the use of Image Sequence in macros to be severely broken since 1.53d. >> >> This regression is fixed in ImageJ 1.53e, now available via the Help>Update ImageJ command. >> >> -wayne >> >>> >>> See the below demo macro to reproduce the problem. >>> I am trying this with daily build 1.53e with Java 8 on Windows 10/64 but the problem is also present in 1.53d. >>> >>> It seems that the problem is simply that the previously available options were removed from the new dialog. >>> But instead of warning the user that the functionality was removed, it is just silently ignored, giving the wrong results. >>> >>> So, can the previously available options be migrated to the new dialog? >>> Or can the new dialog be renamed to something else, restoring the old one, so that existing macros will work? >>> >>> My workflow completely depends on the ability to open virtual stacks with specified slice spacing as I work with very large stacks (16GB to 64GB) so always needing to open all slices in memory is not an alternative, especially not over a slow network or when working on a computer with less than 128GB of RAM. >>> >>> Stein >>> ----------------------- >>> >>> dir = "C:/Users/steinr/Temp/"; >>> path1 = dir + "t1-head/"; >>> path2 = dir + "t1-rendering/"; >>> File.makeDirectory(path1); >>> File.makeDirectory(path2); >>> run("Close All"); >>> >>> //create two example dirs with image sequences >>> run("T1 Head (16-bits)"); >>> run("Image Sequence... ", "format=TIFF save="+dir+"t1-head/"); >>> run("T1 Head Renderings"); >>> run("Image Sequence... ", "format=TIFF save="+dir+"t1-rendering/"); >>> >>> //load generated folders as image stacks using some of the available >>> options >>> >>> //open 25 slices at 50% size: >>> run("Image Sequence...", "open=&path1 starting=5 increment=5 >>> scale=50 sort"); //1.53c and before: options works as expected >>> //1.53d and >>> after: options are silently ignored giving the wrong results >>> >>> //open 12 slices virtual: >>> run("Image Sequence...", "open=&path2 increment=3 sort use"); >>> //1.53c and before: options works as expected //1.53d and after: >>> options are silently ignored giving the wrong results >>> >>> //re-open path1 >>> run("Image Sequence...", "open=&path1 file=.tif sort use"); //1.53c >>> and before: path1 (t1-head) was opened as requested //1.53d and after: >>> path2 (t1-rendering) was silently opened instead of path1; I don't >>> understand why >>> >>> //trying a wrong path >>> path3 = "X:/some/non/existant/path/"; run("Image Sequence...", >>> "open=&path3 file=.tif sort use"); //1.53c and before: macro exits >>> with an error message //1.53d and after: >>> t1-rendering was silently opened instead of giving an error message >>> >>> run("Tile"); -- 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%7Ce6d59cfb4a5b46b9648208d85bdedc4a%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637360360024688963&sdata=nACqaG8aPGM8ccPENcze8EuhYe4jk%2BtIrEwhqT3s8Go%3D&reserved=0 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Free forum by Nabble | Edit this page |