Offer to make PixInsight localizable to any language... and a layers tool

RBA

Well-known member
Feb 18, 2009
544
20
California, USA
deepskycolors.com
I don't know how ready the PixInsight code is for localization (that is, translating the software to other languages). I assume it's plagued with hardcoded strings (??) but regardless, I'd like to offer my time to make sure PixInsight's code is fully localizable so that versions in other languages can be done easily. Once I'm done, the whole platform would be, again, easily localizable to other languages, by simply translating a "localization kit" that would generate a group of "resource" files that could be just added to a PixInsight installation almost plug-and-play. My understanding is that this is not the case at all at this time.

I have extensive experience getting software ready for i18n and l10n. Past projects include making Netscape Navigator/Communicator localizable back in 1997-99, or the very same thing for eBay in 1999~2001 (which led to eBay launching in tons of countries). So you'd be in very good hands... I'd just need a fork in the code to work independently from current development. I know the software and I'm familiar with the coding style guidelines. I'm okay with NDAs and other reasonable legal agreements, I won't charge for any of this, of course, happy to "donate" it to the project.

A timeline for completion is hard to define without knowing what we're up to. 6-9 months sounds like a safe guess, as this would be a part-time endeavor. Being full-time, it could be done in a month.

On a side note, I would also reiterarte to Juan my interest in continuing developing the "layers" tool he started developing back in 2012 or so (but going way beyond the concept of "combining images/layers via PixelMath operations"), if he could only share the code already written. I don't have the drive to start with the sandbox from zero, plus Juan, you'd be getting LOTS of emails from me, much easier picking up where you left off.

That is, assuming there's an interest in any of this.

Cheers!
RBA
 

wconde

New member
Feb 21, 2019
1
0
Both are wonderful ideas. In my opinion PixInsight is an amazing astroimaging processing tool that is very close to be the perfect tool. What PixInsight is missing to be the perfect tool is exactly what Rogelio is proposing: a layers tool beyond the concept of combining images via PixelMath. I know this is something that has been proposed for a long time and I hope this time the project finally moves forward. Thanks for bringing this "back to life" again Rogelio!
 
Last edited:

Abel43

New member
Dec 13, 2020
1
0
Me parece una idea genial !! Esto es algo muy necesario y mejoraría muchísimo la herramienta Pixinsight. Que alguien tenga esta iniciativa me parece un regalo para todos !!
Adelante y muchas gracias RBA

*** EDITED BY THE FORUM ADMINISTRATOR ***
Please follow the forum rules.​
 
Last edited by a moderator:

Rafael Emmanuelli

New member
Dec 16, 2020
1
0
Excelente iniciativa Rogelio. El idioma castellano es la lengua materna de 480 millones de personas y el segundo más hablado en nuestro planeta después del mandarín. Claro que me gustaría contar con una versión de PI en español. Pienso que a los Chinos también les gustaría. ¡Adelante!

*** EDITED BY THE FORUM ADMINISTRATOR ***
Please follow the forum rules.​
 
Last edited by a moderator:

Juan Conejero

PixInsight Staff
Sep 2, 2004
8,156
344
57
Valencia, Spain
pixinsight.com
I don't know how ready the PixInsight code is for localization (that is, translating the software to other languages). I assume it's plagued with hardcoded strings (??) but regardless, I'd like to offer my time to make sure PixInsight's code is fully localizable so that versions in other languages can be done easily. Once I'm done, the whole platform would be, again, easily localizable to other languages, by simply translating a "localization kit" that would generate a group of "resource" files that could be just added to a PixInsight installation almost plug-and-play. My understanding is that this is not the case at all at this time.

I have extensive experience getting software ready for i18n and l10n. Past projects include making Netscape Navigator/Communicator localizable back in 1997-99, or the very same thing for eBay in 1999~2001 (which led to eBay launching in tons of countries). So you'd be in very good hands... I'd just need a fork in the code to work independently from current development. I know the software and I'm familiar with the coding style guidelines. I'm okay with NDAs and other reasonable legal agreements, I won't charge for any of this, of course, happy to "donate" it to the project.

