Replies: 4 comments 2 replies
-
It appeared that you have aliasing problem. |
Beta Was this translation helpful? Give feedback.
-
okay! thanks for the response! funny thing is when i take three vertical
slices of the image so rather than an approx 12" x 18" (or actual 279.4H x
489 mm wide image at 300dpi, i have a test image approx. 12" x 2- 3" image
279.4 mmH by something wide, the image burns without the repeating
horizontal gradient pattern. I chose 8 lines per mm as the quality factor
as it was a multiple of the stepper motor for both the test and the final
run (a multiple of 80 steps per mm). (also did tests at 10 lines per mm
with similar results)
i did wonder if the image/picture shouldn't be sampled at 254 dots per
inch rather than 300 dpi whether this would help.
i have burned a number of images and it appears that once a picture becomes
a certain number of pixels that the problem appears. I thought it was a get
pixel sampling error, or sampling the same row of pixels twice, when a
certain amount of ram is required. The full image is 5776x3300 pixels or
922kb jpg file. If the ram / memory requirements cause memory paging, is
there an error with get pixel across a memory page boundary.
when loading the test image i set the brightness, contrast, and white
level, do the burn, then load the full image leaving the brightness and
contrast and white level at the same settings and expect to get similar
results with the full image, with the same feed rate/stepper speed and
laser/spindle speed settings, but the results are not even close. BUT if i
reload the test image i get similar results to the first test image burn.
This indicates to me that the graphics editor module does not behave as one
would expect. The test sample was pieced together by cutting vertical
slices with photoshop or corel photo paint and moving the slices side by
side, and cutting the image to the new width, or by taking one cut/slice of
the full size image and saving with no pixel adjustments.
For large images I have chosen passthrough and get a fairly good result, on
the horizontal lines but have some vertical aliasing showing up. I wondered
if this would go away with a 254 dots per inch sampling of the image. I
haven't done this test yet!
i do plan this week to edit the jpeg, and resample with 254 dots per inch
and do a passthrough test.
If someone has determined what pixel resolution works best please post it.
the aliasing error is visible in the photo of the full size image on maple
(inclosed). Note: unlike the previous pictures of the burns the aliasing is
not at a fixed repeatable dimension, however it seems to be the full
picture height.
Like you i had assumed the first tests at line by line was due to sampling
and possibly scaling and processing of , brightness and contrast
adjustment settings within LaserGRBL with errors showing up with larger
images.
thank you for your comment, it does confirm what i was thinking regarding
sampling, however it seems to fall apart with a large image size.
[image: image_50407681.JPG]
…On Wed, Sep 7, 2022 at 11:11 AM Sal ***@***.***> wrote:
It appeared that you have aliasing problem.
Make sure your GRBL settings for axis resolution $100 and $101 set
properly, specific for your machine. Then when reaping the photo - select
"lines per mm" as whole fraction of that resolution.
For example, for 1/16 uStep machines these are often =80 (lines per mm).
When reaping image you may chose division friendly to that number. For
example, 10 or 20 or 40 lines per mm will work well, 30 or 60 will produce
aliasing.
—
Reply to this email directly, view it on GitHub
<#1883 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWDE6TMXDGUDSD5IXY5SLXDV5CWBDANCNFSM55MTMAYQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Thank you. It will likely be all in the math.
My settings for $13 set to zero (=mm). And $100 and $101 are 80.
i am working in mm - the 12x18" was the size of the blank wood piece. I
provided actual image size in mm, but as a cabinetmaker i work in inches,
and as a machinist i work with both inches and metric. So constantly doing
math.
would it be best to resample to a DPI of 254 ie 10 dots per mm as a source
to LaserGRBL be an advantage?
it would make calculations to prevent aliasing errors easier?
if burnt at 10 lines per mm this would eliminate aliasing errors. Correct
me if I am wrong.
"On next step, do you select image size by EXIF DPI or specify your own?
Experiment with your own numbers, not 254 but like 200 or 400" I can see if
LaserGrbl is resampling the source that a multiple of the stepping motor in
mm would be an advantage.
I have tried both default and setting 300dpi, but did not try 200 or 400, a
multiple of the stepper motor. I am not sure I fully understand this
setting.
Are you implying that during import the image is resampled to 200 or 400
dots per mm?
digital photography or photo scanners in DPI is not any where near an even
DPmm.
sounds like many more attempts are required, what discouraged me was
getting different results with a slice of the jpeg.
…On Wed, Sep 7, 2022 at 2:09 PM Sal ***@***.***> wrote:
I suspect aliasing caused first of all by not matching steps per scan
lines exactly. If "lines per mm" is not exact number then you will have
periodic rounding error where stepper will have to make larger step, thus
lighter image.
This maybe present in both dimensions, X and Y, but I guess primary raster
scan dimension is less prone to it because of kinematics/inertia that makes
step smoother, but only in one direction. So most aliasing will be between
scan lines.
Additionally, any image processing for dithering and such may add spatial
harmonics to the image, therefore pass through is the best settings,
assuming your machine support variable power.
Make sure your $13 set to zero (=mm). And $100 and $101 are nice round
numbers. If working in inches - get even numbers more difficult, IMHO, but
not impossible. The point is to get exact step in all directions/dimensions
for whole raster. Any funky ratio will get you uneven step through raster
and resulting "shades" or "Moire" effect. You may chose 8 or 10 lines, but
if somewhere else something else recalculated as inches - you may aggregate
that periodic rounding error.
On next step, do you select image size by EXIF DPI or specify your own?
Experiment with your own numbers, not 254 but like 200 or 400.
If not sure - just use very high scan line density, like 40 lines per mm.
May take more time but aliasing maybe minimized.
On example below 3 lines per mm will be horrible in most cases. Starting
from 10 lines and up to full step resolution of your machine (usually 80) .
Takes time but will have significant improvement in quality.
Consider that beam spot will be overlapping. This is like repeat burn, so
you may need to increase speed or reduce quality, if lines per mm is too
high.
Good luck!
[image: image]
<https://user-images.githubusercontent.com/112994211/188946958-31de9e1a-1d9c-40a9-9651-1862af36cf94.png>
—
Reply to this email directly, view it on GitHub
<#1883 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWDE6TJMRRP52HYDP3WS44LV5DK5NANCNFSM55MTMAYQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
thank you, I will try this and verify the step distance. Good to know that
you are doing 20 and 40 lines per mm
again thank you for your help. It would be nice if the web site for
LaserGRBL had some recommendations for this.
I am very grateful for all of Arkypita's work. As a former software
developer I appreciate the time he has spent on this project.
…On Wed, Sep 7, 2022 at 5:04 PM Sal ***@***.***> wrote:
Maybe try sanity check: save work from LaserGRBL as .nc or .g and look
with notepad if it commands GRBL to advance coordinates in whole micro
steps, your step quantum should always be dividable by 1/80th without
remainder. (multiply any commanded coordinate by 80 => you should always
get whole number).
Or try right away high density raster and see the result. I do 20 lines
and still see some lines. 40 lines per mm is not unreasonable for quality
photo.
—
Reply to this email directly, view it on GitHub
<#1883 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWDE6TP34JOGWWU3YF2CAWDV5D7MTANCNFSM55MTMAYQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
issue: test burn done with three vertical slices of the original , both the subset and full image are at 300dpi are loaded with the same parameters and a line by line quality 5, and burned on the same material , same tree. The only source difference is the full image is approx 11" x 20" 2959x5295 pixels 4.4MB 8bit grayscale
Test burn gave reasonably good results at f1200 smin 325 smax 900 5 lines/mm
full burn issue with what appears to be digitizing errors, lighter laser levels, and inconsistent on each horizontal pass
image 1 is the full image reduced to 60dpi to present here
image 2 is the test burn at f1400 and f1200
image 3 is a sample of the final burn showing the issue.
the top half is at the same setting as the sample note the unburnt lines that appear, and the lighter burn
the bottom half is a second pass at f1100 smin 325 smax 935 focal length unchanged
The Questions I have:
why would streaking /unburnt lines appear?
why the lighter burn than the sample?
Beta Was this translation helpful? Give feedback.
All reactions