![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F14195746%2F943d184b6e2535659dd997057d0612ef%2Ffrag1-example-markup.png?generation=1680724353192735&alt=media\")
EDIT: I edited the question because it renumbers questions to start again from 1 for each series of questions, so I am prepending alphabetic characters…
\nThe question is about the actual Vesuvius half-scroll:
\nA: 1-5
\nThe \"air\" part (in the video the fragment stack actually looks like
\nB: 1
\nThe \"air\" part seems to have structure or ringing artifacts
\nC: 1-4
\nAre these the intrinsic result of X-ray imaging?
Or are these the result of scattering or diffraction processes?
Is my assumption correct or incorrect that for the ink-detection challenge no virtual meshing and virtual flattening was applied?
Assuming no virtual meshing and flattening (with unknown Jacobians) was used to produce the training TIFF's, may we assume the test dataset followed the same process without meshing and flattening?
Consider a hypothetical halfspace of a more radiotranslucent material succeeded by a more radio-opaque material. Depending on the shift of a virtual voxel grid normal to the interface (shifting the voxel grid into or out of the phase boundary), voxels that remain completely within the same material will report similar radiodensity values, but the voxel on the boundary will interpolate. No material with the interpolated radiodensity value is present of course… Given this issue the most obvious thing to do would be to add X-ray energy \"color\" channels, so that material compositions would correspond to regions in a higher dimensional space such that interpolated values (on a path between such regions) are significantly less likely to cross so disambiguation becomes much more tractable.
\nD: 1
\n\n\nHow many X-rays were taken, at what step angle? I am assuming 360 as usual.
\n
[0, 360] (end inclusive) with a step angle of 0.1 for 3601 projections per offset position. Number of offset positions depends on the sample. For example, Scroll 1 had 2 horizontal and 21 vertical offset positions. Some of these vertical offsets are redundant (this will be explained in the paper), but the raw dataset is 3601 * 2 * 21 = 151242 projection images for one scroll.
\n\n\nWhat was the pixel resolution of the original X-ray images?
\n
7.91um for the scrolls, 3.24um for the fragments. Due to beam divergence these could be larger by up to 4%, but given where the samples were scanned in the beam, they're likely very close to the nominal pixel size. Note that these were scanned in parallel beam, so the reconstructed pixel size is approximately equal to the detector pixel size.
\n\n\nWhats the digital bit depth on the original X-ray images?
\n
16-bits of effective depth, stored in 32-bit floats by the acquisition system.
\n\n\nHow large would this dataset be in GB?
\n
Depends on the dataset. The Scroll 1 raw data mentioned above is about 1.9TBs. This says nothing of the reconstructed data.
\n\n\nAt what X-ray energy was this acquired?
\n
54keV for everything. Additionally 88keV for the fragments. We are working to get these released as well and you'll find that this is referenced in the paper.
\n\n\nThe \"air\" part (in the video the fragment stack actually looks like
\nglass/plastic
\n
\n fragment and then
\n paper
Here's a marked up slice from Fragment 1:
\n
If you're looking at the slice stack here on Kaggle, note that these are surface volumes and not the original reconstructions. The tissue paper and acrylic frame and not represented in the Kaggle data.
\n\n\nWas the text/ink side of the fragment facing the glass panel or the paper?
\n
No. The ink side of the fragment is faced away from the tissue paper and acrylic frame. In the marked up image above, it would be on the \"top\" edge of the fragment, where the green line is pointing.
\n\n\nThe \"air\" part seems to have structure or ringing artifacts
\n
These are fairly common artifacts in CT scan reconstructions, particularly those reconstructed using filtered backprojection.
\n\n\nAre these the intrinsic result of X-ray imaging?
\n
\n Or are these the result of scattering or diffraction processes?
These datasets are derived from x-ray attenuation data, i.e. \"normal\" x-ray images.
\n\n\nIs my assumption correct or incorrect that for the ink-detection challenge no virtual meshing and virtual flattening was applied?
\n
That is incorrect. Segmentation, meshing, and flattening were used to align the photograph-derived ink labels onto the 3D surface of the fragment AND to generate the optimized surface volumes provided on Kaggle. The original reconstructed volumes are available here if you would like to attempt ink detection without those steps. I would personally be very interested in how you frame the problem without some form of virtual unwrapping.
\n\n\nAssuming no virtual meshing and flattening (with unknown Jacobians) was used to produce the training TIFF's, may we assume the test dataset followed the same process without meshing and flattening?
\n
Though virtual unwrapping was used, it is worth clarifying that all fragment datasets used in the Kaggle competition were prepared in the same way. That includes the private dataset that we use for validating results.
\n\n\n…Given this issue the most obvious thing to do would be to add X-ray energy \"color\" channels, so that material compositions would correspond to regions in a higher dimensional space such that interpolated values (on a path between such regions) are significantly less likely to cross so disambiguation becomes much more tractable.
\nApart from dataset size, is there a reason the scrolls aren't scanned at different X-ray energies?
\n
That is correct in principle. Multi-energy acquisition could theoretically improve contrast between the ink and papyrus. In practice, this is much harder than it sounds. A few things to consider for the scans themselves are:
\nYou also need to consider logistics:
\nAnyway, we've thought a lot about multi-energy scanning, and we try to make it happen when we can, but it's just hard to get good data given all of the constraints.
", "rawMarkdown": "> How many X-rays were taken, at what step angle? I am assuming 360 as usual.\n\n[0, 360] (end inclusive) with a step angle of 0.1 for 3601 projections per offset position. Number of offset positions depends on the sample. For example, Scroll 1 had 2 horizontal and 21 vertical offset positions. Some of these vertical offsets are redundant (this will be explained in [the paper](https://github.com/educelab/EduceLab-Scrolls)), but the raw dataset is 3601 * 2 * 21 = 151242 projection images for one scroll.\n\n> What was the pixel resolution of the original X-ray images?\n\n7.91um for the scrolls, 3.24um for the fragments. Due to beam divergence these could be larger by up to 4%, but given where the samples were scanned in the beam, they're likely very close to the nominal pixel size. Note that these were scanned in parallel beam, so the reconstructed pixel size is approximately equal to the detector pixel size.\n\n> Whats the digital bit depth on the original X-ray images?\n\n16-bits of effective depth, stored in 32-bit floats by the acquisition system.\n\n> How large would this dataset be in GB?\n\nDepends on the dataset. The Scroll 1 raw data mentioned above is about 1.9TBs. This says nothing of the reconstructed data.\n\n> At what X-ray energy was this acquired?\n\n54keV for everything. Additionally 88keV for the fragments. We are working to get these released as well and you'll find that this is referenced in the paper.\n\n> The \"air\" part (in the video the fragment stack actually looks like\n>\n> glass/plastic\n> fragment and then\n> paper\n\nHere's a marked up slice from Fragment 1:\n\n\n\nIf you're looking at the slice stack here on Kaggle, note that these are [surface volumes](https://scrollprize.org/tutorial3#surface-volumes) and not the original reconstructions. The tissue paper and acrylic frame and not represented in the Kaggle data.\n\n> Was the text/ink side of the fragment facing the glass panel or the paper?\n\nNo. The ink side of the fragment is faced away from the tissue paper and acrylic frame. In the marked up image above, it would be on the \"top\" edge of the fragment, where the green line is pointing.\n\n> The \"air\" part seems to have structure or ringing artifacts\n\nThese are [fairly common artifacts](http://www.edboas.com/science/CT/0012.pdf) in CT scan reconstructions, particularly those reconstructed using filtered backprojection.\n\n> Are these the intrinsic result of X-ray imaging?\n> Or are these the result of scattering or diffraction processes?\n\nThese datasets are derived from x-ray attenuation data, i.e. \"normal\" x-ray images.\n\n> Is my assumption correct or incorrect that for the ink-detection challenge no virtual meshing and virtual flattening was applied?\n\nThat is incorrect. Segmentation, meshing, and flattening were used to align the photograph-derived ink labels onto the 3D surface of the fragment AND to generate the optimized surface volumes provided on Kaggle. The original reconstructed volumes are available [here](https://scrollprize.org/data) if you would like to attempt ink detection without those steps. I would personally be very interested in how you frame the problem without some form of virtual unwrapping.\n\n> Assuming no virtual meshing and flattening (with unknown Jacobians) was used to produce the training TIFF's, may we assume the test dataset followed the same process without meshing and flattening?\n\nThough virtual unwrapping was used, it is worth clarifying that all fragment datasets used in the Kaggle competition were prepared in the same way. That includes the private dataset that we use for validating results.\n\n> ...Given this issue the most obvious thing to do would be to add X-ray energy \"color\" channels, so that material compositions would correspond to regions in a higher dimensional space such that interpolated values (on a path between such regions) are significantly less likely to cross so disambiguation becomes much more tractable.\n>\n> Apart from dataset size, is there a reason the scrolls aren't scanned at different X-ray energies?\n\nThat is correct in principle. Multi-energy acquisition could theoretically improve contrast between the ink and papyrus. In practice, this is much harder than it sounds. A few things to consider for the scans themselves are:\n* The edge you want to capture is at a low energy (subtle carbon differences), but the scrolls are dense enough that you get very little transmission at these energies with x-ray tubes. Practically, you end up having to scan at higher energies (50kV+)\n* Even at these energies, scan times can be long for moderate micro-CT resolutions (12+ hours for a 23um scan of a scroll)\n* While that's not the worst scan length as a matter of logistics, you have to consider things like thermal effects on the sample during extended scans. Some materials can expand and contract on the order of microns multiple times over a 12 hour period. This will cause reconstruction problems.\n* To really take advantage of multi-energy scans, the reconstructions themselves need to be aligned so you can do voxel-to-voxel comparisons across scans. Any non-linear scaling effects in the reconstruction (e.g. thermal effects) make this harder.\n* Some of these things can be solved by capturing at a beam line, which is a brilliant light source, but beam lines have their own limitations. For example, the Diamond beam line we worked on has a lower energy limit of 54keV. Other beam lines can capture at lower energies, but they tend to also have smaller fields-of-view and/or pixel sizes. It's really tricky to find the beam line with the right properties _for this task_.\n\nYou also need to consider logistics:\n* Access to the materials must be negotiated. \n* Transport of materials to a scanner or a scanner to the materials is non-trivial. \n* One does not simply walk into a beam line. It requires either (a) writing an acceptable scientific proposal, or (b) a lot of money. \n* Once you have beam time scheduled, you must additionally make sure your material access window lines up with the beam line window.\n* Every sample needs supports (cases, frames, etc.) that are custom-designed and do not risk damage to the physical object. The first 90% of the work is preparing for the scan. The last 90% of the work is scanning and processing the data.\n\nAnyway, we've thought a lot about multi-energy scanning, and we try to make it happen when we can, but it's just hard to get good data given all of the constraints.", "votes": 12, "replies": [ { "id": 2213437, "postDate": "2023-04-07T15:17:04.723Z", "content": "That was a formidable reply!
\nI comprehend this type of research involves a lot difficulties and challenges: from bureaucracy (justifiable given these are unique fragile artifacts) to technological.
\nMy first series of questions (A 1-5) was mostly motivated by an idea for compressing the original dataset of X-ray images (both lossy and lossless).
\nI forgot to ask about the dimensions in pixels of those X-ray images, i.e. for one of the 151242 projection images.
\nAre the 2 horizontal and 21 vertical offset positions different image sensors during the same run, or one and the same image sensor during different runs but with the rotating stage translated to different heights?
\nI assume the 3601'th angular position is to compare with the 1st, for calibration and for estimating the thermal distortions? (in theory it would seem that for each angle say 123.4 degrees there is a second angle 303.4 degrees which in a perfect world ought to encode the same transmission information.
\nIs it known if the backprojection algorithm A) effectively \"simply\" tracks the sinusoidal movement of a given voxel, or B) optimizes for self-consistency so that it also considers the densities along the full ray (necessitating voxel densities from the previous fitting iteration)? I assume it tries to fit a scalar density by voxel, without any angular dependence of voxel opacities.
\nEDIT: forgot to ask, is the X-ray beam switched on and off for each position with the sample held still (causing acceleration and deceleration forces at each step), or is the beam constantly on with the sample rotating continuously?
\nDoes the sensor utilize a global shutter, and in the case of continous illumination and rotation, what duty cycle (or percentage of the time) is the pixel integrating photons? Or is it a rolling shutter, in that case I am also interested in the duty cycle?
\nI believe the dataset can be efficiently compressed such that the datastructure permits consulting voxels, but also permits consulting pixels from the original X-ray images.
\nThanks again for your thorough answer,
", "rawMarkdown": "That was a formidable reply!\n\nI comprehend this type of research involves a lot difficulties and challenges: from bureaucracy (justifiable given these are unique fragile artifacts) to technological.\n\nMy first series of questions (A 1-5) was mostly motivated by an idea for compressing the original dataset of X-ray images (both lossy and lossless).\n\nI forgot to ask about the dimensions in pixels of those X-ray images, i.e. for one of the 151242 projection images.\n\nAre the 2 horizontal and 21 vertical offset positions different image sensors during the same run, or one and the same image sensor during different runs but with the rotating stage translated to different heights?\n\nI assume the 3601'th angular position is to compare with the 1st, for calibration and for estimating the thermal distortions? (in theory it would seem that for each angle say 123.4 degrees there is a second angle 303.4 degrees which in a perfect world ought to encode the same transmission information.\n\nIs it known if the backprojection algorithm A) effectively \"simply\" tracks the sinusoidal movement of a given voxel, or B) optimizes for self-consistency so that it also considers the densities along the full ray (necessitating voxel densities from the previous fitting iteration)? I assume it tries to fit a scalar density by voxel, without any angular dependence of voxel opacities.\n\nEDIT: forgot to ask, is the X-ray beam switched on and off for each position with the sample held still (causing acceleration and deceleration forces at each step), or is the beam constantly on with the sample rotating continuously?\n\nDoes the sensor utilize a global shutter, and in the case of continous illumination and rotation, what duty cycle (or percentage of the time) is the pixel integrating photons? Or is it a rolling shutter, in that case I am also interested in the duty cycle?\n\nI believe the dataset can be efficiently compressed such that the datastructure permits consulting voxels, but also permits consulting pixels from the original X-ray images.\n\nThanks again for your thorough answer,\n", "replies": [ { "id": 2213508, "postDate": "2023-04-07T16:11:54.477Z", "content": "\n\nI forgot to ask about the dimensions in pixels of those X-ray images, i.e. for one of the 151242 projection images.
\n
Ahh, right! That's important. 2560x2160 for all scans. The Diamond high-res camera uses swappable optical modules with the same x-ray camera back. We used Module 2 for the scrolls and Module 3 for the fragments.
\n\n\nAre the 2 horizontal and 21 vertical offset positions different image sensors during the same run, or on and the same image sensor during different runs but with the rotating stage translated to different heights?
\n
Same sensor, multiple translated positions of the sample w.r.t. the camera.
\n\n\nI assume the 3601'th angular position is to compare with the 1st, for calibration and for estimating the thermal distortions?
\n
I'm honestly not sure how they use it for reconstruction correction at Diamond. They use an in-house reconstruction system called Savu which has more plugins than I can count. I'm also not sure how important thermal effects are in a beamline. The x-ray generation method isn't going to produce as much heat (at least in the sample chamber) and the sample chamber is a room that's bigger than my living room at home (i.e. it has lots of space for absorbing heat fluctuations). I'm sure there's some, particularly at 1-3um resolutions, but not sure how much. A post-scan is definitely a common technique in commercial scanners, though, and I would bet they at least have it in their toolkit even if they don't always need it.
\n\n\n(in theory it would seem that for each angle say 123.4 degrees there is a second angle 303.4 degrees which in a perfect world ought to encode the same transmission information.
\n
Yes, and when you have a parallel beam, you can exploit this to reduce the number of offset positions you need to capture. If you translate off center-of-rotation +X, then the projections you get for theta > 180 degrees are the same as what you would get if you translated off center-of-rotation -X. We called this \"annular scanning\" during the session because each horizontal offset position adds an annulus to the total scanned volume, but I'm not sure if there's a better name.
\n\n\nI it known if the backprojection algorithm A) effectively \"simply\" tracks the sinusoidal movement of a given voxel, or B) optimizes for self-consistency so that it also considers the densities along the full ray (necessitating voxel densities from the previous fitting iteration)? I assume it tries to fit a scalar density by voxel, without any angular dependence of voxel opacities.
\n
Backprojection is an analytically-derived reconstruction approach built on the projection-slice/central slice theorem. It relies on a bunch of stuff about the equivalence between object projections and the Fourier-transformed object, but the takeaway is that there's a formula that lets you compute a voxel's density directly (single step) from all projected samples of that voxel.
\nWhat you're describing sounds more like an iterative, forward projection algorithm where you iteratively reconstruct the volume by minimizing the error between the original projections and forward projections of the reconstruction [example]. If I'm understanding you correctly, both approaches necessarily take into effect the angular dependence of voxel opacities. I found Chapter 3 of Hsieh's Computed Tomography book particularly good for understanding the math and intuition around the various reconstruction approaches.
", "rawMarkdown": "> I forgot to ask about the dimensions in pixels of those X-ray images, i.e. for one of the 151242 projection images.\n\nAhh, right! That's important. 2560x2160 for all scans. The Diamond [high-res camera](https://www.diamond.ac.uk/Instruments/Imaging-and-Microscopy/I12/Detectors-at-I12.html#Imaging%20cameras) uses swappable optical modules with the same x-ray camera back. We used Module 2 for the scrolls and Module 3 for the fragments.\n\n> Are the 2 horizontal and 21 vertical offset positions different image sensors during the same run, or on and the same image sensor during different runs but with the rotating stage translated to different heights?\n\nSame sensor, multiple translated positions of the sample w.r.t. the camera.\n\n> I assume the 3601'th angular position is to compare with the 1st, for calibration and for estimating the thermal distortions?\n\nI'm honestly not sure how they use it for reconstruction correction at Diamond. They use an in-house reconstruction system called [Savu](https://github.com/DiamondLightSource/Savu) which has more plugins than I can count. I'm also not sure how important thermal effects are in a beamline. The x-ray generation method isn't going to produce as much heat (at least in the sample chamber) and the sample chamber is a room that's bigger than my living room at home (i.e. it has lots of space for absorbing heat fluctuations). I'm sure there's some, particularly at 1-3um resolutions, but not sure how much. A post-scan is definitely a common technique in commercial scanners, though, and I would bet they at least have it in their toolkit even if they don't always need it.\n\n> (in theory it would seem that for each angle say 123.4 degrees there is a second angle 303.4 degrees which in a perfect world ought to encode the same transmission information.\n\nYes, and when you have a parallel beam, you can exploit this to reduce the number of offset positions you need to capture. If you translate off center-of-rotation +X, then the projections you get for theta > 180 degrees are the same as what you would get if you translated off center-of-rotation -X. We called this \"annular scanning\" during the session because each horizontal offset position adds an annulus to the total scanned volume, but I'm not sure if there's a better name.\n\n> I it known if the backprojection algorithm A) effectively \"simply\" tracks the sinusoidal movement of a given voxel, or B) optimizes for self-consistency so that it also considers the densities along the full ray (necessitating voxel densities from the previous fitting iteration)? I assume it tries to fit a scalar density by voxel, without any angular dependence of voxel opacities.\n\nBackprojection is an analytically-derived reconstruction approach built on the [projection-slice/central slice theorem](https://en.wikipedia.org/wiki/Projection-slice_theorem). It relies on a bunch of stuff about the equivalence between object projections and the Fourier-transformed object, but the takeaway is that there's a formula that lets you compute a voxel's density directly (single step) from all projected samples of that voxel. \n\nWhat you're describing sounds more like an [iterative, forward projection algorithm](https://en.wikipedia.org/wiki/Tomographic_reconstruction#Iterative_Reconstruction_Algorithm) where you iteratively reconstruct the volume by minimizing the error between the original projections and forward projections of the reconstruction [[example]](https://en.wikipedia.org/wiki/Tomographic_reconstruction#Gallery). If I'm understanding you correctly, both approaches necessarily take into effect the angular dependence of voxel opacities. I found Chapter 3 of [Hsieh's _Computed Tomography_ book](https://doi.org/10.1117/3.2197756) particularly good for understanding the math and intuition around the various reconstruction approaches." }, { "id": 2213705, "postDate": "2023-04-07T19:33:25.290Z", "content": "So the original X-ray dataset for a single fragment should be 2560x2160x3601x2x21 = 836.3 GPixels, correct? in the original format of 32-bit floats that would be about 3.042 TB, or about 1.5TB converted to 16-bit integers. Does this sound right?
", "rawMarkdown": "So the original X-ray dataset for a single fragment should be 2560x2160x3601x2x21 = 836.3 GPixels, correct? in the original format of 32-bit floats that would be about 3.042 TB, or about 1.5TB converted to 16-bit integers. Does this sound right?" }, { "id": 2213730, "postDate": "2023-04-07T20:00:23.783Z", "content": "On small change: It is actually stored as U16 and not 32F. I was misinterpreting the fundamental data type before. That doesn't really change much about the data (still 16-bits of dynamic range), but it does change the conversation about data sizes.
\nOtherwise, yeah, that's about right for the Scroll 1. They're all natively stored in Diamond's Nexus file format, which as I understand it is a formalized metadata layer around HDF5. The 1.9TBs I quoted before was calculated by getting the size of a single HDF5 file (one set of 3601 projections) and multiplying by 42. The actual sizes of each chunk vary somewhat (some of the hdf's also contain flatfields and dark fields). Total size for Scroll 1 projections is somewhere between 1.5-1.9TBs.
\nAnd just to be clear, these are the raw x-ray projections, not the reconstructed slices.
", "rawMarkdown": "On small change: It is actually stored as U16 and not 32F. I was misinterpreting the fundamental data type before. That doesn't really change much about the data (still 16-bits of dynamic range), but it does change the conversation about data sizes.\n\nOtherwise, yeah, that's about right for the Scroll 1. They're all natively stored in Diamond's Nexus file format, which as I understand it is a formalized metadata layer around HDF5. The 1.9TBs I quoted before was calculated by getting the size of a single HDF5 file (one set of 3601 projections) and multiplying by 42. The actual sizes of each chunk vary somewhat (some of the hdf's also contain flatfields and dark fields). Total size for Scroll 1 projections is somewhere between 1.5-1.9TBs.\n\nAnd just to be clear, these are the raw x-ray projections, not the reconstructed slices.", "votes": 1 } ] } ] }, { "id": 2210923, "postDate": "2023-04-05T17:51:06.693Z", "content": "EDIT: I edited the question because it renumbers questions to start again from 1 for each series of questions, so I am prepending alphabetic characters…
\nThe question is about the actual Vesuvius half-scroll:
\nA: 1-5
\nThe \"air\" part (in the video the fragment stack actually looks like
\nB: 1
\nThe \"air\" part seems to have structure or ringing artifacts
\nC: 1-4
\nAre these the intrinsic result of X-ray imaging?
Or are these the result of scattering or diffraction processes?
Is my assumption correct or incorrect that for the ink-detection challenge no virtual meshing and virtual flattening was applied?
Assuming no virtual meshing and flattening (with unknown Jacobians) was used to produce the training TIFF's, may we assume the test dataset followed the same process without meshing and flattening?
Consider a hypothetical halfspace of a more radiotranslucent material succeeded by a more radio-opaque material. Depending on the shift of a virtual voxel grid normal to the interface (shifting the voxel grid into or out of the phase boundary), voxels that remain completely within the same material will report similar radiodensity values, but the voxel on the boundary will interpolate. No material with the interpolated radiodensity value is present of course… Given this issue the most obvious thing to do would be to add X-ray energy \"color\" channels, so that material compositions would correspond to regions in a higher dimensional space such that interpolated values (on a path between such regions) are significantly less likely to cross so disambiguation becomes much more tractable.
\nD: 1
\n@csparker,
\nI think it is a right thread to post my questions, instead of openning a new thread.
\nAre scrolls made from papyrus?
Yes, they are made from papyrus.
", "rawMarkdown": "Yes, they are made from papyrus.", "votes": 1, "replies": [ { "id": 2223197, "postDate": "2023-04-16T01:08:08.567Z", "content": "@csparker, thank you for the response.
\nI want to understand something.
\nAFAIK, the papyrus is made from two layers. The process of making papyrus involved layering the strips of pith in two directions, perpendicular to each other. The first layer of strips was laid parallel to each other, with the strips overlapping slightly to form a continuous sheet. The second layer of strips was then laid perpendicular to the first layer, and the two layers were pressed together to create a single sheet of papyrus.
\nThe upper layer of papyrus is the layer that would have been written on. This layer is typically composed of strips that run parallel to the length of the scroll, and perpendicular to the strips in the lower layer.
\nIs that correct?
\nIf yes, I have another question. Looking into the fragment 1, I see more perpendicular strips than a vertical. The vertical strips always intersects with horizontal ones. If I understand how papyrus is done and the resolution of the image, I would anticipate that the accurate unwrapping of the scroll should contain only one direction of strips in the most of slices.
\n\nHow many X-rays were taken, at what step angle? I am assuming 360 as usual.
\n
[0, 360] (end inclusive) with a step angle of 0.1 for 3601 projections per offset position. Number of offset positions depends on the sample. For example, Scroll 1 had 2 horizontal and 21 vertical offset positions. Some of these vertical offsets are redundant (this will be explained in the paper), but the raw dataset is 3601 * 2 * 21 = 151242 projection images for one scroll.
\n\n\nWhat was the pixel resolution of the original X-ray images?
\n
7.91um for the scrolls, 3.24um for the fragments. Due to beam divergence these could be larger by up to 4%, but given where the samples were scanned in the beam, they're likely very close to the nominal pixel size. Note that these were scanned in parallel beam, so the reconstructed pixel size is approximately equal to the detector pixel size.
\n\n\nWhats the digital bit depth on the original X-ray images?
\n
16-bits of effective depth, stored in 32-bit floats by the acquisition system.
\n\n\nHow large would this dataset be in GB?
\n
Depends on the dataset. The Scroll 1 raw data mentioned above is about 1.9TBs. This says nothing of the reconstructed data.
\n\n\nAt what X-ray energy was this acquired?
\n
54keV for everything. Additionally 88keV for the fragments. We are working to get these released as well and you'll find that this is referenced in the paper.
\n\n\nThe \"air\" part (in the video the fragment stack actually looks like
\nglass/plastic
\n
\n fragment and then
\n paper
Here's a marked up slice from Fragment 1:
\n
If you're looking at the slice stack here on Kaggle, note that these are surface volumes and not the original reconstructions. The tissue paper and acrylic frame and not represented in the Kaggle data.
\n\n\nWas the text/ink side of the fragment facing the glass panel or the paper?
\n
No. The ink side of the fragment is faced away from the tissue paper and acrylic frame. In the marked up image above, it would be on the \"top\" edge of the fragment, where the green line is pointing.
\n\n\nThe \"air\" part seems to have structure or ringing artifacts
\n
These are fairly common artifacts in CT scan reconstructions, particularly those reconstructed using filtered backprojection.
\n\n\nAre these the intrinsic result of X-ray imaging?
\n
\n Or are these the result of scattering or diffraction processes?
These datasets are derived from x-ray attenuation data, i.e. \"normal\" x-ray images.
\n\n\nIs my assumption correct or incorrect that for the ink-detection challenge no virtual meshing and virtual flattening was applied?
\n
That is incorrect. Segmentation, meshing, and flattening were used to align the photograph-derived ink labels onto the 3D surface of the fragment AND to generate the optimized surface volumes provided on Kaggle. The original reconstructed volumes are available here if you would like to attempt ink detection without those steps. I would personally be very interested in how you frame the problem without some form of virtual unwrapping.
\n\n\nAssuming no virtual meshing and flattening (with unknown Jacobians) was used to produce the training TIFF's, may we assume the test dataset followed the same process without meshing and flattening?
\n
Though virtual unwrapping was used, it is worth clarifying that all fragment datasets used in the Kaggle competition were prepared in the same way. That includes the private dataset that we use for validating results.
\n\n\n…Given this issue the most obvious thing to do would be to add X-ray energy \"color\" channels, so that material compositions would correspond to regions in a higher dimensional space such that interpolated values (on a path between such regions) are significantly less likely to cross so disambiguation becomes much more tractable.
\nApart from dataset size, is there a reason the scrolls aren't scanned at different X-ray energies?
\n
That is correct in principle. Multi-energy acquisition could theoretically improve contrast between the ink and papyrus. In practice, this is much harder than it sounds. A few things to consider for the scans themselves are:
\nYou also need to consider logistics:
\nAnyway, we've thought a lot about multi-energy scanning, and we try to make it happen when we can, but it's just hard to get good data given all of the constraints.
", "votes": 12, "replies": [ { "id": 2213437, "author_name": "Ludwig Maes", "author_url": "", "post_date": "2023-04-07T15:17:04.723000", "content": "That was a formidable reply!
\nI comprehend this type of research involves a lot difficulties and challenges: from bureaucracy (justifiable given these are unique fragile artifacts) to technological.
\nMy first series of questions (A 1-5) was mostly motivated by an idea for compressing the original dataset of X-ray images (both lossy and lossless).
\nI forgot to ask about the dimensions in pixels of those X-ray images, i.e. for one of the 151242 projection images.
\nAre the 2 horizontal and 21 vertical offset positions different image sensors during the same run, or one and the same image sensor during different runs but with the rotating stage translated to different heights?
\nI assume the 3601'th angular position is to compare with the 1st, for calibration and for estimating the thermal distortions? (in theory it would seem that for each angle say 123.4 degrees there is a second angle 303.4 degrees which in a perfect world ought to encode the same transmission information.
\nIs it known if the backprojection algorithm A) effectively \"simply\" tracks the sinusoidal movement of a given voxel, or B) optimizes for self-consistency so that it also considers the densities along the full ray (necessitating voxel densities from the previous fitting iteration)? I assume it tries to fit a scalar density by voxel, without any angular dependence of voxel opacities.
\nEDIT: forgot to ask, is the X-ray beam switched on and off for each position with the sample held still (causing acceleration and deceleration forces at each step), or is the beam constantly on with the sample rotating continuously?
\nDoes the sensor utilize a global shutter, and in the case of continous illumination and rotation, what duty cycle (or percentage of the time) is the pixel integrating photons? Or is it a rolling shutter, in that case I am also interested in the duty cycle?
\nI believe the dataset can be efficiently compressed such that the datastructure permits consulting voxels, but also permits consulting pixels from the original X-ray images.
\nThanks again for your thorough answer,
", "votes": 0, "replies": [ { "id": 2213508, "author_name": "Seth P.", "author_url": "", "post_date": "2023-04-07T16:11:54.477000", "content": "\n\nI forgot to ask about the dimensions in pixels of those X-ray images, i.e. for one of the 151242 projection images.
\n
Ahh, right! That's important. 2560x2160 for all scans. The Diamond high-res camera uses swappable optical modules with the same x-ray camera back. We used Module 2 for the scrolls and Module 3 for the fragments.
\n\n\nAre the 2 horizontal and 21 vertical offset positions different image sensors during the same run, or on and the same image sensor during different runs but with the rotating stage translated to different heights?
\n
Same sensor, multiple translated positions of the sample w.r.t. the camera.
\n\n\nI assume the 3601'th angular position is to compare with the 1st, for calibration and for estimating the thermal distortions?
\n
I'm honestly not sure how they use it for reconstruction correction at Diamond. They use an in-house reconstruction system called Savu which has more plugins than I can count. I'm also not sure how important thermal effects are in a beamline. The x-ray generation method isn't going to produce as much heat (at least in the sample chamber) and the sample chamber is a room that's bigger than my living room at home (i.e. it has lots of space for absorbing heat fluctuations). I'm sure there's some, particularly at 1-3um resolutions, but not sure how much. A post-scan is definitely a common technique in commercial scanners, though, and I would bet they at least have it in their toolkit even if they don't always need it.
\n\n\n(in theory it would seem that for each angle say 123.4 degrees there is a second angle 303.4 degrees which in a perfect world ought to encode the same transmission information.
\n
Yes, and when you have a parallel beam, you can exploit this to reduce the number of offset positions you need to capture. If you translate off center-of-rotation +X, then the projections you get for theta > 180 degrees are the same as what you would get if you translated off center-of-rotation -X. We called this \"annular scanning\" during the session because each horizontal offset position adds an annulus to the total scanned volume, but I'm not sure if there's a better name.
\n\n\nI it known if the backprojection algorithm A) effectively \"simply\" tracks the sinusoidal movement of a given voxel, or B) optimizes for self-consistency so that it also considers the densities along the full ray (necessitating voxel densities from the previous fitting iteration)? I assume it tries to fit a scalar density by voxel, without any angular dependence of voxel opacities.
\n
Backprojection is an analytically-derived reconstruction approach built on the projection-slice/central slice theorem. It relies on a bunch of stuff about the equivalence between object projections and the Fourier-transformed object, but the takeaway is that there's a formula that lets you compute a voxel's density directly (single step) from all projected samples of that voxel.
\nWhat you're describing sounds more like an iterative, forward projection algorithm where you iteratively reconstruct the volume by minimizing the error between the original projections and forward projections of the reconstruction [example]. If I'm understanding you correctly, both approaches necessarily take into effect the angular dependence of voxel opacities. I found Chapter 3 of Hsieh's Computed Tomography book particularly good for understanding the math and intuition around the various reconstruction approaches.
", "votes": 0, "replies": [] }, { "id": 2213705, "author_name": "Ludwig Maes", "author_url": "", "post_date": "2023-04-07T19:33:25.290000", "content": "So the original X-ray dataset for a single fragment should be 2560x2160x3601x2x21 = 836.3 GPixels, correct? in the original format of 32-bit floats that would be about 3.042 TB, or about 1.5TB converted to 16-bit integers. Does this sound right?
", "votes": 0, "replies": [] }, { "id": 2213730, "author_name": "Seth P.", "author_url": "", "post_date": "2023-04-07T20:00:23.783000", "content": "On small change: It is actually stored as U16 and not 32F. I was misinterpreting the fundamental data type before. That doesn't really change much about the data (still 16-bits of dynamic range), but it does change the conversation about data sizes.
\nOtherwise, yeah, that's about right for the Scroll 1. They're all natively stored in Diamond's Nexus file format, which as I understand it is a formalized metadata layer around HDF5. The 1.9TBs I quoted before was calculated by getting the size of a single HDF5 file (one set of 3601 projections) and multiplying by 42. The actual sizes of each chunk vary somewhat (some of the hdf's also contain flatfields and dark fields). Total size for Scroll 1 projections is somewhere between 1.5-1.9TBs.
\nAnd just to be clear, these are the raw x-ray projections, not the reconstructed slices.
", "votes": 1, "replies": [] } ] } ] }, { "id": 2223183, "author_name": "Yuri Kreinin", "author_url": "", "post_date": "2023-04-16T00:17:02.813000", "content": "@csparker,
\nI think it is a right thread to post my questions, instead of openning a new thread.
\nAre scrolls made from papyrus?
Yes, they are made from papyrus.
", "votes": 1, "replies": [ { "id": 2223197, "author_name": "Yuri Kreinin", "author_url": "", "post_date": "2023-04-16T01:08:08.567000", "content": "@csparker, thank you for the response.
\nI want to understand something.
\nAFAIK, the papyrus is made from two layers. The process of making papyrus involved layering the strips of pith in two directions, perpendicular to each other. The first layer of strips was laid parallel to each other, with the strips overlapping slightly to form a continuous sheet. The second layer of strips was then laid perpendicular to the first layer, and the two layers were pressed together to create a single sheet of papyrus.
\nThe upper layer of papyrus is the layer that would have been written on. This layer is typically composed of strips that run parallel to the length of the scroll, and perpendicular to the strips in the lower layer.
\nIs that correct?
\nIf yes, I have another question. Looking into the fragment 1, I see more perpendicular strips than a vertical. The vertical strips always intersects with horizontal ones. If I understand how papyrus is done and the resolution of the image, I would anticipate that the accurate unwrapping of the scroll should contain only one direction of strips in the most of slices.