A timeline for completion is hard to define without knowing what we're up to. 6-9 months sounds like a safe guess, as this would be a part-time endeavor. Being full-time, it could be done in a month.

On a side note, I would also reiterarte to Juan my interest in continuing developing the "layers" tool he started developing back in 2012 or so (but going way beyond the concept of "combining images/layers via PixelMath operations"), if he could only share the code already written. I don't have the drive to start with the sandbox from zero, plus Juan, you'd be getting LOTS of emails from me, much easier picking up where you left off.

That is, assuming there's an interest in any of this.

Cheers!
RBA

Thanks for your offer. We are currently involved in too many and too complex development projects to consider investing time and resources in building a localizable version of PixInsight. We cannot afford the additional level of complexity required by localized or internationalized versions of our software because we have to focus all of our work and efforts on much more important and critical tasks, some of them aimed at evolving the entire PixInsight platform in very significant ways during the coming years. On the other hand, building a database of translatable literal strings in our source code base and applying the necessary transformations to implement their indexed access would not be a difficult task for us, since we have powerful source code analysis and management utilities that we have been developing for years, which can automate an important part of this work.

As for a layers tool, it is not among our interests, either. We are working on other tools at present, which are more coherent with the lines of development that we have planned for PixInsight in the medium-long term. This includes improved versions of already existing processes, such as better preprocessing, background modeling and image registration tools, and new tools covering fields such as astrometry-based mosaic construction, astrometry and photometry applications, solar system ephemerides, new noise reduction, deconvolution and multiscale analysis algorithms, hardware control tools, etc. This is not to say that we are against a layers tool made by other developers—we are always glad to see new development projects arising on PixInsight; that's why PixInsight is a development platform after all—, but just that we are not going to help, support or promote its development directly.

It is true that we started working on a Layers tool during 2012, but we abandoned it in 2013 after redefining our priorities and future development lines, when we decided to invest our resources in much more interesting projects that have modeled what PixInsight is nowadays. The source code resulting from this initial development work has not been released publicly, and we have decided to keep it private in our development team, so it is not currently available for external use.

PixInsight is an ambitious project with a huge potential for future evolution. This is serious software. We have been working very hard on this project day to day during many years to build a powerful and flexible platform for astronomy, image processing and software development, and what PixInsight is today is just a starting point for what we want to do. Our time, human and material resources are limited; we have to invest them carefully without deviating from the development lines and priorities that will really allow us to achieve our goals in the long term.
 
  • Like
Reactions: dld

RBA

Well-known member
Feb 18, 2009
544
20
California, USA
deepskycolors.com
Thank you for your message, Juan. I see you're still too busy to write short responses :cool:

I'll be a lot quicker (I have the time)... This is what I take from your message +/-:

About localization:
"We don't have time to do this, and we aren't interested in you doing it for us because we could do some basic "translation memory" coding ourselves if we wanted anyway, but we don't have the time to do that either"

Which is unfortunate, but not that surprising, given your disdain against localized versions since, well, forever 😕

I will suggest that, should there be a v2.0 at some point, to make i18n/l10n support part of it. Seems a fitting feature for such update, maybe.

About layers:
"We're super busy" - I like that, don't stop! - "but the truth is we don't like layers, so although we have some code that someone else could use to avoid replicating similar work, we have no intention to help, aka share that code."

Which is fine if that's your preference, of course. Last time I asked you for the code a few months ago you said "SURE!" but that you couldn't find the code, so I waited... Not sure what changed, but it's alright. You've made clear this, too, is another dead end street, so be it. I don't really like your coding style anyways (j/k!)

Un saludo Juan y feliz año nuevo,
RBA
 

fredvanner

Well-known member
Apr 17, 2019
1,892
302
71
Wells, Somerset, UK
We cannot afford the additional level of complexity required by localized or internationalized versions of our software
A wise call in my opinion. It is easy to underestimate the complexity of this task. It is hard enough to achieve if designed into a system from the start, and immensely more difficult so long after the event. It also requires commitment to maintenance (translation and verification) of the translated content for each supported langage for the future history of the product. This is not a one-person task! Any internationalised paradigm (formal separation of language-sensitive content) would also have to apply to the extensive library of scripts if it is to be effective, which requires commitment by key third-party script writers / maintainers.
As for a layers tool, it is not among our interests
I believe the PI project succeeds by keeping its focus on astronomical image processing. There must always be a temptation to try and be a complete general image processing solution, but I see little point in cluttering the already complex specialist capabilities with features that are better supported by the excellent general purpose image processing products available commercially. Where there is a technical (data-based) need to combine images, I think PI provide a rich capability. For artistic enhancement of images, a general purpose image editing program is probably a better option.
 

tommy_nawratil

Well-known member
Feb 28, 2012
83
5
artistic enhancement... can be done in PixInsight in sheer endless variations. What is difficult (for me), is removing artefacts like structured star halos, structured reflections, pixelated noise by stacking slightly shifted sets of subs, etc... While Pixinsight has wonderful tools to remove other artefacts like gradients or noise, retouching is ever a problem. Layers would be wonderful for me as I am used using them for ages and love the intuitive mixing capabilities, but its not that essential and I respect that Juan has decided to concentrate on other things.

However, I admit Rogelios kind offer is a very tempting one, and hope - after the basic things were made clear here - there will be sort of collaboration possible.

feliz ano nuevo!
Tommy
 

RBA

Well-known member
Feb 18, 2009
544
20
California, USA
deepskycolors.com
... but I see little point in cluttering the already complex specialist capabilities with features that are better supported by the excellent general purpose image processing products available commercially.
Fred,

Thanks for your feedback. Juan has already responded a resounding NO to both offers, so you're beating on a dead horse. However, you make some comments I've heard many times that I know are fundamentally wrong and extremely short-sighted, no offense meant. Note I'm not trying to change Juan's mind here, he made it crystal clear he's not interested. But it may be an interesting reading if you have the time....

Oh the layers...
Your opinion is the same as in the PixInsight FAQ: that a layers tool is not needed because PixInsight's goal is not to compete with general purpose tools, and that layers are more suitable for artistic enhancement. To me, respectfully, that's just backwards. Layers offer a work methodology, it's not an artistic tool. It may aid on artistic goals depending on how you use it, like everything else.

In any case, my offer wasn't just an image blending tool (what most people describe as layers), but more of a tool enabling effective parallel and possibly object-oriented workflows, something for which PixInsight offers nothing today and frankly, most other apps aren't that much evolved in that direction either. The concept of layers is a good start, but it doesn't stop there. I'll give you a very basic example, still within the realm of a well-known workflow methodology:

Say, we have an image that just went through 4 processing steps: a deconvolution to our linear image, then a non-linear stretch, some noise reduction after that, and finally a color saturation punch, each with its own masks, if appropriate. PixInsight will allow us to do this sequentially, one step at a time, one result at a time, on top of the previous one. That's all we can do because that's all PixInsight allows and for many, that's all they know: a sequential, cumulative workflow that exists since the days of MS Paint. Now, when Juan started developing "layers" for PixInsight, he went for a very simple format, for starters at least: a pile of images that can be combined via a PixelMath-like expression. You call that "layers". I call it an image blending tool. Nothing special, rather boring actually, but a start (in this case, it was also the end).

Now, picture being able to control all these 4 processes simultaneously. We've defined them all, but now, we can go back to the deconvolution and see what would happen to our final image if we changed it a bit, or perfected the mask,maybe. Now, after we modify our deconvolution, we can see the results not just after the new decon but after the non-linear stretch we had done before, after the noise reduction and after the saturation! So we decide to maybe tone down the noise reduction now, or readjust our nonlinear stretch... Swap the order of noise reduction and saturation... Have the tool suggest the "best" order depending on a predefined goal... We're seeing the results from any and all of this, all at once.

Some might say this is not how astroimages should be processed, and that a strict sequential workflow is mandatory, to which I would respectfully roll my eyes and yawn, seriously... Some may say we could somewhat mimic this behavior with the tools we already have. That's possible, but the workflow and way to interact is radically different. No need to duplicate images, duplicate and manipulate image histories, saving process icons, auxiliary images, etc... This would be a completely different, much cleaner experience (you were talking about cluttering, which is ironic, since the sequential/accumulative workflow we have today in PixInsight combined with the object-oriented UI is what leads to us ending up with our PixInsight workspace full of "stuff" - we're used to it, that's all, it doesn't make it "best"). Here we'd be interacting with multiple processes simultaneously, which would also help us learn how processes affect each other's results and a whole lot more, in a much less cluttered environment. You may say these tools are just for "artistic enhancement", but what I see is a methodology that can increase our astroimage processing potential, productivity and more in many ways. Stark contrast of opinions, indeed.

Now... What I just described still follows a basic parallel workflow (similar to "adjustment layers" if you know what they are) rather than a true object oriented workflow, but I won't develop this any further, the post is getting too long as it is. Plus I'm not sure though, how far I personally could take this programmatically, anyway (this isn't easy, unlike making a program like PixInsight being i18n/l10n ready 😉). For now I have no plans to start something like this from scratch. Maybe some other year, maybe someone else...

So, when you all hear "layers" and think about a lame attempt to copy an old feature out of some popular software from a San Jose, CA company that cannot be mentioned here, and then you immediately think about brushes and other irrelevant "artistic" tools, forgive me for rolling my eyes once again. But like I said, Juan has made his mind and that's that. I know the current methodology works. I just wrote a 700 page book about it!! I'd love to write another one using the above techniques and more, but we already know that's not where PixInsight would be headed any time soon, if it ever does.

I'll write about localization some other day - this was way too long (too busy, didn't have time to shorten it 😅 )
Cheers!
RBA
 
Last edited:

RBA

Well-known member
Feb 18, 2009
544
20
California, USA
deepskycolors.com
Is it possible to have the "Layers" tool as a script file, then users can decide for themselves....
Indeed, anyone is free to develop anything they want. That has never been an issue. Originally I asked Juan to share the code he already had developed so as to speed up getting started, but again, his answer was pretty clear that he has no interest in sharing it or in helping, supporting or promoting its development - in other words "if you want it, you code it", and so there was nothing left to discuss since, again, anyone can code whatever they want from scratch.

However, on my second, long post I was responding to how some people understand layers (an image blending tool and nothing more) and how limited that vision can be. Since I don't have the time or will to start something like this from scratch now, maybe someone reads it and decides to give it a try, so I didn't post it just to share my thoughts.... That said, a script wouldn't work for developing a project this ambitious. A compiled module using the PCL would be the way to do it, no doubt.

Cheers!
RBA
 
  • Like
Reactions: John_Gill

Juan Conejero

PixInsight Staff
Sep 2, 2004
8,156
344
57
Valencia, Spain
pixinsight.com
With the due respect, what you are describing makes no sense in my opinion, beyond a possibly different way to combine a set of images, which is something that we already have.

Deconvolution is not a tunable process in the sense that you cannot 'decide' to deconvolve more here and less there, or when to deconvolve, for pictorial or aesthetic reasons. It requires you to first decide whether or not to apply deconvolution, after a realistic evaluation of the signal and noise present in your data (the answer to this question is 'no' in most cases). Then you must provide an accurate estimate of the point spread function, which is a purely objective image analysis task. Then you have to select the appropriate algorithm, define deringing parameters to protect singularities (mainly jump discontinuities, such as stars), and define regularization parameters to control noise amplification on low-signal regions. There is nothing at all artistic in deconvolution: it is a well defined mathematical process where you have to optimize a set of parameters to achieve the expected outcome, which you must evaluate and approve correctly using several qualitative and quantitative criteria and tools, based on your knowledge and experience. You cannot decide when to apply deconvolution in your workflow, or 'move' the deconvolved result across a stack of 'layers' either: it only makes sense if you apply it to the integrated linear image, which is the very starting point of your final image. Mixing the deconvolved result with the non-deconvolved image, e.g. through a mask, does not make any sense either, except perhaps to protect low-signal regions, but in such case the mask has to be built based on the signal and noise in the image, which is an objective task. Deconvolution is not at all a sharpening tool.

The initial delinearization process is also a critical step where you decide the brightness and contrast of the image that is going to be the starting point of your nonlinear processing. Again, this is an important task where you make decisions based mainly on your knowledge and experience, after analyzing the data. You can of course fine tune brightness and contrast at several stages of your nonlinear processing, especially when you are close to your final image, usually applying subtle variations. The initial delinearization must be correct and you must be able to evaluate it objectively. It cannot be moved across a stack of layers for the same obvious reason as deconvolution: it only makes sense when the image is linear. It does not make sense to change it significantly as an isolated step either, since it is not an isolated step: the rest of your nonlinear processing is going to be strongly conditioned by how you have made your data nonlinear at the beginning.

Noise reduction is a wide and complex topic. You can apply noise reduction to linear and nonlinear data using a variety of tools and techniques, and how and when you apply them depends on the characteristics of your data. As happens with most nontrivial image processing tasks, noise reduction must be guided by thorough qualitative and quantitative analyses that you must be able to perform efficiently and objectively, and this requires work, knowledge and experience. Moving a denoising task across a stack of layers might be possible in some cases, but does not make too much sense on a general basis for the same reason as delinearization: noise reduction significantly influences all subsequent image processing tasks.

Since any nontrivial image processing task in a processing sequence changes the input data for all subsequent tasks, you cannot blindly change one of these tasks as an isolated step. If you change a process in the middle of an existing sequence, it will change the behavior of all subsequent processes, which usually requires a new analysis and evaluation of the data to follow a different path to the final image. Image processing cannot be modelled by a linear structure such as a linked list, as you are proposing, where you can change a node of the list arbitrarily and wait naively until the last node reflects the changes in some way. Significant image processing should be modelled by a nonlinear structure more resemblant to a tree, or to a forest if we consider the masks involved, or perhaps more like a graph. At each branch of a tree, one must have full control on the data in its current state, as well as on the parameters of each process that is going to generate a new bifurcation. PixInsight has been designed and built on the basis of these structural and conceptual paradigms. PixInsight has not been designed and conceived as a set of macroscopic black boxes, but just on the contrary, to provide you with full control on each single step at a microscopic level.

Besides these technical and design considerations based on the nature of image processing algorithms and procedures, your description does not take into account some important practical aspects that must always be evaluated carefully before starting a new development line. One of them is quite obvious: computational complexity. To work in a minimally coherent way, what you are proposing requires the complete recalculation of all individual processes in the processing history of an image after the process that you are modifying. Obviating the fact that some of these processes would be invalid because their input data would be modified, hence requiring a new analysis and parametrization as noted above, this may require long execution times that pose a serious problem for an interactive or 'real-time' tool such as the layers process that you are proposing, even with contemporary hardware.

Another important practical aspect that you are not taking into account is duplication of existing resources. We already have ProcessContainer, which allows you to change individual processes and their masks very easily. If you want to use an existing ProcessContainer instance blindly, you can already do so by executing it at the appropriate point of the processing history of an image. We also have PixelMath (an open-source tool by the way), which allows you to combine different images efficiently with great control, power and flexibility. I see no added value in what you are proposing with respect to the already existing resources.

You mention a 'cluttered environment' as a consequence of PixInsight's object-oriented design and our existing tools. In my opinion—and I have created PixInsight, so maybe my opinion can be somewhat well-founded—, if your workspace becomes cluttered that's mainly because your processing strategies are not well designed and implemented. I can show you projects with huge data sets and extremely complex processing works where the multiple workspaces being used are perfectly organized, clean and well structured, where every icon and image has a meaningful identifier and is documented. So your argument about cleanliness is not at all well justified.

Above all of these technical and practical considerations, the main problem that I see in your description is conceptual. You conceive image processing as something that should be simplified, or even avoided with the help of black boxes to make things 'cleaner'. We conceive image processing as an expressive means that is at the heart of astrophotography as a unique blend of science and art. For us, image processing must be as rich and complex as possible precisely because it is what gives us the freedom necessary to develop our knowledge and creativity.